Unter dieser Rubrik finden Sie Fragen und Antworten zum Thema FHIR®, die für die Umsetzung aller MIOs gleichermaßen relevant sind. Es gibt verschiedene Gründe für den Ausschluss: Funktionen, die durch die ePA übernommen werden (bspw. Versionierung oder lastUpdated), schließen wir aus, um widersprüchliche Informationen, zwischen Instanzen der FHIR® Profile und den Meta-Informationen der ePA, zu vermeiden. Zumal die Funktionalität ePA anders ist, als ein FHIR®-Server. Alle Informationen werden als Bundle gebündelt in die ePA geladen. Dementsprechend werden einzelne Informationen nie verschiedene Daten in dem Element lastUpdated enthalten. Das Bundle enthält weiterhin das Element "timestamp", welches den Zeitpunkt abbildet, zu dem das Bundle zusammengefügt worden ist und implizit (wenn auch nicht ganz exakt) lastUpdated abbildet. Außerdem wird ein Großteil der Einträge in der ePA signiert, wodurch die Information lastUpdated implizit enthalten ist. Viele derzeit in einer Spezifikation (z. B. MIO U-Heft) nicht verwendeten Elemente der Ressourcen werden komplett gestrichen, d. h. das die Kardinalität auf 0..0 gesetzt wird. Ressource https://simplifier.net/uh1x0/kbvprmiocmrappointmentnextappointment Must-Support ist eine Eigenschaft, die zu einem Element hinzugefügt werden kann (Siehe rotes S im obigen Bild). Die Definition der Eigenschaft erfolgt pro MIO. Beispiel: Als Must-Support deklarierte Elemente müssen durch jedes System, welches diese Spezifikation implementiert, unterstützt werden. Das bedeutet, dass das jeweilige System diese interpretieren und verarbeiten können muss. Die Deklarierung als Must-Support wird, wie in der Beispielabbildung dargestellt, durch eine rotes S gekennzeichnet. FHIR® bietet eine gute semantische Definition vieler Elemente, jedoch sind diese nicht immer eindeutig. Zusätzlich kann auch die Interoperabilität nicht durchgehend gewährleistet werden. Beispiel 1 https://simplifier.net/uh1x0/kbvprmiocmrappointmentnextappointment oder https://www.hl7.org/fhir/appointment.html Dort kann man wie im obigen Bild gezeigt ein reasonCode angeben. Dieser reasonCode kann aus einem "beliebigen" (auch wenn ein preferred Codesystem (CS) angegeben ist) CS eingetragen werden. Dieses CS kann vom Sender selbst erzeugt werden und muss dem Empfangenden aber nicht zwangsweise bekannt sein, somit ist an dieser Stelle die Interoperabilität gefährdet, da der Code nicht bekannt ist. So könnte z.B. der Code "N" verwendet worden sein, jedoch ist die Bedeutung von "N" nicht bekannt, da das gesamte Codesystem für den Empfangenden unbekannt ist. Beispiel 2 In der gleichen Ressource kann unter comment ein Freitext erstellt werden. Dieser Freitext könnte sowas wie "Achtung der Patient braucht dringend eine künstliche Beatmung, sonst kommt es zum Atemstillstand" umfassen. Somit wäre eine dringende benötigte Information an einer Stelle eingetragen worden, die das empfangende System nicht zwingend in dieser Qualität versteht und damit auch anzeigen würde. Wenn man solche Elemente einfach in ihrer Grundkardinalität belassen würden, dann könnten diese in nicht eindeutig definierter Art und Weise gefüllt werden. Auch wenn diese Informationen für die Schnittstelle nicht direkt erforderlich sind, also nicht mit dem Must-Support gekennzeichnet sind, so könnten für den Sendenden wichtige Informationen an den Empfänger übertragen werden, ohne das diese adäquat behandelt werden, da Sender und Empfänger leicht unterschiedliche semantische Einschätzungen von dem gleichen Element haben. Weiterhin könnten für den Empfangenden völlig unverständliche Codes transferiert werden. Dies kann absichtlich oder auch unabsichtlich sein. Was ist Must-Support?
Warum werden die Spezifikationen nicht offener gestaltet?
Unter dieser Rubrik finden Sie Fragen und Antworten zum Thema FHIR®, die für die Umsetzung aller MIOs gleichermaßen relevant sind.