Mittwoch, 24. August 2022

Unterstützung für DiGa-Hersteller

Laut aktueller Gesetzeslage sind DiGa-Hersteller ab dem 1.1.2023 verpflichtet, die in der App erhobenen Daten strukturiert in die ePA des Patienten einstellen zu können.

Diese Anforderungen umzusetzen erfordert Zeit und Ressourcen, die viele Hersteller nicht haben.

Wir bieten eine kompetente Begleitung des gesamten Prozesses an: Von der Erstellung einer mit dem DiGA-Toolkit der KBV kompatiblen FHIR-Export-Spezifikation basierend auf Ihrem Datenmodell, über die Beantragung des Praxisausweises, bis hin zur Implementierungsunterstützung bei der Anbindung an die ePA.

Bei Rückfragen oder Interesse melden Sie sich gerne über unser Kontaktformular!

Montag, 22. August 2022

IOP Council stellt Weichen für HL7 FHIR

In der 4. öffentlichen Sitzung des "Interoperability Councils for Digital Health in Germany" wurde vergangene Woche der Kriterienkatalog für die Empfehlung von Interoperabilitätsspezifikationen an das BMG verabsschiedet.

Eine solche Empfehlung ist maßgeblich dafür, dass Spezifikationen in künftigen Gesetzen und Regelungen des BMG Berücksichtigung finden können. Der verabschiedete Kriterienkatalog sieht vor, dass Spezifikationen, in denen medizinische Daten strukturiert repräsentiert werden, auf FHIR aufsetzen müssen, um vom Expertengremium empfohlen werden zu können. Ausgenommen sind Spezifikationen, für deren Anwendungsbereich bereits anderslautende Gesetze existieren.

Ziel des Councils ist es, bei zukünftigen Spezifikationen technologische Konvergenz zu erreichen, um die Interoperabilität besser beurteilen und überprüfen zu können, mehr Wiederverwendbarkeit zwischen den Spezifikationen zu erreichen und die Aufwände für deren Implementierung zu reduzieren. 

Die Probleme, die entstehen, wenn Spezifikationen immer wieder auf anderen Basisstandards aufsetzen oder gar komplett proprietär definiert werden, hat das in der gleichen Sitzung vorgestellte Positionspapier des Arbeitskreises "Datenflow in der Onkologie" aufgezeigt: Dort wurden in den letzten Jahrzehnten über 30 Interoperabilitätsspezifikationen festgelegt, von denen jedoch keine zwei sowohl in Datenrepräsentation als auch Übertragungsprotokoll harmonisiert waren. Dies traf zunächst die Entwickler der Softwaresysteme, die zu deren Umsetzung verpflichtet waren, aber indirekt über explodierende Kosten auch die Anwender dieser Systeme und durch die schlechte Wart- und Testbarkeit der Software, hohe Arbeitsbelastung der Entwickler und geringe Wiederverwendbarkeit bereits ausführlich getesteten Codes letztendlich auch die Datenqualität und damit Patientensicherheit.

Das klare Bekenntnis zu HL7 FHIR ermöglicht es nicht nur, erstmals UseCase-übergreifende Interoperabilität herzustellen, sondern auch, die INA-Plattform zu weit mehr als einem Verzeichnis empfehlenswerter Spezifikationen weiterzuentwickeln. Da FHIR-Spezifikationen in maschinenlesbarer Form vorliegen, können diese nicht nur als Dokument publiziert werden, sondern auch als importierbares Package und als validierbares Schema, das zum Testen von Implementierungen verwendet werden kann. Perspektivisch ist auch die Publikation von Tools, Bibliotheken, Testscripten oder Referenzvalidatoren  und -implementierungen denkbar.

Bereits jetzt nutzt der Kriterienkatalog des Expertengremiums die maschinenlesbare Natur von FHIR-Spezifikationen, um deren Qualität zu beurteilen. Beispiele können automatisiert auf Konformität zur Spezifikation getestet, die Vollständigkeit und Verfügbarkeit von Terminologien geprüft und die Dokumentation mittels Templates harmonisiert werden.

