Videos

Hallo und willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir dir zeigen, an welchen Stellen in unseren MIOs Werte vorgegeben sein können, und wie du diese erkennst.

Es gibt in unseren MIOs mehrere Arten von vorgegebenen Werten. Hier behandeln wir Fixed Values und Patterns.

Hier siehst du ein Beispiel für einen Fixed Value. Dieser ist rechts neben dem Element durch ein gelb hinterlegtes Feld gekennzeichnet.

Für das Element Consent.status ist ein Wert vorgegeben. In diesem Element darf also kein anderer als der von uns festgelegte Wert stehen.

Welcher Wert genau für das Element vorgegeben wurde, kannst du im Informationsfenster des Elements sehen.

Das MIO sieht vor, dass das Element Consent.status den Wert "active" enthält. Wenn du also dieses Profil in unserem MIO befüllen möchtest, achte darauf, dass du hier genau diesen Wert einträgst. Andernfalls entspricht die FHIR-Ressource nicht der MIO-Spezifikation, sie ist also nicht gültig.

Das Element Consent.status ist ein Element mit primitivem Datentyp. Das bedeutet, dass es nur einen einzelnen Wert repräsentiert und dass es sich um ein Element ohne Unterelemente handelt. Im Gegensatz dazu gibt es auch Elemente mit komplexem Datentyp. Diese enthalten Unterelemente. Wie verhält es sich da mit vorgegebenen Werten? Schauen wir uns ein Beispiel an!

Hier siehst du ein Element mit komplexem Datentyp, für das ein Fixed Value festgelegt wurde.

Wenn Werte für Elemente mit komplexem Datentyp vorgegeben sind, dann betrifft das nicht nur das jeweilige Element selbst, sondern auch seine Unterelemente. Das spiegelt sich darin wieder, dass für die beiden im Fixed Value festgelegten Unterelemente auch Fixed Value-Kennzeichnungen angezeigt werden.

Ein Fixed Value gibt exakt vor, welche Werte in einem Element mit komplexem Datentyp anzugeben sind.

Die Daten müssen genau so wie hier vorgegeben in das Element eingetragen werden. Jegliche zusätzlichen, fehlenden oder abweichenden Werte führen dazu, dass die FHIR-Instanz im Bezug auf die MIO-Spezifikation ungültig wird. Hier muss man also genau hinschauen. Als nächstes schauen wir uns Patterns an.

Hier siehst du nun ein Beispiel für ein Pattern.

Auch bei Patterns sind die Unterelemente, die von der Wertevorgabe betroffen sind, mit Fixed Value-Kennzeichnungen versehen.

Außerdem sind die für das Element vorgegebenen Werte hier auch im dazugehörigen Informationsfenster zu finden.

Im Gegensatz zu Fixed Values ist bei Patterns nur wichtig, dass keiner der vorgegebenen Werte abweicht oder fehlt. Zusätzliche Werte sind erlaubt.

Was genau der Unterschied zwischen Fixed Values und Patterns bei komplexen Datentypen ist, schauen wir uns noch einmal genauer an.

Hier siehst du auf der rechten Seite die beiden vorgegebenen Wertpaare, einmal als Fixed value und einmal als Pattern, in der Schreibweise wie wir sie eben bereits auf simplifier in den entsprechenden Informationsfeldern vorgefunden haben.

Links siehst du ein Beispiel für eine Adresse im XML-Format wie sie in einer FHIR-Instanz dokumentiert sein könnte.

Vielleicht ist dir aufgefallen, dass hier neben den beiden Werten für "city" und "district" noch ein Wert für das Element "line" hinterlegt ist.

Wäre diese Adresse gültig, wenn die rechts im Bild gezeigten vorgegebenen Werte für die Dokumentation von Adressen festgelegt sind?

Da hier in der Adresse noch eine Straße und eine Hausnummer im "line"-Element angegeben wurden, wäre diese Adresse für die Vorgabe als Fixed Value nicht gültig. Fixed Values erlauben nämlich keine zusätzlichen Werte. Ohne das "line"-Element wäre die Adresse gültig gewesen.

Wenn die Werte allerdings wie unten rechts im Bild als Pattern vorgegeben sind, dann wäre diese Adresse gültig. Sie erfüllt nämlich die im Pattern angegebenen Mindestanforderungen an Werten und zeigt keine Abweichungen, nur zusätzliche Werte. Und die sind hier erlaubt.

Wir hoffen, dass der Unterschied zwischen Fixed values und Patterns ein bisschen klarer geworden ist.

Das war es erstmal zum Thema vorgegebene Werte in unseren MIOs. Vielen Dank für's Zuschauen!

