Gesundheitsorganisationen stehen bei der Entwicklung von Lösungen vor zahlreichen Entscheidungen in Bezug auf Interoperabilität, Technologie-Stacks, HIPAA-Compliance, Integration und Datenverwaltung. Veränderungen in der Gesundheitsinformationstechnologie müssen berücksichtigt werden, um sicherzustellen, dass Produkte zukunftssicher sind, und Lösungen müssen interoperabel sein, um den Übergang zur wertbasierten Versorgung zu unterstützen. FHIR ist ein offener Standard, der in der Branche breite Anerkennung und Unterstützung für sein Potenzial erlangt hat, Interoperabilität im Gesundheitswesen Wirklichkeit werden zu lassen. FHIR ist gut dokumentiert, leicht erlernbar und wird von einer engagierten, wachsenden Community von Health-IT-Experten unterstützt – alle Zeichen deuten darauf hin, dass dieser Standard von Dauer ist. FHIR schränkt Ihre Entwicklungspraktiken in keiner Weise ein und bietet zahlreiche Vorteile für das Datenmanagement und die Interoperabilität. Dieser Blogbeitrag erläutert, warum Organisationen FHIR einsetzen sollten und wie ein FHIR-Backend den Entwicklungsprozess vereinfacht und Interoperabilität ermöglicht.
Warum FHIR für Gesundheits-Apps wählen?
Bei der Entwicklung von Lösungen für das Gesundheitswesen trifft ein Unternehmen viele Entscheidungen: Technologie-Stacks, Entwicklungsplattformen, HIPAA-konforme Hosting-Anbieter, EHR-Integrationswege, Standards und Terminologien. Einige dieser Entscheidungen wirken sich nicht unmittelbar auf das Ergebnis aus, können aber langfristig erhebliche Folgen haben.
Zwei Lösungen können die aktuellen Geschäftsanforderungen gleichermaßen erfüllen, ihre weitere Entwicklung kann jedoch sehr unterschiedlich verlaufen. Eine Lösung wird schnell veralten, während die andere über Jahre hinweg gedeiht. Um Entscheidungen zu treffen, die Ihrer Lösung einen langen Lebenszyklus sichern, muss ein Unternehmen verstehen, was in den kommenden Jahren mit der Gesundheitsinformationstechnologie geschehen wird.
Das Management der Bevölkerungsgesundheit in einem wertbasierten System ist für jede Gesundheitsorganisation eine Herausforderung. Keine einzelne digitale Gesundheitslösung kann diese Herausforderung allein bewältigen, und der Bedarf an einem Ökosystem vernetzter, interoperabler Gesundheitsanwendungen wächst stetig.
Ein solches Ökosystem war vor einigen Jahren kaum vorstellbar, da es an einem von der Branche anerkannten Interoperabilitätsstandard fehlte. Heutzutage gibt es einen klaren Gewinner unter den Standards – Fast Healthcare Interoperability Resources (FHIR) – und viele Anbieter sowie Leistungserbringer-Organisationen haben bereits ihre Reise in die neue Welt digitaler Gesundheitsplattformen, offener APIs und Anwendungsmarktplätze begonnen.
Die Wahl von FHIR für Ihr nächstes Gesundheitsprojekt könnte die wichtigste Entscheidung sein, um Ihre Lösung zukunftssicher zu machen und für das Gesundheitsinformationsökosystem der nächsten Generation zu rüsten, in dem Daten nahtlos zwischen EHRs, patientenseitigen mobilen Apps und medizinischen Geräten fließen.
Wie ein FHIR-Backend die Entwicklung verändert
Wenn Sie Ihre Lösung auf Basis eines FHIR-Backends entwickeln, bleibt vieles gleich. Die Arbeit mit einem FHIR-Backend verändert Ihren Entwicklungsprozess nicht. Sie müssen weiterhin eine Projektentdeckungsphase durchlaufen, eine Projektvision und einen anfänglichen Scope formulieren. Sie können weiterhin Ihre bevorzugten agilen Methoden, testgetriebene Entwicklung, DevOps und Continuous Integration einsetzen. FHIR wird Ihnen durch keinerlei Prozesseinschränkungen im Weg stehen.
Die Verwendung eines FHIR-Backends beeinflusst auch die Wahl Ihres Technologie-Stacks nicht. Ob Sie Java, Ruby, .NET, Swift oder Clojure bevorzugen – Sie werden Open-Source-Bibliotheken finden, die Ihre bevorzugte Technologie unterstützen. Sie werden moderne Web-Technologien wie REST-APIs für die Arbeit mit Ihrem Backend einsetzen, aber FHIR wird Sie nicht daran hindern, Ihren bevorzugten Tech-Stack weiter zu verwenden.
Der Moment, in dem Sie beginnen, mit Daten zu arbeiten, markiert den ersten wesentlichen Unterschied. Wenn Sie Ihre Lösung von Grund auf entwickeln, müssen Sie Datenmodelle und -strukturen zur Speicherung Ihrer Daten entwerfen. Mit FHIR hingegen müssen Sie lediglich die richtige Entsprechung für Ihre Daten in den offenen FHIR-Datenmodellen finden. Das kann für Ingenieure ohne FHIR- oder Healthcare-IT-Erfahrung zunächst eine Herausforderung darstellen, doch sie werden sich schnell einarbeiten, da FHIR gut dokumentiert und leicht erlernbar ist.
Die FHIR-Dokumentation ist kostenlos online unter https://www.hl7.org/fhir/overview.html verfügbar und ist prägnant und leicht verständlich. Eine ganze Community von Interoperabilitätsexperten ist nur einen Klick entfernt. Registrieren Sie sich einfach unter https://chat.fhir.org/login/ und erhalten Sie alle Ihre Fragen innerhalb weniger Stunden, wenn nicht sogar Minuten, beantwortet. Health Samurai verfügt über umfangreiche Erfahrung bei der Anwendung von FHIR-Datenmodellen auf die Daten unserer Kunden, aber selbst wenn wir den geringsten Zweifel haben, besprechen wir unsere Bedenken sofort mit der FHIR-Community. Auf diese Weise stellen Sie nicht nur sicher, dass Ihre Verwendung der FHIR-Ressourcen und ihrer Felder korrekt ist, sondern geben der Community auch wertvolles Feedback zum Standard und seiner Dokumentation.
Starten 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.
Ihre Daten auf FHIR abbilden
Stellen Sie sich vor, Sie erfassen Informationen zu Patientendiagnosen. Wenn Sie einen FHIR-Server als Backend verwenden, müssen Sie verstehen, wie FHIR Patientendiagnosen abbildet. Sie werden erfahren, dass FHIR Diagnosen als „Conditions" bezeichnet, und finden eine Beschreibung der Condition-Ressource in der FHIR-Spezifikation. Möglicherweise benötigen Sie nicht alle Felder der Condition-Ressource, und wie Sie vielleicht bereits wissen, sind fast keine Felder verpflichtend.
Es ist gut möglich, dass FHIR Sie auf wichtige Datenelemente aufmerksam macht, die Ihrer Aufmerksamkeit entgangen sind, und Sie zu den richtigen Terminologien führt. Beispielsweise lernen Personen, die neu in der Healthcare-IT sind, die SNOMED-Terminology kennen, wenn sie sich mit der FHIR-Condition-Ressource befassen.
Beginnen Sie damit, die benötigten Felder auszuwählen und das erstellte Mapping zu dokumentieren. Danach sind Sie bereit, Diagnosedaten in Ihrem FHIR-Backend zu speichern und zu verwalten.
FHIR-Datenmodelle erweitern
Wie bereits erwähnt, benötigen Sie möglicherweise nicht alle Felder der von Ihnen verwendeten FHIR-Ressourcen. Gleichzeitig kann es vorkommen, dass einige Ihrer Daten nicht gut in das FHIR-Format passen. Es mag Sie überraschen, dass bestimmte Datenelemente, die in Ihrer Organisation als sehr gebräuchlich gelten, von der FHIR-Community nicht als allgemein üblich betrachtet werden. So wurden beispielsweise Ethnie, Organspendebereitschaft, Nationalität und Religion nicht in die Kern-Patient-Ressource aufgenommen. Wenn Sie der Meinung sind, dass einige fehlende Datenelemente oder sogar Ressourcen zu Unrecht so behandelt wurden, können Sie dieses Anliegen jederzeit innerhalb der FHIR-Community ansprechen, da FHIR ein offener, gemeinschaftsgetriebener Standard ist. Und Sie können fehlende Datenelemente stets mithilfe von FHIR-Extensions hinzufügen.
Ein Beispiel für eine Rassen-Extension könnte beispielsweise so aussehen:
{ "url": "http://hl7.org/fhir/StructureDefinition/us-core-race", "valueCodeableConcept": { "coding": [ { "system": "http://hl7.org/fhir/v3/Race", "code": "1096-7" }]}}
Hier bietet Health Samurais Aidbox FHIR-Backend einen unkonventionellen Ansatz für das Problem komplexer FHIR-Extensions. Bei realen Implementierungen FHIR-basierter Lösungen sind wir auf viele Situationen gestoßen, in denen FHIR-Ressourcen umfangreich erweitert werden mussten, um die Workflows unserer Kunden zu unterstützen. Dabei haben wir festgestellt, dass die Befolgung der Standardpraktiken im Umgang mit Extensions eine erhebliche Belastung für Ingenieure darstellte und die Time-to-Market sowie die Entwicklungskosten der Lösung erhöhte. Daher haben wir Aidbox so gestaltet, dass Extensions genauso wie reguläre Kerndaten behandelt werden – ohne Unterschied –, um die FHIR-Erweiterung für Ingenieure zu vereinfachen. Um einem Patienten in Aidbox eine Rasse hinzuzufügen, können Sie einfach patient.race schreiben, während normale FHIR-Extensions eine deutlich längere Notation erfordern würden.
Was passiert jedoch mit der Interoperabilität, wenn FHIR-Extensions vereinfacht werden? Health Samurai übernimmt dies für Sie mit Aidbox. Aidbox speichert alle FHIR-Metadaten und erkennt, wenn Ingenieure ein Feld zu einer Ressource hinzufügen, das nicht Teil der FHIR-Spezifikation ist. Mit diesem Wissen generiert Aidbox eine FHIR-konforme API-Schicht für alle Ihre Daten, die alle zusätzlichen Felder in FHIR-konforme Extensions umwandelt.
Integration Ihrer FHIR-basierten Lösung mit EHR-Systemen
Die Integration Ihrer FHIR-basierten Lösung mit EHRs ist wesentlich einfacher als bei einer individuellen Lösung. Wenn Sie eine SMART on FHIR-Anwendung entwickeln, erhalten Sie die EHR-Daten sofort im FHIR-Format. Und die Speicherung dieser EHR-Daten in Ihrem FHIR-Backend erfordert keinerlei zusätzlichen Aufwand Ihrerseits. SMART on FHIR gewinnt zunehmend an Popularität und wird von mehreren großen EHR-Anbietern unterstützt.
Die FHIR-API von Epic können Sie unter https://open.epic.com/Interface/FHIR und die von Cerner unter http://fhir.cerner.com/ erkunden.
Selbst wenn Sie mit Legacy-EHR-Daten arbeiten, ist dies mit einem FHIR-Backend einfacher als mit einer individuellen Lösung. Viele gängige HL7-Engines, die in Krankenhaussystemen implementiert sind, können ältere HL7 v.2-Daten problemlos in FHIR übersetzen. Es gibt auch gut dokumentierte Mappings für HL7 v.2, CCD und X12-Daten. Wir haben in unserem Aidbox-Backend eine Funktion zur Übersetzung von Legacy-Standarddaten nach FHIR implementiert. Unser HL7 v.2-zu-FHIR-Konnektor ermöglicht die Anpassung des Übersetzungs-Mappings über speziell entwickelte Konfigurationsdateien. Dieser Ansatz hat es uns ermöglicht, verschiedene Versionen von HL7 v.2 und anbieterspezifische Z-Segmente zu verarbeiten, ohne die Codebasis der Lösung zu ändern.
Insgesamt erleichtert die Entwicklung mit einem FHIR-Backend die Integration mit EHR-Technologien und verbessert die Interoperabilität Ihrer Gesundheitslösungen, indem Plug-and-Play-Konnektivität im FHIR-Ökosystem ermöglicht wird.
Siehe auch: Der FHIR-Leitfaden für CTOs.
