Dienstag, 31. Oktober 2017

IHE-Profil "MHD": XDS in einfach

Das IHE-Profil für den Dokumentenaustausch "XDS" hat in den vergangenen Jahren viel Aufmerksamkeit erfahren. Darin wird der Dokumentenaustausch zwischen einem "Document Producer", also einem System, das digitale Dokumente erzeugt und einer "Document Registry", die digitale Dokumente verwaltet, verbunden mit dem "Document Repository", das die Dokumente archiviert, beschrieben.
Der Bedarf einer derartigen Kommunikation ist unbestritten, dennoch geht die Umsetzung in der Praxis nur schleppend voran. Ursächlich sind dafür die hohen Anforderungen an die Implementierung.

In vielen Fällen mag dieser Aufwand gerechtfertigt sein - für komplexe Anforderungen kann es keine einfachen Lösungen geben!
Häufig jedoch sind die Anforderungen in diesem Kontext relativ einfach:

  • Ein (mobiles) Gerät hat Daten erfasst und möchte dieses nun als strukturiertes Dokument mit Patientenkontext und einem minimalen Umfang an Metadaten an die zentrale Dokumentenverwaltung übergeben. 
  • Ein  (mobiles) Gerät möchte eine Liste der verfügbaren Dokumente zu einem Patienten anzeigen und der Benutzer soll die Möglichkeit haben, ein ausgewähltes Dokument zu betrachten.
  • Eine Arztpraxis mit minimaler IT-Ausstattung möchte auf die Dokumente im Archiv eines angebundenen Krankenhauses zugreifen
  • Eine elektronische Patientenakte möchte Dokumente für den Import in eine elektronische Fallakte bereitstellen.
Für diese (und ähnliche) Anwendungsfälle bietet IHE nun alternativ das MHD-Profil an.

IHE: Mobile access to Health Documents (MHD)

Basierend auf FHIR bietet MHD Lösungen, die sich schneller umsetzen lassen, was nur in geringem Maße auf eine Reduktion der Funktionalität zurückzuführen ist.
Die Vereinfachung ergibt sich vorwiegend aus der Natur des FHIR-Standards.
Durch die Verwendung weit verbreiteter Web-Standards für den Datentransport sowie die Verfügbarkeit ausgereifter Programmbibliotheken und Referenzimplementierungen für viele Programmiersprachen, sind Entwickler mit erheblich geringerem Aufwand in der Lage, Integrationslösungen zu realisieren.

Dabei ist der Zusatz "mobile" irreführend! Wie die oben genannten Szenarien (die alle der MHD Spezifikation entnommen sind) zeigen, ist der Einsatz von MHD keines Falls auf mobile Endgeräte begrenzt. Viel mehr handelt es sich um eine Alternative zu XDS, die für mobile Endgeräte aufgrund der dort vorliegenden technologischen Beschränkungen alternativlos, für andere Geräte und Applikationen jedoch aus den gleichen Gründen attraktiv sein kann.

Alles ist eine Ressource

Ein wichtiger Aspekt von FHIR ist die einheitliche Betrachtung aller Dinge als Ressourcen.
Eine Ressource ist ein (wahlweise in JSON oder XML repräsentiertes) Objekt, das über eine eindeutige URL adressiert werden kann und über ein definiertes Set an Suchparametern verfügt.
Alle in FHIR spezifizierten Ressourcen gehorchen den gleichen Gesetzen.

MHD spiegelt diesen Ansatz wieder.
Die Dokumenten-Metadaten (Ressource: DocumentReference), der Patient (Ressource: Patient), das Dokument (Ressource: Binary) an sich (ein PDF, ein CDA-Dokument, eine Grafik, ein Word-Dokument..), der Autor (Ressource: Practitioner):
Alle werden durch FHIR-Ressourcen abgebildet. Für die Übermittlung eines Dokumentes werden diese Ressourcen zusammengefasst (Ressource: Bundle) und dem REST-Paradigma folgend per HTTP POST [basis-url]/ an die Dokumentenverwaltung übergeben.

Dokumentensuche in der Registry: einfach "googlen"*

