Kurzbeschreibung
Übergabe der Daten einer Verordnung Die im FHIR®-Profil abgebildete Information findet sich im Informationsmodell unter 11.1.13.1 Rezeptierdaten/Verordnung, 2. Rezeptierdaten/Verordnung, 2.1 Allgemeine Rezeptierdaten, 2.1.1 Referenz Krankenversicherung, 2.1.11 Noctu, 2.1.13 BVG, 2.1.2 Referenz behandelnde Person / Einrichtung, 2.1.3 Referenz PatientIn, 2.1.4 Rezepttyp, 2.1.5 Gruppierung, 2.1.6 Unfallinformationen, 2.1.6.1 Unfallkennzeichen, 2.1.6.2 Unfalltag, 2.1.6.3 Name des Unfallbetriebs, 2.1.7 Zuzahlungsstatus, 2.1.8 Kennzeichen Rechtsgrundlage, 2.1.9 Ausstellungsdatum, 2.2 Verordnungsinhalt, 2.2.1 Sonderkennzeichen BtM-Rezept, 2.2.12.6 Gebrauchsanweisung, 2.2.2 T-Rezept-Ankreuzfelder, 2.2.2.1 Off-Label, 2.2.2.2 In-Label, 2.2.2.3 Informationsmaterial, 2.2.2.4 Sicherheitsbestimmungen, 2.2.3 Aut idem, 2.2.6 Abgabehinweis, 2.2.7 Dosierung, 2.2.7.1 Kennzeichen, 2.2.7.2 Dosieranweisung und 2.2.9 Anzahl der verordneten Packungen.
Bezeichnung der FHIR®-Ressource
Der FHIR®-Identifikator der FHIR®-Ressource lautet:
https://fhir.kbv.de/StructureDefinition/KBV_PR_VoS_Prescription
Die Ressource kann auf Simplifier.net unter folgendem Link eingesehen werden:
Übersichtsabbildung des Profils
Kommentierungen
-
-
Key
-
VOS2X1X0-53
-
Erstellt
-
09.12.2022
-
Name
-
Robert Fruth
-
Organisation
-
doctolib GmbH
-
Zusammenfassung
-
Inkompatibilität zwischen dem eRezept, der AWST (1.3.0) und der VOS (2.1.0)
-
Beschreibung
-
Es gibt eine Inkompatibilität zwischen dem eRezept, der AWST (1.3.0) und der VOS (2.1.0) bei den MedicationRequest Profilen. Das Element Requester hat unterschiedliche Referenzen.
- eRezept: Practitioner
- AWST: PractitionerRole
- VOS: PractitionerRole
Ein Practitioner kann mehrere assozierte PractitionerRoles haben. Das bedeutet, dass basierend auf dem Practitioner die PractitionerRole nicht eineindeutig ermittelt werden kann.
Somit müssen beide Informationen (Practitioner + PractitionerRole) immer verarbeitet und gespeichert werden, um in einer Software alle Anwendungsfälle auf einer gemeinsamen technischen Basis abbilden zu können (Erstellung eines eRezepts + AWST/VOS Support). Die Profile sollten vereinheilticht werden.
-
-
-
Key
-
VOS2X1X0-52
-
Erstellt
-
09.12.2022
-
Name
-
Robert Fruth
-
Organisation
-
doctolib GmbH
-
Zusammenfassung
-
KBV Basis
-
Beschreibung
-
Wir konnten Ihre Antwort auf unseren ersten Kommentar nicht ganz nachvollziehen. Aus diesem Grund müssen wir hier erneut kommentieren.
Sie schreiben, dass “das Profil des E-Rezepts <span class="error">[...]</span> als Grundlage direkt kopiert und nur an den Stellen angepasst, an denen eine Notwendigkeit für die VoS-SST bestand” wurde.
Was spricht hier gegen ein KBV Basisprofil? Extensions könnten entweder direkt in der Basis hinzugefügt werden, oder hier - im Use-Case-Spezifischen Profil. Für Implementierende und aus Gründen der generellen Ziele der Interoperabilität wäre es durchaus wünschenswert, wenn sowohl das eRezept-Profil, als auch das VOS-Profil dieselbe Basis hätten.
Wenn Sie sich gegen eine KBV Basis entscheiden sollten, würden wir uns wünschen, dass Sie uns die Gründe erläutern könnten, warum genau für dieses Profil keine Basis erstellt wird.
-
-
-
Key
-
VOS2X1X0-41
-
Erstellt
-
10.11.2022
-
Name
-
Robert Fruth
-
Organisation
-
doctolib GmbH
-
Zusammenfassung
-
Vereinheitlichung
-
Beschreibung
-
Das Profil ist nicht von der KBV-Basis abgeleitet. Wie wird die Interoperabilität zwischen dem eRezept MedicationRequest und und dem VOS MedicationRequest gewährleistet? Beide Spezifikation sollten von der Basis abgeleitet werden.
-
