Unter dieser Rubrik finden Sie Fragen und Antworten zum Thema FHIR®, die für die Umsetzung aller MIOs gleichermaßen relevant sind.

Für das Narrative gibt es Vorgaben, welche durch HL7® FHIR® festgelegt werden und für jedes Profil identisch sind. Für das "div" Element im Narrative ist immer Inhalt in Form von XHTML-Code zu verwenden. Diese XHTML Fragmente müssen XHTML-Namespaces beinhalten, wie auch in den Beispielen der HL7® FHIR® Dokumentation gezeigt. Nähere Informationen finden Sie auch auf der entsprechenden Webseite von HL7® FHIR®: http://hl7.org/fhir/narrative.html#Narrative
Bei der Referenzierung einer FHIR®-Ressource werden in unseren Spezifikationen in der Regel die Versionsnummern angegeben. Ist dies an einer Stelle in einem bestimmten Profil nicht der Fall, wird empfohlen für die referenzierte Ressource die Version zu verwenden, die der Version des referenzierenden Profils entspricht.
Innerhalb eines Bundles werden die beinhalteten Personen und Organisationen (z. B. PatientIn, Practitioner, Organization) aus nahezu allen Profilen referenziert. Es sollte darauf geachtet werden, dass z. B. für eine behandelte Person innerhalb eines MIO-Eintrages nur eine Instanz erzeugt wird. Diese Instanz kann mehrfach referenziert werden.
Die einzelnen Profile einer FHIR®- Spezifikation sind über ein Bundle zusammengefasst, sodass ein Bundle mit den zugehörigen Profil-Instanzen eine einzelne Instanz des MIO bildet. Diese Instanz wird in der elektronischen Patientenakte (ePA) gespeichert. Keine Instanzen der anderen MIO-Profile dürfen einzeln (ohne Bundle) in die ePA hochgeladen werden.

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.

Die semantische und syntaktische Definition der Inhalte für die MIOs, welche eine Vorlage in Papierform besitzen, erfolgt dem gesetzlichen Auftrag entsprechend gemäß der Papiervorlage. Daraus resultieren gelegentlich Abweichungen unserer Spezifikationen im Vergleich zu den Ressourcen-Definitionen. Änderungen der Inhalte in den entsprechenden MIOs setzen eine Änderung der Papiervorlage voraus.
Im Informationsmodell sind die Bedingungen in den einzelnen Elementen unter dem Punkt "Bedingungen" zu finden. In FHIR® werden die Bedingungen, soweit möglich, als Constraints definiert. Bedingungen, die über die Möglichkeiten der Constraints hinaus gehen, sind bei der technischen Umsetzung des MIO zu beachten und umzusetzen.
Auf oberster Ebene in der Profil-Definition sind die Constraints für das jeweilige FHIR®-Profil definiert.
Von FHIR® selbst und der Kassenärztlichen Bundesvereinigung (KBV) gibt es keine Vorgaben zur Formatierung der Profile-ID. Die mio42 GmbH verwendet für die veröffentlichten Beispieldateien üblicherweise eine Version 4 UUID.
Bei unseren bisherigen festgelegten MIOs handelt es sich um Dokumente. Die Struktur geben wir durch die Composition vor. Deshalb muss in unseren bisherigen festgelegten MIOs immer genau eine Composition in einem Bundle enthalten sein.
Hierbei handelt es sich um einen Fehler in der Darstellung. Die besagten Composition müssen jeweils von den dafür vorgesehenen Profilen „KBV_PR_MIO_PN_Bundle“ und „KBV_PR_MIO_PC_Bundle“ referenziert werden. Der Fehler wird im Rahmen einer zukünftigen Fortschreibung behoben.
Das Element "text" muss aufgrund eines Fehlers in der FHIR®-Core Spezifikation angegeben werden. In der FHIR®-Core Spezifikation der Composition besagt die Regel "cmp-1", dass in einer Section mindestens ein "entry", "text" oder eine "sub-section" enthalten sein muss. Diese Regel müsste zusätzlich das Element "emptyReason" als Möglichkeit aufführen.
Bei der Referenzierung einer FHIR®-Ressource werden in unseren Spezifikationen in der Regel die Versionsnummern angegeben. Ist dies an einer Stelle in einem bestimmten Profil nicht der Fall, wird empfohlen für die referenzierte Ressource die Version zu verwenden, die der Version des referenzierenden Profils entspricht.

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

Was ist Must-Support?

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.

Warum werden die Spezifikationen nicht offener gestaltet?

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.