Videos

Hallo und willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir dir kurz zeigen, was Profile, Vererbung und Must Support in einem MIO für dich bedeuten.

Essenziell für unsere MIO-Spezifikationen sind Bestandteile wie die versicherte Person oder eine Einrichtung.

Diese Bestandteile des Informationsmodells werden in FHIR als Profile abgebildet.
In vielen Fällen kann ein Profilelement durch genau ein Profil abgebildet werden, wie bei der versicherten Person durch das Patient-Profil.
Das ist jedoch nicht immer der Fall. So werden beispielsweise Geräte häufig durch zwei Profile abgebildet, nämlich Device & DeviceDefinition.

Sehen wir uns als Einstieg den einfacheren Fall anhand des Patient-Profils an.

Auf unserer MIO-Plattform findest du zu den Profilelementen aus dem Informationsmodell auch zugehörige Seiten mit Beschreibungen zu den FHIR-Profilen. Während du hier sowohl textuelle Informationen als auch eine statische Darstellung findest, kannst du die Profile detaillierter und interaktiver auf Simplifier ansehen.

Hier sehen wir nun das FHIR-Profil der versicherten Person.

Ein FHIR-Profil enthält verschiedene Vorgaben für verpflichtende und optionale Inhalte in den tatsächlichen FHIR-Daten, also XML oder JSON Daten aus der Praxis. Es definiert die zu verwendende Struktur, Datentypen, sowie vorgesehene Terminologien.

Damit bestimmt ein FHIR-Profil, wie die tatsächlichen FHIR-Daten aufgebaut sein müssen, damit sie die Vorgaben für dieses MIO erfüllen. Diese Daten, in dem Fall ein Datenobjekt für die versicherte Person, nennt man FHIR-Instanz.

Das FHIR-Profil verhält sich dabei wie ein Bauplan, nach dessen Vorgaben die FHIR-Instanzen erstellt werden.

Sehen wir uns mal an, welche Vorgaben in diesem Profil gelten. Am besten siehst du das in der Snap-Ansicht.
Hier siehst du auf den ersten Blick diese Zahlen hinter den Elementen sowie diese roten Zeichen.

Bei diesen Zahlen sprechen wir von Kardinalitäten. Eine Kardinalität gibt einen Bereich mit Hilfe eines minimalen und eines maximalen Wertes an, der definiert, wie häufig ein Wert für das Element übermittelt werden darf. Müssen sie mindestens einmal vorkommen, sprechen wir von mandatorischen Elementen, diese sind in der Instanz verpflichtend. Ist die Mindestkardinalität 0, sind die Elemente optional. Bei einem Sternchen als maximale Kardinalität, dürfen Elemente beliebig oft in der Instanz vorkommen.

Die roten Symbole kennzeichnen ein Must Support Element. Wenn ein Element als Must Support markiert ist, muss es von Systemen, die das MIO umsetzen, unterstützt werden. Das heißt meist, die Elemente müssen sowohl gelesen als auch geschrieben werden können, mindestens müssen enthaltene Elemente beim Aktualisieren von Instanzen beibehalten werden und dürfen nicht verworfen werden. Mehr Kontext zum MustSupport findest du jeweils in den FHIR-Festlegungen auf der MIO-Plattform.

Nähere Informationen zu den Anforderungen, welche sich durch MustSupport ergeben, findest du für das jeweilige MIO auf unserer MIO-Plattform unter MIO-Festlegungen. So kann es sein, dass sich Anforderungen an rein lesende Systeme von Anforderungen an schreibende Systeme unterscheiden.

Nicht alle Vorgaben erfinden wir in unseren MIOs neu. Damit unsere FHIR-Spezifikationen kompatibel zu anderen Anwendungsfällen sind, übernehmen wir Vorgaben aus anderen Spezifikationen. Dafür basieren unsere Profile auf Profilen aus anderen Spezifikationen, wie den deutschen Basisprofilen, welche sozusagen als "Elternprofile" ihre Vorgaben auf unsere Profile übertragen. Dies nennt man in FHIR ableiten. Wir nutzen also andere Spezifikationen binden sie als Dependencies, in unseren MIOs ein.

