Spezifische Operationalisierungshinweise

Definition der Konformitäten der IPS aus der DIN EN 17269:2020-04

Dieser Text stammt aus der DIN EN 17269:2020-04:

• 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 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 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 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.

Definition der Konformitäten des eHDSI Patient Summary Templates

Vorgestellt werden hier die allgemein gültigen Konformitätsdefinitionen von CDA-Dokumenten (Quelle: https://wiki.hl7.de/index.php?title=HL7_CDA_Core_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

Umsetzung der Konformitäten der IPS in diesem Informationsmodell

Für die Überführung der Konformitäten und Kardinalitäten der IPS und denen des NFDM für das Szenario "IPS" und den inhaltlichen Vergleich der beiden Datensätze wurden die Konformitäten aus der DIN EN 17269:2020-04 wie folgt umgesetzt (Für die Entscheidung, wie "R" einzuordnen sei, wurde vor allem dieser Hinweis aus der DIN EN 17269:2020-04 berücksichtigt: "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")"):

• M: (1...1) M
• R: (1...1) M
• RK: (0...1) R
• O: (0...1) O
• C: C

Übernahme von Texten aus dem NFDM

Wenn in der NFDM Spezifikation Version 1.6.0 vorhanden, werden die Beschreibungstexte als Zitat in den Beschreibungsabschnitt dieses Informationsmodells übernommen. Falls keine Beschreibungen vorhanden sind, wird dies dargestellt durch den folgenden Hinweis: "Aus der Spezifikation des Informationsmodell Notfalldaten-Management Version 1.6.0: Keine Beschreibung vorhanden."

Freitexte und Datenspende

Für erstellende Systeme:

Gemäß § 363 SGB V können PatientInnen ihre Daten für eine Datenspende freigeben. Hierbei sollte beachtet werden, dass bei Freitextfeldern (String/Freitext) keine Daten hinterlegt werden, die eine eindeutige Zuordnung zu einer Person ermöglichen (z. B. Name, Versichertennummer). Das erstellende System sollte die eintragende Person beim Befüllen von Freitexten darauf hinweisen.

Transformationsprotokoll NFDM nach PKA

Die Transformation des xml-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ä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

Rückwärtskompatibilität zum auf der eGK erstellten Notfalldatensatz

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