Auch die Suche nach Dokumenten folgt dem REST Paradigma:
Zeige mir alle Laborbefunde zu Patient "123456" -  so einfach wie googlen*: 
HTTP GET [basis-url]/DocumentReference?subject=123456&type=Laborbefund

Das Ergebnis ist eine Liste der zutreffenden Dokumente, die deren vollständigen Metadaten enthält sowie die URL des jeweils zugehörigen Dokumentes.
Das Dokument zur Anzeige abzurufen ist nichts anderes, als die Ressource an der entsprechenden URL anzufordern:
HTTP GET [basis-url]/Binary/34567


MHD oder XDS? Warum nicht beides!

Die Spezifikation von XDS und MHD sind bezüglich des Umfangs und der Notation der Metadaten abgestimmt, so dass ein Mapping von einem Profil in das andere ohne Probleme möglich ist.
IHE empfiehlt existierenden XDS-Registries/Repositories die Gruppierung von XDS mit MHD, um MHD-basierten Applikationen den Zugriff auf die Dokumente zu ermöglichen:
Quelle: http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)




PIX/PDQ: Das Gleiche in grün

Zumeist wird XDS mit dem PIX- oder PDQ-Profil gruppiert, da sich Document Producer und Document Registry zunächst über die eindeutige Identifizierung eines Patienten verständigen müssen.
Hier entfaltet sich der ganze Charme der FHIR-basierten Profilvarianten:

Wer MHD mit mPDQ (der FHIR-basierten Variante des "Patient Demographic Query"-Profils) gruppiert, wird feststellen, dass sowohl die Repräsentation der Patientendaten (Ressource: Patient)
als auch die Mechanismen der Suche (googeln!*) über beide Profile hinweg identisch sind:
HTTP GET [basis-url]/Patient?family=Mustermann&given=Max

Einmal implementieren - endlos wiederverwenden


FHIR ist wie Lego. Die Ressourcen bilden die Bausteine, IHE liefert die Baupläne dazu. Die Bausteine sind jedoch immer wieder die selben, lediglich die Art der Zusammensetzung ändert sich.
Wer einmal begonnen hat, FHIR zu implementieren, kann daher immer wieder auf bereits implementierte Ressourcen zurückgreifen, um neue Funktionen zu nutzen, sei es, um weitere FHIR-basierte IHE-Profile zu implementieren, Web-Applikationen über das SMART-Framework anzubinden oder Decision-Support-Dienste - beispielsweise für den Arzneimittel-Interaktionscheck - standardisiert zu integrieren.

Somit ist MHD nicht nur eine einfache Alternative für XDS, sondern auch eine zukunftssichere Investition.
Denn, dass sich FHIR duchsetzen wird, daran hegt auch IHE inzwischen keine Zweifel mehr, wie sich aus der Einführung zum MHD-Profil, bezug nehmend auf den noch-nicht-normativen Status von FHIR, ablesen lässt:
Whenever possible, IHE profiles are based on established and stable underlying standards. However, if an IHE committee determines that an emerging standard offers significant benefits for the use cases it is attempting to address and has a high likelihood of industry adoption, it may develop IHE profiles and related specifications based on such a standard.

Um dem Aufschrei der Datenschützer zuvorzukommen:
Dies bedeutet nicht, dass alle Dokumente im WWW ungeschützt offenliegen!! Lediglich die zugrunde liegende Technologie für die Kommunikation von FHIR-Client und -Server ist die gleiche wie zwischen Browser und Webserver. Die in MHD empfohlenen Mechanismen zur Autorisation, Authentifikation und Verschlüsselung zu beschreiben, würde jedoch den Umfang dieses Artikels sprengen, sind jedoch im MHD (bzw. referenzierten Profilen) nachzulesen.



Montag, 23. Oktober 2017

Neu: Unser 2-tägiger FHIR-Intensiv-Workshop

Wer stellt sich der Herausforderung?


Themen:

Tag 1

Einführung in FHIR 
Übung: Demografische Patientendaten
Das REST Paradigma 
Tools: REST-Client
Übung: REST Interaktionen
Bundles & Search
Übung: Suchen mit HTTP
~ FHIR-Abend ~

