UC3: Rezeptanforderung durch Apotheke

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

Im ersten Schritt stellt die Pflegeeinrichtung eine Rezeptanforderung 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.

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.

Voraussetzungen

Nachrichten einer Rezeptanforderung identifizieren sich mit folgendem MessageHeader.eventCode: #eRezept_Rezeptanforderung;Rezeptanfrage.

Folgende Bedingungen müssen für das Profil ERPServiceRequestPrescriptionRequest eine Rezeptanforderung erfüllt sein:

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 ERP ServiceRequest PrescriptionRequest ü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_Bestätigung

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

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 ERP ServiceRequest DispenseRequest ü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.