Die generellen Vorgaben der Anlage 2b BMV-Ä zur Verordnung digitaler Gesundheitsanwendungen gemäß § 33a SGB V erfordern eine Festlegung zu Inhalt und Form der Verordnung digitaler Gesundheitsanwendungen in elektronischer Form. Die Abbildung der Verordnungsdaten erfolgt mittels FHIR (Fast Healthcare Interoperability Resources). Die Vorgaben hierfür sind in der „Technischen Anlage zur elektronischen Verordnung digitaler Gesundheitsanwendungen (e16D)“ [KBV_ITA_VGEX_Technische_Anlage_EVDGA] enthalten. Das Dokument und die dazugehörigen FHIR-Ressourcen sind unter https://update.kbv.de/ita-update/DigitaleMuster/eVDGA/ und auf https://simplifier.net/evdga veröffentlicht.
Das Inkrafttreten der Vorgaben zur elektronischen Verordnung digitaler Gesundheitsanwendungen wird über den Anforderungskatalog nach § 73 Abs. 9 SGB V für Verordnung von DiGA [EXT_ITA_VGEX_Anforderungskatalog_VDGA] durch die Bundesmantelvertragspartner zu einem späteren Zeitpunkt vereinbart. Dabei wird gewährleistet, dass für die Softwarehersteller ein ausreichender Umsetzungszeitraum gegeben ist, um die gesetzliche Frist zur Einführung zu ermöglichen.
Die KBV hat für alle mit Hilfe von FHIR spezifizierten digitalen Vordrucke eine Reihe von Vorgaben erstellt, um eine formularübergreifend einheitliche Abbildung von identischen Informationen zu gewährleisten. Im Zusammenhang mit der Erstellung der Vorgaben für die elektronische Verordnung von digitalen Gesundheitsanwendungen wurden die formularübergreifenden FHIR-Profile angepasst, um die neuere Version 1.4.0 der KBV-Basis-Profile nutzen zu können. Die aktualisierte Version des „Technischen Handbuchs digitale Muster“ [KBV_ITA_VGEX_Technisches_Handbuch_DiMus] und die dazugehörigen FHIR-Profile der Version 1.2.0_cc sind unter https://update.kbv.de/ita-update/DigitaleMuster/eVDGA/ und auf https://simplifier.net/evdga veröffentlicht.
Mit den Ressourcen für Profile, Kodesysteme (Code Systems) und Wertesätze (Value Sets) der eVDGA-Schnittstelle (eVDGA) in der Version 1.0.0_cc und der formularübergreifenden Schnittstelle (FOR) in der Version 1.2.0_cc erhalten Sie die Möglichkeit, die FHIR-Definitionen der Schnittstelle zu prüfen und Stellung zu nehmen.
Die FHIR-Spezifikation des Release R4 baut auf folgende Basisprofilen auf:
- deutsche Basisprofile von HL7 in der Version 1.4.0
- KBV-Basis-Profile in der Version 1.4.0
- KBV-FOR-Profile in der Version 1.2.0_cc
Die Profil-Ressourcen geben Auskunft darüber, mit welchen Anpassungen sowie Einschränkungen die einzelnen Datenelemente der Basisprofile zu verwenden sind. Die Kodesystem-Ressourcen werden verwendet, um die Existenz eines Kodesystems oder einer Kodesystemergänzung und ihrer Schlüsseleigenschaften zu deklarieren und zu beschreiben, sowie optional einen Teil oder den gesamten Inhalt zu definieren. Kodesysteme definieren, welche Kodes (Symbole und/oder Ausdrücke) existieren und wie sie verstanden werden. Wertesätze verknüpfen Kodesystem-Definitionen und ihre Verwendung in kodierten Elementen. Eine Wertesatz-Ressourceninstanz wählt einen Satz von Kodes aus, indem es in diesem Satz Kodes zusammenfasst, die aus einem oder mehreren Kodesystemen stammen und für die Verwendung in einem bestimmten Kontext vorgesehen sind und verwendet werden können.
Es werden gegenüber den Basisprofilen keine weiteren Erweiterungsressourcen (Extensions) definiert.
Im Rahmen dieser Kommentierung wurden unter dem Simplifier-Projekt https://simplifier.net/evdga alle benötigten KBV-Ressourcen (KBV-eVDGA in der Version 1.0.0_cc und KBV-FOR in der Version 1.2.0_cc) bereitgestellt.
Hinweis
Anders als in der aktuellen Spezifikation von eRezept und eAU referenzieren die Profil-Instanzen nur die Haupt- und Nebenversionsnummer der Profilversionen, um sie unabhängig von der Revisionsnummer der Profilversionen einsetzen zu können.
BEISPIELE
KBV_FHIR_eVDGA_Beispiele_V1.0.0_cc.zip
VALIDIERUNGSPAKET
KBV_FHIR_eVDGA_V1.0.0_cc_zur_Validierung.zip
3 Ergebnisse
| Key | Erstellt | Organisation | Zusammenfassung | Lösung | Kommentierungsergebnis |
|---|---|---|---|---|---|
| EVDGA-20 | 12.12.2023 | gematik GmbH | Fehler bei Validierung des Beispiels evdga-bundle-private-krankenversicherung | Keine Spezifikationsänderung |
Vielen Dank für Ihren Kommentar. Das Beispiel ist korrekt. Die Aussage, dass die Kardinalität von type.coding tatsächlich mit 1..1 angegeben sei, ist dagegen nicht korrekt. Die Kardinalität von Patient.identifier:versichertenId_PKV.type.coding ist mit 2..2 angegeben. Der Grund für die Lösung liegt darin, dass die Slices "versichertenId_PKV" und "versichertennummer_pkv" anhand der zugeordneten Identifier-Profile "http://fhir.de/StructureDefinition/identifier-pkv-kvid-10" und "http://fhir.de/StructureDefinition/identifier-pkv" wegen des identischen Patterns (system": "http://fhir.de/CodeSystem/identifier-type-de-basis", "code": "PKV") nicht unterscheidbar sind. Deshalb wurde in den KBV-Basisprofilen der Version 1.5.0 ein zusätzliches Pattern definiert ("system": "https://fhir.kbv.de/CodeSystem/KBV_CS_Base_identifier_type", "code": "pkv-id"). Diese Lösung hat überdies keinen Bezug zu der vom Validator ausgegebenen Warnung. Diese wird ausgegeben, weil die verwendeten Codes nicht aus dem Valueset "http://hl7.org/fhir/ValueSet/identifier-type" stammen, welches im R4 Identifier-Profil über die Binding Strength "extensible" gebunden ist und das Bindung schon durch das deutsche HL7-Basisprofil erweitert wird. Diese unnötige Warnung ist also durch die HL7 FHIR-Spezifikation selbst bedingt und kann leider nicht per Konfiguration des Validators deaktiviert werden. |
|
Bei der Validierung des im Paket kbv.itv.evdga#1.0.0-cc enthaltenen Beispiels evdga-bundle-private-krankenversicherung meldet der HL7 FHIR Validator (v6.022) folgendes: Warning @ Bundle.entry<span class="error">[2]</span>.resource/<strong>Patient/0821422d-1697-4435-a306-565c1d7fe147</strong>/.identifier<span class="error">[0]</span>.type (line 168, col14): None of the codings provided are in the value set 'IdentifierType' (<span class="nobr"><a href="http://hl7.org/fhir/ValueSet/identifier-type" class="external-link" rel="nofollow">http://hl7.org/fhir/ValueSet/identifier-type<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>|4.0.1), and a coding should come from this value set unless it has no suitable code (note that the validator cannot judge what is suitable) (codes = <span class="nobr"><a href="http://fhir.de/CodeSystem/identifier-type-de-basis#PKV" class="external-link" rel="nofollow">http://fhir.de/CodeSystem/identifier-type-de-basis#PKV<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>, <span class="nobr"><a href="https://fhir.kbv.de/CodeSystem/KBV_CS_Base_identifier_type#pkv-id" class="external-link" rel="nofollow">https://fhir.kbv.de/CodeSystem/KBV_CS_Base_identifier_type#pkv-id<sup><img class="rendericon" src="/images/icons/linkext7.gif" height="7" width="7" align="absmiddle" alt="" border="0"/></sup></a></span>) In dem beigefügten Profil KBV_PR_FOR_Patient ist in dem Slice Patient.identifier:versichertenID_pkv die Kardinalität von type.coding tatsächlich mit 1..1 angegeben. In dem Beispiel oben sind allerdings 2 Codes beim type.coding angegeben: "identifier": [ Ist das Beispiel korrekt? |
|||||
| EVDGA-19 | 07.12.2023 | gematik GmbH | Einheitlicher Umgang mit meta.profile | Vollständig angenommen |
Vielen Dank für Ihren Kommentar. Das Slicing von meta.profile im Profil KBV_PR_EVDGA_HealthAppRequest wird entfernt. |
|
Der Umgang mit meta.profile unterscheidet sich von KBV_PR_EVDGA_HealthAppRequest (Slicing) zu KBV_PR_EVDGA_Bundle (Fixed Value). Grundsätzlich ist die Nachnutzung der Profile schwierig, da viele Felder verboten, Slices geschlossen, und meta.profile hart kodiert werden. Im Rahmen eines Packages wäre der einheitliche Umgang mit meta.profile sinnvoll (also entweder überall Fixed Value oder überall Slice) |
|||||
| EVDGA-5 | 16.11.2023 | gevko GmbH | Fragen rund um das Profi KBV_PR_EVDGA_HealthAppRequest | Sofort abgelehnt |
Vielen Dank für Ihren Kommentar. Die Definition des Codesystems der PZN von DiGA-Verordnungseinheiten stellt derzeit nur ein Platzhalter ohne Inhalt dar. Es kann bei einer nicht auszuschließenden zukünftigen Aufnahme von PZN-Definitionen in das Codesystem nicht garantiert werden, dass Werte für das Element "display" definiert werden und falls dies der Fall sein sollte, dass die korrekten Werte definiert werden. Maßgeblich für die Bezeichnung der Verordnungseinheit sind die Angaben im DiGA-Verzeichnis. |
|
Weshalb ist das Element „DeviceRequest.code<span class="error">[x]</span>:codeCodeableConcept.coding.display“ verboten und weshalb steht die Bezeichnung der DiGA-Verordnungseinheit stattdessen in dem Element „DeviceRequest.code<span class="error">[x]</span>:codeCodeableConcept.text“? |
|||||
