Zurück zu Allen Fallstudien
healthcareVoller Zugang freigeschaltet

Ein Bestellformular für Patientenbedarf, das einer Sicherheitsprüfung Standhält

Klinisches Personal bestellt Gerätebedarf für namentlich genannte Patienten. Damit wird ein gewöhnliches Webformular zum Patientendatensystem — DSGVO-pflichtig und Gegenstand einer Sicherheitsprüfung, an der die meisten solcher Formulare scheitern.

Globaler Medizintechnik-Hersteller · Patientenversorgung EMEA

healthcare
3
supply Lines
GDPR
patient Data
0
passwords

!Der Bedarf

Verbrauchsmaterial für ein implantiertes oder getragenes Medizinprodukt zu bestellen ist kein Warenkorb. Jede Position ist eine Katalognummer, die an eine bestimmte Therapie gebunden ist — das Gerät selbst, seine Reservoirs, seine Sensoren — und jede Bestellung nennt einen Patienten, sein Geburtsdatum, sein Schulungsdatum und, wenn die Therapie endet, den Abbruchgrund. Diese Nutzlast sind Gesundheitsdaten einer identifizierten Person, fallen also in jedem bedienten EMEA-Markt unter die DSGVO und müssen die Sicherheitsprüfung des Herstellers bestehen, bevor sie in die Nähe der Produktion kommen. Der ursprüngliche Bau authentifizierte gegen die Konzern-Identitätsplattform, wodurch jede Umgebungsfreigabe ein Ticket in einem wochenlangen internen Prozess war.

Der Ansatz

Wir haben die Bestellung um Katalognummern statt Freitext modelliert: Die drei Bedarfslinien — Gerät, Reservoirs, Sensoren — tragen je eigene Teilenummer und Menge und lassen sich nicht in etwas Nichtexistentes vertippen. Patientenidentität, Geburtsdatum, Schulungsdatum und Therapieendgrund werden auf Schemaebene validiert; der Abbruchgrund bietet eine definierte Auswahl plus Freitext, damit reale klinische Situationen nicht in die falsche Schublade gezwungen werden. Das Formular ist mehrsprachig, denn EMEA ist kein einzelner Markt. Jede Übermittlung rendert ein PDF, das die Fachkraft vor dem Versand prüfen kann, dazu eine Zusammenfassungsansicht; die fertige Bestellung wird per E-Mail zugestellt, statt in einer Datenbank auf Entdeckung zu warten. Anschließend haben wir die Abhängigkeit von der Konzern-Identität durch Magic-Link-Authentifizierung ersetzt: kein Passwort wird erzeugt, gespeichert oder übertragen — und ein Firmen-Mailgateway, das Links vorab abruft (der Scanner öffnet die Mail vor dem Menschen), wurde ausdrücklich behandelt statt in der Produktion entdeckt.

Verwendete Technologien

Next.jsTypeScriptSupabasePasswordless magic-link authZodPDF generation

Das Ergebnis

Drei Bedarfslinien nach Katalognummer und Menge bestellt — Gerät, Reservoirs und Sensoren — statt per Freitextbeschreibung
Patientenname, Geburtsdatum, Schulungsdatum und Therapieendgrund auf Schemaebene validiert
Eine definierte Auswahl an Abbruchgründen plus Freitext, damit reale klinische Fälle nicht auf die nächstbeste Option gezwungen werden
Ein mehrsprachiges Formular, denn EMEA sind mehrere Märkte und nicht einer
Ein PDF je Übermittlung zur Prüfung durch die Fachkraft, dazu eine Zusammenfassung, bevor etwas rausgeht
Fertige Bestellungen per E-Mail zugestellt, statt in einer Datenbank auf Entdeckung zu warten
Passwortlose Magic-Link-Authentifizierung, mit ausdrücklicher Behandlung von Firmen-Mailgateways, die Links vorab abrufen

Die Wirkung

Patientendaten sind konstruktionsbedingt minimiert: Das Formular erhebt, was die Bestellung wirklich braucht, und sonst nichts
Nirgends im Ablauf wird ein Passwort erzeugt, gespeichert oder übertragen — die stärkste Zugangsdatei ist die, die es nicht gibt
Ein Teilenummern-Modell sorgt dafür, dass eine Bestellung keinen Artikel beschreiben kann, den der Katalog nicht führt
Die Fachkraft sieht das PDF vor dem Absenden, sodass ein Fehler von der Person auffällt, die den Patienten kennt
Der Wegfall der Konzern-Identitätsabhängigkeit nahm die Umgebungsfreigabe aus einer wochenlangen internen Ticket-Warteschlange
Die Sicherheitsprüfung bekommt eine konkrete, überprüfbare Darstellung statt einer allgemeinen Zusicherung

Bereit für ähnliche Ergebnisse?

Kontaktieren Sie uns
Supalabs AI solutions