Seitenhistorie

Hallo und herzlich willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir Dich auf einen Flug durch unsere Informationsmodelle mitnehmen. Diese findest du in jedem festgelegten MIO in dem Bereich "Hintergrundinformationen". Wir fliegen nun durch das Informationsmodell des MIO Medikation.

Das Informationsmodel stellt den Aufbau eines MIOs aus medizinische Sicht dar. Hier wird gezeigt, welche Informationen im MIO wie abgebildet werden. Darüber hinaus sind Erläuterungen und weiterführende Informationen zu den jeweiligen Datenelementen enthalten. Bei der Erstellung eines MIOs bildet das Informationsmodell die Grundlage für die Entwicklung der FHIR-Spezifikation. 

Ein Informationsmodell ist in der Regel in eine inhaltliche Zusammenstellung, auch "Composition" genannt, und in Profilelemente aufgeteilt. Die "Composition" ist als eine Art Inhaltsverzeichnis zu verstehen und enthält neben strukturdefinierenden Elementen vor allem Referenzen auf Profilelemente. In welchen dann die eigentlichen Informationen erfasst werden. 

In diesem Datenelement beispielsweise, siehst du, wie ein referenzierendes Element aufgebaut ist. Hier erfolgt der Verweis auf die Medikations-Informations-Liste. Wir erkennen bereits an Kardinalität und Konformität, dass es in jeder Instanz des MIO Medikation genau eine Medikations-Informations-Liste geben muss. Genauere Erklärungen zu Kardinalitäten und Konformitäten finden sich in den Erläuterungen.

Nun folgen wir dem Link und gelangen zu dem Profilelement "Medikations-Informations-Liste".

In der Hierarchie des Informationsmodells sind wir nun im Bereich "Profilelemente" angekommen. Am Anfang der Seite befindet sich immer eine Beschreibung des Elements, gefolgt von den Kardinalitäten und Konformitäten sowie dem FHIR-Mapping. An den untergeordneten Inhalten lässt sich erkennen, welche Informationen in diesem Profilelement erhoben werden. Diese können weitere gruppierende Elemente oder ausfüllbare Elemente sein. 

Wir wollen nun einen Blick darauf werfen, wie die einzelnen Einträge einer Medikationsliste aufgebaut sind.

Hier sehen wir erneut ein referenzierendes Element, das uns zu einem weiteren Profilelement führt. Folgen wir dem Link gelangen wir zu dem Profilelement Medikations-Information. Hier wird angegeben, wie genau ein bestimmtes Arzneimittel eingenommen oder verabreicht wird. Es ist also das Äquivalent einer Medikationszeile in einem tabellarischen Medikationsplan. 

Auch hier finden sich Beschreibung, Kardinalität und Konformität, sowie das FHIR-Mapping. Außerdem ist zu sehen, dass dieses Profilelement von dem entsprechenden KBV-Basisprofil abgeleitet wurde.

Nun sehen wir uns gemeinsam ein ausfüllbares Element an. Den Status einer Medikations-Information. 

Dieses Element besitzt keine Unterelemente. In unserem Beispiel kann mittels einer Auswahl an vordefinierten Codes angegeben werden, ob ein bestimmtes Arzneimittel tatsächlich gerade eingenommen wird, pausiert oder abgesetzt ist.

Schauen wir zum Ende unseres Rundflugs noch auf die Bereiche Anwendungsszenarien und Übersicht der verwendeten Codesysteme. 

In dem vorliegenden MIO gibt es nur ein Anwendungsszenario. In anderen MIOs sind durchaus aber auch mehrere Szenarien definiert. Diese können sich in Kardinalitäten und Konformitäten unterscheiden. Wir sehen nun in einer Tabelle alle vergebenen Kardinalitäten und Konformitäten für die einzelnen Elemente des Informationsmodells zusammengefasst.

In der Übersicht der verwendeten Codesysteme, werden alle im jeweiligen MIO eingesetzten Codesysteme inklusive weiterer notwendiger Informationen wie z.B. deren Version aufgelistet.

