Rezeptanforderung in der Pflege
Fachliche Beschreibung
In diesem Anwendungsfall löst ein Anfragender (z.B. eine Pflegeeinrichtung) den Prozess aus und stellt eine Rezeptanfrage an einen verordnenden Arzt. Der Arzt kann nun die Anfrage bearbeiten und ein E-Rezept erstellen. Mit Erstellung des E-Rezepts erhält der Verordnende die Informationen "PrescriptionID" und "AccessCode" vom E-Rezept-Fachdienst und kann somit einen E-Rezept-Token erzeugen.
Nun entscheidet sich der weitere Verlauf je nach Zustelltyp (ServiceRequest.orderDetail.code). Wenn der Code "#issue-prescription" angegeben wurde, wird nach dem Erstellen des E-Rezepts eine Bestätigung ohne den Token an den Anfragenden versendet. Damit endet der Workflow. Der Code "#return-to-requester" signalisiert, dass der E-Rezept-Token an den Anfragenden zu übermitteln ist, damit dieser dann die Belieferungsanfrage an die Apotheke starten kann.
Eine detaillierte fachliche Beschreibung findet sich im dazugehörigen Featuredokument gemF_eRp_KIM.
Ein Mapping der fachlichen Informationseinheiten des Featuredokuments zu den Profilen findet sich unten.
Rezeptanforderung
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Rezeptanfrage
Eine anfragende Person oder Einrichtung benötigt ein E-Rezept, um einen Patienten mit Medikamenten zu versorgen. Diese fragt nun einen Arzt um eine entsprechende Verordnung an.
Hierfür wird eine Rezeptanforderung gestellt und eine Rezeptbestätigung erwartet.
Vorbereitung
Folgende Profile sind für diesen Übertragungsweg zu nutzen und im ERP Service Request Message Container einzubetten:
HINWEIS: In einem ERP Service Request Message Container können beliebig viele Anfrage zum Ausstellen einer Verordnung (ServiceRequest) übertragen werden.
Profil | Referenziert in | Optional |
---|---|---|
Message Header | ERPServiceRequestMessageContainer.entry | |
Anfrage zum Ausstellen einer Verordnung (ServiceRequest) | ERPServiceRequestRequestHeader.focus | |
Angefragte Medikation (MedicationRequest) | ERPServiceRequestPrescriptionRequest.basedOn | |
KBV_PR_FOR_Patient | ERPServiceRequestPrescriptionRequest.subject | |
Organisation mit KIM-Addresse, KBV_PR_FOR_Practitioner | ERPServiceRequestPrescriptionRequest.performer | |
Angabe zur Medikamentenreichweite | ERPServiceRequestPrescriptionRequest.reasonReference | x |
Organisation mit KIM-Addresse | ERPServiceRequestPrescriptionRequest.supportingInfo:AuslieferndeApotheke | x |
KBV Medication | ERPServiceRequestMedicationRequest.medication[x] | |
KBV_PR_FOR_Coverage | ERPServiceRequestMedicationRequest.coverage | x |
Wichtige Parameter
Folgende Informationen sind für diesen Anwendungsfall und Übertragungsweg verpflichtend in den Profilen zu setzen.
Verordnungsanfrage (ERPServiceRequestPrescriptionRequest)
- .status = #active (offene Anfrage)
- .basedOn = ERPServiceRequestMedicationRequest (angefragte Medikation)
- .requester = Organization/ Practitioner (Anfragende Person/ Einrichtung)
- .performer = Practitioner (Arzt, der die Verordnung austellen soll)
Angefragte Medikation (ERPServiceRequestMedicationRequest)
- .medicationReference (Angabe der benötigten Medikation)
Über ServiceRequest.reasonCode
und ServiceRequest.reasonReference
kann angegeben werden, warum die Medikation angefragt wird.
Weitere Parameter
Ausliefernde Apotheke (ERPServiceRequestOrganization)
In der Rezeptanforderung kann unter ServiceRequest.supportingInfo:AuslieferndeApotheke
die Apotheke angegeben werden, die nach Ausstellen des Rezeptes die Belieferung vornehmen soll. Diese Angabe ist dafür vorgesehen, dass das Softwaresystem der Pflegeeinrichtung die Antwort des Verordnenden automatisiert verarbeiten kann, ohne dass ein Mitarbeiter die Nachricht manuell an die Apotheke versenden muss.
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 = #revoked
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_Rezeptübermittlung
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Rezeptbestaetigung
Der Arzt kann nach dem Erhalt einer Rezeptanforderung diese prüfen und eine entsprechende Verordnung erstellen, signieren und im E-Rezept-Fachdienst einstellen ([2]).
Der Arzt 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.
Verfahren nach Einstellen des E-Rezepts
Je nach Zustelltyp ServiceRequest.orderDetail.code
muss nun das PVS weiter verfahren und eine Antwort an den Anfragenden geben ([4]).
Verfahren bei Zustelltyp: #issue-prescription
Wenn in der Anfrage dieser Zustelltyp ausgewählt wurde, dann soll das E-Rezept nur am Fachdienst eingestellt werden. Der Patient wird dann selbst das Rezept über die App oder eGK in der Apotheke einlösen. Hierbei handelt es sich um den fachlichen Fall "Spezialfall mit Versichertenbeteiligung".
Hierzu ist im ServiceRequest der .status auf #completed zu setzen und als Antwort an die anfragende Einrichtung, bzw. Person zurückzuschicken. So weiß der Anfragende, ob das Rezept erfolgreich im E-Rezept-Fachdienst eingestellt wurde. Der E-Rezept-Token DARF dabei NICHT in die Antwort mit eingebettet werden.
Sobald die Antwort gesendet wurde endet bei diesem Zustelltyp der Workflow nach dieser Übertragung.
Folgende Informationen sind im ERPServiceRequestPrescriptionRequest in der Antwort zu übermitteln:
Verordnungsanfrage (ERPServiceRequestPrescriptionRequest)
- .status = #completed
- .basedOn = KBV_PR_ERP_Prescription (ersetzt den initialen MedicationRequest)
Verfahren bei Zustelltyp: #return-to-requester
In diesem Fall möchte die anfragende Einrichtung, bzw. Person die Informationen zum Einlösen des E-Rezepts erhalten, um diese Informationen dann an eine Apotheke weiterzugeben.
Hier muss das PVS dann ebenfalls den .status auf #completed setzen und den E-Rezept-Token unter .extension[EPrescriptionToken]
hinterlegen.
Folgende Informationen sind im ERPServiceRequestPrescriptionRequest in der Antwort zu übermitteln:
Verordnungsanfrage (ERPServiceRequestPrescriptionRequest)
- .extension:EPrescriptionToken.value = E-Rezept-Token
- .status = #completed
- .basedOn = KBV_PR_ERP_Prescription (ersetzt den initialen MedicationRequest)
Stornierung - Verordnung
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Rezeptanfrage_Storno
Der Arzt 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, je nach Zustelltyp, an die Pflegeeinrichtung versendet hat, ist der Vorgang beendet.
Je nach Zustelltyp sind folgende Nachbedingungen gegeben:
Zustelltyp | Ergebnis |
---|---|
#issue-prescription | E-Rezept wurde eingestellt, Anfragender ist informiert |
#return-to-requester | Der Anfragende ist im Besitz des E-Rezept-Tokens |
Die Pflegeeinrichtung hat nun die Information, dass die Anfrage bearbeitet wurde. Nun kann eine Belieferungsanfrage an eine abgebende Apotheke initiiert werden.
Falls der Token an die anfragende Einrichtung übermittelt wurde, muss diese nun das E-Rezept-Token zur Weiterverarbeitung speichern ([5]).
Dispensieranforderung_Rezeptübermittlung
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Abgabeanfrage
Bei Zustelltyp #issue-prescription kann der Versicherte selbst oder über einen Vertreter das E-Rezept in einer beliebigen Apotheke einlösen. Die Pflegeeinrichtung erhält lediglich die Information, dass das E-Rezept vom Verordnenden ausgestellt wurde.
Der E-Rezept Token wird bei Zustelltyp #return-to-requester an die Pflegeeinrichtung übermittelt. Nach Erhalt der Antwort vom Verordnenden ist die Pflegeeinrichtung im Besitz des E-Rezept Tokens und kann das E-Rezept in einer beliebigen Apotheke einlösen. Über eine Anfrage an eine Apotheke zur Dispensierung eines Medikamentes ([6]), kann die Pflegeeinrichtung mit den verordneten Medikamenten beliefert werden.
Vorbereitung
Folgende Profile sind für diesen Übertragungsweg zu nutzen und im ERP Service Request Message Container einzubetten:
HINWEIS: In einem ERP Service Request Message Container können beliebig viele Anfrage zum Beliefern einer Verordnung (ServiceRequest) übertragen werden.
Profil | Referenziert in | Optional |
---|---|---|
Message Header | ERPServiceRequestMessageContainer.entry | |
Anfrage zum Beliefern einer Verordnung (ServiceRequest) | ERPServiceRequestRequestHeader.focus | |
KBV_PR_ERP_Prescription | ERPServiceRequestDispenseRequest.basedOn | |
KBV_PR_FOR_Patient | ERPServiceRequestDispenseRequest.subject | |
Organisation mit KIM-Addresse | ERPServiceRequestDispenseRequest.performer | |
KBV_PR_FOR_Practitioner | ERPServiceRequestDispenseRequest.supportingInfo:AusstellenderArzt | |
KBV Medication | KBV_PR_ERP_Prescription.medication[x] | |
KBV_PR_FOR_Coverage | KBV_PR_ERP_Prescription.coverage |
Wichtige Parameter
Folgende Informationen sind für diesen Anwendungsfall und Übertragungsweg verpflichtend zu setzen.
Anfrage zum Beliefern einer Verordnung (ERPServiceRequestDispenseRequest)
- .extension:EPrescriptionToken.value = E-Rezept-Token
- .status = #active
- .basedOn = KBV_PR_ERP_Prescription
- .requester = Anfragende Einrichtung/ Person
- .supportingInfo:AusstellenderArzt (Für eventuelle Rückfragen an den Verordnenden)
Es wird angenommen, dass zwischen einer anfragenden Pflegeeinrichtung und Apotheke bereits vereinbarte Prozesse zur Übergabe der eigentlichen Medikation bestehen. Daher wurden diese nicht weiter spezifiziert. Für etwaige Kommunikation darüber kann das Feld ServiceRequest.note
genutzt, oder direkt Kontakt aufgenommen werden.
Stornierung - Abgabeanfrage
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Abgabeanfrage_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 = #revoked
angegeben. Falls die Apotheke den Vorgang noch nicht bearbeitet hat, ist der Vorgang abzubrechen. Wenn die Apotheke das E-Rezept bereits über $accept in den Status "in Abgabe (gesperrt)" gestellt hat, ist dieses nach Möglichkeit wieder freizugeben.
Nachbedingung
Die Apotheke ist im Besitz des E-Rezept-Tokens und hat alle Informationen, die sie für eine Kontaktaufnahme benötigt, sowohl zur anfragenden Person/ Einrichtung, wie auch zum ausstellenden Arzt.
Mit Besitz des Tokens ist eine Apotheke in der Lage den E-Rezept-Fachdienst nach dem Rezept abzufragen und kann dieses entsprechend bearbeiten ([7]). Die Apotheke kann im letzten Schritt die Verarbeitung der Anfrage und die Belieferung bestätigen ([8]).
Dispensieranforderung_Bestätigung
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Abgabebestaetigung
Abschließend übermittelt die Apotheke eine Bestätigung an die anfragende Einrichtung/ Person, dass die Abgabe bestätigt ist. In der Antwort sollen auch die Abgabedaten inkludiert sein, damit der Anfragende informiert ist welches Präparat geliefert wird.
Hierfür MUSS im Bundle folgende Inhalte geliefert werden:
Anfrage zum Beliefern einer Verordnung (ERPServiceRequestDispenseRequest)
- .status = #completed
- .extension:AbgabeDaten = GEM_ERP_PR_MedicationDispense, damit der Anfragende nachvollziehen kann mit welcher Medikation tatsächlich beliefert wird
Stornierung - Abgabe
MessageHeader.eventCode: #eRezept_Rezeptanforderung;Abgabeanfrage_Storno
Die Apotheke kann die Dispensierung der Abgabe auch ablehnen. Hierbei ist ServiceRequest.status
auf #revoked
zu setzen und nach Möglichkeit ein Hinweis unter ServiceRequest.note
anzuzeigen.
Nachbedingung
Die anfragende Einrichtung/ Person ist darüber informiert, dass die Abgabe erfolgt ist und welche Medikamente geliefert werden. Dieser letzte Schritt schließt den Anwendungsfall ab.
Sonderfall: Apotheke als Anfragender
In diesem Fall übernimmt die heimversorgende Apotheke nach §12a ApoG die Rezeptanforderung. Die Pflegeeinrichtung leitet die Anfrage der Apotheke und Antwort des Verordnenden weiter.
Der Ablauf ist im Folgenden dargestellt:
In diesem Anwendungsfall löst die heimversorgende Apotheke den Anwendungsfall aus und erstellt die Rezeptanforderung. Die Pflegeeinrichtung dient damit als eine Art "Proxy", die die Rezeptanforderung weiterleitet und die Bestätigung des Verordnenden zur Apotheke durchreicht.
Dementsprechend wird im Message Header sowie im Service Request die Pflegeeinrichtung nicht angegeben.
Rezeptanforderung
Wenn die heimversorgende Apotheke eine Anfrage stellen möchte, dann erstellt sie das Message Bundle wie folgt:
Im MessageHeader.destination als auch ServiceRequest.performer ist der Verordnende anzugeben. Die KIM-Nachricht wird allerdings an die Pflegeeinrichtung gesendet.
Diese kann nun den MessageHeader auswerten und an den Verordnenden weiterleiten.
Falls MessageHeader.destination.identifier:KIM-Adresse.value nicht der eigenen KIM-Adresse entspricht und MessageHeader.eventCoding.code = eRezept_Rezeptanforderung;Rezeptanfrage enthält, leitet das Pflegesystem die Nachricht automatisiert an den Verordnenden weiter.
Rezeptbestätigung
Wenn der Verordnende das Rezept ausgestellt hat übermittelt dieser nun eine KIM-Nachricht an die Pflegeeinrichtung. Das Message Bundle ist dabei wie folgt aufzubauen:
Falls MessageHeader.destination.identifier:KIM-Adresse.value nicht der eigenen KIM-Adresse entspricht und MessageHeader.eventCoding.code = eRezept_Rezeptanforderung;Rezeptbestaetigung enthält, leitet das Pflegesystem die Nachricht automatisiert an die Apotheke weiter.
Storno
Das gleiche Verfahren gilt auf beiden Wegen (Apotheke -> Verordnender und Verordnender -> Apotheke) auch mit MessageHeader.eventCoding.code = eRezept_Rezeptanforderung;Rezeptanfrage_Storno
Beispiele
Beispiele für Zustelltyp #return-to-requester
Beispiele für diesen Anwendungsfall befinden sich im Simplifier Projekt. Beispiele für diesen Anwendungsfall sind benannt nach "UC1-*"
Beispiele für Sonderfall: heimversorgende Apotheke
Beispiele für diesen Anwendungsfall befinden sich im Simplifier Projekt. Beispiele für diesen Anwendungsfall sind benannt nach "UC2-*"
Beispiele für Zustelltyp #issue-prescription
Beispiele für diesen Anwendungsfall befinden sich im Simplifier Projekt. Beispiele für diesen Anwendungsfall sind benannt nach "UC3-*"
Mappings
Im Feature Dokument zu diesem Projekt gemF_eRp_KIM, Kapitel 3 werden die Anwendungsfälle fachlich beschrieben. Aus den dort aufgeführten fachlichen Informationsobjekten kann hier das Mapping auf die FHIR-Ressourcen nachvollzogen werden.
ERPServiceRequestPrescriptionRequest Mappings
id | Feld | Fachliche_Informationseinheit |
---|---|---|
ServiceRequest | Rezeptanforderung | Rezeptanforderung |
ServiceRequest.basedOn | Praeparat | Rezeptanforderung |
ServiceRequest.requisition | Vorgangs_ID | Rezeptanforderung |
ServiceRequest.priority | Prioritaet | Rezeptanforderung |
ServiceRequest.subject | Patienteninformationen | Rezeptanforderung |
ServiceRequest.requester | Adressat_der_Rezeptuebermittlung | Rezeptanforderung |
ServiceRequest.performer | Adressat_der_Rezeptanforderung | Rezeptanforderung |
ServiceRequest.reasonCode | Bedarfsbegruendung (Code) | Rezeptanforderung |
ServiceRequest.reasonReference | Bedarfsbegruendung (Observation) | Rezeptanforderung |
ServiceRequest.reasonReference | Restreichweite | Rezeptanforderung |
ServiceRequest.note | Freitext | Rezeptanforderung |
ServiceRequest | Rezeptanforderung_Storno | Rezeptanforderung-Ablehnung |
ServiceRequest.requisition | Vorgangs_ID | Rezeptanforderung-Ablehnung |
ServiceRequest.reasonCode | Ablehnungsgrund | Rezeptanforderung-Ablehnung |
ServiceRequest.note | Freitext | Rezeptanforderung-Ablehnung |
ServiceRequest | Rezeptanforderung_Rezeptübermittlung | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest.extension:EPrescriptionToken | ERezept_Task_ID | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest.extension:EPrescriptionToken | ERezept_Access_Code | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest.basedOn | Strukturierter_Verordnungsdatensatz | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest.requisition | Vorgangs_ID | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest.note | Hinweise_fuer_Empfaenger | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest.note | Freitext | Rezeptanforderung-Rezeptuebermittlung |
ServiceRequest | Rezeptanforderung_Storno | Rezeptanforderung-Storno |
ServiceRequest.requisition | Vorgangs_ID | Rezeptanforderung-Storno |
ServiceRequest.reasonCode | Begründung der Stornierung | Rezeptanforderung-Storno |
ERPServiceRequestMedicationRequest Mappings
id | Feld | Fachliche_Informationseinheit |
---|---|---|
MedicationRequest | Rezeptanforderung_medizinische_Informationen | Rezeptanforderung-medizinische-Informationen |
MedicationRequest.extension:PriorPrescriptionID | Vorheriges_Rezept | Rezeptanforderung-medizinische-Informationen |
MedicationRequest.medication[x] | Praeparat | Rezeptanforderung-medizinische-Informationen |
ERPServiceRequestDispenseRequest Mappings
id | Feld | Fachliche_Informationseinheit |
---|---|---|
ServiceRequest | Dispensieranforderung_Bestätigung | Dispensieranforderung-Bestaetigung |
ServiceRequest.requisition | Vorgangs_ID | Dispensieranforderung-Bestaetigung |
ServiceRequest.supportingInfo:AbgabeDaten | Strukturierter_Dispensierungsdatensatz | Dispensieranforderung-Bestaetigung |
ServiceRequest.note | Hinweise_fuer_Empfänger | Dispensieranforderung-Bestaetigung |
ServiceRequest.note | Freitext | Dispensieranforderung-Bestaetigung |
ServiceRequest | Dispensieranforderung_Rezeptübermittlung | Dispensieranforderung-Rezeptuebermittlung |
ServiceRequest.extension:EPrescriptionToken | ERezept_Access_Code | Dispensieranforderung-Rezeptuebermittlung |
ServiceRequest.extension:EPrescriptionToken | ERezept_Task_ID | Dispensieranforderung-Rezeptuebermittlung |
ServiceRequest.basedOn | Strukturierter_Verordnungsdatensatz | Dispensieranforderung-Rezeptuebermittlung |
ServiceRequest.requisition | Vorgangs_ID | Dispensieranforderung-Rezeptuebermittlung |
ServiceRequest.note | Hinweise_fuer_Empfänger | Dispensieranforderung-Rezeptuebermittlung |
ServiceRequest.note | Freitext | Dispensieranforderung-Rezeptuebermittlung |