Posts mit dem Label IHE werden angezeigt. Alle Posts anzeigen
Posts mit dem Label IHE werden angezeigt. Alle Posts anzeigen

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.




Freitag, 19. Februar 2021

eHealth-Podcast zum Thema "FHIR"

Wir waren zu Gast beim eHealth-Podcast!

Was hat FHIR mit dem Krankenhaus-Zukunftsgesetz zu tun? Schließen sich FHIR und IHE gegenseitig aus? Wie macht man ein KIS am besten FHIR-kompatibel?  Ist HL7 Version 2 jetzt passé?

...und was meint Mr. Spock dazu?

Die Antworten gibt es hier:



Montag, 9. März 2020

FHIR - Wer nutzt es, wem nützt es?

Als Trost für die abgesagte KHIT-Tagung in der kommenden Woche, finden diejenigen, die sich für unseren geplanten Vortrag "FHIR - Wer nutzt es, wem nützt es?" interessiert hätten, hier ein Interview  des Krankenhaus-IT-Journals mit Gefyra CEO Simone Heckmann zu genau diesen beiden Fragen:
http://www.medizin-edv.de/modules/AMS/article.php?storyid=4972

Simone Heckmann, Geschäftsführerin / CEO, Gefyra GmbH: „Mir ist es wichtig, dass die Krankenhäuser FHIR als eine Chance sehen, aktuelle Probleme und Herausforderungen wie z.B. Vendor-Lock-In, Patienten-Teilhabe und integration mobiler Anwendungen anzugehen und nicht nur als "schon wieder ein neuer Standard".

Montag, 9. Dezember 2019

FHIR® Workshop im März 2020

Auch im kommenden Jahr setzen wir unsere erfolgreiche Kooperation mit dem Zentrum für Telematik und Telemedizin (ZTG) fort und veranstalten mehrere öffentliche FHIR-Workshops in ganz Deutschland.

Der erste Termin steht bereits fest: Vom 11.3.-13.3.2020 können Interessierte in Berlin ein umfangreiches Basiswissen über den neuen HL7-Standard "FHIR" erwerben. In kurzweiligen Präsentationen und vertiefenden Übungen vermitteln wir Wissenswertes über die grundlegenden Technologien, zeigen typische Anwendungen, stellen FHIR-basierte IHE-Profile und Tools vor und beantworten Fragen zum Einsatz von FHIR im Rahmen der MI-Initiative und der KBV-Spezifikationen. Ausführliche Informationen und Preise gibt es auf der Homepage des ZTG

Weitere Termine folgen in Kürze!

Mittwoch, 3. April 2019

Neue FHIR-Schulungen

Pünktlich zur DMEA haben wir unser Schulungsprogramm für 2019 überarbeitet und erweitert!

Ab sofort haben Sie die Wahl zwischen unserer eintägigen
FHIR-Einführung für Entscheider 
und dem zweitägigen 
FHIR-Basis-Workshop für Entwickler 
mit den optionalen Zusatzmodulen
  • FHIR für Spezifizierer
  • Cloverleaf® on FHIR
  • KBV on FHIR
  • FHIR-Apps mobil und cross-platform
Unsere Schulungen sind als In-House-Schulungen konzipiert und können Ihren individuellen Bedürfnissen, Vorkenntnissen und Zielsetzungen angepasst werden.
Die Schulungen halten wir wahlweise auf Deutsch oder Englisch.

Zusammen mit unseren Kooperationspartnern, dem ZTG und HL7 Deutschland e.V. bieten wir öffentliche Schulungen an.
Die nächsten Termine sind:
  • 20.-22.5. Münster (Anmeldung hier)
  • 4.-6.9. Berlin (geplant)
  • 2.-4.12. Köln (geplant)

Donnerstag, 12. April 2018

IHE MHD: XDS "in einfach"

Die DMI lädt auf der ConhIT 2018 im Veranstaltungsraum "Trier" zu Kompetenzworkshops mit
Fachreferenten ein, unter anderem:

IHE-Profil MHD: XDS „ in einfach“
(Referentin: Simone Heckmann)

Der Vortrag bietet eine Kurzeinführung in FHIR, einen Überblick über die Aktivitäten von IHE in Bezug auf den neuen HL7-Standard und stellt das neue, FHIR-basierte MHD-Profil (Mobile Access to Health Documents) dem etablierten XDS-Profil (Cross-Enterprise Document Sharing) gegenüber.

