Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

KIM-Nachrichten für das E-Rezept

    

     

      
Version
      
2.0.0_CC
     
     

      
Revision
      
1067571
     
     

      
Stand
      
10.12.2024
     
     

      
Status
      
zur Abstimmung freigegeben
     
     

      
Klassifizierung
      
öffentlich_Entwurf
     
     

      
Referenzierung
      
gemF_eRp_KIM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

Das Dokument beschreibt Prozesse, welche das Verordnen und Abgeben von E-Rezepten unterstützen. Es werden verschiedene Anwendungsszenarien betrachtet:

• Anforderung von Rezepten im Kontext der Pflege
• Anforderungen von Rezepten für anwendungsfertige Zytostatika Zubereitungen

Es werden Kommunikationspattern und Nachrichtenformate zwischen den Beteiligten beschrieben. Die Übermittlung dieser Nachrichten ist über die Anwendung Kommunikation im Medizinwesen (KIM) vorgesehen.

1.1 Zielsetzung

Die Beschreibung des Funktionsumfangs als Feature erleichtert das Verständnis und die Nachvollziehbarkeit der Lösung, ausgehend von der Darstellung der Nutzersicht auf Epic-Ebene, über das technische Konzept bis zur Spezifikation der technischen Details. Mit den hier aufgestellten Anforderungen sollen Hersteller in der Lage sein, den zusätzlichen Funktionsumfang ihrer verantworteten Komponente bzw. Produkttyp bewerten und umsetzen zu können. 

1.2 Zielgruppe

Das Dokument richtet sich an die Hersteller von Primärsystemen der verordnenden und abgebenden Leistungserbringerinstitutionen und der Pflegeeinrichtungen sowie den Herstellern von Systemen, welche die Ermittlung der korrekten Informationen für die zu verschreibenden Verordnungen unterstützen können.

1.3 Abgrenzungen

Die Anwendungsfälle zum Verordnen und Abgeben von E-Rezepten, welche im Rahmen der Anwendung E-Rezept definiert wurden, bestehen unverändert.

Der Nachrichtenaustausch zwischen den Akteuren der im Dokument beschriebenen Anwendungsfälle erfolgt über KIM. Der Nachrichtenaustausch zwischen einem Versicherten zu Apotheken über das E-Rezept-FdV, bei dem die Nachrichten auf dem E-Rezept-Fachdienst gespeichert werden, besteht davon unverändert. 

1.4 Methodik

Anforderungen und Anwendungsfälle

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Anforderungen und Anwendungsfälle werden im Dokument wie folgt dargestellt:
<ID> - <Titel der Afo / Titel des Anwendungsfalles>
Text / Beschreibung
[<=]

Die einzelnen Elemente beschreiben:

• ID: einen eindeutigen Identifier.
• bei einer Anforderung besteht der Identifier aus der Zeichenfolge 'A_' gefolgt von einer Zahl,
• bei einem Anwendungsfall besteht der Identifier aus der Zeichenfolge 'AF_' gefolgt von einer Zahl, 
• Titel der Anforderung / Anwendungsfalles: ein Titel, welcher zusammenfassend den Inhalt beschreibt
• Text / Beschreibung: ausführliche Beschreibung des Inhalts, kann neben Text Tabellen, Abbildungen und Modelle enthalten

Dabei umfasst die Anforderung/der Anwendungsfall sämtliche zwischen ID und Textmarke [<=] angeführten Inhalte.

Rolle Arzt/Zahnarzt

Wenn im Dokument die Rolle Arzt benannt wird, dann umfasst diese sowohl die Ärzte als auch Zahnärzte, sofern Zahnärzte nicht explizit ausgeschlossen werden. 

User Stories

Eine User Story ist eine in Alltagssprache formulierte Software-Anforderung. Sie ist bewusst kurzgehalten und umfasst in der Regel nicht mehr als zwei Sätze. User Stories werden im Rahmen der agilen Softwareentwicklung zusammen mit Akzeptanztests zur Spezifikation von Anforderungen eingesetzt. [Wikipedia: User Story]
Aus diesem Grund kann in den User Stories eine abweichende Terminologie genutzt werden, welche für den Leser nachvollziehbar (bspw. Patient = Versicherter) ist.

Hinweise auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung seitens der Gesellschafter erfordern, sind wie folgt im Dokument gekennzeichnet:

Beispiel für einen offenen Punkt.

2 Epics und User Stories

In diesem Abschnitt wird das Feature fachlich beschrieben und der Mehrwert für Nutzer vorgestellt. Aus diesen Epics und User Stories wird anschließend ein fachliches und technisches Konzept abgeleitet.

2.1 Rezeptanforderungen in der Pflege

Im Rahmen der Betreuung von pflegebedürftigen Versicherten ist das Gestalten der Medikationsprozesse für die Versicherten eine zentrale Aufgabe. Es existieren in der Praxis unterschiedliche Konstellationen.

Der überwiegende Teil der stationär versorgten Versicherten überträgt diese Aufgabe an die vollstationäre Pflegeeinrichtung in welcher sie leben, diese ist damit auch dafür verantwortlich, bei Bedarf eine neue Verschreibung für ein Arzneimittel bei der Arztpraxis anzufragen (Rezeptmanagement). Auch ambulante Pflegedienste übernehmen häufig das Medikationsmanagement für die Versicherten und regeln dies in individuellen Absprachen. Der Ablauf der Rezeptanforderung läuft heute meist über unsichere Kommunikationskanäle (Fax, E-Mail, etc.) bzw. wird durch Botengänge erledigt. Durch die Digitalisierung des Rezeptformulars ergeben sich Verbesserungspotentiale für Pflegeeinrichtungen und heimversorgende Apotheken. Daher soll es eine Möglichkeit geben, die Kommunikation im E-Rezeptmanagement für alle Beteiligten zu erleichtern. 

Disclaimer: Es ist gesetzlich festgelegt, unter welchen Voraussetzungen die folgenden Anwendungsfälle genutzt werden können. Die Legitimation von Anwendungsfall 2 wird derzeit noch rechtlich geprüft.

Anwendungsfall 1: Die Pflegeeinrichtung übernimmt das Rezeptmanagement