Hallo und willkommen zu Per Anhalter durchs MIOVersum. In diesem Video möchten wir dir kurz zeigen, wie du unsere MIO-Validierungspakete nutzen kannst, um Beispiele und die Spezifikationen zu validieren.

Kommen wir zunächst zur Frage: Was sind Beispiele bei einem MIO?

Gegeben ist hier das Practitioner-Profil des Medikationsplans. Zu sehen sind alle befüllbaren Elemente die für die behandelnde Person in diesem MIO relevant sind. 

Hier sehen wir einen fiktiven Datensatz einer behandelnden Person.
Dr. med. Minna zu Kühn ist 1977 geboren, weiblich und lebt in Berlin. Weitere Details zu Fachbereich und Kontaktdaten sind ebenfalls vorhanden.

Diese Daten müssen nun in der FHIR-Struktur des Practitioner-Profils abgebildet werden. Nur dann sind die Daten mit dem MIO konform.

Daten, die in einer FHIR-Struktur vorliegen, nennt man FHIR-Instanz.
Eine FHIR-Instanz nutzt in der Regel XML oder JSON. 
Hier sehen wir die Daten von Dr. med. Minna zu Kühn in einer FHIR-Instanz abgebildet.

Wie du siehst, wird jede Information aus dem Beispieldatensatz einem entsprechenden Element des FHIR-Profils zugeordnet und in der FHIR-Instanz eingesetzt.
Damit entsteht ein FHIR-Beispiel, dieses wird also immer anhand der Vorgaben es FHIR-Profils erstellt, wie hier bspw. beim Familiennamen zu sehen ist

Für unsere MIOs veröffentlichen wir neben einzelnen FHIR-Instanzen für technische Minimal- und Maximalbeispiele auch zusammenhängende Fallbeispiele.

Während technische Beispiele keinen Anspruch auf fachliche Korrektheit der Informationen haben, unsere Fallbeispiele werden von Mediziner:innen erstellt und geprüft.
Diese sollen das MIO in realistischen Anwendungsfällen zeigen.
Kontextinformationen, textuelle Beschreibungen, sowie Inhalte der Fallbeispiele, findest du auf der MIO-Plattform bei den Inhalten zum jeweiligen MIO.
Die FHIR-Instanzen zu den Beispielen veröffentlichen wir auf Github in unseren Validierungspaketen.

Auf Github veröffentlichen wir zu jedem MIO ein Validierungspaket.
Dieses soll als Orientierungshilfe für Entwickler:innen bei der Umsetzung der MIOs dienen.
Es enthält die Abhängigkeiten des MIO, wie KBV-Basis-Profile oder Deutsche HL7 FHIR Basis-Profile, die Spezifikation des MIO und Fallbeispiele, sowie technische Beispiele. 
Damit sind alle nötigen Ressourcen für die Arbeit mit dem MIO vorhanden.

Sehen wir uns noch einmal die Beispiele in technischer Form an.

Die Fallbeispiele liegen hier in Form von FHIR-Instanzen in XML bzw. JSON vor.

Jedes Fallbeispiel wird in einer XML- bzw. JSON dabei, dem sogenannten Bundle, abgebildet. Das Bundle bündelt alle, für das Beispiel notwendigen FHIR-Instanzen.

Zusätzlich zu den Fallbeispielen, veröffentlichen wir auch die technischen Beispiele, kategorisiert in Minimal- und Maximalbeispiele.

Die technischen Beispiele liegen als separate FHIR-Instanzen zu je einem Profil, wie dem Patient, vor.

Wir unterscheiden zwischen Minimal- und Maximalbeispielen, je nachdem ob wir nur die verpflichtenden Elemente mit der Kardinalität 1..1 befüllen, oder optionale Elemente ebenfalls befüllen.

Anhand der Validierungspakete, kannst du ausprobieren, wie man FHIR-Instanzen validiert.
Das solltest du später auch mit deinen eigenen erstellten FHIR-Instanzen tun.
Eine Anleitung zum Validieren mit dem HL7 FHIR Validator findest du in der Readme des Validierungspaketes.
Mehr Details zum Validierungsvorgang, erklären wir in einem separaten Video.

Wir hoffen, dieser kleine Überblick zu Beispielen & Validierungspaketen hilft dir, um noch besser mit unseren MIOs zu arbeiten. 

Hallo und willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir dir zeigen, wieso du deine FHIR®-Ressourcen validieren solltest und wie das funktioniert.

