Seiteninhalt:
Diese Seite beschreibt die fachliche Beschreibung des Anwendungsfalls “Rezeptanforderung für anwendungsfertige Zytostatikazubereitungen”. Für eine detaillierte Beschreibung dient das FeatureDokument “KIM-Nachrichten für das E-Rezept” (Feature Dokument gemF_eRp_KIM).
WICHTIG: Hierbei MUSS die Verordnung exakt der angefragten Medikation entsprechen. Diese Art der Anfrage wird über MessageHeader.eventCode = #eRezept_ParenteraleZubereitung;* kenntlich. Hierdurch MUSS im Primärsystem der verordnenden LEI der Hinweis gegeben werden, dass die zu verordnende nicht von der angefragten Medikation abweichen darf.
Der Arzt übernimmt die angefragte Medikation in die Verordnung und stellt diese im E-Rezept-Fachdienst ein. Darauf hin erhält der Arzt die Informationen für den E-Rezept Token und übermittelt den Token an die Apotheke.
Diese kann das Rezept am E-Rezept-Fachdienst einlösen.
Für diesen Fall gibt es Festlegungen zur Nutzung von Identifern im Prescription Request, siehe Festlegungen Identifier.
Die Apotheke erstellt mittels Zytostatika-Programm oder Taxierungssoftware die notwendigen Informationen für die Rezeptanforderung zusammen, um sie dann einem verordnenden Leistungserbringer zu übermitteln.
Der verordnende LE stellt ein E-Rezept am E-Rezept-Fachdienst ein und überträgt den E-Rezept Token als Antwort an die anfragende Apotheke. Diese kann das E-Rezept am E-Rezept-Fachdienst einlösen.
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.
Zum Erstellen müssen die in Fachmodell Rezeptanforderung aufgeführten fachlichen Informationen übertragen werden. Das Mapping stellt ebenfalls dar, in welchen Profilen die Informationen angegeben werden müssen.
Folgende Profile sind für diesen Übertragungsweg zu nutzen und im Message Container einzubetten:
| Profil | Referenziert in | Optional |
|---|---|---|
| Message Header | ERPServiceRequestMessageContainer.entry[0] | |
| Prescription Request | ERPServiceRequestRequestHeader.focus | |
| Patient | ERPServiceRequestPrescriptionRequest.subject | |
| Organization, | ERPServiceRequestPrescriptionRequest.requester | |
| Practitioner | ERPServiceRequestPrescriptionRequest.performer | x |
| MedicationRequest | ERPServiceRequestPrescriptionRequest.basedOn | |
| KBV_PR_ERP_Medication_PZN, KBV_PR_ERP_Medication_Compounding, KBV_PR_ERP_Medication_Ingredient oder KBV_PR_ERP_Medication_FreeText | ERPServiceRequestMedicationRequest.medication[x] |
Folgendes Klassendiagramm soll die verwendeten Profile graphisch darstellen:
Folgende Bedingungen müssen erfüllt, bzw. Felder gesetzt sein, damit die Nachricht einer Rezeptanforderung seitens der Pflegeeinrichtung entspricht:
| Profil | Bedingung |
|---|---|
| ERPServiceRequestRequestHeader | .eventCode = #eRezept_ParenteraleZubereitung;Rezeptanfrage |
| ERPServiceRequestPrescriptionRequest | .status = #active |
| ERPServiceRequestOrganization | .type.coding = #APO |
Die MedicationRequest Ressource ist nach Profil MedicationRequest anzugeben. Die Informationen zum Arzneimittel sind in der referenzierten Medication Ressource nachgehalten, die einem Profil der KBV_Medication entspricht.
Falls der Anfragende die Anfrage stornieren möchte, wird der gleiche ServiceRequest (.identifer:requestId muss gleich sein) erneut an den Verordnenden versendet. Folgende Bedingungen müssen erfüllt sein:
| Profil | Bedingung |
|---|---|
| ERPServiceRequestRequestHeader | .eventCode = #eRezept_ParenteraleZubereitung;Rezeptanfrage_Storno |
| ERPServiceRequestPrescriptionRequest | .status = #entered-in-error |
| ERPServiceRequestPrescriptionRequest | .reasonCode Angabe des Stornierungsgrund |
Für die PDF Repräsentation der Anfrage werden außerdem die medizinischen Inhalte der ursprünglichen Verordnungsanfrage übertragen. Das empfangende System kann diese ignorieren.
Der Verordnende sollte mittels dieser Übertragung alle wesentlichen Informationen zur Verfügung haben, die er für das Ausstellen einer Verordnung benötigt:
Im Falle einer Stornierung sollte das sendende System den Eintrag als “storniert” gekennzeichnet haben. Das empfangende System kann eine unbearbeitete Anfrage löschen und muss sonst dem Verordnenden kenntlich machen, dass eine Stornierungsanfrage gesendet wurde. Falls ein E-Rezept erstellt wurde ist dieses vom Verordnenden zu löschen.
Der Verordnende kann nach dem Erhalt einer Rezeptanforderung diese prüfen und eine entsprechende Verordnung erstellen, signieren und im E-Rezept-Fachdienst einstellen ([2] und [3]).
Der Verordnende erhält in der Antwort vom Fachdienst die PrescriptionID und den AccessCode. Beide Informationen werden benötigt, damit die Apotheke das E-Rezept einlösen und zur Abrechnung bringen kann.
Zum Erstellen müssen die in Rezeptanforderung_Bestätigung aufgeführten fachlichen Informationen übertragen werden. Das Mapping stellt ebenfalls dar, in welchen Profilen die Informationen angegeben werden müssen.
Folgende Profile sind für diesen Übertragungsweg zu nutzen und im Message Container einzubetten:
| Profil | Referenziert in | Optional |
|---|---|---|
| Message Header | ERPServiceRequestMessageContainer.entry[0] | |
| Prescription Request | ERPServiceRequestRequestHeader.focus | |
| Patient | ERPServiceRequestPrescriptionRequest.subject | |
| Practitioner | ERPServiceRequestPrescriptionRequest.performer | |
| MedicationRequest | ERPServiceRequestPrescriptionRequest.basedOn | |
| KBV_PR_ERP_Medication_PZN, KBV_PR_ERP_Medication_Compounding, KBV_PR_ERP_Medication_Ingredient oder KBV_PR_ERP_Medication_FreeText | ERPServiceRequestMedicationRequest.medication[x] |
Folgendes Klassendiagramm soll die verwendeten Profile graphisch darstellen:
Folgende Bedingungen müssen erfüllt, bzw. Felder gesetzt sein, damit die Nachricht einer Rezeptanforderungs Bestätigung entspricht:
| Profil | Bedingung |
|---|---|
| ERPServiceRequestRequestHeader | .eventCode = #eRezept_ParenteraleZubereitung;Rezeptbestaetigung |
| ERPServiceRequestPrescriptionRequest | .status = #completed |
| ERPServiceRequestPrescriptionRequest | .extension:EPrescriptionToken = E-REzept Token |
Falls der Verordnende die Anfrage ablehnen möchte, wird der gleiche ServiceRequest (.identifer:requestId muss gleich sein) an den Anfragenden zurück gesendet. Folgende Bedingungen müssen erfüllt sein:
| Profil | Bedingung |
|---|---|
| ERPServiceRequestRequestHeader | .eventCode = #eRezept_Rezeptanforderung;Rezeptanfrage_Storno |
| ERPServiceRequestPrescriptionRequest | .status = #revoked |
| ERPServiceRequestPrescriptionRequest | .reasonCode Angabe des Ablehnungsgrunds |
Für die PDF Repräsentation der Anfrage werden außerdem die medizinischen Inhalte der ursprünglichen Verordnungsanfrage übertragen. Diese sind vom PVS aus der initialen Anfrage zu übernehmen. Das empfangende System kann diese ignorieren.
Sobald das PVS die Anfrage bearbeitet hat, erhält die Apotheke nach Abschluss dieses Vorgangs das E-Rezept-Token am E-Rezept-Fachdienst und kann damit das E-Rezept einlösen und die Zubereitung abrechnen.
Falls der Verordnende die Anfrage abgelehnt hat, ist der Vorgang entsprechend im Apothekensystem zu markieren.
Beispielhafte FHIR-Ressourcen sind auf der folgenden Seite Beispiele verfügbar.