Ein Mitarbeiter der Pflegeeinrichtung stellt Bedarf für ein Rezept fest (z.B. beim Stellen der Arzneimittel oder durch eine Reichweitenberechnung des Primärsystems). Die Pflegeeinrichtung übermittelt dann (z.B. per KIM) eine Rezeptanforderung an die Praxis des behandelnden Arztes unter Angabe eines Grundes für den neuen bzw. erneuten Bedarf (nach Dosierung, nach Vitalwertmessung, nach Bedarf). Der Arztpraxis werden die Rezeptanforderungen in einer übersichtlichen Darstellung angezeigt, die eine schnelle Prüfung und Weiterverarbeitung ermöglicht. Der Arzt stellt das Rezept aus und übermittelt die Verordnungsdaten und Zugriffsinformationen (Task-ID & Accesscode) zurück an die Pflegeeinrichtung oder lehnt die Anfrage ab. Eine stationäre Pflegeeinrichtung leitet die Rezepte für auf Grundlage des Vertrages nach § 12a des Apothekengesetzes (ApoG) per KIM an die heimversorgende Apotheke weiter, die die Arzneimittel dann bereitstellt. Ambulante Pflegedienste leiten die Rezepte an die Wunsch-Apotheke des Versicherten weiter, die die Arzneimittel dann bereitstellt. Die Apotheke informiert die Pflegeeinrichtung per automatisch erzeugter KIM-Nachricht über das abgegebene Arzneimittel.

Je nach individueller vertraglicher Reglung ist es ebenfalls möglich, dass der Patient bzw. ein Vertreter das Rezept selbst einlösen (dieser Anwendungsfall ist insbesondere für die ambulante Pflege relevant).

Sollte ein angefordertes Rezept nicht mehr benötigt werden (z.B. Versicherter wird ins Krankenhaus verlegt), oder wurde eine Anfrage fälschlicherweise verschickt, kann die Anfrage wieder storniert werden. Das System der Arztpraxis kann die Anfrage dann je nach Bearbeitungsstatus entweder direkt aus der Liste löschen oder ein bereits erstelltes E-Rezept löschen (sofern noch nicht eingelöst).

Abbildung 1 Prozessschaubild zu Anwendungsfall 1

Anwendungsfall 2: Eine Apotheke übernimmt das Rezeptmanagement

Eine stationäre Pflegeeinrichtung kann eine heimversorgende Apotheke nach § 12a ApoG mit der Versorgung mit Arzneimitteln und dem Rezeptmanagement (insbesondere für Dauermedikationen) beauftragen. In diesem Fall berechnet die Apotheke die Reichweite der Arzneimittel für die Versicherten. Die Apotheke benötigt rechtzeitig neue Rezepte, wenn das Ende der Reichweite in Sicht kommt. Diese kann die Apotheke bei der behandelnden Arztpraxis per KIM anfordern. Der Arztpraxis werden die Rezeptanforderungen in einer übersichtlichen Darstellung angezeigt, die eine schnelle Prüfung und Weiterverarbeitung ermöglicht. Die Arztpraxis erstellt die angeforderten Rezepte und sendet die Verordnungsdaten und Zugriffsinformationen (Task-ID & Accesscode) zurück an die anfordernde heimversorgende Apotheke. 
Wenn das Rezept nach ärztlicher Prüfung nicht benötigt wird, weil beispielsweise die Therapie angepasst wurde, kann die Arztpraxis die Anfrage ablehnen. Sollte ein angefordertes Rezept nicht mehr benötigt werden (z.B. Versicherter wird ins Krankenhaus verlegt), oder wurde eine Anfrage fälschlicherweise verschickt, kann die Anfrage von der anfordernden Apotheke wieder storniert werden. Das System der Arztpraxis kann die Anfrage dann je nach Bearbeitungsstatus entweder direkt aus der Liste löschen oder ein bereits erstelltes E-Rezept löschen (sofern noch nicht eingelöst). Die Pflegeeinrichtung des Versicherten wird über die Anforderung, die Verordnung und die Belieferung der Rezepte in Kenntnis gesetzt werden, sodass diese über den aktuellen Bearbeitungsstand informiert ist und Inhalte von neuen Verordnungen automatisch im System dokumentiert werden können. Bei jeder der oben beschriebenen Nachrichten soll der Pflegeeinrichtung des Versicherten automatisiert eine Kopie der Nachricht übermittelt werden. Weiterhin informiert die heimversorgende Apotheke die Pflegeeinrichtung per automatisch erzeugter Nachricht über das abgegebene Arzneimittel. 

Abbildung 2 : Prozessschaubild zu Anwendungsfall 2

2.1.1 User Stories des Versicherten

Als Versicherter möchte ich:

• rechtzeitig und im Sinne meiner medizinischen Behandlung mit den erforderlichen Arzneimitteln versorgt werden.
• wenn es so mit meiner Pflegeeinrichtung besprochen ist, meine Rezepte in meiner Wunsch-Apotheke einlösen können, auch wenn das Rezept von meiner Pflegeeinrichtung für mich angefordert wurde.

2.1.2 Gemeinsame User Stories des Anfordernden (Pflegeeinrichtung oder heimversorgende Apotheke)

Als Mitarbeiter einer Pflegeeinrichtung oder einer heimversorgenden Apotheke möchte ich: 

• die Rezeptanforderung digital und ohne Medienbruch über einen sicheren Kommunikationskanal an eine Arztpraxis übermitteln können.
• die Rezeptanforderung direkt aus der Medikationsdokumentation oder künftig auch dem elektronischen Medikationsplan bzw. der elektronischen Medikationsliste eines Versicherten auslösen können, damit ich Zeit spare und keine händischen Rezept-Anforderungslisten führen muss.
• mehrere Rezepte (ggf. auch von verschiedenen Versicherten und Mehrfachverordnungen) auf einmal bei einem Arzt anfordern können, sodass ich weniger Klicks habe und gleiche Angaben nicht doppelt erfassen muss. 
• in meinem System erkennen können, für welche Arzneimittel ich schon eine Rezeptanforderung angefragt habe (und wann), sodass ich nicht zweimal die gleiche Anforderung absende.
• dass automatisch alle verfügbaren Informationen (zum Versicherten, dem benötigten Arzneimittel, dem behandelnden Arzt, ggf. heimversorgenden Apotheke) aus meinem System in der Anforderung übermittelt werden, um Verzögerungen durch notwendige Nachreichungen zu vermeiden.
• die Dringlichkeit z.B. aufgrund einer geringen Restreichweite angeben können, damit der Arzt besser einschätzen kann, wie schnell die Anfrage bearbeitet werden muss. 
• dem Arzt den Grund für die Anforderung mitteilen können, damit Unklarheiten vermieden werden. 
• dass der Versicherte das Rezept nur selbst per App, Ausdruck oder Gesundheitskarte einlösen kann, wenn ich es in der Rezeptanforderung angegeben habe.
• dass die Rückmeldungen vom Arzt auf die Rezeptanforderungen dem angefragten Arzneimittel/Rezept/Versicherten zuordenbar sind, um den Kommunikationsverlauf eindeutig nachvollziehen zu können.
• bei Erhalt einer Antwort auf eine Rezeptanforderung zweifelsfrei erkennen können, ob der Arzt das Rezept mitgeschickt hat oder ob und warum der Arzt die Anforderung abgelehnt hat.
• eine Rezeptanforderung zurücknehmen können, wenn mir z.B. ein Fehler unterlaufen ist oder das Rezept nicht mehr benötigt wird, sodass der Arzt sich nicht unnötige Arbeit macht bzw. das Rezept stornieren kann.
• sofern mein System die Nachrichten nicht automatisiert weiterverarbeiten kann, die Rückmeldung auf meine Rezeptanfrage in meinem KIM Postfach sehen und lesen können. 