Tag 2

Das Operations Framework
Übung: Operations mit HTTP
Ressourcen und Referenzen 
Übung: Ressourcen verlinken
Terminologien
Übung: Terminologien
Transaktionen
Paradigmen: Dokumente und Messaging
Questionnaires
Use-Case: SMART Apps
Use-Case: CDS-Hooks
FHIR und V2/CDA/IHE
Wrap-Up
~ FHIR-Abend ~

Die Schulung kann wahlweise in Deutsch oder Englisch gehalten werden.
Weitere Informationen erhalten Sie über unser Kontaktformular oder hier.

FAQ: Was passiert auf einem Connectathon?

Frage

Was passiert auf einem Connectathon?

Antwort

Im Gegensatz zu IHE-Connectathons, wird bei FHIR-Connectathons nicht die Software getestet, sondern der Standard.

Entwickler kommen mit einer Idee oder einem UseCase, möglicherweise sogar mit einer (halb-)fertigen Implementierung auf den Connectathon und testen, in wie weit sich FHIR als Basis dieser Implementierung eignet. Dabei erhalten Sie Unterstützung von FHIR-Experten und erfahrenen Entwicklern. Daher spricht man häufig auch von einem "Hackathon". Wenn ein Problem nicht mit der geballten Community-Wissenspower gelöst werden kann, dann wird darüber diskutiert, ob und wie der Standard angepasst werden muss, um den konkreten UseCase besser zu unterstützen.

Die Connectathons sind daher ein Win/Win für Entwickler und Standardisierer.

Für Neulinge bieten die Connectathons (insbesondere jene im Rahmen der DeveloperDays) zusätzlich Tutorials und Workshops.

Ein wichtiger Termin für alle, die sich für die Teilnahme an einem Connectathon interessieren, ist der 12./13. Mai 2018. Im Rahmen des HL7 International WorkGroupMeetings in Köln wird dort ein Connectathon stattfinden, zu dem über 300 Teilnehmer erwartet werden! 

Unter der Rubrik "FAQ" veröffentlichen wir Fragen, die uns auf unterschiedlichen Wegen erreichen. Wenn auch Sie uns eine Frage zum Thema "FHIR" stellen möchten, nutzen Sie bitte das Kontaktformular auf unserer Homepage.

FAQ: Unendliche Mannigfaltigkeit in unendlicher Kombination: FHIRs Schwäche?

Frage

Sind die schier unendlichen Möglichkeiten, FHIR Resourcen zu kombinieren und zu verlinken nicht ein Hindernis bei der Interoperabilität?

Antwort

Der Standard als ein Lego-Baukasten zu sehen. Es gibt viele verschiedene Klötzchen, aus denen man einen Würfel, ein Raumschiff oder das Taj Mahal bauen kann.
Wichtig ist, dass es Baupläne gibt, die beschreiben, wie man aus den unzähligen Möglichkeiten, Klötzchen zusammenzusetzen, genau die richtigen Klötzchen und Verbindungen wählt, damit am Ende das gewünschte Ergbnis herauskommt. In der Standardisierung spricht man hierbei von "Implementation Guides" (IG).

Das Konzept der IGs ist nicht neu. Diese gab es auch schon für V2 und V3/CDA. Allerdings waren IGs bislang meist mehrere hundert Seiten starke PDFs.

Wie gut sich eine Implementierung an solche IGs hält, ist daher immer davon abhängig, wie gründlich der Implementierer den Bauplan studiert hat.
Und dabei haben sich in der Vergangenheit die Abgründe aufgetan.

FHIR ist sich mehr als seine Vorgänger der Bedeutung der IGs bewusst. Daher sind diese nun nicht länger nur "Beipackzettel" sondern ein integraler Teil des Standards, der es erstmals möglich macht, die IGs in maschinenlesbarer Form zu veröffentlichen, so dass diese unmittelbar zur Code-generierung, Validierung und für Compliance-Tests verwendet werden können.