Mittwoch, 10. Januar 2018

Continua on FHIR: Kommunikationslücke zwischen ConsumerHealthCare und Gesundheitsdienstleistern schließen!

Die Zeiten in denen Blutdruck- und Glukose-Messwerte von Patienten in Notizheftchen eingetragen wurden, um Fortschritt und Verlauf der eigenen Erkrankung im Blick zu behalten, sind vorbei.

Längst haben moderne, bezahlbare bluetooth-fähige Geräte verbunden mit Smartphone-Apps und Cloud-Diensten den Markt erobert.

Einerseits bietet dieser Trend große Chancen, die Betreuung chronisch Kranker zu verbessern, die Anzahl erforderlicher Arztbesuche zu verringern, Senioren länger ein unabhängiges Leben im eigenen zu Heim zu ermöglichen, Forschern eine kostengünstige Möglichkeit zum Follow-Up von Studienteilnehmern zu bieten oder mit pfiffigen Apps und integration Sozialer Netzwerke, Compliance und Motivation von Patienten zu erhöhen.

Doch wo viel Licht ist, ist auch viel Schatten. Bedenken bezüglich der Qualität und Vergleichbarkeit der gemessenen Daten werden ebenso angeführt, wie Mängel bei Sicherheit und Datenschutz.

Die Personal Connected Health Alliance (PCHA) ist ein Zusammenschluss von Herstellern mit dem Ziel, die Kommunikation mit medizinischen Geräten und Sensoren im Consumer-Bereich einfach, kompatibel und sicher zu gestalten und mit Hilfe von Standardisierung und Zertifizierung die Qualität der Geräte und der gemessenen Daten vergleichbar zu machen.

Ähnlich wie IHE definiert die PCHA dazu keine eigenen Standards, sondern setzt auf etablierte Definitionen z.B. IEEE, Bluetooth oder HL7 und füllt - wo erforderlich - die Lücken. Die resultierenden Spezifikationen werden als Continua Design Guidelines veröffentlicht.

Die Guidelines unterteilen die Kommunikation in ein mehrstufiges Modell:

Quelle: wiki.hl7.org
Am Beispiel eines konkreten Szenarios könnte die Kommunikation folgendermaßen ablaufen:

  1. Ein Glukose-Messgerät übermittelt die gemessenen Daten per Bluetooth an ein Smartphone
  2. der Patient entscheidet, die Messdaten mit seinem Hausarzt zu teilen und gibt Sie an einen entsprechenden (Cloud-)Service frei. 
  3. Nach einer Validierung der Daten kann der Hausarzt die Daten in die Elektronische Patientenakte übernehmen

Während die Kommunikation zwischen Gerät und "Personal Health Gateway" basierend auf IEEE 11073 und Transportstandards wie Bluetooth oder USB gesetzt und etabliert ist, bereitete die bisherige Spezifikation zur Kommunikation zwischen PHG und Cloud-Dienst sowie der Integration in die elektronische Patientenakte basierend auf dem IHE-Profil "PCD-01" bei der Implementierung immer wieder Kopfschmerzen.

PCD-01 setzt auf Nachrichten im HL7 V2 Format, das in der Krankenhaus-IT-Welt zwar seit Jahrzehnten etabliert ist, Web-Entwicklern jedoch geradezu anachronistisch erscheinen muss.

Weiterhin erforderte die Integration in die elektronische Patientenakte wiederum eine "Umschlüssselung" der V2 Nachricht in CDA und die Implementierung eines weiteren IHE-Profils: XDS.b

Insgesamt kommt man damit auf ein beachtliches Sammelsurium zu implementierender Standards: HL7 V2, HL7 V3 (CDA), SOAP, SAML, ebXML, ATNA (DICOM) ...
Entsprechend aufwendig und teuer gestaltet sich die Entwicklung darauf basierender Applikationen.

Der Ruf der Implementierer nach einheitlichen, modernen, webbasierten Protokollen wurde von der PCHA gehört: Am 14.12.2017 wurde die erste FHIR-basierte Continua Guideline veröffentlicht.
Damit schafft PCHA die Möglichkeit, Continua-zertifizierte Applikationen schneller und kostengünstiger zu implementieren, da auf etablierte Webstandards wie REST und OAUTH2 zurückgegriffen werden kann und der umfangreiche Stack an FHIR-Tools und Bibliotheken nutzbar wird.
Die Kommunikation zwischen Personal Health Gateway, CloudService und Elektronischer Gesundheitsakte kann damit basierend auf einem einheitlichen Standard-Framework implementiert werden. Für die Integration der Sensoren und Geräte bietet die Guideline Mappings zwischen IEEE 11073 und den FHIR-Ressourcen "DeviceComponent und Observation" an.