2.1.2.1 Zusätzliche User Stories der Pflegeeinrichtung

Als Mitarbeiter einer Pflegeeinrichtung möchte ich:

• in meinem System konfigurieren können, ob und nach welchen Regeln die übermittelten Rezepte direkt an eine Apotheke mit Heimversorgungsvertrag weitergeleitet werden soll, sodass mich das Weiterleiten der Nachrichten in meinem Arbeitsprozess nicht aufhält. 
  
• in meinem System hinterlegen können, wenn bei einzelnen Versicherten die Rezepte bei Rezeptanforderungen von dem Versicherten selbst abgeholt und eingelöst werden sollen.
• bei Rezeptübermittlung die Informationen aus der Verordnung ohne manuelles abtippen in meine Dokumentation übernehmen können, sodass diese immer vollständig und aktuell ist.
• bei Rezeptübermittlung mitgeschickte Anhänge in die Akte des Versicherten übertragen können, sodass diese immer vollständig ist.
• bei der Rezeptübermittlung mitgeben können, ob die Medikamente per Bote von der Pflegeeinrichtung abgeholt, per Bote von der Apotheke geliefert oder durch den Versicherten/einem Vertreter selbst abgeholt werden.
• in meinem System nachvollziehen können, wenn eine heimversorgende Apotheke ein Rezept von dem behandelnden Arzt erhalten hat, sodass ich weiß, welches Arzneimittel verordnet wurde.
• von der heimversorgenden Apotheke Informationen über das abgegebene Arzneimittel erhalten und in meine Dokumentation übernehmen können, sodass diese immer vollständig und aktuell ist. 

2.1.2.2 Zusätzliche User Stories der heimversorgenden Apotheke

Als Mitarbeiter einer heimversorgenden Apotheke möchte ich: 

• bei jedem Versicherten, für den ich die Versorgung übernehme, nur einmalig die KIM Adresse der Pflegeeinrichtung und des Arztes (ggf. mehrerer Ärzte) erfassen müssen, sodass ich diese nicht bei jeder Anfrage erneut heraussuchen und eingeben muss. 
• nur einmalig konfigurieren müssen, dass die Nachrichten an die Pflegeeinrichtung (in Kopie) gesendet werden sollen und dass diese fortan immer automatisch und ohne manuelle Aufwände für mich versendet werden. 
• die Pflegeeinrichtung, die ich versorge, immer die Informationen zum abgegebenen Arzneimittel automatisch zugeschickt bekommt, wenn ich das Rezept beliefert habe. 
• sofern mein System die Nachrichten nicht automatisiert weiterverarbeiten kann, die Rückmeldung auf meine Rezeptanfrage in meinem KIM Postfach sehen und lesen können. Damit ich das Rezept in meine Warenwirtschaft manuell übernehmen kann, soll der Rezeptcode als Datamatrix-Code (z.B. auf dem E-Rezept Ausdruck PDF) angezeigt werden.

2.1.3 User Stories des verordnenden Leistungserbringers

Als verordnender Arzt möchte ich:

• dass mein System die angeforderten Rezepte mit allen notwendigen Informationen (zum Arzneimittel und Versicherten) in einer übersichtlichen Ansicht anzeigt, um die Anfragen schnell und übersichtlich erfassen und abarbeiten zu können, und damit sie nicht zwischen anderen KIM Nachrichten untergehen.
• dass mein System mich dabei unterstützt, ohne aufwendige manuelle Eingaben die Informationen aus der Rezeptanfrage in ein E-Rezept zu übernehmen, sodass ich sie nur noch prüfen und signieren muss.
• alle Anfragen einzeln einsehen und prüfen können, sodass ich die Rezepte bewusst ausstelle und mir keine Fehler unterlaufen. 
• dass die Übersicht der Rezeptanforderungen automatisch um stornierte Rezeptanforderungen bereinigt wird, sodass ich keine Arbeit mit bereits stornierten Anfragen habe.
• dass mein System automatisch versucht, ein bereits signiertes Rezept zu löschen, wenn eine Stornierungsanfrage von einer Pflegeeinrichtung eingeht, sodass ich keinen manuellen Aufwand damit habe. Gelingt dies nicht (wegen fortgeschrittenem Status), so soll mein System die Stornierungsanfrage automatisch negativ quittieren. 
• auch Folgerezepte an ein Pflegeheim bzw. eine heimversorgende Apotheke senden können, ohne dass diese mir vorher eine Rezeptanforderung gesendet haben, wenn diese z.B. telefonisch abgesprochen ist.
• zusätzliche Kontaktdaten des Anfragenden erhalten, um diese kurzfristig auch über andere Kommunikationskanäle innerhalb und außerhalb der Telematikinfrastruktur erreichen zu können (bzw. Telefonnummer und künftig auch TI-Messenger-Adresse). 
• falls sich eine Änderung in der Medikation ergibt, zusammen mit dem Rezept auch eine aktualisierte Version des Medikationsplans (z.B. als Anhang) an die Pflegeeinrichtung bzw. die heimversorgende Apotheke senden können, falls der Versicherte dem elektronischen Medikationsplan in der ePA widersprochen hat.
• dass mein System für meine Antwort die Empfängeradresse des Anfordernden automatisch übernimmt, damit ich mich nicht damit beschäftigen muss und Fehler im Prozess vermeide. 
• dass der Versand von E-Rezepten an eine Pflegeeinrichtung oder Apotheke mich in meinem Arbeitsprozess nicht aufhält.  
• eine Rezeptanfrage einfach ablehnen und die anfordernde Einrichtung darüber informieren können, wenn ich den Bedarf nicht nachvollziehen kann.
• nur einmalig konfigurieren müssen, dass die Nachrichten an die Pflegeeinrichtung in Kopie gesendet werden sollen und dass diese immer automatisch und ohne manuelle Aufwände für mich versendet werden.
• die Dringlichkeit der Anfrage erkennen können, um zu wissen wie schnell die Anfrage bearbeitet werden muss.
• dass mein System mich erinnert, wenn ich eine Anfrage länger nicht bearbeitet habe, sodass die Anfrage im Arbeitsalltag nicht untergeht. 
• sofern mein System die automatisierte Weiterverarbeitung nicht unterstützt, die Nachrichten in meinem KIM Postfach lesen können, sodass ich die Anforderung dennoch bearbeiten kann. 