In vielen Profilen leiten wir von den KBV-Basis-Profilen ab. Diese wiederum leiten oft von den Basisprofilen von HL7-Deutschland ab, auf denen auch andere Projekte wie ISiK basieren. Alle MIOs und andere FHIR-Spezifikationen basieren immer auf der FHIR-Core-Spec, den ursprünglichen Ressourcendefinitionen.

Welche Vorgaben wir übernommen oder selbst definiert haben, kann man in der Hybrid-Ansicht unterscheiden.
Ausgegrautes wurde übernommen, schwarz hervorgehobenes haben wir angepasst. Dies sieht man direkt an den Elementen, oder auch im Informations-Fenster mit mehr Details.

Wir hoffen, dieser kleine Überblick hilft dir, mit unseren MIO Profilen und Spezifikationen zu arbeiten.

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 durch das MIOVersum. In diesem Video möchten wir dir zeigen, was Slicings sind und was sie in unseren MIOs für dich bedeuten.

Hier sehen wir ein für die meisten MIOs typisches Profil: das Patient Profil. Sind dir daran schon mal diese blauen Symbole aufgefallen, die ein bisschen wie eine frisch geschnittene Pizza aussehen?

Wenn ein Element mit so einem Symbol gekennzeichnet ist, bedeutet das, dass ein Slicing vorliegt. Die möglichen Inhalte dieses Elements können also in verschiedene Kategorien, die Slices, eingeteilt werden.

In diesem identifier-Element wurden 4 verschiedene Slices definiert.

Das erste Slice heißt "pid" und ermöglicht eine Identifikation mittels einer Patienten-ID

Das Slice "versichertenId_GKV" steht für die ID der gesetzlichen Krankenversicherungen

Das Slice "versichertennummer_pkv" kann für die Identifikation von privat Versicherten genutzt werden

Und zuletzt das Slice "versichertennummer_kvk", zur Identifikation anhand der Krankenversicherungskartennummer

Jede Slice-Kategorie stellt eine mögliche Form der Identifikation dar und hat ihre eigenen Vorgaben dafür, wie der Inhalt des Elements aussehen muss, um der jeweiligen Kategorie zu entsprechen. Wie du siehst können die Slice verschiedene Kardinalitäten haben. 

Um zwischen den Slices zu unterscheiden, gibt es für jedes Slicing ein spezifisches Unterscheidungsmerkmal, das jedes Slice auf eindeutige Weise charakterisiert. Dieses Unterscheidungsmerkmal ermöglicht es, den Informationsgehalt des geslicten Elements zweifelsfrei einem bestimmten Slice zuzuordnen. Was genau das Unterscheidungsmerkmal ist, findest du heraus, wenn du dir das geslicte Element noch einmal genauer ansiehst.

An dieser Stelle findest du die Regelungen, die für das Slicing bestehen. Ganz am Schluss ist das Merkmal aufgeführt, das die Slices voneinander unterscheidet und unter ihnen einen gegenseitigen Ausschluss ermöglicht. Für das identifier-Element ist das der Value, also der Wert, welcher in den Slices im Element type.coding.code hinterlegt ist. Wollen wir das einmal für ein paar Slices prüfen?

Im pid-Slice wurde für das Element type.coding.code festgelegt, dass es den Wert "MR" enthalten muss. 

Im versichertenID_GKV-Slice wurde für das Element type.coding.code festgelegt, dass es den Wert "GKV" enthalten muss. Für die übrigen Slices wirst du an dieser Stelle jeweils andere Werte finden. Klasse, oder?

Die Unterscheidung von Slice-Kategorisierung kann nicht nur anhand vorgegebener Werte erfolgen, sondern auch durch die Existenz bestimmter Elemente, ihre Datentypen oder andere Eigenschaften.