Dadurch können mit INA erhebliche Mehrwerte für die Nutzer der dort veröffentlichten Spezifikationen erzeugt werden, die weit über das Herunterladen eines Dokumentes hinausgehen.

Es bleibt zu hoffen, dass diese Möglichkeiten schnell und unbürokratisch realisiert werden.

Mittwoch, 15. September 2021

Was ist eigentlich ein "ImplementationGuide"?

Der Begriff "ImplementationGuide" führt im Kontext von FHIR immer wieder zu Missverständnissen.

Hier folgt der Versuch einer Klärung der häufigsten Fragen:

Was ist eigentlich ein Implementierungsleitfaden?

Wikipedia definiert den Begriff "Leitfaden" als "eine Handlungsvorschrift mit bindendem Charakter".
Im Kontext der Standardisierung kennen wir Implementierungsleitfäden als Anleitung für die Entwicklung kompatibler Softwarelösungen. Als solche präzisiert ein typischer Implementierungsleitfaden (z.B. von IHE) i.d.R. die Verwendung eines internationalen Standards im Kontext eines konkreten UseCases.

Beispiele:

  • IHE-RAD beschreibt die konkrete Verwendung von (u.A.) HL7 Version 2 Nachrichten zur Implementierung des radiologischen Order-Entry-Workflows.
  • Der Implementierungsleitfaden "Arztbrief 2014" beschreibt die Darstellung eines strukturierten Arztbriefes auf Basis von HL7 CDA
  • Der "International Patient Summary" beschreibt die Vereinbarungen für eine internationale Patientenkurzakte auf Basis von FHIR.

Für Implementierungsleitfäden gibt es Standard-übergreifend kein einheitliches Format. In der Regel handelt es sich um menschenlesbare Dokumente (PDF, HTML), die auch auf maschinenlesbare Artefakte verweisen können, aber nicht müssen.

Was ist der Unterschied zwischen einem Implementierungsleitfaden und einem Profil?

Antwort 1: Es ist das gleiche!
Im Kontext von IHE-Spezifikationen beschreibt der Begriff "Profil" das Dokument, das beschreibt, wie ein internationaler Standard für einen bestimmten UseCase "profiliert" wurde, also den Implementierungsleitfaden.

Antwort 2: Es ist nicht das gleiche!
Im Kontext von FHIR versteht man unter einem "Profil" die Summe der Contraints, die beschreiben, wie ein konkreter FHIR-Ressourcentyp (z.B: "Condition") in einem konkreten Kontext (z.B. beim Datenaustausch zwischen Systemen in einem Krankenhaus) verwendet werden soll.

Die Aufgaben eines Profils sind unter anderem:

  • die Festlegung der UseCase-spezifischen Pflichtfelder
  • die Festlegung der darüber hinaus optional verwendeten Felder (mit rotem "S" gekennzeichnet)
  • die Festlegung der verwendeten Extensions 
  • die Festlegung der verwendeten Terminologien (z.B. zur Codierung von Diagnosen)
  • die Festlegung von Regeln, die erfüllt werden müssen (sog. "Invarianten")

Dabei beschreibt ein Profil aber immer nur die Constraints für einen einzigen Ressourcentyp. Um einen UseCase (z.B. eine Patientenkurzakte) zu beschreiben, benötigt man in der Regel mehrere Profile für verschiedene Ressourcentypen. Artefakte wie Extensions, ValueSet oder Datentyp-Profile sind dabei eigenständige Objekte, die von den Profilen referenziert werden.

Was ist der Unterschied zwischen einem ImplementationGuide und einem Implementierungsleitfaden?

Der ImplementationGuide ist eine Resource aus dem FHIR Conformance Framework (einer Gruppierung von verschiedenen Ressourcentypen, die im Kontext der Erstellung von FHIR-basierten Spezifikationen benötigt werden), also ein strukturiertes, maschinenlesbares Objekt, das wie jede andere FHIR-Ressource wahlweise in XML oder JSON serialisiert werden kann. Es dient dazu, die Einzelteile, die einen Implementierungsleitfaden ausmachen (HTML-Webseiten mit Erläuterungstexten und darin eingebetteten Grafiken, Beispieldaten, Profile, ValueSets, Extensions ...) zu einem Paket zu verschnüren, zu publizieren und zwischen verschiedenen Tools und Systemen austauschbar zu machen. 

