Die FHIR®-Spezifikation 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
-
DIGA1X0X0-66
-
Erstellt
-
12.12.2021
-
Name
-
Veselin Markov
-
Organisation
-
adesso SE
-
Zusammenfassung
-
Zusätzliche FHIR-Ressourcen
-
Beschreibung
-
Zwei zusätzliche FHIR-Ressourcen für eine Einwilligungserklärung und für die Verschreibung der DiGA sind nötig.
Jede DiGA muss von den Nutzern eine Zustimmung für das Verarbeiten der Daten holen. Der FHIR-Consent braucht dafür ein passendes Profil.
Die DiGAs werden verschrieben und können dann bis zu drei Monaten genutzt werden. Aus dem definierten Profil muss ersichtlich sein
1. bis wann die DiGA verwendbar ist
2. ist es ein Probelauf ohne ärztliche Verordnung
3. wurde sie selbst oder auf Rezept durch die Krankenkasse bezahlt.
Vielleicht ist FHIR-CarePlan hier eine Option das umzusetzen.
-
-
-
Key
-
DIGA1X0X0-40
-
Erstellt
-
09.12.2021
-
Name
-
Thomas Liebscher
-
Organisation
-
Philips GmbH
-
Zusammenfassung
-
Allgemeine Bemerkung
-
Beschreibung
-
Es finden häufig unnötige Einschränkungen im Rahmen der Profilierung statt. Das macht es internationalen Anwendungen schwer, konform mit dem Profil zu sein, wenn man nicht gezielt dafür entwickelt. Das wiederum erhöht den Aufwand für internationale Anbieter.
Im Sinne einer offenen und wiederverwendbaren Spezifikation müssen unnötige Einschränkungen und Extensions soweit es geht vermieden werden. Eine Kompatibilität von DIGAs/Apps/Anwendungen rein mit der Basisspezifikation muss immer noch eine Weiterverwendung durch EPA (und MIOs) nutzende Anwendungen ermöglichen. Wir leben in Europa mit einem europäischen Binnenmarkt. Lasst uns offene Spezifiktionen entwickeln und nicht solche eingeengten.
-