Aber Moment mal, da stand doch noch mehr in der Definition des Slicings. Gehen wir nochmal dorthin zurück.

Hier steht an zweiter Stelle "Closed". Was bedeutet das? Hier spricht man von einem "geschlossenen" Slicing. Das geslicte Element darf ausschließlich die in den Slices festgelegten Informationen übertragen. Jegliche Information, die in kein Slice passt, ist nicht erlaubt. Bei diesem identifier-Element ist das der Fall.

Slicings sind jedoch nicht immer geschlossen. Dazu schauen wir uns noch ein weiteres Slicing-Beispiel an.

Dieses Element stellt eine Adresse dar.

Wie du siehst, steht hier der Ausdruck "Open" und nicht "Closed". Es handelt sich also um ein "offenes" Slicing. Das bedeutet, dass neben Adressen, die den Vorgaben des Slices "Strassenanschrift" oder des Slices "Postfach" entsprechen, auch weitere Adressen hinterlegt werden können, die in keine der beiden Slice-Kategorien passen.

Das war es auch schon zum Thema Slicings in unseren MIOs. Vielen Dank für's Zuschauen!

Hallo und willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir dir zeigen, was für Arten von Elementen in MIO-Profilen vorkommen können, unter anderem komplexe Datentypen, Choice-Elemente und Extensions.

Profile wie in diesem Fall ein MedicationStatement für die Medikationsinformation im MIO Medikation, haben bestimmte vorgegebene Elemente.
Welche Elemente in einem Profil zur Verfügung stehen, ist in erster Linie abhängig vom Typen der Ressource. Ein MedicationStatement beinhaltet beispielsweise andere Elemente als ein Patient. 

Welchen Datentyp ein Element aufweist, siehst du rechts neben dem Element. Der Datentyp bestimmt, welche Unterelemente und Daten dieses Element beinhalten kann. 

So sehen wir zum Beispiel, dass das status Element den "Code" Datentyp hat und direkt einen Code enthalten muss, während statusReason ein CodeableConcept ist, das weitere Unterelemente beinhaltet.
Wie du also sieht, gibt es in FHIR einige verschiedene Datentypen.

Dazu gehören einerseits atomare Datentypen, in FHIR primitive Datentypen genannt, wie Integer oder Strings für Zahlen oder Texte, aber auch komplexe Datentypen. Eine detaillierte Übersicht aller Datentypen findest du in der FHIR Spezifikation.

Komplexe Datentypen können ein Wertebereich, Werte mit vorgegebenen Einheiten, oder komplexere Strukturen wie Identifier definieren. Diese können durch ihre Definition stets die gleichen Unterelemente beinhalten.
Andere Beispiele sind Datentypen für Adressen oder Namen, welche wir auch MIO-übergreifend aus den KBV-Basisprofilen oder Basisprofilen von HL7 Deutschland übernehmen.
Die vorgegebenen Datentypen bieten eine Konsistenz, die Herstellern helfen kann, wieder verwendbare Module oder Skripte für den Umgang mit FHIR zu erstellen.

Einige Elemente in den FHIR-Profilen unserer MIOs ermöglichen die Auswahl zwischen verschiedenen Datentypen.
Diese nennen wir folgerichtig "choice-Elemente". Erkennen kannst du sie an dem blauen Symbol für Slicings in Kombination mit einem X in eckigen Klammern hinter dem Elementnamen. Außerdem haben Choice-Elemente keinen Datentypen angegeben.

Wenn du ein Choice Element nun aufklappst, siehst du die Auswahl möglicher Datentypen dargestellt wie Slices. Achte hier auf die Kardinalitäten des Choice Elementes sowie der einzelnen Optionen.
In den meisten Fällen musst du dich für genau einen Datentypen entscheiden, da das Choice-Element eine maximale Kardinalität von 1 hat.
Bei unseren MIOs herrscht die Besonderheit, dass wir Choice-Elemente explizit per Slicing anführen, wenn wir beispielsweise deren Kardinalität anpassen, da dies mit FHIR-Tooling aktuell nicht anders möglich ist.