Für humanoide Konsumenten einer Spezifikation ist die ImplementationGuide-Ressource in der Regel uninteressant. Selbige wollen das HMTL-Dokument in seiner menschenlesbaren Form betrachten können, nicht die maschinenlesbare Auflistung seiner Einzelteile.

Während im Englischen höchstens die Anordnung der Majuskeln zur Unterscheidung von ersterem, dem "ImplementationGuide" und letzterem, dem "implementation guide" herangezogen werden kann, hat es sich hierzulande etabliert, die Ressource bei ihrem englischen Namen zu nennen, jedoch das HTML-Dokument zu "(Implementierungs-)Leitfaden" zu übersetzen.
Schwierig wird es, wenn man mit hartgesottenen FHIR-Nerds spricht, die aus ökonomischen Gründen beides unter dem Akronym "IG" zusammenfalten.

CAVE: In Simplifier, einer beliebten Plattform zur Erstellung und Publikation von FHIR-Spezifikationen, findet man in einem Projekt einerseits einen "ImplementationGuide" im Tab "Resources", andererseits aber auch das gerenderte Dokument als HTML-Seite(n) im Tab "Guides". Da hat man schnell mal daneben geklickt und wundert sich!

Vergleiche:

vs.

Wer darf Implementierungsleitfäden schreiben?

Hinter dieser Frage steckt vermutlich das größte Missverständnis!
 
Während Leitfäden in der Vergangenheit ausschließlich im Wortsinne als "Richtlinien" aus der Feder von Organisationen wie HL7, IHE oder anderen STUs (Standards Defining Organizations) verwendet wurden, gibt es in FHIR technisch keinen Unterschied zwischen 
  • der Beschreibung einer Implementierung im Sinne einer Richtlinie von Standardisierungsorganisationen an die Industrie oder 
  • der Beschreibung einer Impementierung im Sinne eines Pflichtenheftes im Rahmen einer Beschaffung/Beauftragung oder 
  • der Beschreibung einer Implementierung im Sinne einer Schnittstellendokumentation.
In allen diesen Szenarien kommen die gleichen Artefakte zum Einsatz: Profile, Extensions, ValueSets, Beispieldaten sowie ein beschreibendes, menschenlesbares Dokument; alles verpackt zu einer ImplementationGuide-Ressource.

Es sollten sich also nicht nur Mitarbeiter von Standardisierungsorganisationen mit den Resourcen und Tools des FHIR Conformance Frameworks vertraut machen, sondern auch alle, die Requirements-Engineering betreiben oder Schnittstellen implementiern und dokumentieren müssen.

Von Herstellern, die ihr Produkt als "FHIR-enabled" bezeichnen, wird erwartet, dass deren Schnittstellenspezifikation in Form eines ImplementationGuides bereitgestellt wird. Prosaische Dokumentationen in Form von unstrukturierten PDFs werden von der FHIR-Community wie auch von den FHIR-Tools und -Referenzimplementierungen als unzureichend abgelehnt.

Dabei ist der Aufwand für die Erstellung von FHIR-basierten Schnittstellendokumentationen erheblich geringer als bei der Erstellung von Spezifikationen. Oft können die Profile aus den Richtlinien, die vom Hersteller implementiert wurden, wiederverwendet werden und müssen nur durch die Nenung der optionalen bzw. die Beschreibung der zusätzlich implementierten Features ergänzt werden.

Tools wie Simplifier und der dort integrierte "ImplementationGuide Editor" oder der IG Publisher machen die Erstellung, Pflege und Publikation der Schnittstellenbeschreibung besonders einfach. 


Unsere Schulung "FHIR Spezifikation erstellen und anwenden" am 15.11.2021 gibt ein Einblick in das FHIR Conformance Framework und demonstriert das Vorgehen zur Erstellung eines eigenen ImplementationGuides anhand einfach nachvollziehbarer Beispiele.




-->