Tabelle 1: Wichtige Begriffe aus dem Kontext des Epics Rezeptanforderung

2.2 Rezeptanforderungen für anwendungsfertige Zytostatika Zubereitungen

Abweichend vom Standardprozess für die Verordnung von apothekenpflichtigen Arzneimitteln kann die Herstellung von anwendungsfertigen Zytostatika Zubereitungen auf Basis einer ärztlichen Anordnung (Therapieplan, welche die Angaben nach §2 AMVV umfassen muss) erfolgen, noch bevor das zugehörige Rezept durch den behandelnden Arzt förmlich ausgestellt wird; eine Plausibilitätsprüfung nach § 7 Abs. 1b ApBetrO muss möglich sein. Notwendig ist dies, da es im Rahmen der Zubereitungen zu kurzfristigen Änderungen kommen kann und möglichst termingenaue Lieferungen notwendig sind (mehrfache Anpassung des Therapieplanes). Ein Mitwirken des Versicherten für die Erstellung des E-Rezepts durch den Arzt und die Verarbeitung des E-Rezepts in der Apotheke ist nicht notwendig.

Übermittlung der Information über KIM:

Die Rezeptanforderung wird via KIM als Kommunikationsmedium zur Übermittlung der notwendigen Informationen zwischen Apotheken und Verordnenden übertragen, sodass ein korrektes, abrechnungsfähiges E-Rezept erstellt werden kann.

Die Übermittlung einer Rezeptanforderung via KIM wurde einstimmig von der Industrie unter Befürwortung der gematik und Charité gewählt, da es sich hierbei um einen bereits etablierten sowie sicheren Übermittlungsverfahren handelt.

2.2.1 User Stories des abgebenden Leistungserbringers

Als Apotheker möchte ich:

• dass die korrekte Abrechnung der hergestellten Arzneimittel durchgeführt werden kann.
• dass die Dosierung der Zubereitung gemäß der Abgabe im E-Rezept dokumentiert ist.
• dass ein E-Rezept einem Vorgang in der Herstellung- / Taxierungssoftware zugeordnet werden kann.

2.2.2 User Stories des verordnenden Leistungserbringers

Als verordnender Arzt möchte ich:

• ein angefordertes Rezept direkt an die Apotheke übermitteln.
• alle notwendigen Informationen zum Rezept übermittelt bekommen, um Nachfragen bei der Apotheke zu vermeiden.
• eine automatische Vorbereitung des E-Rezepts im Primärsystem, sodass ich das Rezept nur noch prüfen muss und dann verschreiben kann.

2.2.3 User Stories des Versicherten

Als Versicherter möchte ich:

• die verordneten und erhaltenen Arzneimittel in der E-Rezept-App sehen können.
• für den Erhalt des Arzneimittels nicht aktiv werden müssen
• die Möglichkeit haben, Chargen-Informationen der verabreichten Arzneimittel nachvollziehen zu können.

3 Fachliches Konzept

Im fachlichen Konzept werden Nachrichten definiert, welche im Kontext des E-Rezepts dezentral zwischen den Beteiligten versendet und empfangen werden. Die Daten der Nachrichten werden dabei strukturiert und in FHIR-Bundles aufbereitet.

Als sicheres Verfahren zur Übermittlung ist die TI-Anwendung Kommunikation im Medizinwesen (KIM) vorgesehen. Grundsätzlich sind auch andere Verfahren, bspw. zukünftig der TI-Messenger, denkbar.

3.1 Fachliche Informationsmodelle