Siehe hierzu auch: http://hl7.org/implement/standards/fhir/conformance-module.html

Die Aufgabe, IGs für die Nutzung von FHIR in Deutschland zu erstellen, fällt dem Technischen Komitee von HL7 Deutschland zu.

Dieses entwickelt fortlaufend den "FHIR Basisleitfaden für Deutschland". Dort werden Gemeinsamkeiten vereinbart, die allen in  und für Deutschland implementierten Produkten zueigen sein sollten, um die Interoperabilität zu gewährleisten.
Dort wird zum Beispiel festgelegt, wie
  • eine Lebenslange Arztnummer 
  • eine ICD-10-Diagnose
  • eine gesetzliches Versicherungsverhältnis
  • oder die von einer eGK eingelesenen Patientendanten
in FHIR repräsentiert werden.

Der deutschsprachige Bereich des FHIR-Chats bildet dazu die Arbeits- und Diskussions-Plattform: https://chat.fhir.org/#narrow/stream/german.20(d-a-ch).

Die Beteiligung steht jedem offen, die Anmeldung ist kostenlos.

Unter der Rubrik "FAQ" veröffentlichen wir Fragen, die uns auf unterschiedlichen Wegen erreichen. Wenn auch Sie uns eine Frage zum Thema "FHIR" stellen möchten, nutzen Sie bitte das Kontaktformular auf unserer Homepage.

Mittwoch, 18. Oktober 2017

Forderungen der Ärzte an elektronische Patientenakten: FHIR bietet die Basis für die Umsetzung!

Dr. med. Christiane Groß, Ärztlicher Beirat zur Begleitung des Aufbaus einer Telematik-Infrastruktur fasst auf dem 2. Deutschen Interoperabilitätstages in Dortmund die Anforderungen der Ärzte an eine elektronische Patientenakte zusammen:

  • zeitgleicher Zugriff auf einzelne Behandlungsdaten verschiedener Institutionen für alle an der Behandlung Beteiligten
  • Übernahme einzelner Daten in die eigene Akte
  • Umfangreiche Suchfunktionen
  • einheitliche Datenformate
  • Möglichkeit des Patienten einzelne Aktenteile zu verbergen
  • Patient soll Daten beitragen können, die der Arzt bei Bedarf übernehmen kann
  • Wiederauffindbarkeit und Erkennbarkeit von Befunden und deren Quellen
  • Datensparsamkeit
  • Plattformunabhängigkeit
  • Semantische Datenvernetzung
  • Intelligente Akte mit Vorschlägen und Hinweise auf Leitlinien
  • Gleiche Strukturen in elektronischer Patientenakte und Fallakte
  • offene, herstellerunabhängige Schnittstellen
  • Herstellerunabhängige Modularität der Lösungsbausteine