Unsere MIO Spezifikationen enthalten FHIR®-Profile. Diese sind wie ein Bauplan und enthalten Vorgaben für deine FHIR®-Instanzen, also für die tatsächlichen Daten, die dein System erzeugt und beispielsweise in die ePA schreibt.
du musst zu den Profilen passende FHIR®-Instanzen erzeugen, damit die Empfänger der Daten diese korrekt verarbeiten können. Wenn Daten von den Vorgaben und damit der erwarteten Form abweichen, können enthaltene Elemente unter Umständen von empfangenden Systemen nicht verarbeitet werden.

Die Validierung stellt sicher, dass keine Fehler unterkommen und die Instanzen tatsächlich den Vorgaben folgen.
Wir bezeichnen FHIR®-Instanzen, welche die Vorgaben eines Profils erfüllen, als "konform zu dem Profil".

Um den Start der Arbeit mit unseren MIOs und das Validieren zu erleichtern, stellen wir zu jedem MIO ein Validierungspaket auf Github bereit, dass alle Daten enthält, die du zur Validierung und Verwendung unserer MIO Spezifikation brauchst.

Wie läuft nun das Validieren tatsächlich ab?

Es gibt sogenannte FHIR®-Validatoren. Das sind Anwendungen bzw. Werkzeuge, welche für die Validierung von FHIR®-Instanzen gegen eine FHIR®-Spezifikation genutzt werden können. Das Vorgehen ist dabei immer gleich: du gibst dem Validator als Eingabe an, welche Instanz bzw. Instanzen du validieren möchtest und gegen welche Profile oder welche Spezifikation du prüfen möchtest. Der Validator erzeugt dann einen Prüfbericht, welcher potenziell gefundene Fehler und Warnungen enthält.

Hier eine kleine Auswahl der bekanntesten FHIR®-Validatoren.

Der offizielle FHIR®-Validator des FHIR® Projektes von HL7 in Zusammenarbeit mit HAPI-FHIR® steht sowohl online als auch als herunterladbare Java-Anwendung zur Verfügung. Während die Online-Version für schnelle Überprüfung einzelner Ressourcen komfortabel sein kann, empfehlen wir für Überprüfung in der Entwicklungsumgebung die Java-Anwendung zu verwenden.

Diese ist auf Github zum Download verfügbar. Es handelt sich hierbei um ein auf der Konsole ausführbares Programm, bei welchem per Parameter die Pfade zu überprüfenden Instanzen, sowie die zu berücksichtigenden Spezifikationen angegeben werden. Wir verwenden bei der Spezifikation unserer MIOs ebenfalls den HL7 bzw. HAPI-FHIR® Validator und empfehlen diesen deshalb für die Vergleichbarkeit der Validierungsergebnisse. Auch die Online-Version verwendet den HAPI-FHIR® Validator, jedoch meist in einer weniger aktuellen Version, weshalb sich für stets aktuelle Versionen sowie internetunabhängige Nutzung sich ebenfalls die Java Anwendung anbietet. 

Eine ausführlichere Anleitung für die Verwendung bietet HL7 auf der eigenen Confluence Webseite.

Alternativ haben auch andere Anwendungen Validatoren eingebaut.
So überprüft Forge beim Spezifizieren direkt die Profile, das firely Terminal bietet neben anderen Funktionen einen eigenen Validator für die Kommandozeile, und Simplifier stellt ebenfalls einen Online FHIR®-Validator für Simplifier-Nutzer bereit, in welchen für schnelle Überprüfung einzelne Ressourcen eingefügt werden können.

Genau wie beim HL7 FHIR® Validator ist es bei diesen Tools wichtig, alle zugrundeliegenden Spezifikationen anzugeben, damit anhand dieser Vorgaben korrekt geprüft werden kann.

Sehen wir uns nun kurz an, wie Validierungsergebnisse aussehen können.

Es gibt drei Schweregrade von Meldungen: Informationen bzw. Empfehlungen, Warnungen und Fehlermeldungen.
Empfehlungen und Warnungen müssen individuell beachtet und eingeschätzt werden.
So kann eine Meldung über Codes außerhalb vorgegebener ValueSets unproblematisch sein, wenn bewusst beispielsweise eigene Terminologien wegen unpassender Vorgaben genutzt werden und die Vorgaben offen, also extensible, sind.

Fehlermeldungen hingegen bedeuten, dass die Instanz nicht valide bzw. konform zur Spezifikation und damit nicht gültig ist.
Fehlermeldungen müssen behoben werden, wenn sie durch die Instanz verursacht werden.
Es gibt bei manchen MIOs allerdings auch bekannte Fehler, welche ignoriert werden können.
Diese sind auf unserer MIO-Plattform aufgeführt.

Wir hoffen, dieser kleine Überblick zum Validieren hilft dir, um noch besser mit unseren MIOs arbeiten zu können.