UC2: Rezeptanforderung mit Patienteneinlösung
Dieser Anwendungsfall beschreibt den Vorgang einer Rezeptanforderung mit Einlösung durch den Patienten. Der Prozess wird von einer Pflegeeinrichtung initiiert.
Fachliche Beschreibung
In diesem Anwendungsfall initiiert eine Pflegeeinrichtung den Prozess, indem sie eine Rezeptanfrage an einen verordnenden Arzt stellt. In dieser Anfrage ist angegeben, dass die Verordnung vom Patienten eingelöst werden soll.
Der Arzt bearbeitet die Anfrage und erstellt ein E-Rezept mit Flowtype 160/200, damit der Versicherte das E-Rezept selbst einlösen kann. Nach der Erstellung des E-Rezepts erhält der Verordnende die Informationen "PrescriptionID" und "AccessCode" vom E-Rezept-Fachdienst und kann damit einen E-Rezept-Token generieren.
Der verordnende Leistungserbringer übermittelt den E-Rezept-Token, sowie den Patientenausdruck als PDF (s. Feature Dokument gemF_eRp_KIM) anschließend an die Pflegeeinrichtung.
Die Pflegeeinrichtung kann den Patienten informieren, dass das E-Rezept in einer Apotheke eingelöst werden kann und gibt ggf. den Patientenausdruck mit.
Rezeptanforderung
In diesem Anwendungsfall erstellt die Pflegeeinrichtung im Namen des Patienten eine Rezeptanforderung mit der Kennzeichnung zur Patienteneinlösung an einen verordnenden Leistungserbringer. Der verordnende LE stellt ein E-Rezept am E-Rezept-Fachdienst ein und überträgt den E-Rezept Token als Antwort an die Pflegeeinrichtung. Die Pflegeeinrichtung kann nun optional den Versicherten über die Ausstellung des E-Rezeptes informieren.
In der Rezeptanforderung sind medizinische Informationen zum angefragten Arzneimittel, wie auch administrative Informationen enthalten. Die folgenden Beschreibungen liefern detailiierte Informationen, wie eine Rezeptanforderung zu befüllen und auszuführen ist.
[1] Rezeptanforderung
Fachliches Mapping
Die Rezeptanforderung enthält im wesentlichen folgende Informationen:
- MetaDaten zur Nachricht
- Involvierte Parteien
- Angaben zur Medikation
- Weitere Informationen
Das Mapping dieser fachlichen Informationen aus dem Logical Model zu den konkreten Profilen kann unter Mapping für Rezeptanforderung eingesehen werden.
Entsprechend der Informationen und Kardinalitäten sind die Profile zu befüllen.
Verwendung von Profilen
Folgende Profile sind für diesen Übertragungsweg zu nutzen und im ERP Service Request Message Container einzubetten:
| Profil | Referenziert in | Optional |
|---|---|---|
| ERP ServiceRequest Request Header | ERPServiceRequestMessageContainer.entry[0] | |
| ERP ServiceRequest PrescriptionRequest | ERPServiceRequestRequestHeader.focus | |
| ERP ServiceRequest Patient | ERPServiceRequestPrescriptionRequest.subject | |
| ERP ServiceRequest Organization, | ERPServiceRequestPrescriptionRequest.requester | |
| ERP ServiceRequest Practitioner | ERPServiceRequestPrescriptionRequest.performer | x |
| ERP ServiceRequest MedicationRequest | ERPServiceRequestPrescriptionRequest.basedOn | |
| KBV_PR_ERP_Medication_PZN, KBV_PR_ERP_Medication_Compounding, KBV_PR_ERP_Medication_Ingredient, KBV_PR_ERP_Medication_FreeText | ERPServiceRequestMedicationRequest.medication[x] |
Folgendes Klassendiagramm soll die verwendeten Profile graphisch darstellen:
Voraussetzungen
Folgende Bedingungen müssen erfüllt, bzw. Felder gesetzt sein, damit die Nachricht einer Rezeptanforderung entspricht:
| Profil | Bedingung |
|---|---|
| ERPServiceRequestRequestHeader | .eventCode = #eRezept_Rezeptanforderung;Rezeptanfrage |
| ERPServiceRequestPrescriptionRequest | .status = #active |
| ERPServiceRequestPrescriptionRequest | .requester.type = #PFL | #APO |
| ERPServiceRequestMedicationRequest | .extension:redeemByPatient = true |
Folgende FHIR-Constraints wurden für das Profil ERPServiceRequestPrescriptionRequest im Rahmen einer Rezeptanforderung gesetzt:
| Feld | Condition |
|---|---|
| ServiceRequest | If the status is active, the requester must be present. |
| ServiceRequest | If the status is active, then the request must be based on an ERP MedicationRequest. |
Über ServiceRequest.reasonCode und ServiceRequest.reasonReference kann angegeben werden, warum die Medikation angefragt wird.
Angabe der Verordnungsinhalte
Die MedicationRequest Ressource ist nach Profil ERP ServiceRequest MedicationRequest anzugeben. Zur Behandlung von gesonderten Fällen kann in der MedicationRequest Ressource folgendes gesetzt werden:
| Feld | Bedeutung |
|---|---|
| .extension:PriorPrescriptionID | Angabe einer vorherigen Task ID auf die sich die Anfrage bezieht |
| .extension:requestMVO.extension:Kennzeichen | Angabe, ob der Anfragende die Ausstellung des E-Rezeptes im Rahmen einer Mehrfachverordnung wünscht |
| .extension:redeemByPatient | Angabe, ob die angefragte Verordnung durch den Versicherten eingelöst werden soll. Hier muss der verordnende das E-Rezept mit Workflow 160/169 erstellen. |
| .dispenseRequest.quantity | Angabe der gewünschten Packungsmenge des Arzneimittels |
Stornierung - Verordnungsanfrage
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Rezeptanfrage_Storno
Falls der Anfragende die Anfrage stornieren möchte, wird der gleiche ServiceRequest (.identifer:requestId muss gleich sein) erneut an den Verordnenden versendet und
- .status = #entered-in-error
angegeben. Hierzu kann ebenfalls ein Grund unter ServiceRequest.reasonCode angegeben werden.
Ergebnis der Übertragung
Im Falle der erfolgreichen Übertragung sollte der Verordnende alle wesentlichen Informationen zur Verfügung haben, die er für das Ausstellen einer Verordnung benötigt:
- Daten des Patienten, für den die Verordnung erstellt werden soll
- Daten des Anfragenden, an den die Informationen übertragen werden sollen
- Daten zum angefragten Medikament, dass verordnet werden soll
- Optional der Grund und/ oder die Reichweite der aktuellen Medikation
Rezeptanforderung_Bestätigung
[4] Rezeptanforderung_Bestätigung
Der Verordnende kann nach dem Erhalt einer Rezeptanforderung diese prüfen und eine entsprechende Verordnung erstellen, signieren und im E-Rezept-Fachdienst einstellen ([2]).
Der Verordnende erhält in der Antwort vom Fachdienst die PrescriptionID und den AccessCode ([3]). Beide Informationen werden benötigt, um ein E-Rezept in einer Apotheke einzulösen.
Fachliches Mapping
Die Rezeptanforderung_Bestätigung enthält im wesentlichen folgende Informationen:
- MetaDaten zur Nachricht
- Weitere Informationen
Das Mapping dieser fachlichen Informationen aus dem Logical Model zu den konkreten Profilen kann unter
Entsprechend der Informationen und Kardinalitäten sind die Profile zu befüllen.
Verwendung von Profilen
Folgende Profile sind für diesen Übertragungsweg zu nutzen und im ERP Service Request Message Container einzubetten:
| Profil | Referenziert in | Optional |
|---|---|---|
| ERP ServiceRequest Request Header | ERPServiceRequestMessageContainer.entry[0] | |
| ERP ServiceRequest PrescriptionRequest | ERPServiceRequestRequestHeader.focus | |
| ERP ServiceRequest Patient | ERPServiceRequestPrescriptionRequest.subject | |
| ERP ServiceRequest Practitioner | ERPServiceRequestPrescriptionRequest.performer | |
| ERP ServiceRequest MedicationRequest | ERPServiceRequestPrescriptionRequest.basedOn | |
| KBV_PR_ERP_Medication_PZN, KBV_PR_ERP_Medication_Compounding, KBV_PR_ERP_Medication_Ingredient, KBV_PR_ERP_Medication_FreeText | ERPServiceRequestMedicationRequest.medication[x] |
Folgendes Klassendiagramm soll die verwendeten Profile graphisch darstellen:
Voraussetzungen
Folgende Bedingungen müssen erfüllt, bzw. Felder gesetzt sein, damit die Nachricht einer Rezeptanforderungs Bestätigung entspricht.
HINWEIS: Der E-Rezept Token darf bei diesem Anwendungsfall nicht übertragen werden.
| Profil | Bedingung |
|---|---|
| ERPServiceRequestRequestHeader | .eventCode = #eRezept_Rezeptanforderung;Rezeptbestaetigung |
| ERPServiceRequestPrescriptionRequest | .status = #completed |
Folgende FHIR-Constraints wurden für das Profil ERPServiceRequestPrescriptionRequest im Rahmen einer Rezeptanforderung gesetzt:
| Feld | Condition |
|---|---|
| ServiceRequest | If the status is completed, the performer must be present. |
Ablehnung - Verordnung
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Rezeptanfrage_Storno
Der Verordnende kann das Ausstellen der Verordnung auch ablehnen. Hierbei ist ServiceRequest.status auf #revoked zu setzen und ein Grund unter ServiceRequest.reasonCode auszuwählen und anzugeben. Es kann auch ServiceRequest.note genutzt werden, um weitere Hinweise zu geben, warum die Anfrage storniert wurde.
Ergebnis
Sobald das PVS die Anfrage bearbeitet und eine Antwort an die Pflegeeinrichtung versendet hat, ist der Vorgang für den Verordnenden beendet.
Die Pflegeeinrichtung hat nun die Information, dass die Anfrage bearbeitet wurde und den E-Rezept Token. Nun kann eine Abgabeanfrage an eine Apotheke versendet werden.