Die fachlichen Informationsmodelle für den Austausch von Nachrichten der beteiligten Teilnehmer sind als FHIR-Logical Models abgebildet. Sie lassen sich unter folgenden Quellen (https://simplifier.net/erezept-servicerequest ) abrufen:

Tabelle 2 : Fachliche Informationsmodelle

3.2 Use Cases für Rezeptanforderungen

Im Prozess der Rezeptanforderung kann der Anfragende eine Nachricht an einen verordnenden Leistungserbringer senden und ein oder mehrere Rezepte anfragen. Der Vorgang, sowie jede einzelne Anfrage zu einem Arzneimittel, lassen sich jeweils über die Vorgangs- bzw. Request-ID im FHIR-Datensatz referenzieren.

3.2.1 UC1: Rezeptanforderung durch Pflegeeinrichtung

Die Rezeptanforderung wird durch die Pflegeeinrichtung initiiert. Die Pflegeeinrichtung sendet die Rezeptanforderung, die mehrere Arzneimittel beinhalten kann, an den Verordnenden. Der Wunsch zur Ausstellung einer Mehrfachverordnung, sowie die Dringlichkeit aufgrund geringer Restreichweite und der Grund der Anfrage, kann angegeben werden. Weiterhin kann die Pflegeeinrichtung Anhänge, wie zum Beispiel den aktuellen Medikationsplan, bereitstellen.

Die Pflegeeinrichtung kann eine Anforderung zum Stornieren der Rezeptanforderung an den Verordnenden senden, sodass der Verordnende das E-Rezept nicht erstellt oder das bereits erstellte E-Rezept löscht.

Der Verordnende erstellt ein E-Rezept (Workflow mit Steuerung durch Leistungserbringer (169 bzw. 209))  und sendet die Informationen zum E-Rezept zurück an die Pflegeeinrichtung. Der Verordnende kann die Rezeptanforderung ablehnen. 

Die Pflegeeinrichtung leitet nach Erhalt der Rezeptinformationen diese an die heimversorgende Apotheke weiter und kann die medizinischen Informationen in das Dokumentationssystem übernehmen. Die Weiterleitung an die heimversorgende Apotheke kann automatisiert geschehen. Der Pflegeeinrichtung steht die Option zur Verfügung, wie die Belieferung der Arzneimittel erfolgen soll: Abholung per Bote von der Pflegeeinrichtung, Lieferung per Bote von der Apotheke oder Abholung durch den Versicherten/einem Vertreter.

Die Apotheke beliefert das E-Rezept und übermittelt eine Bestätigung und Inhalt zum abgegebenen Arzneimittel an die Pflegeeinrichtung. Die Pflegeeinrichtung kann diese Informationen ebenfalls in ihr Dokumentationssystem übernehmen.

Falls bei der Prüfung des E-Rezeptes in der Apotheke ein Fehler auftritt, kann die Apotheke das E-Rezept zurückgeben und den Anwendungsfall "UC3: Rezeptanforderung der heimversorgenden Apotheke" ausführen, um ein neues korrigiertes E-Rezept vom verordnenden Leistungserbringer anzufordern (Korrekturfall). Der Verordnende kann nach Prüfung der Anfrage das ursprüngliche Rezept selbst löschen und ein neues, korrigiertes Rezept an die anfordernde Apotheke senden. Jede Nachricht die in diesem Fall ausgetauscht wird, soll in Kopie auch an die Pflegeeinrichtung gehen. 

Abbildung 3: Sequenzdiagramm Rezeptanforderung durch Pflegeeinrichtung

3.2.2 UC2: Rezeptanforderung der Pflegeeinrichtung mit Einlösung durch Patient

Die Rezeptanforderung wird durch die Pflegeeinrichtung initiiert. Die Pflegeeinrichtung sendet die Rezeptanforderung an den Verordnenden mit dem Hinweis, dass der Versicherte das E-Rezept selbst einlöst. Der Verordnende erstellt ein E-Rezept (Workflow 160 bzw. 200) und sendet die Informationen zur Verordnung, jedoch ohne den E-Rezept-Token, zurück an die Pflegeeinrichtung. Der Verordnende kann die Rezeptanforderung ablehnen. 

Der Versicherte hat die Möglichkeit, mittels E-Rezept-FdV auf das E-Rezept zuzugreifen, sich einen Ausdruck beim Verordnenden abzuholen oder das E-Rezept mittels eGK in einer Apotheke seiner Wahl einzulösen. 

Die Pflegeeinrichtung kann eine Anforderung zum Stornieren der Rezeptanforderung an den Verordnenden senden, sodass der Verordnende das E-Rezept nicht erstellt oder das bereits erstellte E-Rezept löscht. 

Abbildung 4: Sequenzdiagramm Rezeptanforderung durch Pflegeeinrichtung (Selbstabholer)

3.2.3 UC3: Rezeptanforderung der heimversorgenden Apotheke

Die Rezeptanforderung wird durch eine Apotheke initiiert. Die Apotheke sendet die Rezeptanforderung mit allen relevanten Informationen an den verordnenden Leistungserbringer und übermittelt eine Kopie der Anfrage an die Pflegeeinrichtung.

Der Verordnende erstellt ein E-Rezept (Workflow mit Steuerung durch Leistungserbringer (169 bzw. 209)) und sendet die Informationen zum E-Rezept zurück an die heimversorgende Apotheke und übermittelt eine Kopie der Antwort an die Pflegeeinrichtung. Der Verordnende kann die Rezeptanforderung ablehnen. 

Die Apotheke sendet nach der Belieferung des E-Rezeptes die Informationen zu den abgegebenen Arzneimitteln an die Pflegeeinrichtung.

Die Apotheke kann eine Anforderung zum Stornieren der Rezeptanforderung an den Verordnenden senden, sodass der Verordnende das E-Rezept nicht erstellt oder das bereits erstellte E-Rezept löscht. 

Abbildung 5: Sequenzdiagramm Rezeptanforderung durch heimversorgende Apotheke

3.2.4 UC4: Rezeptanforderung für anwendungsfertige Zytostatika Zubereitungen

Die KIM-Kommunikation zur Rezeptanforderung für anwendungsfertige Zytostatika Zubereitungen findet zwischen der herstellenden Apotheke und dem verordnenden Leistungserbringer statt.

Bei der herstellenden Apotheke können zwei unterschiedliche Sendequellen auftreten, diese Sendequelle wird im Weiteren als "Apothekensystem" bezeichnet:

• das Zytostatika-Programm (Hierbei handelt es sich um eine Spezialsoftware innerhalb der Apotheke, welches bei der Herstellungsdokumentation und -planung von anwendungsfertige Zytostatika Zubereitungen unterstützt.)
  
• die Taxierungssoftware (hierbei handelt es sich um eine Software zur Preisermittlung gemäß gültiger Verträge und zur Abrechnung eingereichter Rezepte)

Die Rezeptanforderung wird von der Apotheke nach dem Start der Zubereitung initiiert. Ein Therapieplan, der die Anforderungen aus §2 AMVV erfüllt, muss zu diesem Zeitpunkt in der Apotheke vorliegen.

Das Apothekensystem sendet die Rezeptanforderung an das Primärsystem der verordnenden LEI. Der Verordnende erstellt ein E-Rezept (Workflow mit Steuerung durch Leistungserbringer (169 bzw. 209)). Der Verordnende prüft und signiert die Verordnung. Das Primärsystem stellt das E-Rezept im E-Rezept-Fachdienst ein und erhält im Response die Informationen zum E-Rezept-Token. Das Primärsystem sendet in einer Antwortnachricht zur Rezeptanforderung die E-Rezept bezogenen Informationen (E-Rezept-Token) an das Apothekensystem zurück.

Der Verordnende kann eine Rezeptanforderung ablehnen. 

Die Apotheke kann die Rezeptanforderung stornieren, solange der Verordnende den E-Rezept-Token noch nicht an die Apotheke übermittelt hat. Wenn die Stornierung nicht möglich ist, weil das E-Rezept bereits ausgestellt wurde, dann hat die Apotheke die Informationen zum E-Rezept übermittelt bekommen. Die Apotheke kann das E-Rezept abrufen und eigenständig löschen oder zurückgeben und durch den Arzt löschen lassen.

Abbildung 6: Sequenzdiagramm Rezeptanforderung durch Apotheke für anwendungsfertige Zytostatika Zubereitungen

4 Einordnung in die Telematikinfrastruktur

Der Versand von E-Rezept-Token und Informationen im Kontext von E-Rezepten zwischen Leistungserbringerinstitutionen in der TI setzt auf die Nachnutzung bereits vorhandener Komponenten. Es werden die KIM-Clientmodule in den Leistungserbringerinstitutionen, die KIM-Fachdienste sowie der Verzeichnisdienst der TI (VZD) genutzt. KIM steht für die Anwendung "Kommunikation im Medizinwesen" und bietet einen sicheren Informationstransportkanal zwischen Leistungserbringerinstitutionen an.

Die Nutzung von KIM ist vergleichbar mit dem Schreiben, Versenden und Empfangen von E-Mails. Darüber hinaus nutzt KIM eine Nachrichtensignatur und -verschlüsselung, was KIM-Nachrichten vertrauenswürdig (weil vom Sender signiert) und vertraulich (weil vom Sender für den Empfänger verschlüsselt) macht.

Die Leistungserbringer(-institutionen) kommunizieren in Form von E-Rezept-spezifischen FHIR-Nachrichten, die vom Primärsystem des Absenders vor Versand über KIM erzeugt bzw. bereitgestellt und vom Primärsystem des Empfängers nach Empfang über KIM interpretiert bzw. verwaltet werden müssen. Eine automatische Verarbeitung der Nachrichten ist möglich und wird empfohlen. Vor Versand und nach Empfang der E-Rezept-spezifischen Nachrichten ist es möglich, dass das jeweilige Primärsystem diese Nachrichten mit Hilfe des Gematik Referenzvalidators auf formale Korrektheit und technische Verarbeitbarkeit hin prüft. Dazu gehört die Prüfung, dass die FHIR-Ressourcen konform zu den referenzierten Profilen bzw. Profilversionen sind,

Abbildung 7: Übersicht Nutzung KIM-Nachrichten für E-Rezept 

5 Technisches Konzept und Spezifikation

Das technische Konzept behandelt die Abbildung der fachlichen Informationseinheiten auf FHIR-Objekte und -Ressourcen sowie die Beschreibung von Use Cases, die eine dezentrale Umsetzung der Kommunikation zwischen den Beteiligten ermöglichen.

Für den Datenaustausch werden FHIR-Ressourcen genutzt, die speziell für diesen Anwendungsfall profiliert wurden. Als Kommunikationsmedium ist die Verwendung von KIM vorgesehen.

Dieses Kapitel beschreibt die spezifischen Anforderungen und Vorgaben für diese Umsetzung.

5.1 FHIR-Ressourcen

Die in diesem Anwendungsfall genutzten FHIR-Ressourcen werden im XML-Format übertragen und setzen sich aus folgenden FHIR-Projekten zusammen.

5.1.1 Rezeptanforderung FHIR-Projekt

Zur Umsetzung der Use Cases wurden für die Datensätze FHIR-Profile definiert und über Simplifier veröffentlicht.

Die detaillierte Beschreibung zur Nutzung der Profile und technischen Beschreibung der Use Cases findet sich im Implementation Guide. Hier findet sich auch das Mapping der fachlichen Informationen auf technische Profile. 

Primärsysteme, die dieses Feature umsetzen müssen den Implementation Guide aus dem FHIR-Projekt umsetzen.

Tabelle 3 : Dokumentation ServiceRequest

5.1.2 App Transport Framework FHIR-Projekt

Für die Übermittlung der Rezeptanforderung wird das App Transport Framework (ATF) genutzt. Das ATF bietet eine Grundprofilierung, die für andere Anwendungsfälle verwendet wird. Die FHIR-Profile aus diesem Feature basieren auf den Profilen des ATF.

Tabelle 4 : Dokumentation ATF

5.1.3 Validierung von FHIR-Ressourcen

Die gematik empfiehlt die Durchführung einer Validierung von erzeugten (und über KIM zu versendenden) und konsumierten (und über KIM zu empfangenen) FHIR-Ressourcen im Rahmen der jeweiligen Primärsysteme mittels eines Validierungstools. Als Validierungstool wird der [gematik_Referenzvalidator] empfohlen, welcher seinerseits den HAPI-Validator als Kernkomponente kapselt.

Der Referenzvalidator kann auch als entwicklungsunterstützende Maßnahme verwendet werden.

Die Bereitstellung eines Plug-Ins erfolgt nach finaler Veröffentlichung des Feature Dokuments.

Für das Konsumieren von über KIM zugestellten FHIR-Ressourcen wird die Umsetzung des sog. Schiedsrichter-Szenarios des Referenzvalidators empfohlen. Dieses besagt, dass eine Validierung von über KIM empfangenen FHIR-Ressourcen durchgeführt wird, sofern die im Primärsystem implementierte Fachlogik zur Interpretation der FHIR-Ressourcen fehlschlägt. Daraufhin wird der Referenzvalidator genutzt, um zweifelsfrei festzustellen, ob die empfangenen Ressourcen tatsächlich invalide sind und - falls dem so ist - Maßnahmen ergreifen zu können, wie beispielsweise das Zurückweisen oder absichtliche Ignorieren der betreffenden empfangenen Nachricht sowie das Informieren des Anwenders.

Der Referenzvalidator ist in der Lage, gezielt anhand referenzierter FHIR-Profile zu validieren und dabei Struktur, Kardinalität, Wertebereiche und Bindings von Codings und CodeableConcepts sowie Constraints und Invarianten zu prüfen.

Die Beschreibung von Validierungsschritten und das Ergreifen von Folgemaßnahmen bei Validierungsfehler sind nicht Bestandteil der Feature Beschreibung.

5.2 Vorgaben zu KIM-Nachrichten

Die in diesem Feature beschriebenen Anwendungsfälle sind mit KIM zu nutzen. Anfragen werden auf diesem Wege Peer-to-Peer unter den Beteiligten ausgetauscht.

Für KIM-Nachrichten in diesen Anwendungsfällen sind Message Disposition Notifications (MDN) zulässig. Bei Antworten auf einen Vorgang ist der InReplyTo-Header mit der Message-ID der ursprünglichen Nachricht zu belegen.

5.2.1 Aufbau der Nachricht

Jede Nachricht in diesem Anwendungsfall hat eine gesonderte Dienstkennung, Betreffzeile und Struktur, um einen möglichst hohen Grad an Dunkelverarbeitung zu ermöglichen.

5.2.1.1 Dienstkennung

Für KIM-Nachrichten in diesem Feature werden folgende KIM-Dienstkennungen genutzt:

1. eRezept;atf_eRezept_Rezeptanforderung;1.0
2. eRezept;atf_eRezept_ParenteraleZubereitung;1.0

Der erste Teil bezieht sich auf die Anwendung, der zweite Teil indiziert den ATF-Anwendungsfall, welcher sich aus [ATF-UseCase-CS] ergibt. Die Version 1.0 bezieht sich auf die Version dieses Feature Dokuments.

Das signalisiert einem empfangenden Client, dass diese Nachricht eine strukturierte FHIR-Nachricht des entsprechenden Anwendungsfalls enthält und im Rahmen einer ATF Nachricht auszuwerten sind. Die Daten entsprechen dem Datenmodell des ATF. Das ermöglicht einem Client Nachrichten im Posteingang zu verschatten und eine Businesslogik zu implementieren, um die Nachricht im Hintergrund zu verarbeiten.

5.2.1.2 Betreff und Body der Nachricht

Wenn eine KIM-Nachricht erstellt wird, kann der Body-Text, der für den Empfänger der Nachricht gedacht ist, vom Sender gesetzt werden. Das PS kann den Anwender dabei unterstützen einen Text zu generieren oder er kann als Freitext vom Sender verfasst werden.

Zum Setzen des Betreffs kann das PS einem vom Nutzer definierten oder automatisch generierten Text setzen. Als weitere Option enthält das FHIR-Package die ConceptMap "Service Identifier To Subject Concept Map". Diese bildet den Nachrichtentyp auf einen String ab, der als Betreffzeile für die KIM-Nachricht genutzt werden kann.

5.2.1.3 Anhänge

Eine ATF KIM Nachricht für Rezeptanforderungen enthält neben dem Freitext der Nachricht mindestens zwei Anhänge: den FHIR-Datensatz und eine PDF-Repräsentation der Nachricht.

Folgende Anhänge werden in diesem Feature definiert und im Folgenden erläutert:

Tabelle 5 : Anhänge der KIM-Nachricht

5.2.1.3.1 FHIR-Datensatz zur Rezeptanforderung

Der FHIR-Datensatz wird gemäß dem oben referenzierten Implementation Guide erstellt und der KIM-Nachricht als Base64 -Datensatz angehangen. Der FHIR-Datensatz wird nicht durch den Sender signiert.

Der FHIR-Datensatz wird über den Content-Type "application/fhir+xml" identifiziert. Der filename lautet "atf_eRezept_Rezeptanforderung.xml" für eine Rezeptanforderung und "atf_eRezept_ParenteraleZubereitung.xml" für eine Rezeptanforderung einer anwendungsfertigen Zytostatika Zubereitung. Diese Dateinamen ergeben sich aus [ATF-UseCase-CS].

5.2.1.3.2 PDF Repräsentation der Rezeptanforderung

Um sicherzustellen, dass jede Nachricht auch verarbeitet werden kann, wenn der Empfänger das Feature nicht implementiert hat, muss jeder KIM-Nachricht eine PDF-Repräsentation der Nachricht angehangen werden.

Für jeden Nachrichtentyp aus dem Anwendungsfall "Rezeptanforderung" wird ein XSLT-Stylesheet bereitgestellt. Diese XSLT-Stylesheets können genutzt werden, um den FHIR-Datensatz in HTML zu überführen. Das sendende System muss dieses HTML anschließend in ein PDF konvertieren.

Der Content-Type des PDFs ist "application/pdf", und der filename lautet bspw. "eRezept_Rezeptanforderung;Rezeptanfrage.pdf" für die PDF einer initialen Rezeptanforderung eines Anfragenden an Verordnenden. Die Namen ergeben sich analog zum FHIR-Datensatz aus [ATF-ServiceIdentifier-CS].

5.2.1.3.3 Weitere Anhänge

Für den Nachrichtentyp "Rezeptanforderung_Bestätigung" in UC2 muss das verordnende PS der Nachricht auch den Patientenausdruck als PDF anhängen. Dieser wird nach der PDF-Repräsentation der Rezeptanforderung angehängt und trägt den filename "patientenausdruck.pdf". Dieser Ausdruck kann von der Pflegeeinrichtung ausgedruckt und dem Versicherten zur Einlösung des E-Rezeptes bereitgestellt werden.

Es ist möglich, weitere Anhänge bereitzustellen. Diese werden ebenfalls als PDF-Repräsentation angehangen und sind dem Nutzer des empfangenden Systems anzuzeigen. Beispielsweise kann der Medikations- oder Therapieplan angehangen werden.

5.2.2 Beispielhafte KIM-Nachricht

5.3 Verarbeitung von Rezeptanforderungen

5.3.1 Dunkelverarbeitung und Kennzeichnungen

Das Konzept ist dahingehend ausgelegt, dass alle Nachrichten von Nutzern mindestens in Form eines PDFs verstanden und bearbeitet werden können. Die Nutzung eines FHIR-Datensatzes soll jedoch dazu dienen, dass die Anfragen und Antworten automatisiert in einer Dunkelverarbeitung abgearbeitet werden können.

PS mit integrierten KIM-Client Modulen können anhand der KIM-Dienstkennung erkennen, dass die Nachricht einen FHIR-Datensatz im Rahmen dieses Features enthält und entsprechende Businesslogik anstoßen.

Der FHIR-Datensatz wiederum enthält in MessageHeader.eventCode den Anwendungsfall, sowie den genauen Nachrichtentyp innerhalb des Anwendungsfalls. Damit können die überlieferten Informationen ausgewertet und dem Nutzer innerhalb des PS zur Darstellung gebracht werden.

Informationen zur Auswertung des Datensatzes finden sich im [FHIR-IG-ServiceRequestIG].

Im folgenden eine tabellarische Darstellung der verwendeten Codes und Kennzeichnungen:

Tabelle 6 : Kennzeichen KIM-Nachricht und FHIR-Datensatz

5.3.2 Statusverwaltung

Das Konzept ermöglicht es in jedem Anwendungsfall dem Nutzer darzustellen, in welchem Status sich der Anwendungsfall befindet. Dieser Status kann nur durch den Anfragenden verfolgt werden, da dieser den Prozess steuert. Für die Anwendungsfälle UC3 und UC4 findet nur eine bilaterale Kommunikation zwischen Apotheke und Verordnendem statt.

In UC1 und UC2 ist die Pflegeeinrichtung jeweils diejenige, die den Prozess steuert, sowie Rezept- und Abgabeanfrage versendet, und somit den Status nachverfolgen kann. In UC3 kann die Pflegeeinrichtung durch erhalt der Kopien den Bearbeitungsstand ebenfalls nachvollziehen.

5.3.3 Workflow-Typen von E-Rezepten

In der Kommunikation zu einer initialen Rezeptanforderung (Nachrichtentyp: Rezeptanforderung) wird mitgeteilt, ob die Einlösung des E-Rezeptes durch den Versicherten vollzogen werden soll. Dementsprechend muss das PS des verordnenden LE ein E-Rezept mit Workflow 160 bzw. 200 oder 169 bzw. 209 erstellen. Die folgende Tabelle zeigt die Bedingungen und die zu resultierenden Workflow-Typen der E-Rezepte auf:

Tabelle 7 : Workflow-Typen

6 Best Practice UX Primärsysteme

Folgende Aspekte sollen hierbei beachtet werden:

Rezept-anforderndes Primärsystem (Pflegeeinrichtung/Apotheke)

• Bestehende Arbeitsabläufe im System zur Rezeptanforderung (z.B. via Fax oder E-Mail) sollen nachgenutzt und um den Versand via KIM erweitert werden.
• Der Nutzer soll eine Rezeptanforderung aus der Medikationsdokumentation heraus auslösen können.
• Der Nutzer soll in einer Liste gesammelte Rezeptanforderungen für verschiedene Versicherten (z.B. alle Versicherte von einem Arzt oder aus einer Heimeinheit) für einen konfigurierbaren Zeitraum (z.B. alle Rezepte die in den nächsten zwei Wochen fällig werden) auslösen können (die dann aber dennoch jeweils als einzelne Nachricht verschickt werden). 
• Der Nutzer soll die Rezeptanforderung mit möglichst wenig manuellem Aufwand ausfüllen können und bei der Eingabe von Pflichtfeldern unterstützt werden.
• Der Nutzer soll vom System unterstützt werden Daten aus der Patientenakte des Primärsystems in die Rezeptanforderung ohne manuellen Aufwand zu übernehmen (Versicherter, behandelnder Arzt, Arzneimittel, ...) und diese bei Bedarf noch anpassen können.
• Das System soll den Nutzer dabei unterstützen, die richtige KIM-Adresse in der Anfrage einzufügen, sodass der Nutzer nicht bei jeder neuen Anfrage die KIM-Adresse der verordnenden Leistungserbringerinstitutionen und der betreuenden Pflegeeinrichtungen aus dem VZD oder der Patientenakte des Primärsystems heraussuchen muss. 
• Das System soll dem Nutzer den aktuellen Status der gestellten Rezeptanforderungen (an Verordneten gesendet, storniert, Rezept erhalten, Rezept an Apotheke weitergeleitet, Arzneimittel erhalten) in einer Übersicht anzeigen.
• Das System soll es dem Nutzer ermöglichen in dieser Übersicht einzelne Rezeptanforderungen zu stornieren. 
• Das System soll dem Nutzer in dieser Übersicht den Kommunikationsverlauf zu einer Rezeptanforderung in einer zusammenhängenden Darstellung anzeigen, sodass die Nutzer diesen nachvollziehen kann.
• Der Nutzer soll Informationen zur Verordnung und zu dem abgegebenen Arzneimittel sowie ggf. beigefügte Dokumente in die Medikationsdokumentation der Patientenakte übernehmen können. Eine Konfiguration zur Automatisierung ist möglich. 
• Das System soll den Nutzer über eingehende Antworten des Verordnenden benachrichtigen. 
• Das System der Pflegeeinrichtung soll dem Nutzer ermöglichen, Regeln für die Weiterleitung von verordneten Rezepten zu definieren, nach denen die Rezepte automatisch an eine heimversorgende Apotheke weitergeleitet werden können.

Primärsystem verordnende Leistungserbringerinstitution:

• Das System soll die Inhalte der KIM-Nachricht aufarbeiten und übersichtlich im Primärsystem in einer Aufgabenliste anzeigen.
• Das System soll in den Rezeptanforderungen einen Absprung in die zugehörige Patientenakte ermöglichen.
• Das System soll Informationen zum angeforderten Rezept aus der Anfrage übernehmen und das E-Rezept soweit wie möglich vorbereiten, sodass der Nutzer nur noch prüfen (ggf. anpassen) und signieren muss oder es ablehnen kann.
• Das System soll Inhalte von neuen Rezeptanforderung mit zuvor verschriebenen Rezepten oder dem Medikationsplan vergleichen und die Unterschiede dem Nutzer anzeigen, sodass Abweichungen leicht auffallen.
• Das System soll nach dem erfolgreichen Einstellen des E-Rezeptes in den E-Rezept-Fachdienst die Antwortnachricht ohne weiteren Klick erstellen und versenden. Der Empfänger soll automatisch aus der Rezeptanforderung übernommen werden. 
• Das System soll den Nutzer über eingehende Rezeptanforderungen benachrichtigen (Notification).
• Das System soll den Nutzer erinnern, wenn Rezeptanforderungen länger nicht bearbeitet wurden.
• Das System soll stornierte Rezeptanfragen automatisch aus der Aufgabenliste löschen, sofern das Rezept noch nicht erstellt wurde.
• Das System soll automatisch eine Antwort an den Anfordernden senden, wenn ein Rezept aus einer stornierten Rezeptanfrage nicht mehr gelöscht werden kann.
• Das System soll dem Nutzer ermöglichen, mehrere Rezeptanfragen gesammelt auf einen Klick zu beantworten (also E-Rezepte signieren, E-Rezepte einstellen und Antwort versenden). Der Signatur und Versandprozess soll den Nutzer nicht bei der weiteren Arbeit im System blockieren.

Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp] und die beispielhafte Umsetzung im TI Demonstrator: Rezeptanforderung: Ambulanter Pflegedienst und Rezeptanforderung: Heimversorgende Apotheke 