Damit sind wir nun am Ende unseres kleinen Rundflugs angekommen. Wir hoffen, dass wir dir das Informationsmodell als Quelle für den fachlichen Blick auf die Inhalte von MIOs näherbringen konnten. Vielen Dank, dass du uns an Bord begleitet hast.

Hallo und willkommen zu Per Anhalter durch das MIOversum. In diesem Video möchten wir dir kurz zeigen, welche Materialien wir zur Implementierung eines MIO zur Verfügung stellen.

Hier findest du alle unsere festgelegten MIOs. Dabei ist die Struktur immer die gleiche, egal welches MIO du dir ansehen willst.

Sehen wir uns das MIO Telemedizinisches Monitoring mal genauer an. Zunächst möchten wir die Frage klären: Welche Materialien stellen wir zur Implementierung eines MIO zur Verfügung?

Öffnest du das MIO Telemedizinisches Monitoring, gelangst du auf dessen Startseite. Dort findest du allgemeine Informationen wie zum Beispiel was ist das MIO, was kann das MIO und welche Relevanz hat das MIO. In der Navigationsübersicht auf der linken Seite, kannst du zu verschiedenen Menüpunkten wie bspw. den Grundlagen, den verbindlichen Vorgaben oder der Umsetzungsunterstützung springen.  Um die wichtigsten Fakten zum MIO kennenzulernen, solltest du zunächst auf 'Hintergrundinformationen' klicken.

In diesem Bereich findest du allgemeine Informationen, welche zum Verständnis des MIO beitragen. Dazu gehören Antworten auf die Fragen:

Welche Hintergrundinformationen liegen vor:  In den Hintergrundinformationen sind Informationen zu den rechtlichen Rahmen, die fachliche Entwicklungsgrundlage eines MIOs, die Weiterentwicklungen im MIO-Kontext, das Fazit oder die Querverweise hinterlegt.

Welche Anwendungen und  Anwendergruppen betrifft das MIO: In Anwender und Anwendergruppen wird beschrieben, wie das MIO angewendet werden kann und welche Gruppen von Personen es benutzen wird.

welchen Nutzen hat das MIO: Im Nutzen des MIOs wird beschrieben, welchen Nutzen das MIO für versicherte Personen und ärztliches und medizinisches Personal hat.

Was ist im Informationsmodell enthalten: Das Informationsmodell stellt die fachlichen Inhalte hierarchisch dar. Es soll dabei besonders dem medizinischen Fachpublikum eine Übersicht über die Inhalte bieten.

Oder auch die Anwendungsszenarien des MIO sind hier zu finden: In Anwendungsszenarien wird das Szenario wird das Eintragen von Daten in einen Patientenbericht durch die/den Primär behandelnde(-n) Ärztin / Arzt beschrieben

Im Bereich "Verbindliche Vorgaben" findest du alles wichtige zu unserer FHIR-Spezifikation. Klappen wir einmal die linke Navigationsspalte genauer aus um zu sehen, was hier enthalten ist. Neben Informationen zur Festlegung findest du hier auch Informationen zu FHIR und auch der Signatur.

Auf dieser Seite befindet sich das PDF Dokument zur MIO-Festlegung

Auf der Seite FHIR befinden sich beispielsweise Inhalte zu den in der ePA zu speichernden FHIR-Ressourcen, dem Umgang mit Must-Support-Feldern und dem Format der FHIR-Ressourcen. Je nach MIO können noch andere Inhalte aufgeführt werden.

Im Bereich Signatur, Informationen zu dieser.

.Im Bereich der Umsetzungsunterstützung finden du unsere Umsetzungsangebote. Dieses beinhaltet:

unsere Operationalisierungshinweise, dieses sind Empfehlungen, die sich an die umsetzenden IT-Systeme im Rahmen der MIO-Implementierung richten. Es gibt bezüglich unserer MIOs drei Arten von Operationalisierungshinweisen. 

Elementspezifische Operationalisierungshinweise

