Die Spezifikation des FHIR® beinhaltet die technische Repräsentation des beschriebenen Informationsmodells. Dabei werden sowohl die einzelnen FHIR®-Profile sowie -Ressourcen im Abschnitt FHIR®-Ressourcen, Phase I spezifiziert als auch im Abschnitt Übergreifende FHIR®-Festlegungen, Phase I Festlegungen getroffen, die über die Definition der einzelnen FHIR®-Ressourcen hinausgehend gelten.
Die Namen der FHIR®-Profile weisen Abweichungen zu den Bezeichnungen im Informationsmodell auf, da bei der technischen Repräsentation auf eine der FHIR®-Spezifikation nahe Namensgebung geachtet wurde. So sind z.B. die Namen in FHIR® in der Regel Englisch und im Informationsmodell Deutsch.
Zur Verdeutlichung des Zusammenhangs der Elemente ist in der folgenden Tabelle ein Mapping zwischen den Elementen des Informationsmodells und der technischen Spezifikation in FHIR® dargestellt:
Einige Elemente der FHIR®-Spezifikation haben keine direkt korrespondierenden Elemente im Informationsmodell. Dazu zählen das CodeSystem, ValueSet und die ConceptMap, die für die Abbildung der Wertelisten aus dem Informationsmodell benötigt werden.
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).
-