Veröffentlicht am 8. Januar 2015 von Nicola Rizhikov
Die Stadtregierung von Sankt Petersburg hat ein Projekt gestartet, dessen Ziel die Schaffung eines einheitlichen Integrationsbusses für den Austausch von Laboraufträgen und -ergebnissen für staatliche Ambulanzen, Krankenhäuser und Labore ist.
Es werden zahlreiche Ziele angestrebt: papierlose Auftragserteilung, schneller Zugang zu Ergebnissen für Ärztinnen, Ärzte und Patientinnen und Patienten, Ressourcenplanung und -optimierung sowie Informationen für Analysen und Data Mining durch staatliche Gesundheitsorganisationen.
Die erste Iteration bestand darin, die aktuellen Prozesse zu analysieren und einen funktionsfähigen Prototypen zu erstellen. Diese Iteration wurde durch die Entwicklung einer benutzerdefinierten SOAP-API und die Integration einiger Organisationen aus der Fokusgruppe abgeschlossen.
Am Ende des Pilotprojekts wurde deutlich, dass ein internationaler Standard als Grundlage verwendet werden sollte. Wir wurden gebeten, bei der Auswahl zwischen den Standards zu helfen (wir verfügen über Erfahrung in der Integration, allerdings im US-amerikanischen Umfeld).
Wir haben HL7 v2, HL7 v3 & FHIR betrachtet und diese mit einer benutzerdefinierten API verglichen.
HL7 v2
Auf den ersten Blick wirkt HL7 v2 wie der beste Kandidat. Für die Vereinigten Staaten mag das zutreffen, da dort bereits zahlreiche Systeme (HIS, EHR, LIS) im Einsatz sind, die HL7-v2-Nachrichten austauschen. Das Bild in Russland ist jedoch ein anderes: Die meisten Laborinformationssysteme sind individuell entwickelt und verwenden HL7 v2 nicht. Das Hauptargument für HL7 v2 ist daher nicht stichhaltig, während alle ursprünglichen Schwächen von v2 zum Tragen kommen.
Das HL7-v2-Protokoll wurde ad hoc weiterentwickelt, weshalb ein veraltetes Nachrichtenformat, keine integrierte Erweiterbarkeit, kein maschinenlesbares Profiling/keine Constraints und keine Zukunftsperspektive vorhanden sind (der Standard befindet sich lediglich in der Support- und nicht mehr in der Entwicklungsphase).
Das veraltete Nachrichtenformat erfordert die Implementierung aufwändiger Parser und Builder nahezu von Grund auf. Nur Java- und .Net-Entwicklerinnen und -Entwickler können die Bibliotheken HAPI und nHAPI wiederverwenden, während andere verbreitete Plattformen (node.js, erlang, php, python, ruby usw.) über keine komfortablen und robusten Bibliotheken verfügen.
Das Fehlen von Erweiterbarkeit und Profiling/Constraints könnte durch einen Ansatz wie LRI behoben werden. Mindestens die Hälfte von LRI besteht jedoch lediglich aus Korrekturen und Patches für HL7-v2-Fehler, ohne einen echten Mehrwert zu bieten.
Zusammenfassend: HL7 v2 erfordert einen erheblichen sinnlosen Aufwand, um einen veralteten Standard einzuführen.
HL7 v3 & CDA
Ein weiterer Kandidat ist HL7 v3 & CDA. Es gibt zwei Pro-Argumente: Einige HL7-v3-Standards sind in Russland inzwischen normativ, und die HL7-Arbeitsgruppe hat 2013 ein DSTU für Laboraufträge und -ergebnisse veröffentlicht.
HL7 v3 verfügt über ein solides theoretisches Fundament und ist für echte semantische Interoperabilität ausgelegt, weist jedoch eine wichtige Schwäche auf – die Implementierbarkeit. Dies zeigt sich allein daran, dass bis heute keine guten Implementierungsbibliotheken existieren. Zudem ist die Einarbeitungskurve steil und der Standard für Implementierende komplex. HL7 v3 ist kein einzelner Standard, sondern ein umfangreicher Stapel von Standards, sodass selbst die Lokalisierung dieses Standards zeitaufwändig erscheint.
Das Projekt hat eine Deadline von etwa 6 Monaten, und es erscheint nicht realistisch, HL7 v3 & CDA für den Start zu verwenden. Die gesamte Zeit würde für die Schulung der Entwicklerinnen und Entwickler aufgewendet werden.
FHIR
Die nächste Option ist FHIR. Hierbei handelt es sich um einen modernen Standard für schnelle Interoperabilität. Der Standard ist darauf ausgelegt, die richtige Balance zwischen den Anforderungen des semantischen Austauschs von Gesundheitsinformationen und der Implementierungskomplexität zu finden.
Er verfügt über integrierte Erweiterbarkeit und Profiling sowie einen guten Werkzeugkasten an Bibliotheken und Diensten. FHIR ermöglicht es, nur den erforderlichen Teil des Standards zu implementieren, was den Projektstart erheblich vereinfachen und die schrittweise Hinzufügung neuer Funktionen ermöglichen kann.
Wir haben die in der ersten Iteration entwickelte benutzerdefinierte API mit der FHIR-API verglichen und eine nahezu perfekte Übereinstimmung festgestellt. Um FHIR-konform zu sein, müsste die aktuelle API nur wenige Ressourcen neu implementieren: Organization, Practitioner, Patient, Encounter, DiagnosticOrder, DiagnosticReport & Observation. Erforderliche Geschäftsregeln könnten als FHIR-Erweiterungen ausgedrückt werden. Labor-, Krankenhaus- und Ambulanzsysteme könnten über eine REST-API mit dem Bus kommunizieren, wobei eine verfügbare Referenzimplementierung und Client-Bibliotheken genutzt werden. Öffentliche FHIR-Dienste könnten als Sandboxes für die Entwicklung genutzt werden. Health Samurai hat mit Unterstützung von HL7 Russia bereits den Großteil der FHIR-Dokumentation lokalisiert.
Selbstverständlich gibt es noch viele kleine technische Fragen, aber wir müssen sagen, dass FHIR den Anforderungen und Bedürfnissen dieses Projekts perfekt entspricht.
Wir hoffen, dass die Verantwortlichen und Entscheidungsträgerinnen und Entscheidungsträger die richtige Wahl mit FHIR treffen und ihre Ziele erreichen werden.
Beginnen Sie mit dem Aidbox FHIR Server für Datenspeicherung, Integrationen, Healthcare-Analysen und mehr, oder beauftragen Sie unser Team, um Ihre Softwareentwicklungsanforderungen zu unterstützen.
Siehe auch: Integration von Legacy-Systemen meistern und FHIR zur Vereinfachung der Healthcare-Entwicklung einsetzen.