Spezifische Operationalisierungshinweise: Diese Operationalisierungshinweise gelten übergreifend für ein gesamtes MIO.

und die Übergreifenden Operationalisierungshinweise: Diese Operationalisierungshinweise gelten für alle festgelegten MIOs gleichermaßen.

In unseren FAQs, findest du eine Übersicht über Antworten auf häufig gestellte Fragen zu unseren MIOs und deren Umsetzung. Wir unterscheiden unsere FAQs in folgende Kategorien:

FAQ MIO Spezifisch, Unter dieser Rubrik findest du Fragen und Antworten die sich ausschließlich auf das jeweilige MIO beziehen. 

FQA ePA, hier findest du alle Fragen und Antworten rund um das Zusammenspiel unserer MIOs und der ePA, die für die Umsetzung aller MIOs gleichermaßen relevant sind.

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

FAQ HL7: hier befinden sich Fragen und Antworten zum Thema HL7®, die für die Umsetzung aller MIOs gleichermaßen relevant sind.

und zum Schluss haben wir noch die FAqs Sonstiges; hier findest alle weiteren Fragen und Antworten, die für die Umsetzung aller MIOs gleichermaßen relevant sind.

Wir haben in unsere Rubrik Umsetzungsunterstützung noch die Fallbeispiele, das sind fiktive Beispiele, die medizinisch realistische Situationen abbilden. Sie dienen zur Veranschaulichung des MIOs sowohl aus fachlicher Perspektive als auch bezogen auf die Umsetzung in FHIR®.

Die mio42 bietet ein Validierungspaket an, in diesem sind alle relevanten Dateien, die zur Implementierung benötigt werden, enthalten.

Auf der Austauschplattform GitHub , kannst du Beispieldateien hochladen so das ein Austausch zwischen den implementierenden Systemen von MIOs auch ohne Connectathon möglich ist

Auf Simplifier , werden alle für das MIO erstellten FHIR®-Dateien zur Verfügung gestellt. Dazu gehören neben den FHIR®-Profilen auch die Terminologiedateien wie Codesysteme und ValueSets. über diesen Link können alle MIO Projekte der Kassenärztlichen Bundesvereinigung abgerufen werden. 

In unserer externen Umsetzungsunterstützung , stellen wir materialen zum MIO zur Verfügung, welche das MIO betreffen aber nicht durch die mio42 erstellt werden, bspw. den MIO Baukasten.

Das ist unser Umsetzungsangebot. Schauen wir mal auf unsere Veranstaltungen

Unter "Veranstaltungen" findest du einen Überblick über die unterschiedlichen Veranstaltungsformate und für wen sie geeignet sind. Das kann zum Beispiel eine Support-Session für das jeweilige MIO sein oder ein Connectathon. 

Wenn du Fragen zum MIO Viewer, zu medizinischen Informationen der MIOs, zur semantischen Kodierung, zur FHIR®-Umsetzung oder zu unserer Webseite habt, kannst du diese über unser Support Formular Stellen. Die Anfrage geht bei uns ein und wir geben dir so schnell wie mögliche eine Rückmeldung zu deiner Anfrage. Wir hatten eben schon das Thema Operationalisierungshinweise und  FAQs. Wenn deine Frage interessant für die Allgemeinheit sein könnte, wird aus dieser, ein FAQ oder ein Operationalisierungshinweis.

Um immer auf dem Laufenden zu sein, kannst du dich gerne für unseren IT Newsletter anmelden. Dieser ist für alle implementierenden Systeme, die an der Umsetzung unserer MIOs arbeiten zu empfehlen. Wenn du allgemeine Informationen zu unseren MIOs erhalten möchtest, kannst du auch gerne unseren allgemeinen Newsletter abonnieren.

Wir hoffen, wir konnten dir einen ersten guten Überblick über unsere Seitenstruktur und den Materialien für die Implementierung geben.

Hallo und willkommen zu Per Anhalter durch das MIOVersum. In diesem Video möchten wir dir kurz zeigen, wie du dich in der FHIR-Spezifikation auf simplifier zurecht findest.

Für jedes MIO gibt es ein eigenes simplifier-Projekt. Hier siehst du die Startseite für das Projekt zum PIO Überleitungsbogen V1.0.0

Auf der Startseite findest du allgemeine Hintergrundinformationen zum MIO sowie verschiedene Verlinkungen z. B. auf die entsprechende Projektseite auf mio.kbv.de oder unserem Validierungspaket auf Github.

Weitere Informationen welche du hier auf der Startseite von simplifier finden kannst, ist eine Ressourcen-Übersicht. Hier wird die Anzahl der verwendeten Profile, ValueSets, Codesysteme, Extensions und Conceptmaps aufgeführt.

Zusätzlich gibt es verschiedene Reiter: Resources, Dependencies und Packages sind dabei die wichtigsten.

Unter dem Reiter Dependencies findet man die Projekte, auf welchen das MIO beruht bzw. Projekte, von deren Inhalt unser MIO abhängig ist.  Dazu gehören bei jedem MIO fest angegebene Versionen der KBV-Basisprofile, der Basisprofile von HL7 Deutschland, sowie die FHIR-Core-Spezifikation. Je nach Projekt können auch weitere Abhängigkeiten aufgeführt werden.

Unter dem Reiter Packages findet man das FHIR-Package für das MIO, welches in allen bisher veröffentlichten Versionen verfügbar ist. Dabei wird auch zwischen den Phasen Kommentierung, Benehmensherstellung und Festlegung unterschieden. 

Unter dem Reiter Resources versteckt sich eine Auflistung aller im Projekt spezifizierten Ressourcen. 

In der Auflistung sehen wir, dass jede Ressource in diesem Projekt den Status "Active" aufweist. Dieser wird vergeben, sobald ein MIO festgelegt wird. Die Ressourcen stehen damit zur Verwendung zur Verfügung. In den Phasen der Kommentierung und Benehmensherstellung verwenden wir den Status "Draft", da wir in diesen Phasen noch aktiv Änderungen an den Ressourcen vornehmen.

Schauen wir einmal genauer in ein Profil, nehmen wir dafür den Patienten: 

Die Profile werden in simplifier als Baumstruktur abgebildet. durch klicken, bspw. auf das "+" bzw. "-" kann eine weitere Ebene des Baumes auf- oder zugeklappt werden 

Zu jedem Element können weitere Informationen angezeigt werden. Diese erhält man, indem man mit der Maus über die Elemente fährt. Um das Informationsfenster für ein Element zu fixieren, klickt man auf das Element. Ein weiterer Klick auf das gleiche Element löst die Fixierung. In dem Fenster werden verschiedene Informationen bereitgestellt: Abgebildet werden Constraints, Beschreibungen zu den jeweiligen Elementen oder auch Verlinkungen auf ValueSets, sogenannte ValueSet-Bindings, welche für ein Element zur Verfügung stehen. 

In simplifier ist es möglich, zwischen verschiedenen Ansichten zu wechseln. Es wird zwischen den Ansichten diff, hybrid und snap unterschieden

Mit diff werden Unterschiede zum "Eltern-Profil" angezeigt. Wenn das Profil von einem anderen Profil abgeleitet wurde, ist hier bspw. erkennbar, welche Elemente zusätzlich entfernt oder welche Informationen verändert wurden.

Der snap zeigt, was in dem Profil aktuell alles enthalten ist. Wenn für dich nur wichtig ist, was aktuell nutzbar ist, verwendet am besten diese Ansicht.

Bei hybrid handelt es sich um eine Kombination aus der Anzeige von Snap & Diff. Im Profilbaum und Informations-Fenster sieht man durch Hervorhebung, welche Anpassungen im MIO vorgenommen wurden. Aus "Eltern-Profilen" übernommene Informationen bzw. Vorgaben werden ausgegraut angezeigt.

Wir hoffen, der kleine Einblick in simplifier hat dir gefallen und hilft, damit du dich zukünftig gut in simplifier zurecht findest.

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.