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.