Primärsystem abgebende Leistungserbringerinstitution (Apothekenverwaltungssystem)

• Das AVS soll ermöglichen, dass die Informationen zum abgegebenen Arzneimittel automatisch an die Pflegeeinrichtung gesendet werden. 
• Das AVS soll den Nutzer bei eingehenden zugewiesenen E-Rezepten benachrichtigen (Notification).
  

Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp] die beispielhafte Umsetzung im TI Demonstrator: Rezeptanforderung: Ambulanter Pflegedienst und Rezeptanforderung: Heimversorgende Apotheke 

7 Datenschutz und Sicherheit

Das Feature "KIM-Nachrichten für das E-Rezept" beinhaltet keine Erweiterungen für die Produkttypen der Anwendung E-Rezept. Für die Realisierung des Kommunikationsbedarfs zwischen verschiedenen Leistungserbringern mit Bezug zu ausgestellten oder auszustellenden E-Rezepten wird das sichere Übermittlungsverfahren KIM genutzt. Dazu müssen die Kommunikationspartner Teilnehmer an KIM sein und im Zuge dessen das KIM-Produkt eines zugelassenen KIM-Anbieters nutzen. Durch die Produktzulassung und Anbieterzulassung wird die Sicherheit und Datenschutzkonformität von KIM-Produkten sichergestellt. KIM ist für die Übertragung von personenbezogenen medizinischen Daten geeignet -  und damit auch für die Übertragung von Informationen zu bzw. aus E-Rezepten.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Referenzierte Dokumente

8.2.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

8.2.2 Weitere Dokumente

8.2.3 Weitere Quellen

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis