In den Anwendungsszenarien wird beschrieben, ob und wie häufig ein bestimmtes Element abhängig vom Kontext bei einem Eintrag vorliegen kann bzw. muss. Erläuterungen hierzu sind hier zu finden.

Hier sind die Szenarien für das Notfalldaten-Management gelistet. Es gibt insgesamt 5 Szenarien:

  1. DPE, das Szenario für den Datensatz Persönliche Erklärungen der versicherten Person
  2. NFD, das Szenario für den Notfalldatensatz
  3. Gemeinsame Daten, das Szenario für die Angaben zur versicherten Person
  4. IPS Kardinalitäten, das Szenario für die Darstellung der Inhalte in einer IPS nach DIN EN 17269:2020-04
  5. Wiederverwendbare Elemente, das Szenario für die wiederverwendbaren Elemente wie im Abschnitt wiederverwendbare Elemente der NFDM-Spezifikation beschrieben

Es ist wichtig, dass die Szenarien DPE und NFD getrennt sind, da es eine Vorgabe des NFDM ist, dass die beiden Datensätze voneinander isoliert verwendet werden können. Die Einwilligung für die Nutzung des einen oder anderen Datensatzes kann durch die versicherte Person separat vergeben werden.

Die Bedeutung der Kardinalitäten/Konformitäten ist wie folgt:

  • 1...n M: Das Element muss mindestens einmal und darf höchstens n-mal vorkommen
  • 0...n R: Das Element muss gar nicht und darf höchstens n-mal vorkommen. Zu beachten: die Information, die das Element darstellt, ist wichtig, sodass in einem Softwaresystem ein Hinweis erscheinen sollte, der die bearbeitende Person daran erinnert, das Element auszufüllen, wenn dies möglich ist
  • 0...n: Das Element muss gar nicht und darf höchstens n-mal vorkommen
  • C Bedingung: Das Vorhandensein des Elementes ist an eine Bedingung geknüpft

Die Kardinalitäten/Konformitäten werden in FHIR® wie folgt umgesetzt (n ist eine ganze Zahl, 0 oder *)

  • 1...n M: 1...n
  • 0...n R: 0...n
  • 0...n: 0...n
  • C Bedingung: Bedingung

DPE

Das Szenario DPE beschreibt, wie Daten zum Datensatz der Persönlichen Erklärungen eingetragen werden. In der Anwendung NFDM, wie sie zur Zeit auf der eGK verwendet wird, ist die ärztliche behandelnde Person im Moment die einzige Person, die berechtigt ist, Daten anzulegen. Um dies zu ermöglichen, muss die versicherte Person ihre Einwilligung erteilen. In der Implementierung des vorliegenden Informationsmodells soll es aber auch möglich sein, dass die versicherte Person selbst die Einträge in dem DPE bearbeiten kann. Daher gibt es in diesem Szenario zwei Akteure: die ärztliche behandelnde Person und die versicherte Person. Für die initiale Erstellung eines DPE gelten die gleichen Kardinalitäten und Konformitäten wie für die spätere Bearbeitung.


NFD

Das Szenario NFD beschreibt, wie Daten in den Notfalldatensatz eingetragen werden. Der NFD wird durch die ärztliche behandelnde Person ausgefüllt. Diese bestätigt die eingegebenen Daten mittels Signatur. Für die initiale Erstellung eines NFD gelten die gleichen Kardinalitäten und Konformitäten wie für die spätere Bearbeitung.


Gemeinsame Daten

Das Szenario Gemeinsame Daten beschreibt, wie die Daten der versicherten Person eingetragen werden. Diese Daten kommen sowohl in DPE als auch in NFD vor. Wenn einer der beiden Datensätze angelegt wird, muss dieser Abschnitt ausgefüllt werden. Für die initiale Erstellung der gemeinsamen Daten gelten die gleichen Kardinalitäten und Konformitäten wie für die spätere Bearbeitung.


IPS

Das Szenario IPS beschreibt, wie Inhalte in einer IPS platziert werden könnten. Es sind nur diejenigen Abschnitte der IPS nach DIN EN 17269:2020-04 aufgeführt, die mit Inhalten aus dem NFDM befüllt werden können. Eine ausführliche Beschreibung der Umsetzung von Kardinalitäten und Konformitäten aus der IPS findet sich in den folgenden Eigenschaften des Datensatzes: "Umsetzung der Konformitäten der IPS in diesem Informationsmodell", Definition der Konformitäten der IPS aus der DIN EN 17269:2020-04". Mehr Informationen zu den Unterschieden zwischen dem NFDM und der IPS findet sich in den Operationalisierungshinweisen zu den jeweiligen Abschnitten.


Wiederverwendbare Elemente

Das Szenario "Wiederverwendbare Elemente" beschreibt die Kardinalitäten und Konformitäten der wiederverwendbaren Elemente wie in der Spezifikation des NFDM definiert.




Kommentierungen

    • Key

    • PKA1X0X0-61

    • Erstellt

    • 03.10.2021

    • Name

    • Ralf Franke

    • Organisation

    • gevko GmbH

    • Zusammenfassung

    • Berücksichtigung der International Patient Summary IPS)

    • Beschreibung

    • Die Möglichkeit, Daten aus der IPS verlustfrei in die PKA zu importieren und auch wieder zurück, sollte für die Zukunft berücksichtigt/offengehalten werden.
      Die betreffenden Elemente der FHIR-Spezifikation der IPS könnten in der PKA FHIR-Spezifikation als „optional“ definiert werden.
      Die Steuerung der Verwendung (soll das Element benutzt werden oder nicht) kann auf der Seite der Anbieter der TI-Systeme im Rahmen der funktionalen Umsetzung erfolgen.

    • Key

    • PKA1X0X0-40

    • Erstellt

    • 01.10.2021

    • Name

    • Morten Ernebjerg

    • Organisation

    • D4L data4life gGmbH, partner in the EU-funded Smart4Health project

    • Zusammenfassung

    • Grund für die Verwendung von Extension KBV_EX_Base_Terminology_German?

    • Beschreibung

    • Der Grund für die Verwendung und Struktur von der Extension KBV_EX_Base_Terminology_German für deutsche display Texts ist uns nicht ganz klar.

      1. Es gibt schon einen Core FHIR Extension für die Übersetzung eines Strings (<span class="nobr"><a href="http://www.hl7.org/fhir/extension-translation.html" class="external-link" rel="nofollow">http://www.hl7.org/fhir/extension-translation.html<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>), die scheinbar auch verwendet werden könnte
      2. Der KBV-Extension erscheint unnötig verschachtelt, zumal nur ein einziger String enthalten ist (da würde eine einfache Extension scheinbar reichen) - vgl. dazu auch Extension KBV_EX_MIO_NFD_Medication_Name (<span class="nobr"><a href="https://simplifier.net/pka/kbvexmionfdmedicationname" class="external-link" rel="nofollow">https://simplifier.net/pka/kbvexmionfdmedicationname<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>).
      3. Übersetzungen für Code System display Labels kann auch mit Code System Supplements abgedeckt werden (wie in den deutschen Basisprofile, z.B. <span class="nobr"><a href="https://simplifier.net/basisprofil-de-r4/administrative-gender-supplement" class="external-link" rel="nofollow">https://simplifier.net/basisprofil-de-r4/administrative-gender-supplement<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>).

    • Key

    • PKA1X0X0-39

    • Erstellt

    • 01.10.2021

    • Name

    • Morten Ernebjerg

    • Organisation

    • D4L data4life gGmbH, partner in the EU-funded Smart4Health project

    • Zusammenfassung

    • Genereller Profilierungsansatz

    • Beschreibung

    • Die Entscheidung für eine "engen" Profilierungsansatz mit vielen 0..0-Kardinalitäten usw. wurde bei der Vorstellung am 08.09.2021 relativ gründlich besprochen. Hier möchten wir nur kurz einige Kommentare dazu festhalten, die uns besonders mit Hinblick auf internationalen Datenaustausch wichtig erscheinen:

      • Ein offener Profilierungsansatz wäre durchaus kompatibel mit dem Wunsch, die Anwender nicht zwangsläufig mit Datenelement außerhalb der NFD/DPE zu konfrontieren. Man könnte alle NFD/DPE-Elemente als "must-support" setzen und die anderen Elemente unprofiliert lassen (wie es in dem FHIR IPS IG Gemacht wird). Anwendungen könnten dann nur "must-support" Elementen bei (einfachen) Datenanzeige und -eingabe darstellen, und so die Daten auf den NFD einengen.
      • Der enge Profilierungsansatz erschwert die Übernahme von passenden Daten, die schon als FHIR vorliegen (z.B. als IPS FHIR Bundle oder aus dem MII-Systemen) oder für die es Standardmappings auf FHIR gibt. Auch wenn die PKA-Elemente konform befüllt sind, muss trotzdem zusätzliche Business-Logik implementiert werden, um Elemente zu entfernen, die in PKA wegprofiliert sind.
      • Falls die PKA später erweitert wird, wird es zu Rückwärtsinkompatibilitäten führen, wenn die neu hinzugefügten Elementen vorher wegprofiliert waren (was fast immer der Fall wäre).