Seitenhistorie

Hier können Hinweise, die im Rahmen der Softwareumsetzung hilfreich sein können, hinterlegt werden. Sie richten sich dementsprechend an die SoftwareherstellerSoftware-Hersteller. Operationalisierunghinweise müssen sinnvoll, zweckmäßig und im gesetzlichen Rahmen angesiedelt sein.

...

• Das MIO PKA ist so gebaut, dass alle Felder aus einem auf der eGK gespeicherten Notfalldatensatz bzw. Datensatz persönliche Persönliche Erklärungen gelesen werden können. Bei der Eingabe neuer Daten ist die Angabe von Codes der Angabe von Freitexten vorzuziehen.

...

Transformationsprotokoll NFDM nach PKA:

• Die Transformation des xmlXML-Schemas, das in der Spezifikation des Notfalldaten-Managements, Version 1.6.0, definiert ist, erfolgte soweit möglich anhand folgender fest definierter Regeln. Konformität/KardinaliätKardinalität:

• Min Occurs 0, Max Occurs 1 - > 0…1 O
• Min Occurs 0, Max Occurs n - > 0…n O
• Min Occurs 1, Max Occurs 1 - > 1…1 M
• Use required: 1..1 M
• Use optional: 0...1 O

...

• String-Datentypen werden, wo möglich, durch Code-Datentypen ergänzt. Wenn ein geeignetes Valueset ValueSet existiert, wird dieses zur Verfügung gestellt, um die Eingabe codierter Elemente zu erleichtern. Grundsätzlich ist die Angabe von Codes der Angabe von Freitexten vorzuziehen.

...

• M Verbindlich (en: Mandatory) (Ausnahmen nicht zulässig): Ein verbindliches Element muss immer vorhanden sein und muss ggf. mit einem gültigen Wert angegeben werden. In diesem Fall sind keine Ausnahmen oder leere bzw. Null-Werte zulässig. Wenn auf ein zusammengesetztes Element Bezug genommen wird (z. B. ein Abschnitt, eine Liste, ein Kennzeichnungskonzept), wird das Vorhandensein der enthaltenen Elemente mittels der Konformitätsregeln dieser Unterelemente bestimmt. Der Empfänger muss die verbindlichen Elemente verstehen. Wenn ein „verbindliches“ Element fehlt, ist das Dokument keine konforme IPS mehr. Ein abgeleitetes Modell (das auch implementierbare Spezifikationen enthält) muss eine äquivalente Konformitätsstrenge einhalten.
• R Erforderlich (en: Required) (Ausnahmen zulässig): Ein erforderliches Element muss immer vorhanden sein und sollte ggf. mit einem gültigen Wert angegeben werden. In diesem Fall sind Ausnahmen oder leere bzw. Null-Werte zulässig. Wenn auf ein zusammengesetztes Element Bezug genommen wird (z. B. ein Abschnitt, eine Liste, ein Kennzeichnungskonzept, ein komplexer Datentyp), wird das Vorhandensein der enthaltenen Elemente mittels der Konformitätsregeln dieser Unterelemente bestimmt. Der Empfänger muss die erforderlichen Elemente verstehen. Wenn ein „erforderliches“ Element fehlt, ist das Dokument keine konforme IPS mehr. Ein abgeleitetes Modell (das auch implementierbare Spezifikationen enthält) muss eine äquivalente Konformitätsstrenge einhalten oder darf diese weiter verschärfen (z. B. von „R“ zu „M“).
• RK Erforderlich, falls bekannt (en: Required, if known): Ein Element, das als „erforderlich, falls bekannt“ bezeichnet ist, sollte angegeben werden. Wenn entsprechende Informationen vorliegen, muss das Element vorhanden sein und ggf. mit einem gültigen Wert angegeben werden. Wenn keine entsprechenden Informationen vorliegen, darf das Element weggelassen werden, leer bleiben oder — je nach Implementierung — mit Ausnahme- oder Null-Werten angegeben werden. Wenn auf ein zusammengesetztes Element Bezug genommen wird (z. B. einen Abschnitt, eine Liste, ein Kennzeichnungskonzept, einen komplexen Datentyp), wird das Vorhandensein der enthaltenen Elemente mittels der Konformitätsregeln dieser Unterelemente bestimmt. Der Empfänger muss die erforderlichen Elemente verstehen. Ein abgeleitetes Modell (das auch implementierbare Spezifikationen enthält) muss eine äquivalente Konformitätsstrenge einhalten oder darf diese weiter verschärfen (z. B. von „RK“ zu „R“).
• C Bedingt (en: Conditional) (verfügt über zugehörige Bedingungsprädikate): Abhängig von den Prädikatsbedingungen darf das Element unterschiedliche Konformitätsstrengen (z. B. O, R, RK) annehmen oder auch nicht vorhanden sein. Ein Prädikat kann einfacher Natur sein (z. B.: „Element A existiert“; „Merkmal b = Wert 1“) oder komplex (z. B.: „Element C existiert“ UND „das Merkmal x von Element D = Wert 2). Ein bedingtes Element darf anhand einer einzelnen Bedingung („wenn Prädikat A, dann ‚Erforderlich‘, sonst ‚Optional‘“) oder mehrerer Bedingungen (z. B. „wenn Prädikat A, dann ‚Erforderlich‘; wenn Prädikat B, dann ‚Optional‘; sonst ‚Nicht vorhanden‘“) bewertet werden. Die resultierende Konformitätsstrenge (M, R, RK, O, ...) wird durch die Bedingungen bestimmt. Wenn auf ein zusammengesetztes Element Bezug genommen wird (z. B. ein Abschnitt, eine Liste, ein Kennzeichnungskonzept, ein komplexer Datentyp), wird das Vorhandensein der enthaltenen Elemente mittels der Kombination der Prädikatsbedingungen dieses das Elements und der Konformitätsregeln von dessen Unterelementen bestimmt. Zum Beispiel: 1) Eine Ausnahme wird nicht ausgelöst, wenn ein erforderliches Unterelement fehlt, sofern das Elternelement ordnungsgemäß weggelassen wird. 2) Eine Ausnahmebedingung wird ausgelöst, wenn ein erforderliches Unterelement fehlt, das Elternelement jedoch vorhanden ist. Abgeleitete Modelle oder implementierbare Spezifikationen müssen eine äquivalente Konformitätsstrenge einhalten; allerdings ist es gestattet, die Konformitätsstrenge zu ändern, wenn die Prädikatsbedingung dies zulässt. Der Empfänger muss die bedingten Elemente — falls erforderlich — verstehen. Zum Beispiel könnte ein bedingtes Element, das optional oder nicht vorhanden sein könnte, von einem abgeleiteten Modell weggelassen und vom Empfänger ignoriert werden. Oder eine Bedingung, durch die ein bedingtes Element erforderlich würde, gilt nicht in einem Rechtssystem; in diesem Fall könnte eine auf das Rechtssystem bezogene Spezifikation dieses das Element weglassen und der Empfänger könnte es ignorieren. Abhängig von den Bedingungen wird bei fehlenden Daten ggf. eine Ausnahme ausgelöst.
• O Optional: Dieses Datenelement kann in einem abgeleiteten Modell, auch bei Implementierungen, weggelassen werden. Der Empfänger darf optionale Elemente ignorieren. Wenn auf ein zusammengesetztes Element Bezug genommen wird (z. B. ein Abschnitt, eine Liste, ein Kennzeichnungskonzept, ein komplexer Datentyp), wird das Vorhandensein der enthaltenen Elemente mittels des Vorhandenseins dieses das Elements und der Konformitätsregeln von dessen Unterelementen bestimmt. Zum Beispiel wird keine Ausnahme ausgelöst, wenn ein erforderliches Unterelement fehlt, sofern das Elternelement weggelassen wird. Der Grund für die Spezifizierung der optionalen Datenelemente liegt darin sicherzustellen, dass Sender und Empfänger die entsprechende semantische Interpretation dieser Elemente verwenden. Es wird keine Ausnahme ausgelöst, wenn die Daten fehlen.

...

• Vorgestellt werden hier die allgemein gültigen Konformitätsdefinitionen von CDA-Dokumenten (Quelle: https://wiki.hl7.de/index.phptitlephp?title=HL7_CDA_Core_Principles#Conformance_information Principles ):

• O: An optional item may be omitted if no data is present, i.e. no corresponding XML attribute or element is sent (marked as “O”)
• R: For required items, lower cardinality is always zero or 1.
• Elements must be present and populated with data if present in the sending system. If no data is available (yet), a null flavor (see below) indicates and possibly classifies the missing information (marked as R).
• Attribute flagged as required must be present in the instance and populated.
• M: For mandatory elements data must be sent and no missing values are allowed, i.e. if the sending system does not have information for mandatory elements the XML instance cannot be created and sent (marked as M).
• NP: no data may be present at all (not permitted)
• C: conditional conformance; typically a conformance table shows the circumstances (conditions) derived from information in the instance and the corresponding cardinalities and conformance statements.

...

Darstellung von Codes:

• Ein Code-Element wird im Informationsmodell immer als ein einziges Element mit dem Datentyp "Code" abgebildet. Das Type Code entspricht einer Information, die durch einen definierten Code aus einem Code-System wird gegebenenfalls im Elementnamen spezifiziert. Ein separates Element für das Codesystem, wie im Informationsmodell NFDM, wird nicht abgebildet. In der FHIR-Umsetzung besteht das Code-Element aus vier Teilen: Code, Displayname, Code-System, Versionausgedrückt wird. Verwendbare Codes können ggf. durch Wertelisten (sog. Valuesets) eingeschränkt sein. Bei der Verwendung dieses Datentyps wird in der Regel der Code, die Bedeutung (das Konzept) in Form eines Wiedergabenamens sowie das entsprechende Codesystem angegeben.

...