FHIR hat die technische Basis für die Umsetzung:

  • zeitgleicher Zugriff auf einzelne Behandlungsdaten verschiedener Institutionen für alle an der Behandlung Beteiligten 
    • Die REST-basierte Kommunikation in FHIR ermöglicht den transparenten Zugriff auf verteilte Daten
    • Die Integration des OpenID/OAUTH2-Standards ermöglicht einrichtungsübergreifende Autorisation und Authentifikation
  • Übernahme einzelner Daten in die eigene Akte
    • Einzelne Datenelemente (Resourcen) können zwischen Systemen ausgetauscht werden, die Provenance-Resource macht die Herkunft der Daten nachvollziehbar
  • Umfangreiche Suchfunktionen
    • FHIR verfügt über sehr umfangreiche Suchfunktionen mit definierten Suchparametern pro Resource und der Möglichkeit, komplex verknüpfter Bedingungen.
  • einheitliche Datenformate
    • Alle Datenelemente (Resourcen) in FHIR sind konkret spezifiziert und haben ein wohldefiniertes Verhalten.
  • Patient soll Daten beitragen können, die der Arzt bei Bedarf übernehmen kann
    • Eine der Kernanwendungen für FHIR ist die Implementierung patientenbezogener Applikationen.
  • Möglichkeit des Patienten einzelne Aktenteile zu verbergen
    • Über Security-Labels können einzelne Resourcen als besonders schutzbedürftig gekennzeichnet werden.
  • Wiederauffindbarkeit und Erkennbarkeit von Befunden und deren Quellen
  • Datensparsamkeit
    • FHIR strukturiert die Daten in Resourcen (Patient, Behandler, Medikament, Messwert...), die einzeln eine vollständige medizinische Bedeutung haben. Aus solchen Resourcen zusammengestellte strukturierte Dokumente können nach konkreten Informationen durchsucht werden und müssen nicht als Ganzes ausgetauscht werden. Jede Resource verfügt über eine "Summary", die nur die wichtigsten Informationen enthält.
  • Plattformunabhängigkeit
    • FHIR ist an keine Plattform gebunden. Es gibt verschiedene Möglichkeiten der Datenrepräsentation und es sind bereits fertige Referenzimplementierungen in Java, .NET, Delphi und vielen anderen Programmiersprachen verfügbar
  • Semantische Datenvernetzung
    • Mit Hilfe des umfangreichen Terminologie-Frameworks integriert FHIR nicht nur die semantische Interoperabilität durch die Nutzung von Terminologien, sondern ermöglicht es auch den Entwicklern, die Pflege und Handhabung dieser Terminologien an Spezialsysteme zu delegieren
  • Intelligente Akte mit Vorschlägen und Hinweise auf Leitlinien
    • Das FHIR-basierte CDS-Hooks-Framework ermöglicht die nahtlose, standardisierte Integration von Entscheidungs-Unterstützungs-Systemen in Primärsysteme
  • Gleiche Strukturen in elektronischer Patientenakte und Fallakte
    • Die FHIR Resourcen können wiederverwendet und immer wieder zu neuen Strukturen zusammengestellt werden (ein vom Patienten gemessener Blutdruckmesswert kann aus der Patientenakte in das Praxissystem übernommen, von dort in einen Arztbrief eingebunden, elektronisch an ein Klinikum übermittelt und von dort wieder in die elektronische Patientenakte übernommen werden).
  • offene, herstellerunabhängige Schnittstellen
    • FHIR ist frei verfügbar und lizenz-offen. Es bestehen keine Einschränkungen bei der Nutzung und Implementierung. Viele OpenSource-Implementierungen sind ebenfalls frei verfügbar.
  • Herstellerunabhängige Modularität der Lösungsbausteine
    • Das FHIR-basierte SMART-Framework zeigt, wie verschiedene "Insellösungen" von Drittherstellern nahtlos und standardisiert in Primärsysteme eingebettet werden können.



Dienstag, 17. Oktober 2017

"FHIR für Programmierer" auf dem 2. Deutschen Interoperabilitätstag


Nach erfolgreicher Premiere im Rahmen des IHE-Europe Connectathons 2016 in Bochum wird der Deutsche Interoperabilitätstag im Jahr 2017 fortgesetzt. Bei dem Erfolgsformat diskutieren führende Persönlichkeiten aus Politik und Selbstverwaltung, Anwenderinnen und Anwender im Gesundheitswesen sowie Vertreterinnen und Vertreter der Industrie über ihre Ansätze zur Schaffung von Interoperabilität.

2017 wird die Veranstaltung in Kombination mit der HL7-/IHE-Jahrestagung in Nordrhein-Westfalen stattfinden.

-->  https://www.ztg-nrw.de/veranstaltungen/dit_2017/  <--

DATUM/ZEITVERANSTALTUNGSORT
18.10.2017 - 20.10.2017
ganztägig
Kongresszentrum Westfalenhallen Dortmund,
44137 Dortmund
Im Rahmen der angebotenen Tutorials wird es einen halbtägigen Workshop "FHIR für Programmierer" geben.

Die Anmeldung zum Deutschen Interoperabilitätstags 2017, zur HL7-/IHE-Jahrestagung und den begleitenden Tutorials ist kurzfristig vor Ort an der Teilnehmerregistrierung im Kongresszentrum Westfalenhallen Dortmund möglich.

