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:

INFORMATIONSMODELL

FHIR®-SPEZIFIKATION

Versicherte/r PatientInKBV_PR_MIO_NFD-DPE_Patient
Datensatz persönliche Erklärungen

KBV_PR_MIO_NFD-DPE_Bundle

Persönliche Erklärungen

KBV_PR_MIO_DPE_Composition_DPE

KBV_PR_MIO_NFD-DPE_Consent_Active_Advance_Directive

KBV_EX_MIO_DPE_Consent_Description_File_Location

KBV_EX_MIO_DPE_Consent_Description

KBV_PR_MIO_DPE_Consent_Personal_Consent

NotfalldatensatzKBV_PR_MIO_NFD_Composition_NFD
NFD_Versicherter_EinwilligungKBV_PR_MIO_NFD-DPE_Consent_Active_Advance_Directive
Schwangerschaft

KBV_PR_MIO_NFD_Diagnostic_Report_Pregnancy

KBV_PR_MIO_NFD_Observation_Pregnancy_Calculated_Delivery_Date

KBV_PR_MIO_NFD_Observation_Pregnancy_Status

Allergie/Unverträglichkeit gegen ArzneimittelKBV_PR_MIO_NFD_Allergy_Intolerance
Implantat

KBV_PR_MIO_NFD_Device_Implant

KBV_PR_MIO_NFD_Device_Use_Statement_Implant

KBV_EX_MIO_NFD_Date_Implantation

KommunikationsstörungKBV_PR_MIO_NFD_Condition_Communication_Disorder
Weglaufgefährdung/HinlaufgefährdungKBV_PR_MIO_NFD_Condition_Runaway_Risk
Sonstige HinweiseKBV_PR_MIO_NFD_Observation_Note
DiagnoseKBV_PR_MIO_NFD_Condition
ProzedurKBV_PR_MIO_NFD_Procedure
Freiwillige ZusatzinformationKBV_PR_MIO_NFD_Observation_Voluntary_Additional_Information
Medikationseinträge

KBV_EX_MIO_NFD_Medication_Name

KBV_PR_MIO_NFD_Medication_Recipe

KBV_PR_MIO_NFD_Medication_Statement_Administration_Instruction

KBV_EX_MIO_NFD_Medication_Strength

KBV_PR_MIO_NFD_Medication

Diagnostizierende/indizierende Person/Institution

KBV_PR_MIO_NFD_Organization

KBV_PR_MIO_NFD-DPE_Practitioner

KBV_PR_MIO_NFD_Practitioner_Role

AdresseKBV_PR_MIO_DPE_Address
Kommunikationsdaten

KBV_PR_MIO_NFD-DPE_Practitioner

KBV_PR_MIO_NFD_Organization

KBV_PR_MIO_NFD-DPE_Related_Person_Contact_Person

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