Seiteninhalt:
Die gematik hat mit dem E-Rezept ein Produkt eingeführt, das zur Digitalisierung der Verordnung, Abgabe und Abrechnung von Rezepten beiträgt. Der gesamte Prozess der Verordnung wird über den zentralen E-Rezept-Fachdienst abgewickelt.
Dieses Feature zielt darauf ab, eine digitale und medienbruchfreie Kommunikation im Zusammenhang mit E-Rezepten zu ermöglichen, beispielsweise zur Anforderung von E-Rezepten.
Derzeit existiert kein strukturierter, dezentraler Kommunikationsweg für E-Rezepte. Diese Spezifikation soll sicherstellen, dass Leistungserbringer im deutschen Gesundheitswesen strukturierte Informationen über E-Rezepte austauschen können.
Ziel dieser Spezifikation ist es, den Versorgungsprozess für Leistungserbringer zu vereinfachen, zu automatisieren und dadurch zu beschleunigen.
Im Folgenden werden grundlegende Merkmale und Konzepte beschrieben, die für die Umsetzung dieses Features wichtig sind.
Anwendungsfälle des Features “KIM-Nachrichten für das E-Rezept” werden nicht über einen zentralen Dienst der TI gelöst, sondern dezentral Peer-to-Peer zwischen Clients auf Basis von FHIR ausgeführt. Daher handelt es sich grundlegend, aufbauend auf dem App-Transport-Framework (ATF) der gematik, um ein FHIR Message Konzept (https://www.hl7.org/fhir/messaging.html). Aus dem App-Transport-Framework werden die Ressourcen “Bundle” und “MessageHeader” genutzt, um einerseits alle Ressourcen zu übermitteln, als auch Informationen über Sender und Empfänger zu halten. Die Funktionsweise und Implementierung des App-Transport-Framework sind im entsprechenden Implementation Guide zu finden.
Dieser Implementation Guide basiert auf Version 1.4.0 des App Transport Frameworks. Die folgende Stufe des ATF MUSS unterstützt werden, um konform zu diesem IG zu sein:
Stufe 1
In dieser Spezifikation dient der unter MessageHeader.eventCode anzugebende EventCode sowohl zur Identifikation des Anwendungsfalls als auch des Nachrichtentyps innerhalb des Anwendungsfalls. So zeigt der Code eRezept_Rezeptanforderung;Rezeptanfrage beispielsweise an, dass es sich um den Anwendungsfall “Rezeptanforderung” sowie um eine initiale Rezeptanforderung eines Anfragenden an einen Verordnenden handelt.
Die in dieser Spezifikation zulässigen EventCodes sind im ServiceIdentifierVS definiert.
Jeder im Implementierungsleitfaden beschriebene Anwendungsfall enthält eine Angabe darüber, welcher EventCode zu verwenden ist.
Unter MessageHeader.focus werden die Ressourcen aufgelistet, die alle relevanten Informationen zu einer Anfrage bündeln. In diesem Projekt übernimmt die FHIR-Ressource ServiceRequest diese Funktion als Trägerressource. MessageHeader.focus listet alle ServiceRequests auf, die als Ausgangspunkt für die Auswertung der Anfragen in einer Nachricht dienen.
Alle Anwendungsfälle in diesem Projekt basieren auf ServiceRequest-Ressourcen, die gemäß FHIR-Spezifikation verwendet werden, um einen Dienst bzw. eine Dienstleistung anzufragen. Der ServiceRequest dient dabei als Trägerressource für die auszutauschenden Informationen.
Jede Nachricht kann mehrere ServiceRequest-Ressourcen enthalten. Jede ServiceRequest besitzt eine eigene requestID und stellt somit eine separate Anfrage dar. Eine detaillierte Beschreibung und Darstellungen sind unter Mehrere Anfragen einzusehen.
Ein einzelner ServiceRequest bzw. eine einzelne Anfrage wird über ServiceRequest.identifier:requestId identifiziert. Über ServiceRequest.requisition können mehrere ServiceRequests mithilfe eines gemeinsamen Identifiers gebündelt werden, um z.B. Vorgänge mit mehreren Anfragen zusammenzufassen.
HINWEIS: Unter Identifier sind weitere vorgaben zu Identifiern getroffen worden.
Folgende Service Requests und damit verbundene Service Anfragen sind derzeit spezifiziert:
Ein ServiceRequest spiegelt neben den fachlichen Informationen auch den Status des Vorgangs wieder. Über das Feld .status kann dargestellt werden, in welchem Zustand sich der Vorgang befindet:
| Status | Bedeutung |
|---|---|
| active | Anfrage ist aktiv und muss noch bearbeitet werden |
| entered-in-error | Anfrage wurde vom Anfragenden storniert |
| revoked | Anfrage wurde vom Verordnenden abgelehnt |
| completed | Anfrage wurde von der zu bearbeitenden Partei erfüllt |
Die in diesem Projekt erzeugten Ressourcen lassen sich mit einem XSLT-Stylesheet in ein HTML überführen, um sie für Anwender sichtbar zu machen. Notwendigkeit und Voraussetzungen sind im Featuredokument gemF_eRp_KIM beschrieben. Das Stylesheet findet sich im GitHub Repository: XSLT-Stylesheet.
Dort sind auch für die Anwendungsfälle PDFs hinterlegt, die eine Beispielhafte Transformation von XML Beispielen zeigen, siehe XSLT Beispiele.
Beispielinstanzen sind unter Beispiele zu finden.
Folgende UseCases sind mit entsprechenden Beispielen beschrieben:
| Name | Description |
| Rezeptanforderung der Pflegeeinrichtung | Anfrage einer Pflegeeinrichtung an einen Verordnenden zur Erstellung eines E-Rezepts für die Heimversorgung |
| Bestätigung der Rezepterstellung für Heimversorgung | Antwort des Verordnenden an die Pflegeeinrichtung mit Bestätigung der E-Rezept-Erstellung für die Heimversorgung |
| Abgabeanforderung mit alternativer Lieferadresse | Anfrage der Pflegeeinrichtung an eine Apotheke zur Belieferung mit alternativer Lieferadresse für die Heimversorgung |
| Abgabeanforderung an Apotheke | Anfrage der Pflegeeinrichtung an eine Apotheke zur Belieferung mit dem E-Rezept für die Heimversorgung |
| Bestätigung der Belieferung mit alternativer Lieferadresse | Antwort der Apotheke an die Pflegeeinrichtung mit Bestätigung der Belieferung an alternative Lieferadresse |
| Bestätigung der Belieferung durch Apotheke | Antwort der Apotheke an die Pflegeeinrichtung mit Bestätigung der Belieferung für die Heimversorgung |
| UC1-Multi-1 Initiale Rezeptanforderung | Dieses Beispiel bildet ein Message Bundle einer initialen Rezeptanforderung mit mehreren Anfragen an den Arzt ab. |
| UC1-Multi-2 erfüllte Rezeptanforderung | Dieses Beispiel bildet ein Message Bundle einer erfüllten Rezeptanforderung mit den akzeptierten Anfragen des Arztes ab. |
| UC1-Multi-2 abgelehnte Rezeptanforderung | Dieses Beispiel bildet ein Message Bundle einer erfüllten Rezeptanforderung mit den abgelehnten Anfragen des Arztes ab. |
| UC1-Rejection Ablehnung einer Rezeptanforderung | Dieses Beispiel bildet ein Message Bundle mit einer Ablehnung des Arztes einer Rezeptanforderung ab. |
| UC1-Storno-1 stornierte Rezeptanforderung | Dieses Beispiel bildet ein Message Bundle einer stornierten Rezeptanforderung an den Arztes ab. |
| Beispiel Medication Dispense | Beispielhafte MedicationDispense eines Arzneimittels, das beliefert werden soll |
| MessageHeader Pflegeeinrichtung an Verordnenden (UC1) | Message Header für Rezeptanforderung der Pflegeeinrichtung an Verordnenden für Heimversorgung |
| Rezeptanforderung der Pflegeeinrichtung | ServiceRequest der Pflegeeinrichtung zur Anforderung eines E-Rezepts beim Verordnenden für die Heimversorgung |
| Name | Description |
| Rezeptanforderung für Patienteneinlösung | Anfrage einer Pflegeeinrichtung an einen Verordnenden zur Erstellung eines E-Rezepts für Patienteneinlösung (Flowtype 160/200) |
| Bestätigung der Rezepterstellung für Patienteneinlösung | Antwort des Verordnenden an die Pflegeeinrichtung mit Bestätigung der E-Rezept-Erstellung zur Patienteneinlösung |
| MessageHeader Pflegeeinrichtung an Verordnenden (UC2) | Message Header für Rezeptanforderung zur Patienteneinlösung von Pflegeeinrichtung an Verordnenden |
| Rezeptanforderung für Patienteneinlösung | ServiceRequest der Pflegeeinrichtung zur Anforderung eines E-Rezepts für Patienteneinlösung |
| Name | Description |
| Nachrichtenkopie der Apothekenrezeptanforderung | Kopie der Rezeptanforderung der Apotheke, die an die Pflegeeinrichtung gesendet wird |
| Rezeptanforderung der Apotheke an Verordnenden | Anfrage einer heimversorgenden Apotheke an einen Verordnenden zur Erstellung eines E-Rezepts |
| Nachrichtenkopie der Rezeptbestätigung | Kopie der Bestätigung der E-Rezept-Erstellung, die an die Pflegeeinrichtung gesendet wird |
| Bestätigung der Rezepterstellung für Apotheke | Antwort des Verordnenden an die Apotheke mit Bestätigung der E-Rezept-Erstellung |
| Name | Description |
| Rezeptanforderung für Zytostatika-Zubereitung | Anfrage einer Apotheke an einen Verordnenden zur Erstellung eines E-Rezepts für anwendungsfertige Zytostatika-Zubereitungen |
| Bestätigung der Zytostatika-Rezepterstellung | Antwort des Verordnenden an die Apotheke mit Bestätigung der E-Rezept-Erstellung für Zytostatika-Zubereitungen |
Die Beispiele tragen jeweils das Präfix zum entsprechenden UseCase und der entsprechenden Sequenz. Bsp: UC1-3-* ist ein Beispiel, was UC1 zugeordnet ist und den dritten Schritt in der Abfolge entspricht. Für UC1 gibt es auch Beispiele für Stornierung und Ablehnung.
HINWEIS: Die Beispiele, die in dieser Spezifikation auf Simplifier vorhanden sind verwenden URL-Referenzen. Dies dient der Anschaulichkeit und dem Nachvollziehen von Ressourcen und Referenzen. Für den produktiven Einsatz sollten absolute Referenzen mit UUID’s verwendet werden: “urn:uuid:e615aa46-30f3-4d3f-b3f1-3274ad314b5c”.
Die folgenden Videos demonstrieren die Anwendungsfälle aus Sicht der Akteure der in diesem IG aufgeführten Akteure (Ein Klick auf den Link führt zum Video auf Youtube):