Die Veranstaltung ist im Rahmen der Zertifizierung der ärztlichen Fortbildung der Ärztekammer Westfalen-Lippe mit 8 Punkten (Kategorie: A) anrechenbar.

Teilnahmegebühren:

VeranstaltungPreis (inkl. MwSt.) Studierende
2. Deutscher Interoperabilitätstag (DIT)170,- €90,- €
HL7/IHE-Jahrestagung330,- €100,- €
Kombiticket (DIT/HL7/IHE)395,- €
Tutorials je 50,- €

Die Tagungsgebühr schließt Verpflegung und Getränke in den Pausen ein.
Die Übernachtung wird von den Teilnehmern selbst reserviert.

Montag, 16. Oktober 2017

Deutsche FHIR Basisprofile: Kommentarauflösung hat begonnen

Am gestrigen Sonntag, dem 15.10.2017 ging die erste Kommentierungsphase für die FHIR Basisprofile zu Ende.

Nun beginnt die Auflösung der eingegangenen Kommentare.
Insgesamt gilt es, 28 offene Kommentare zu bearbeiten.


Die Diskussion und Abstimmung zu den jeweiligen Punkten findet im FHIR-Chat statt.
Die Beteiligung steht jedem offen und das verantwortliche Technische Komitee von HL7 Deutschland würde sich sehr freuen, eine möglichst große Zahl von Stimmen und Meinungen zu hören, um sicherzustellen, dass die Anforderungen Aller in den Basisprofilen repräsentiert sind.


Einige der aktuell diskutierten Themen umfassen zum Beispiel:
Issue #50: GKV-Hilfsmittelnummer in Basisprofil

Issue #54: ValueSet-Bindung für Bundesländer

Weiterhin werden aktuell auch Themen aus dem Ballot des Medikationsplanes besprochen, die Auswirkungen auf das Basisprofil haben.


Für folgenden Kommentar liegt bereits ein Lösungsvorschlag zur Abstimmung vor.
Issue #16: NamingSystem für Apotheken ID (IDF)


Weitere Diskussionsthreads werden in den kommenden Tagen erstellt.


Das Technische Komitee bittet um Beachtung der Tatsache, dass zum Zeitpunkt der Abstimmung nur noch "dafür" oder "dagegen" gestimmt werden kann. Die Diskussion ist dann abgeschlossen. 

Auch die Beteiligung an der Abstimmung steht jedem Interessierten offen, Es ist lediglich ein (kostenfreier) Account für den FHIR Chat erforderlich.

Mittwoch, 11. Oktober 2017

Neue IHE-Profile für den Austausch strukturierter Dokumente mit klinischem Mehrwert

IHE International kündigte am 9. Oktober die Veröffentlichung von zwei neuen IHE-Profilen an: mXDE und QEDm

Das Ziel dieser Profile ist es, den unmittelbaren Zugriff auf relevante Datenelemente innerhalb eines strukturierten Dokumentes zu ermöglichen um Klinikern damit einen schnellen Überblick über den Verlauf einzelner Messwerte zu liefern, ohne dazu unzählige Dokumente durchforsten zu müssen, sowie die Option, die strukturiert vorliegenden Daten zu statistischen und wissenschaftlichen Zwecken zu aggregieren.

mXDE (Mobile Cross-Enterprise Document Data Element Extraction) kombiniert die grob-granularen Query-Funktionen des IHE XDS-Profils und dessen FHIR-basierten pendant MHD (Mobile access to Health Documents) mit den feingranularen, ebenfalls FHIR-basierten Funktionen des QEDm (Query for Existing Data for Mobile)

Die neue Gleichung für den strukturieren Dokumentenaustausch lautet also  

mXDE = XDS + QEDm

wobei für Entwickler die äquivalente Gleichung 

mXDE = MHD + QEDm

einfacher zu lösen sein dürfte, da sie durchgehend auf den Prinzipien eines einzigen Standards beruht: FHIR!

Weitere Informationen findet man auf der mXDE-Homepage.

IHE ergänzt damit die inzwischen stattliche Liste der bereits vorhandenen FHIR-basierten Workflow-Profile:
-->