Am 24. Januar bietet die PCHA ein kostenloses Webinar zum Thema "Continua on FHIR" an!

Gute Nachrichten für Deutschland:
2017 trat die PCHA dem Spitzenverband IT-Standards im Gesundheitswesen (SITiG) bei, um gemeinsam mit IHE-DE und HL7-DE die Standardisierung in Deutschland zu fördern.


Links:
http://www.pchalliance.org/continua-design-guidelines
https://www.slideshare.net/DevDays/furore-devdays-2017-continua-implementing-fhir

Montag, 13. November 2017

IHE-Profil "MMA": Mobile Medikamenten-Administration mit FHIR

Quelle: https://www.mechatronic.de
Das IHE-Profil "Mobile Medication Ad­mi­ni­stra­tion" (MMA) definiert die Integration von mobilen Pflege-Do­ku­men­tations­sytemen, Patienten-Apps, in­telli­genten Medi­kamen­ten-Dis­pensern und anderen, die Medikamenten-Verabreichung unterstützenden Anwendungen, mit einer elektronischen Patientenakte, wie zum Beispiel einem Krankenhaus- oder einem Praxis-Infor­mations­system.
Es ist damit Teil einer Serie von IHE-Profilen, die auf HL7 FHIR als Mechanismus für die Interaktion zwischen Primärsystemen und mobilen Endgeräte setzen. Weitere Profile werden künftig den gesamten Medikations-Workflow abdecken.

MMA beschreibt zwei Aspekte der Medikamenten-Verabreichung:

  1. Die Übermittlung geplanter Medikamenten-Verabreichungen vom Primärsystem an ein Endgerät
  2. Die Übermittlung eines Berichts über verabreichte Medikamente von einem Endgerät an das Primärsystem.
Beide Transaktionen sind optional, jedes System kann sowohl eines als auch beide Aspekte implementieren.

Typische Anwendungsszenarien sind:

  • Ein Anwendungssystem in der mobilen Pflege informiert die Pflegekraft über die Medikamente, die ein bestimmter Patient in einem bestimmten Zeitraum einnehmen muss. Die Pflegekraft dokumentiert die Abgabe der Medikamente im Anwendungssystem.
  • Ein intelligenter Medikamenten-Dispenser oder eine Smart-Phone-Applikation erhält Informationen  zur Medikamenten-Verabreichung von einem Praxis- oder Apothekensystem und erinnert den Patienten an die Einnahme seiner Medikamente.
  • Eine Smart-Phone-Applikation zur Erfassung der Patienten-Compliance im Rahmen eines Therapie-Programmes
  • Die Dokumentation der Medikamenten-Verabreichung durch eine Infusionspumpe
  • Die manuell oder durch Barcode-Scan erfasste Dokumentation verabreichter Medikamente durch eine Pflegekraft im Krankenhaus-Umfeld
Quelle: wiki.ihe.net


Das IHE-Profil ist vollständig kompatibel mit der FHIR-STU3-Spezifikation, fügt dieser jedoch zusätzliche Constraints und UseCase-spezifische Leitfäden für Entwickler hinzu.
Folgende FHIR-Ressourcen werden von MMA verwendet:
  • Patient
  • Medication
  • MedicationRequest
  • MedicationAdministration

Anwendung in Deutschland:

Für die Abbildung der Medication-Ressource speziell in Deutschland unter Verwendung der hier üblichen und verbreiteten Formen der Kodierung wird im Rahmen des MedikationsplanPlus-Projektes ein entsprechendes Profil erarbeitet. Für die Patient-Ressource gibt es in den Basisprofilen für Deutschland bereits ein lokalisierte Fassung.  Die im Rahmen der Umsetzung des Medikationsplans implementierten FHIR-Ressourcen Patient und Medication können für MMA wiederverwendet werden.

Mittwoch, 8. November 2017

Das Mädchen von Seite 1...

...und Seite 8 in ArchivAktiv über Interoperabilität als Wegbereiter für die vernetzte Zukunft.

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.



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: