WAS SIND WICHTIGE ASPEKTE IM MIO-KONTEXT? Constraints und Operationalisierungshinweise

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.