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