Eine Übersicht zum Zusammenspiel der Ressourcen kann unter In der ePA zu speichernde FHIR®-Ressourcen, Phase I entnommen werden. In diesem Teilabschnitt werden die einzelnen FHIR®-Ressourcen auf jeweils einzelnen Unterseiten dargestellt. Ausgenommen davon sind ValueSets, ConceptMaps und CodeSysteme, die aus Gründen der Übersichtlichkeit gebündelt vorgelegt werden. Eine Ressource ist ein unabhängiger Baustein, der eine bestimmte Semantik hat, beispielsweise beschreibt die Ressource KBV_PR_MIO_EMP_Medication ein Arzneimittel mit allen dazugehörigen Attributen. Aus Gründen der Übersichtlichkeit wurde für die Benennung der Unterseiten das Präfix KBV_PR_MIO_PROJEKTKÜRZEL_RESSOURCENNAME_ weggelassen und nur der verbleibende Teil als Name für die jeweilige Unterseite genutzt.


Nomenklatur

Alle Ressourcen dieser Spezifikation wurden in FHIR® R4 entwickelt und haben folgende Benennung:

https://fhir.kbv.de/TTT/KBV_XX_MIO_EMP_*


Die Auswahl unter TTT ist:

  1. StructureDefinition
  2. CodeSystem
  3. ValueSet
  4. ConceptMap

Die Auswahl unter XX ist:

  1. PR
  2. EX
  3. CS
  4. VS
  5. CM


In dieser Spezifikation werden auf höchster Ebene verschiedene Arten von Ressourcen verwendet:

Profile

Profile beschreiben einen bestimmten Teilaspekt eines Sachverhaltes, also z.B. die behandelnde Person. Profile sind immer durch ihre Bezeichnung (PR = Profil) erkennbar:

https://fhir.kbv.de/StructureDefinition/KBV_PR_MIO_EMP_Practitioner

Extensions

Extensions erweitern ein Profil um bestimmte Informationen, die so nicht vorgesehen waren oder in seltenen Fällen auftreten (80%-Regel). Extensions sind immer durch ihre Bezeichnung (EX = Extension) erkennbar:

https://fhir.kbv.de/StructureDefinition/KBV_EX_MIO_EMP_Follow_Up

Codesystem

Codesysteme sind immer durch ihre Bezeichnung (CS = Codesystem) erkennbar:

https://fhir.kbv.de/CodeSystem/KBV_CS_MIO_EMP_Identifiertyp

ValueSet

Valuesets können als Auswahllisten interpretiert werden. Es können Codes aus verschiedenen Listen zusammengefügt werden, um dem User eine Auswahlliste bereitzustellen. Valuesets sind immer durch ihre Bezeichnung (VS = Valueset) erkennbar:

https://fhir.kbv.de/ValueSet/KBV_VS_MIO_EMP_Observation-Interpretation

ConceptMap

Mit ConceptMaps könne Übersetzungen/Verbindungen zwischen Codes verschiedener Codesysteme erzeugt werden. ConceptMaps sind immer durch ihre Bezeichnung (CM = ConceptMap) erkennbar:

https://fhir.kbv.de/ConceptMap/KBV_CM_MIO_EMP_ConceptMap



Kommentierungen

    • Key

    • EMP1X0X0-274

    • Erstellt

    • 26.04.2024

    • Name

    • Dr. Gerd Bauer

    • Organisation

    • ABDA – Bundesvereinigung Deutscher Apothekerverbände e. V.

    • Zusammenfassung

    • Beispiele

    • Beschreibung

    • Realistische Beispiele für einen gesamten Medikationsplan wären zum Verständnis sehr hilfreich und bereits für die Kommentierung nötig gewesen.
      Falls noch Beispiele ergänzt werden, sollte neben der FHIR-Struktur auch eine ohne FHIR-Kenntnisse "lesbare" Darstellung zur Verfügung gestellt werden.

    • Key

    • EMP1X0X0-192

    • Erstellt

    • 25.04.2024

    • Name

    • Kim Becker

    • Organisation

    • Dedalus HealthCare GmbH

    • Zusammenfassung

    • Harmonisierung zu ISiK wünschenswert

    • Beschreibung

    • Es wäre für uns von großem Vorteil, eine Abstimmung mit den ISiK-Profilen der Stufe 4 zu erwägen, da andernfalls der Implementierungsaufwand erheblich steigt. Wir haben festgestellt, dass es an einigen Stellen Unterschiede gibt, zum Beispiel in der Namensgebung (Medikament, MedikationsListe, MedikationsInformation) sowie in den verwendeten Code-Systemen. Daher wäre eine Abstimmung zwischen MIO42 und gematik äußerst hilfreich.

    • Key

    • EMP1X0X0-144

    • Erstellt

    • 25.04.2024

    • Name

    • Olaf Rode

    • Organisation

    • Fraunhofer FOKUS

    • Zusammenfassung

    • Fehlendes Metadatum [Resource].date

    • Beschreibung

    • Es wäre hilfreich, wenn in den verschiedenen Ressourcen (StructureDefinitions, CodeSystems, ValueSet) das date-Element ergänzt werden könnte. Dies ermöglicht eine zeitliche Einordnung der jeweiligen Versionen und wird insbesondere dann hilfreich, wenn perspektivisch mehrere Versionen verfügbar sind.

    • Key

    • EMP1X0X0-133

    • Erstellt

    • 22.04.2024

    • Name

    • Mark Langguth

    • Organisation

    • Langguth.Digital

    • Zusammenfassung

    • Einheitlichkeit in der Codierung von Observations

    • Beschreibung

    • Die verschiedenen Observations (Creatinine, Pragnancy_Status, Body_Weight, Body_Height etc.) besitzen mal nur einen loinc-Code und mal sowohl einen loinc-Code als auch einen snomed-Code.

      Es ist nicht erkennbar, warum nicht durchgängig beide Codesysteme verwendet werden oder nicht durchgängig nur loinc verwendet wird. Eine Einheitlichkeit wäre wünschenswert.