In manchen Fällen müssen wir in MIOs auch Informationen unterbringen, für die es keine vorgesehenen Elemente gibt. Dies wird über Extensions, also Erweiterungen für die Profile umgesetzt.

Eine Extension erkennst du in der Baumdarstellung am Stern-Symbol.

Ein Beispiel ist die Extension für das "behandlungsziel", die wir auf oberster Ebene der Medikationsinformation hinzugefügt haben. 

Beim Datentyp sehen wir, dass es sich um eine Extension für eine Referenz auf eine Goal Ressource handelt.
Manchmal sind die Inhalte einer Extension nicht direkt ersichtlich, zum Beispiel, wenn diese aus einer Dependency übernommen wurde.
In diesen Fällen kannst du mehr Details sehen, indem du dir die Spezifikation der Extension ansiehst. Dies geht entweder, indem du auf die Extension klickst und in dem Informationsfenster dem Link der Extension-URL folgst, oder im Projekt aus welchem die Extension stammt nach ihr suchst.

Extensions behandelst du wie normale Bestandteile des Profils. Sie können an allen Elementen vorkommen. Es können auch mehrere Extensions an einem Element angefügt sein.

In der Regel darfst du in MIOs nur in den Profilen vorgegebene Extensions verwenden und keine eigenen Extensions hinzufügen.

Damit hast du einen ersten Überblick über Datentypen, Choice-Elemente und Extensions in MIOs. Vielen Dank für's Zuschauen!

Hallo und willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir dir kurz zeigen, was Constraints und Operationalisierungshinweise sind und wo du diese finden kannst.

Operationalisierungshinweise sind Empfehlungen, die sich an die implementierenden Systeme richten. Es gibt bezüglich unserer MIOs verschiedene Arten von Operationalisierungshinweisen. Auf unserer MIO-Plattform findest du Operationalisierungshinweise immer im entsprechenden MIO-Projekt. Wir zeigen dir dies einmal am Beispiel des Überleitungsbogens.

Wir sehen hier die Übersichtsseite des Überleitungsbogens. Aufgeführt werden hier nicht nur die Grundlagen und Spezifikation, sondern auch die Umsetzungsunterstützung. Klappt man diese aus, gelangt man unter anderem zu den Operationalisierungshinweisen. 

Auf der Seite wird deutlich, dass wir zwischen elementspezifischen, spezifischen und übergreifenden Operationalisierungshinweisen unterscheiden:

Die Elementspezifischen Operationalisierungshinweise gelten immer für das Element, für welches sie definiert sind.

Die Spezifischen Operationalisierungshinweise gelten für das gesamte MIO und die

Übergreifenden Operationalisierungshinweise sind auf alle MIOs anzuwenden.

Bitte beachte, dass sich die Inhalte der elementspezifischen und spezifischen Operationalisierungshinweise in den jeweiligen MIOs unterscheiden.

Neben den Operationalisierungshinweisen gibt es noch verbindliche Vorgaben für die implementierenden Systeme - sogenannte Constraints. Mit der Struktur unserer Profile setzen wir schon eine Menge Vorgaben um, welche durch das Informationsmodell vorgegeben werden. Manche Einschränkungen oder Regeln können jedoch nicht so einfach abgebildet werden. Dann ist es in FHIR möglich ein Constraint einzuführen, um die Einschränkung bzw. Regel durchzusetzen.

Doch woraus bzw. wie ergeben sich eigentlich Constraints?

Aus medizinischen Gegebenheiten, wenn sich bspw. verschiedene Elemente gegenseitig ausschließen oder bedingen.

Um die Genauigkeit von Angaben zu schärfen: bspw. bei Datumsangaben

