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.

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:

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.

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

ERPServiceRequestMedicationRequest Mappings

ERPServiceRequestDispenseRequest Mappings