Dieser Implementation Guide verwendet die Schlüsselwörter MUSS, DARF NICHT, SOLL NICHT und KANN als deutsche Pendants des RFC 2119, um Anforderungen als Ausdruck normativer Festlegungen zu kennzeichnen.
Der Medication Service MUSS als Ausprägung eines FHIR Data Service sämtliche Anforderungen aus [IG_TICommon#Medication] berücksichtigen.
Der Medication Service MUSS als FHIR Data Service der ePA sämtliche Anforderungen aus [IG_EPABasic#Medication] berücksichtigen.
Schnittstellenadressierung
Der Medication Service MUSS sämtliche FHIR-Schnittstellen unter den folgenden Pfaden verfügbar machen:
[base]/epa/medication/api/v1/fhir/
[base]/epa/medication/render/
wobei [base] einem gültigen Pfadnamen eines VAU-Kanals nach folgendem Schema entsprechen muss:
http://epa4all
Schnittstellenimplementierung
Der Medication Service MUSS zusätzlich folgende HTTP Status Codes unterstützen:
Code
Beschreibung
Error Code
Anmerkung
423
If the insurant objected to the medication process or objected to the submission of prescription and dispensation data into the ePA system, the Medication Service is locked.
locked
Tabelle: HTTP Status Codes für die Medication-Service-Antwortnachrichten
Der Medication Service MUSS die in diesem Implementation Guide definierten Schnittstellen (d.h. Query API, Operation API und Render API) implementieren und dabei die Vorgaben der [FHIR-Spezifikation] berücksichtigen. Der Anbieter des ePA-Aktensystems MUSS die Konformität in einem Zulassungsverfahren nachweisen.
Falls der Versicherte der Teilnahme am digital gestützten Medikationsprozess (d.h. "medication = deny") und dem Einstellen von Verordnungsdaten und Dispensierinformation durch den E-Rezept-Fachdienst nicht widersprochen hat (d.h. "erp-submission = permit") MUSS das ePA-FdV dem Versicherten beim Aufruf der elektronischen Medikationsliste (eML) erkenntlich machen, dass die eML aufgrund des derzeitigen Widerspruchs durch Leistungserbringer nicht eingesehen und zur Behandlung des Versicherten genutzt werden kann.
Das ePA-FdV KANN es dem Nutzer ermöglichen für sein Aktenkonto oder für das Aktenkonto des zu Vertretenden unter Verwendung von der Operation API: Medikationsliste abrufen (eML) oder der Query APIs die Medikationsliste oder deren Details anzuzeigen bzw. nach Details zu suchen.
Das Primärsystem MUSS entweder Operation API: Medikationsliste abrufen (eML), Query APIs oder Render API: Medikationsliste abrufen (eML) implementieren, um die Medikationsliste oder deren Details anzuzeigen bzw. nach Details zu suchen.
FHIR-spezifische Anforderungen
Server-spezifische Festlegungen
Die folgenden Rahmenbedingungen hinsichtlich der FHIR-Spezifikation sind für den Medication Service festgelegt.
Der E-Rezept-Fachdienst muss sich bei jeder Übertragung von Daten in den Medication Service auf einen bestimmten Versicherten beziehen. Dazu böte es sich an, eine im Medication Service hinterlegte FHIR Patient-Ressourceninstanz direkt zu referenzieren. Aufgrund der gesetzlich intendierten, fehlenden Leseberechtigung des E-Rezept-Fachdienstes ist das jedoch nicht möglich, sodass stattdessen lediglich ein KVNR-Identifier für die Zuordnung zu einem bestimmten Versicherten übertragen wird. Konkret MÜSSEN E-Rezept-Fachdienst sowie Medication Service deshalb sicherstellen, dass die FHIR-Elemente MedicationRequest.subject.identifier sowie MedicationDispense.subject.identifier an den von HL7 Deutschland e.V. definierten Datentyp Identifier für Patient gebunden sind.
Das Löschen von Verschreibungsdaten oder Dispensierinformationen innerhalb des E-Rezept-Fachdienstes wird im Medication Service über ein Ändern des Status (d.h. Status = “cancelled”) der jeweiligen Ressourceninstanz umgesetzt.
Für die FHIR Operations ist es erforderlich, dass eine Referenzierung der Ressourcen innerhalb der Parameter-Instanz möglich ist.
De-Duplizierung
Die zentrale De-Duplizierung bei inhaltlich identischen Ressourcen im Medication Service ist von entscheidender Bedeutung, um sowohl den Nutzen als auch die Qualität der Daten im Medication Service zu gewährleisten. Durch den nachstehenden Ansatz wird vermieden, dass ePA-Clients eigene, möglicherweise unterschiedliche Aggregierungsalgorithmen dezentral implementieren, was zu Inkonsistenzen in den Daten des Medication Service führen könnte. Zusätzlich verbessert eine zentrale De-Duplizierung die Verknüpfbarkeit und Integration der vorhandenen FHIR-Ressourcen.
Zur eindeutigen Identifizierung werden im Rahmen einer Verschreibung und ihr zugeordnete Dispensierinformationen die folgenden Identifier erzeugt und den notwendigen FHIR-Ressourcen hinzugefügt:
Der Medication Service MUSS für jede MedicationRequest-, MedicationDispense- und Medication-Ressource einen RxPrescriptionProcessIdentifier erzeugen und dieser hinzufügen.
Der RxPrescriptionProcessIdentifier MUSS nach dem Schema (E-Prescription-ID + "_" + authoredOn[YYYYMMDD]) generiert werden.
Die Erzeugung dieses Identifiers MUSS durch den Medication Service erfolgen.
Beispiel Extension für die Ressourcen Medication und MedicationDispense
Der Medication Service MUSS für jede MedicationRequest-, MedicationDispense- und Medication-Ressource einen RxOriginatorProcessIdentifier erzeugen und dieser hinzufügen.
Der RxOriginatorProcessIdentifier MUSS nach dem Schema (Resource-ID + "_" + Prescription-ID) generiert werden.
Dieser Identifier MUSS jede Prescription-ID mit der ursprünglichen Resource-ID des Erstellungssystems verknüpfen, um eine präzise Nachverfolgung und Koordination der Arzneimitteldaten zu gewährleisten.
Die Erzeugung dieses Identifier MUSS durch den Medication Service erfolgen.
Anforderungen an den EPAMedicationUniqueIdentifier
Dieser im Medication Service erzeugte Identifier an Medication-Ressourcen stellt die Eindeutigkeit anhand von Hashwerten über Pharmazentralnummer (PZN), Wirkstoff oder Freitext sicher. Von der Hashwertbildung ausgenommen sind die FHIR-Elemente id, identifier, meta, amount, batch sowie status.
Die Erzeugung des EPAMedicationUniqueIdentifier MUSS für jede Medication beim Einstellen in den Medication Service durch die Geschäftslogik der entsprechenden FHIR-Operation generiert und der entsprechenden Medication hinzugefügt werden. Falls beim Hinzufügen einer Medication in den Medication Service ein Wert für den EPAMedicationUniqueIdentifier vorhanden ist, MUSS dieser durch den Medication Service ersetzt werden.
Der Medication Service MUSS vermeiden, contained Medication-Elemente einer Medication-Instanz einen EPAMedicationUniqueIdentifier hinzuzufügen.
Die contained Medication-Ressourcen müssen jedoch bei der Generierung des EPAMedicationUniqueIdentifier der übergeordneten Medication-Instanz berücksichtigt werden. Die enthaltene Medication bleibt innerhalb der Hauptinstanz ohne eigenständige Identifizierung.
Der Medication Service MUSS die einzelnen Bestandteile in folgender Reihenfolge in die Hash-Berechnung einfließen lassen:
Medication.code – Alle Kodierungen in der Reihenfolge ihrer Angabe in der Medication-Instanz.
Medication.code.text – Nach Entfernung von Leerzeichen und Umwandlung in Kleinbuchstaben.
Medication.form – Alle Kodierungen in der Reihenfolge ihrer Angabe in der Medication-Instanz.
Falls ein ingredient.itemCodeableConcept vorhanden ist, werden die Kodierungen und der Text extrahiert.
Falls eine ingredient.strength vorhanden ist, werden die numerischen Werte und Einheiten verarbeitet.
Falls ingredient.itemReference vorhanden ist, wird die Referenz gespeichert und erst nach der Verarbeitung von ingredient.itemCodeableConcept behandelt.
Alphabetische Sortierung der Ingredients – Nach der Kombination der Werte müssen alle Ingredients alphabetisch sortiert werden.
Enthaltene Medications (contained) – Falls eine über ingredient.itemReference referenzierte contained Medication existiert, wird sie rekursiv verarbeitet und alphabetisch sortiert.
Extensions – Berücksichtigung spezifischer Extensions mit der entsprechenden URL, wobei die Werte in Kleinbuchstaben umgewandelt, Leerzeichen entfernt und alphabetisch sortiert werden.
Der daraus resultierende Hashwert wird in Großbuchstaben dargestellt und stellt den eindeutigen EPAMedicationUniqueIdentifier dar.
Der Medication Service MUSS den EPAMedicationUniqueIdentifier mittels des SHA-256-Algorithmus generieren.
Eine Beispielimplementierung für die Generierung eines SHA-256-basierten Hash-Werts ist auf GitHub veröffentlicht und steht als Referenz zur Verfügung.
Rückgabewerte
Der Medication Service MUSS die Funktion GET [base]/epa/medication/api/v1/fhir/metadata implementieren. Diese Funktionalität stellt sicher, dass bei einem Aufruf von /metadata das FHIR CapabilityStatement des Servers mit dem Namen EPAMedicationServiceServer zurückgegeben wird. Dieses Capability Statement bietet eine detaillierte Beschreibung der Fähigkeiten des Medication Service und ist entscheidend für das Verständnis der unterstützten FHIR-Funktionalitäten.
Der Medication Service MUSS bei der Verarbeitung von FHIR-Operationen spezifische Statusmeldungen im Format EPA Medication Service Operation Outcome bereitstellen. Diese Statusmeldungen MÜSSEN dem Value Set EPAMSOperationOutcomeDetailsVS entsprechen und in den folgenden Fällen ausgegeben werden:
SVC_IDENTITY_MISMATCH – Die Telematik-ID im ID-Token oder die KVNR im x-insurantid HTTP-Header stimmt nicht mit den FHIR-Daten überein.
MEDICATIONSVC_NO_VALID_STRUCTURE – Ungültige Datenstruktur im Medication Service
MEDICATIONSVC_PRESCRIPTION_NO_EXIST – Verschreibung nicht im Medication Service vorhanden.
MEDICATIONSVC_PRESCRIPTION_DUPLICATE – Doppelte Verschreibung im Medication Service erkannt.
MEDICATIONSVC_PRESCRIPTION_STATUS – Operation für den aktuellen Verschreibungsstatus nicht zulässig.
MEDICATIONSVC_DISPENSATION_NO_EXIST – Dispensierung nicht im Medication Service vorhanden.
MEDICATIONSVC_DISPENSATION_STATUS – Operation für den aktuellen Dispensierungsstatus nicht zulässig.
MEDICATIONSVC_OPERATION_SUCCESS – Operation erfolgreich im Medication Service abgeschlossen.
MEDICATIONSVC_PARAMETERS_REFERENCE_NO_EXIST – Nicht auflösbare Referenz in den übergebenen Parametern.
Der Medication Service MUSS sicherstellen, dass diese Statusmeldungen in einer konsistenten und maschinenlesbaren Form ausgegeben werden, um eine eindeutige Fehlerbehandlung zu ermöglichen.
Validierung
Der Medication Service MUSS bei der Validierung der FHIR-Schema- und Strukturvorgaben für FHIR-Operationen, die ausschließlich vom E-Rezept-Fachdienst genutzt werden, auf die Validierung der KBV-Schlüsseltabellen verzichten.
Die strukturelle FHIR-Validierung der Eingabedaten muss sich auf das FHIR-Schema und die korrekte Verwendung der Ressourcen und Datentypen beschränken.
Eine Prüfung auf zulässige Werte innerhalb der KBV-Schlüsseltabellen (z. B. für Darreichungsformen) darf nicht erfolgen.
Der E-Rezept-Fachdienst gilt als vertrauenswürdiger Fachdienst und verwaltet die KBV-Schlüsseltabellen über einen eigenen Aktualisierungsmechanismus.