Aus technischen Gründen, bspw. um leere Datenelemente oder leere Instanzen zu verhindern.

Constraints werden teilweise auf unserer MIO-Plattform aufgeführt und sind auch in der FHIR-Spezifikation zu finden. Schauen wir uns das einmal genauer auf simplifier an: Constraints werden für ein oder für mehrere Elemente eines Profils erstellt. Um die Constraints leichter auffindbar zu machen, platzieren wir diese aber nicht auf der jeweiligen Elementebene, sondern auf der höchsten Profilebene.

Klicken wir in der Baumstruktur die oberste Profilebene an, öffnet sich rechts das zugehörige Informations-Fenster. Hier sind auch die Constraints enthalten. In der Snapshot-Ansicht werden uns alle Constraints für diese Observation angezeigt, es ist also nicht ersichtlich, ob neue Constraints in dem MIO eingeführt wurden oder nicht. Es ist dafür sinnvoll in die hybrid oder differential Ansicht zu wechseln. In diesen erkennt man deutlicher, welche Constraints für dieses MIO von uns hinzugefügt wurden. 

Und wie genau werden Constraints formuliert?

Schauen wir uns die Constraints einmal genauer an: 

Das Constraint hat als erstes eine Benennung, den sogenannten Key.

Zudem gibt es eine Beschreibung. Diese kann sowohl auf deutsch als auch auf englisch sein.

Die Expression, also die Bedingung, wird mit FHIR-Path ausgedrückt und muss erfüllt sein, wenn sie auf das Element angewendet wird

Für jedes Constraint ist zudem der "Schweregrad" festzulegen, also ob im Falle einer falschen Angabe ein Error oder ein Warning ausgegeben wird. Diese Angabe ist auf simplifier nur in der XML- oder JSON-Ansicht ersichtlich. 

Optional können noch folgende Angaben enthalten sein:

Eine Erklärung, warum die Einschränkung angewendet wird und was dadurch vermieden werden soll (Requirements)

Die URL des Profils, welches die Einschränkung definiert hat

Nehmen wir uns als Beispiel folgendes Constraint: 

Für das Constraint gibt es neben dem notwendigen Key auch eine deutsche Beschreibung "Das Ergebnis kann 0 oder 5 sein". Es wird in der Beschreibung noch nicht ersichtlich, auf welches Element sich das Constraint bezieht. Schauen wir also in den FHIR-Path.

Im FHIR-Path wird zuerst die zugrundeliegende Ressource, also die Observation aufgeführt. Danach folgt die Aufzählung des Elements "value as Quantity"- es geht quasi um einen Wert, der im Datentypen Quantity abgebildet wird. Schauen wir uns das einmal in der Baumstruktur an: Es gibt lediglich einen value, welcher als Quantity abzubilden ist und zwar valueQuantity. Damit haben wir das betreffende Element bereits finden können.  Aus der deutschen Beschreibung können wir jetzt schon ableiten, dass das Ergebnis von valueQuantity entweder 0 oder 5 sein kann. Überprüfen wir dennoch den Rest der Expression: .value=0 - ein Wert darf also null sein. Wir erinnern uns: Im Schritt davor haben wir herausgefunden, dass valueQuantity das betreffende Element ist. valueQuantity kann also den Wert 0 haben. Danach folgt ein or, also ein oder: valueQuantity kann neben dem Wert 0 möglicherweise noch einen weiteren Wert annehmen, schauen wir in das Constraint.

Der zweite Teil des Constraints ist wie auch der erste Teil aufgebaut - es handelt sich wieder um das Element valueQuantity. Der einzige Unterschied ist der Zielwert - hier 5.

Setzt man das Constraint also vollständig zusammen, kann man sagen: valueQuantity kann entweder den Wert 0 oder den Wert 5 annehmen. Andere Werte sind nicht erlaubt. Wir kommen zum gleichen Ergebnis wie bereits in der Beschreibung wiedergegeben wird.

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

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.