Haben Sie Niederlassungen oder Kliniken auf der ganzen Welt und möchten statistische Daten in einem zentralen Speicher zusammenführen? Möchten Sie außerdem zu 100 % sicher sein, dass Ihr System HIPAA-konform ist und lokale Regulierungsvorschriften (wie die DSGVO) einhält? Oder haben Sie mehrere Niederlassungen in den USA und möchten ein medizinisches Data Warehouse implementieren, um die Leistung auf lokaler Ebene zu verbessern? All dies lässt sich durch die Synchronisierung medizinischer Datenspeicher erreichen. In diesem Artikel möchte ich Ihnen von unseren Erfahrungen bei der Implementierung einer HIPAA-konformen Datensynchronisierung über mehrere Aidbox-Instanzen berichten.
Die Datensynchronisierung zwischen mehreren Systemen ist nichts Neues. Sie wird in verteilten Systemen mit mehreren Datenspeichern eingesetzt, in der Regel um die Integration mit mehreren Systemen zu ermöglichen oder die Performance zu steigern. Im Gesundheitswesen ist dieser Prozess zusätzlich mit dem Schutz von PHI verbunden. Beispielsweise dürfen persönliche Patientendaten nicht an Speicherorte übermittelt werden, die sich in anderen Ländern befinden.
Das WaveAccess-Team hat in Zusammenarbeit mit Health Samurai eine Erweiterungslösung für Aidbox für einen US-amerikanischen Kunden mit Kliniken in mehreren Ländern entwickelt. Diese Erweiterung unterstützt die HIPAA-konforme Datensynchronisierung zwischen mehreren lokalen Aidbox-Instanzen und einem globalen Aidbox. Ein weiterer wesentlicher Bestandteil dieses Dienstes ist das Datenanonymisierungsmodul, das PHI schützt, indem es alle Patientenidentifikatoren aus den Daten entfernt, bevor diese an eine andere Aidbox-Instanz übermittelt werden.
Betrachten wir nun unsere praktischen Erfahrungen bei der Implementierung dieser Lösung. Wir gehen dabei auf unsere spezifischen technischen Herausforderungen ein und erläutern genau, wie wir diese Probleme gelöst haben.
Dieser Artikel richtet sich an CTOs, technische Manager, Projektmanager, Teamleiter und andere technische Fachkräfte, die für die Übertragung von Daten zwischen mehreren FHIR-Servern verantwortlich sind.
Lesen Sie weiter und erfahren Sie mehr über:
- Beschreibung des Anwendungsfalls
- HIPAA-Konformität
- Herausforderungen bei der Synchronisierung
- Struktur und Ablauf des Synchronisierungsmoduls
1. Beschreibung des Anwendungsfalls
Der Kunde betreibt eine Kliniikkette in mehreren Ländern mit Hauptsitz in den USA. Es gibt mehrere lokale Anwendungen für medizinisches Fachpersonal, die Aidbox-Instanzen als medizischen Datenspeicher verwenden, sowie eine globale Anwendung für administrative Zwecke mit einem eigenen Aidbox. Das globale Aidbox soll medizinische Informationen von der lokalen Ebene für Statistiken, Management usw. enthalten. Umgekehrt sollen die lokalen Aidboxes konsistente Informationen über die Organisationsstruktur und Geopositionsdaten aus dem globalen Aidbox erhalten. Das bedeutet, dass lokale Aidboxes bestimmte anonymisierte Informationen über Patienten, Termine, Beobachtungen, Diagnosen und andere verknüpfte Entitäten an das globale Aidbox senden und im Gegenzug spezifische Informationen zu ihrem jeweiligen Standort erhalten sollen (z. B. eine Liste verfügbarer Länder, Bundesstaaten, Organisationen usw.).
Um den Datenaustauschprozess zu implementieren, mussten wir ein Synchronisierungsmodul entwickeln, das eine beidseitige Synchronisierung mit der Möglichkeit zur Anonymisierung von Patienten-PHI konfigurieren und durchführen kann.
Die übergeordnete Architektur sieht folgendermaßen aus:
Die lokalen Aidboxes erfassen die Daten aus den lokalen Anwendungen. Die Synchronisierungsdienste empfangen diese Daten, anonymisieren sie und übertragen sie an das globale Aidbox. Diese Dienste verwalten auch den Prozess der Datenübermittlung vom globalen Aidbox auf die lokale Ebene.
Dieser Ansatz trägt zum Schutz des Patienten-PHI bei. Da die Synchronisierungsdienste lokal gespeichert sind, werden die sensiblen Informationen ebenfalls lokal verarbeitet. Nachdem die Anonymisierung durch diese Dienste abgeschlossen ist, können die medizinischen Daten sicher an das globale Aidbox übertragen werden.
2. HIPAA-Konformität
Der Health Insurance Portability and Accountability Act von 1996 (HIPAA) ist ein Bundesgesetz, das die Schaffung nationaler Standards zum Schutz sensibler Gesundheitsdaten von Patienten vor unbefugter Weitergabe ohne Einwilligung oder Wissen des Patienten vorschreibt. Diese sensiblen Patientendaten werden als geschützte Gesundheitsinformationen (Protected Health Information, PHI) bezeichnet und umfassen demografische Daten sowie Daten, die Einzelpersonen identifizieren, darunter Name, Adresse, Geburtsdatum und Sozialversicherungsnummer.
Wie können Organisationen medizinische Daten von Patienten übertragen, erfassen und verarbeiten? Gemäß der HIPAA Privacy Rule bestehen keine Einschränkungen bei der Verwendung oder Offenlegung von de-identifizierten (anonymisierten) Gesundheitsinformationen. Der einfachste Weg zur De-Identifizierung von Daten besteht darin, alle festgelegten Identifikatoren und andere Informationen zu entfernen, die zur Identifizierung eines Patienten verwendet werden könnten.
Das bedeutet, dass eine HIPAA-konforme Lösung über eine Anonymisierungsfunktion verfügen muss, die alle Patientenidentifikatoren aus den medizinischen Daten entfernt, bevor diese an andere Speicherorte übertragen werden.
Wenn Sie mehr über HIPAA erfahren möchten, finden Sie detailliertere Informationen auf der Website des U.S. Department of Health & Human Services oder lesen Sie unseren Artikel Aidbox HIPAA-Buch / Teil 1 / Technische Schutzmaßnahmen.
3. Aidbox-Synchronisierungsmodul
Betrachten wir nun unsere Lösung. Gemäß den Anforderungen soll der Synchronisierungsdienst über folgende Funktionen verfügen:
- Beidseitige Synchronisierung zwischen lokalen und globalem Aidboxes
- HIPAA-konforme Datenanonymisierung
- Konfiguration der Synchronisierung
3.1 Allgemeine Struktur
Im häufigsten Fall sieht die Architektur des Synchronisierungsmoduls wie das folgende Diagramm aus:
Das Modul empfängt Daten von einem lokalen Aidbox, anonymisiert sie und sendet sie an das globale Aidbox. Während des Entwicklungsprozesses standen wir vor folgenden Herausforderungen:
- Wie können wir erkennen, welche Daten in einem lokalen Aidbox geändert wurden und daher an das globale Aidbox gesendet werden sollen?
- Wie können wir sicherstellen, dass nur vordefinierte Aidbox-Instanzen eine Synchronisierung mit dem globalen Aidbox durchführen können?
- Wie soll die Datenanonymisierung implementiert werden?
Gehen wir diese Herausforderungen durch.
3.2 Verfolgung von Datenänderungen
Die Aufgabe der Datensynchronisierung lässt sich nicht lösen, ohne zu ermitteln, welche Entitäten seit der letzten Synchronisierungsiteration geändert wurden. Aidbox stellt einen Mechanismus zur Verfolgung von Ressourcenänderungen bereit, die sogenannte Aidboxes Changes API. Anstelle von Export-/Importvorgängen für Entitäten oder Massenoperationen verwendet die Changes API einen Mechanismus, der auf Iterationen verschiedener Versionen basiert und eine zusätzliche Prozesstransparenz bietet. Dies ist im Falle von Notfällen, die während des Synchronisierungsprozesses auftreten können, sehr hilfreich.
Wir haben außerdem eine benutzerdefinierte Ressource namens ChangesInfo erstellt, die einen Entitätsnamen und eine Versionsnummer enthält. Während des Synchronisierungsprozesses rufen wir diese Ressource für jeden der zu synchronisierenden FHIR-Ressourcentypen ab, ermitteln deren Version und rufen den $changes-Endpunkt auf. Wenn seit der letzten Synchronisierungsiteration Entitäten geändert wurden, gibt der Endpunkt die Liste dieser Entitäten zurück. Schließlich erstellen wir eine Aidbox-Transaktion mit einer PUT-, POST- oder DELETE-Operation für jede der geänderten Entitäten.
3.3 Synchronisierungssteuerung
Der Synchronisierungsprozess soll sicher und kontrollierbar sein. Aus diesem Grund haben wir eine weitere benutzerdefinierte Ressource, AidboxInstance, definiert, die dem globalen Aidbox hinzugefügt wurde. Sie hilft dabei, den Zugriff lokaler Aidboxes auf das globale Aidbox zur Durchführung der Synchronisierung zu beschränken. Bei jeder Iteration des Hintergrundprozesses prüfen wir die AidboxInstance-Entität für das lokale Aidbox, um sicherzustellen, dass sie in der Datenbank des globalen Aidbox vorhanden ist und synchronisiert werden soll.
3.4 Datenanonymisierung
Datenanonymisierung ist der Prozess des Schutzes privater oder sensibler Informationen durch Löschen oder Verschlüsseln von Identifikatoren, die eine Person mit gespeicherten Daten verknüpfen. In unserem Fall sind die sensiblen Informationen, die anonymisiert werden müssen, die Attribute identifier, name, telecom und address der Patient-FHIR-Ressource, die benutzerdefinierten Attribute patientFirstName, patientLastName und patientMiddleName in der QuestionnaireResponse-FHIR-Ressource sowie das Attribut answer einiger QuestionnaireResponse-FHIR-Ressourcen, die mit Fragen wie „Persönliche E-Mail", „Name", „Telefon", „Geburtsdatum" und „Adresse" verknüpft sind.
Wenn die Daten das Synchronisierungsmodul verlassen, werden diese Attribute geleert. Es versteht sich von selbst, dass die Menge der zu leerenden FHIR-Entitäten und Attribute in der Anwendung konfiguriert werden kann.
3.5 Synchronisierungsablauf
Der Prozess der Datensynchronisierung wird in den folgenden zwei Diagrammen dargestellt. Das erste veranschaulicht den Prozess der Datenübermittlung von den lokalen Aidboxes zum globalen. Das zweite zeigt den umgekehrten Prozess.
Der erste Schritt bei der Übertragung von Daten vom lokalen Aidbox zum globalen besteht darin, alle Datenänderungen mithilfe der Aidbox Changes API zu identifizieren. Anschließend werden die Daten vom Anonymisierungsmodul verarbeitet, um alle PHI-Attribute zu entfernen. Schließlich werden die Daten in das globale Aidbox übertragen.
Der Prozess der Datenübertragung vom globalen Aidbox zum lokalen ist identisch, mit Ausnahme des Anonymisierungsschritts. Die Daten, die von der globalen Ebene übertragen werden, sind eher administrativer Natur und enthalten keine Informationen über Patienten. Diese Art von medizinischen Daten fällt nicht unter HIPAA und kann ohne Einschränkungen übertragen werden.
3.6 Zusammenfassung
Das Synchronisierungsmodul ist ein isolierter Dienst, der im Hintergrund läuft und die Synchronisierung zwischen den definierten lokalen Aidbox-Entitäten und der globalen Aidbox-Entität gewährleistet. Es verfügt außerdem über eine API zur manuellen Synchronisierung einzelner Entitätstypen.
Abschließend möchte ich die Vorteile dieser Lösung auflisten:
- Einfache Wartung. Basierend auf der Changes API liefert der Dienst Informationen über jeden Schritt des Synchronisierungsprozesses für jede Entität, was die Fehlersuche erheblich erleichtert.
- Hohe Anpassbarkeit. Wir können beliebige weitere Zwischenschritte hinzufügen, wie wir es beim Anonymisierungsprozess getan haben. Dies kann sich auf die Endleistung auswirken, aber wir setzen Multithreading und Parallelismus ein, um diese zusätzlichen Kosten zu reduzieren.
- Sicherheitsgarantie. Wir haben den Synchronisierungszugriff für jede lokale Aidbox-Instanz festgelegt. Das bedeutet, dass nur bestimmte Aidboxes eine Synchronisierung mit der globalen Instanz durchführen können.
- HIPAA-Konformität. Das globale Aidbox empfängt und speichert ausschließlich de-identifizierte Gesundheitsinformationen. Das Anonymisierungsmodul entfernt alle Identifikatoren und sonstige sensible Informationen aus den Daten, was deren sichere Übertragung gewährleistet.
Um die HIPAA-konforme Synchronisierung in Ihren Systemen zu erkunden, empfiehlt sich die Verwendung der kostenlosen Version von Aidbox. Sie bietet eine sichere Umgebung zum Testen und Entwickeln von Synchronisierungsprozessen und stellt alle erforderlichen Werkzeuge ohne Funktionseinschränkungen bereit.
4. Fazit
In diesem Artikel haben wir unsere Erfahrungen bei der Implementierung eines Moduls für den HIPAA-konformen Aidbox-Synchronisierungsprozess geteilt. Die Synchronisierung mehrerer medizinischer Datenspeicherumgebungen ist für verteilte oder globale Gesundheitsinformationssysteme von enormer Bedeutung. Ein gut konfigurierter Synchronisierungsprozess ermöglicht es medizinischen Organisationen, statistische Daten effizient zu erfassen, die für medizinische oder Management-Forschung genutzt werden können, oder die Performance zu verbessern, indem Data Warehouses in die Systemarchitektur integriert werden. Unabhängig von Ihrem Ziel sollten Sie den Schutz der Patienten-PHI und die Datenanonymisierung nicht außer Acht lassen.
Wenn Sie Niederlassungen in verschiedenen Ländern haben, ein medizinisches Data Warehouse integrieren möchten oder einfach Fragen haben, kontaktieren Sie uns gerne. Wir und das Health Samurai-Team helfen Ihnen gerne weiter.
Autor:
Paul Chayka,
Healthcare Solution Expert | Project Manager und Team Leader bei WaveAccess
Siehe auch: Verwaltung von Mehrklininikdaten mit OrgBAC.
