Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

KIM-Nachrichten für das E-Rezept

    

     

      
Version
      
2.0.0
     
     

      
Revision
      
1329499
     
     

      
Stand
      
08.08.2025
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
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 die bestehenden Prozesse zum Verordnen und Abgeben von E-Rezepten unterstützen. Es werden verschiedene Anwendungsszenarien betrachtet:

• Anforderung von Rezepten im Kontext der Pflege
• Anforderung von Rezepten für anwendungsfertige Zytostatikazubereitungen

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 dargestellten Beschreibungen und den referenzierten Implementation Guides 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 (PS) 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 die Anwendung KIM. Der Nachrichtenaustausch zwischen einem Versicherten zu Apotheken über das E-Rezept-Frontend des Versicherten (E-Rezept-FdV), bei dem die Nachrichten auf dem E-Rezept-Fachdienst gespeichert werden, besteht davon unverändert. 

Die Pflichten der Ärzte zur wirtschaftlichen Verordnung bleiben unbenommen, der Anforderungskatalog nach § 73 SGB V für Verordnungssoftware gilt weiterhin uneingeschränkt. Auch die Pflichten der Ärzte nach § 15 (2) BMV-Ä bleiben unberührt.

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. 

Rolle Pflegeeinrichtung

Wenn im Dokument die Rolle Pflegeeinrichtung benannt wird, dann umfasst diese sowohl die stationären Pflegeheime als auch ambulanten Pflegedienste, sofern ambulanten Pflegedienste nicht explizit ausgeschlossen werden. 

Rolle heimversorgende Apotheke

Wenn im Dokument die Rolle heimversorgende Apotheke benannt wird, ist eine Apotheke gemeint, die auf Grundlage des Vertrages nach § 12a des Apothekengesetzes (ApoG) die Rezepte einer stationäre Pflegeeinrichtung beliefert.

Rolle Wunsch-Apotheke

Wenn im Dokument die Rolle Wunsch-Apotheke benannt wird, ist eine Apotheke gemeint, die auf Grundlage einer individuellen Vereinbarung/Absprache zwischen einem ambulanten Pflegedienst und eines Versicherten die Rezepte des Versicherten beliefert. Die Wahl der Apotheke liegt beim Versicherten. 

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 Versorgung 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 Rezeptmanagement 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, Pflegedienste und heimversorgende Apotheken. Daher soll es eine Möglichkeit geben, die Kommunikation im Rezeptmanagement für alle Beteiligten zu erleichtern. 

Anwendungsfall 1: Die Pflegeeinrichtung übernimmt das Rezeptmanagement

Ein Mitarbeiter der Pflegeeinrichtung stellt den Bedarf für ein Rezept fest (z.B. beim Stellen der Arzneimittel oder durch eine Reichweitenberechnung des Primärsystems). Die Pflegeeinrichtung übermittelt dann eine Rezeptanforderung an die Praxis des behandelnden Arztes unter Angabe eines Grundes für den neuen bzw. erneuten Bedarf (mögliche Gründe: 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 (ggf. auch eine Mehrfachverordnung) aus und übermittelt die Verordnungsdaten und Zugriffsinformationen (Rezept-ID & Accesscode) zurück an die Pflegeeinrichtung oder lehnt die Anfrage ab. Die Arztpraxis muss sicherstellen, dass die Prüfung der VSD nach den aktuellen Rahmenbedingungen durchgeführt wurde.

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 Versicherte bzw. ein Vertreter das Rezept selbst einlöst (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 Pflegeeinrichtung per KIM-Nachricht die Anfrage wieder stornieren.

Das Primärsystem der Arztpraxis kann dann je nach Bearbeitungsstatus entweder die Anfrage direkt aus der Aufgabenliste löschen oder ein bereits erstelltes E-Rezept löschen (sofern noch nicht eingelöst).

Abbildung 1 Prozessschaubild zu Anwendungsfall 1

Anwendungsfall 2: Eine heimversorgende Apotheke übernimmt das Rezeptmanagement

Disclaimer: Dieser Passus gilt erst nach Inkrafttreten einer entsprechenden Gesetzesänderung.

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 Primärsystem der Arztpraxis kann dann je nach Bearbeitungsstatus entweder die Anfrage 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 KIM-Nachrichten wird der Pflegeeinrichtung des Versicherten automatisiert eine Kopie der KIM-Nachricht übermittelt. Weiterhin informiert die heimversorgende Apotheke die Pflegeeinrichtung per automatisch erzeugter KIM-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.
• über neue Verordnungen in meinem Namen und die stattfindende Belieferung/Bevorratung (im Heim) bzw. Versorgung informiert sein. Das schließt die Transparenz zum Verordner und Beliefernden mit ein.
• die Dokumentation der erfolgten Versorgung in meiner ePA und in meinem (elektronischen) Medikationsplan.
• dass pflegende Angehörige bzw. gesetzliche Vertreter Zugriff auf die Informationen zum Verordnungsprozess haben können. 

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

Als Mitarbeiter einer Pflegeeinrichtung oder einer heimversorgenden Apotheke (mit entsprechender Einwilligung des Versicherten) 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 (insbesondre die KIM-Adresse), ggf. heimversorgenden Apotheke) aus meinem System in die Rezeptanforderung übernommen 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 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 die Information zum zur Anforderung erstellten 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 KIM-Nachrichten nicht automatisiert weiterverarbeiten kann, die Rückmeldung auf meine Rezeptanfrage in meinem KIM Postfach sehen und lesen können. 
• dass mein System die Empfängeradresse des Verordnenden automatisch übernimmt, damit ich mich nicht damit beschäftigen muss und Fehler im Prozess vermeide.  
• dass das Anfordern der  Rezepte und die Kenntnisnahme der Rückmeldungen von Apotheke und Arzt schnell abläuft 
  und mich in meinem Arbeitsprozess nicht aufhält.
• bei jedem Versicherten, für den ich die Versorgung übernehme, nur einmalig die KIM Adresse der Pflegeeinrichtung bzw. der heimversorgenden oder Wunsch-Apotheke und des Arztes (ggf. mehrerer Ärzte) im VZD der TI suchen müssen, sodass ich diese nicht bei jeder Anfrage erneut heraussuchen und eingeben muss. 

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 heimversorgende oder Wunsch-Apotheke weitergeleitet werden soll, sodass mich das Weiterleiten der KIM-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 (insbesondere die Informationen zur Einnahme) 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 Arzneimittel per Bote von der Pflegeeinrichtung abgeholt, per Bote von der Apotheke geliefert oder durch den Versicherten/einem Vertreter selbst abgeholt werden. Diese Angabe möchte ich nur einmalig manuell erfassen und dann automatisch ausgefüllt bekommen. 
• 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 ...

• nur einmalig konfigurieren müssen, dass die KIM-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 Konfiguration möchte ich jederzeit ändern können. 
• , sofern mein System die KIM-Nachrichten nicht automatisiert weiterverarbeiten kann, die Rückmeldung auf meine Rezeptanfrage in meinem KIM Postfach sehen und lesen können.

2.1.3 User Stories der abgebenden heimversorgenden oder Wunsch-Apotheke

Als Mitarbeiter einer heimversorgenden oder Wunsch-Apotheke möchte ich ...

• dass die per KIM übermittelten Rezept-Token in meiner Warenwirtschaft automatisiert verarbeitet werden, sodass ich die Zugangsdaten zum E-Rezept manuell aus meinem KIM Postfach in meine Warenwirtschaft übertragen muss. Sollte keine vollständige Integration umgesetzt sein, so sollte der Rezeptcode wenigstens als Datamatrix-Code (z.B. auf dem E-Rezept Ausdruck PDF) angezeigt werden, sodass ich diesen per Scan in meine Warenwirtschaft übernehmen kann. 
• , dass die Pflegeeinrichtung, von der ich ein Rezept erhalten, immer die Informationen zum abgegebenen Arzneimittel automatisch zugeschickt bekommt, wenn ich das Rezept beliefert habe. 

2.1.4 User Stories des verordnenden Leistungserbringers

Als verordnender Arzt möchte ich ...

• , dass mein Primärsystem 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 Primärsystem mich dabei unterstützt, ohne aufwendige manuelle Eingaben die Informationen aus der Rezeptanfrage in den Verordnungsprozess 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 Primärsystem automatisch versucht, ein bereits erstelltes E-Rezept zu löschen, wenn eine Stornierungsanfrage von einer Pflegeeinrichtung eingeht, sodass ich keinen manuellen Aufwand damit habe. Gelingt dies nicht (wegen fortgeschrittenem Status des E-Rezepts), so soll mein Primärsystem 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 Primärsystem für die Antwortnachricht die Empfängeradresse des Anfordernden automatisch aus der Anforderungsnachricht übernimmt, damit ich mich nicht damit beschäftigen muss und Fehler im Prozess vermeide. 
• , dass der Versand von Informationen zum ausgestellten E-Rezepten an eine Pflegeeinrichtung oder heimversorgende 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 im Primärsystem konfigurieren müssen, dass die KIM-Nachrichten an die Pflegeeinrichtung in Kopie gesendet werden sollen und dass diese immer automatisch und ohne manuelle Aufwände für mich versendet werden. Diese Konfiguration möchte ich jederzeit ändern können. 
• die Dringlichkeit der Anfrage erkennen können, um zu wissen wie schnell die Anfrage bearbeitet werden muss.
• dass mein Primärsystem mich erinnert, wenn ich eine Anfrage länger nicht bearbeitet habe, sodass die Anfrage im Arbeitsalltag nicht untergeht. 
• sofern mein Primärsystem die automatisierte Weiterverarbeitung nicht unterstützt, die KIM-Nachrichten in meinem KIM Postfach lesen können, sodass ich die Anforderung dennoch bearbeiten kann. 

2.2 Rezeptanforderungen für anwendungsfertige Zytostatikazubereitungen

Abweichend vom Standardprozess muss im Rahmen der Verordnung von anwendungsfertigen Zytostatikazubereitungen 
ein Therapieplan (enthält die Angaben nach § 2 AMVV) im Vorfeld der Verschreibung vom Arzt an die Apotheke übermittelt werden, 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 verordnendem Arzt übertragen, sodass ein korrektes, abrechnungsfähiges E-Rezept erstellt werden kann.

2.2.1 User Stories des abgebenden Apotheke

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 Arztes

Als verordnender Arzt möchte ich ...

• ein angefordertes Rezept direkt an die rezeptanfordernde 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 erstellen kann.

2.2.3 User Stories des Versicherten

Als Versicherter möchte ich ...

• die verordneten und bezogenen Arzneimittel im E-Rezept-FdV sehen können.
• 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.

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 1 : Fachliche Informationsmodelle

3.2 Use Cases für Rezeptanforderungen

Im Prozess der Rezeptanforderung kann die anfragende Institution (Pflegeeinrichtung oder heimversorgende Apotheke) eine Nachricht an einen verordnenden Leistungserbringer (im Folgenden: der Verordnende) senden und ein oder mehrere Rezepte anfragen. Der Vorgang, sowie jede einzelne Anfrage zu einem Arzneimittel, lassen sich jeweils über die Vorgangs- bzw. Anfrage-ID im FHIR-Datensatz referenzieren. Eine Beschreibung der im Projekt verwendeten Identifier ist auf der Seite [FHIR-IG - Festlegungen Identifier] im FHIR-IG beschrieben.

3.2.1 UC1: Rezeptanforderung durch Pflegeeinrichtung

Die Rezeptanforderung wird durch die Pflegeeinrichtung initiiert. Die Pflegeeinrichtung sendet die Rezeptanforderung an den Verordnenden. Die Rezeptanforderung kann mehrere Arzneimittel (ggf. auch von mehreren Versicherten) beinhalten. Die Pflegeeinrichtung kann den Wunsch zur Ausstellung einer Mehrfachverordnung, die Dringlichkeit aufgrund geringer Restreichweite und den Grund der Anfrage angeben. 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 für apothekenpflichtige Arzneimittel (160 bzw. 200)) 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 (z.B. Einnahmehinweis und Name des Arzneimittels) an einer geeigneten Stelle im Pflegedokumentationssystem speichern. 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. Das System der Pflegeeinrichtung soll diese Informationen ebenfalls in ihr Dokumentationssystem automatisch ü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 Versicherten

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 für apothekenpflichtige Arzneimittel (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

Disclaimer: Dieser Passus gilt erst nach Inkrafttreten einer entsprechenden Gesetzesänderung.

Die Rezeptanforderung wird durch eine heimversorgende Apotheke initiiert. Die heimversorgende 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 für apothekenpflichtige Arzneimittel (160 bzw. 200)), sendet die Informationen zum E-Rezept zurück an die anfordernde heimversorgende Apotheke und übermittelt eine Kopie der Antwort an die Pflegeeinrichtung. Der Verordnende kann die Rezeptanforderung ablehnen. 

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

Die heimversorgende 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 Zytostatikazubereitungen

Die KIM-Kommunikation zur Rezeptanforderung für anwendungsfertige Zytostatikazubereitungen 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 Zytostatikazubereitungen 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 Durchführung der Plausibilitätsprüfung bzw. 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 zurückgeben und durch den Arzt löschen lassen.

Abbildung 6: Sequenzdiagramm Rezeptanforderung durch Apotheke für anwendungsfertige Zytostatikazubereitungen

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 2 : 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 stellt ein übergeordnetes FHIR-Framework bereit, das neben wiederverwendbaren Basisprofilen auch verbindliche Konventionen und Nutzungsvorgaben definiert. Die in diesem Feature verwendeten FHIR-Profile orientieren sich an diesen Vorgaben und leiten sich aus den ATF-Grundprofilen ab.

Tabelle 3 : Dokumentation ATF

5.1.3 Validierung von FHIR-Ressourcen

In der Entwicklungs- und Testphase empfiehlt die gematik den Einsatz des Referenzvalidators [gematik_Referenzvalidator].

Der Referenzvalidator ist in der Lage, FHIR-Ressourcen 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. Er dient der Sicherstellung der strukturellen und semantischen Qualität von FHIR-Ressourcen, indem er hilft, Fehlerursachen zu analysieren sowie konzeptionelle oder syntaktische Schwächen frühzeitig zu erkennen und zu beheben.

Hinweis: Im Produktivbetrieb wird bei vollständiger Implementierung des ATF für jede Nachricht auf Seiten des Empfängers eine automatisierte Antwort erstellt und an den Absender versendet. Diese Rückmeldung enthält das Ergebnis der Verarbeitbarkeit der Nachricht. So wird sichergestellt, dass das sendende System darüber informiert ist, ob die übermittelte Nachricht vom Empfängersystem maschinell verarbeitet werden konnte.

Wenn das sendende System die Information erhält, dass das Verarbeiten beim Empfänger fehlgeschlagen ist, muss der Sender auf eine alternative Kommunikation zurückgreifen. Der Hersteller des sendenden Systems soll die nicht verarbeitbare Nachricht analysieren und bei Fehlerfreiheit den Empfänger über mögliche Probleme informieren.

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 automatisierter Verarbeitung der Nachricht zu ermöglichen.

5.2.1.1 Dienstkennung

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

1. eRezept;Rezeptanforderung;1.0
2. 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 verbergen und eine Businesslogik zu implementieren, um die Nachricht im Hintergrund automatisiert zu verarbeiten.

5.2.1.2 Betreff

Das Primärsystem setzt den Betreff mit einem, gemäß dem im FHIR-Package definierten ConceptMap [FHIR-IG - Service Identifier To Subject Concept Map], automatisch generierten Text. Die ConceptMap übersetzt den Nachrichtentyp der Nachricht in einen menschenlesbaren Text.

Der Betreff muss unter Verwendung dieser Übersetzung erstellt werden.

5.2.1.3 Freitext im Body

Das Befüllen eines Freitextes im Body der KIM-Nachricht ist nicht vorgesehen. Alle Informationen zur Anforderung, inklusive Freitexte des Senders, sind im FHIR-Datensatz aufzunehmen.

5.2.1.4 Anhänge

Eine ATF KIM-Nachricht für Rezeptanforderungen enthält mindestens zwei Anhänge: den FHIR-Datensatz und eine PDF-Repräsentation des Datensatzes. Um die Datensätze zu sortieren und ggf. via Dateinamen zuordnen zu können, soll die Vorgangs-ID (ServiceRequest.requisition) im Dateinamen als Präfix angegeben werden. Dabei gilt generell die folgende Bildungsregel:

Folgende Anhänge werden in diesem Feature definiert und MÜSSEN je nach verpflichtender Angabe bereitgestellt werden:

Tabelle 4 : Anhänge der KIM-Nachricht

Eine Rezeptanforderung enthält bspw. mindestens die folgenden Dateien:

• 2d3f5cea_eRezept_Rezeptanforderung;Rezeptanfrage_FHIR-Datensatz.xml
• 2d3f5cea_eRezept_Rezeptanforderung;Rezeptanfrage_PDF-Datensatz.pdf

5.2.1.4.1 FHIR-Datensatz zur Bearbeitung einer Rezeptanforderung

Der FHIR-Datensatz wird gemäß dem [FHIR-IG - Rezeptanforderung] erstellt und der KIM-Nachricht als Base64 -Datensatz angehangen. Der FHIR-Datensatz wird nicht durch den Ersteller signiert.

5.2.1.4.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 des Datensatzes 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.

5.2.1.4.3 Weitere Anhänge

Für den Nachrichtentyp "Rezeptanforderung_Bestätigung" in UC2 muss das Primärsystem (PS) des verordnenden LEI den Patientenausdruck entsprechend dem E-Rezept-Verfahren erstellen und als PDF der KIM-Nachricht beifügen.

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 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 Automatisierte Verarbeitung 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 abgearbeitet werden können.

Primärsysteme 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 enthält in MessageHeader.eventCode den Anwendungsfall, sowie den Nachrichtentypen innerhalb des Anwendungsfalls. Damit können die überlieferten Informationen ausgewertet und dem Nutzer innerhalb des Primärsystemes dargestellt und für die Vorbereitung der Verordnung genutzt werden. Dies ersetzt nicht die Prüfung (inkl. ggf. nötigen Anpassungen) und das Signieren des E-Rezepts oder ggf. das Ablehnen der Anfrage. 

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

Im folgenden eine tabellarische Darstellung der verwendeten Codes und Kennzeichnungen:

Tabelle 5 : 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 diejenige, die den Prozess steuert. Sie versendet sowohl die Rezept- an den Verordnenden als auch die Abgabeanfrage an die heimversorgende Apotheke und kann somit den Status nachverfolgen. In UC3 kann die Pflegeeinrichtung durch Erhalt der Kopien den Bearbeitungsstand ebenfalls nachvollziehen.

5.3.3 Workflow-Typen von E-Rezepten

Für E-Rezepte, die für anwendungsfertige Zytostatikazubereitungen ausgestellt werden, wird der Workflow mit Steuerung durch den Leistungserbringer (Flowtype 169 bzw. 209) genutzt. Für alle anderen Rezeptanforderungen werden Flowtypes gesetzt, bei denen der Leistungserbringer den Workflow nicht steuern kann.

Auch im Falle, dass das E-Rezept explizit nicht durch den Versicherten einzulösen ist, wird ein Flowtype ungleich 169 bzw. 209 verwendet.

Die folgende Tabelle zeigt die Bedingungen und die zu resultierenden Workflow-Typen der E-Rezepte auf:

Tabelle 6 : Workflow-Typen

6 Best Practice UX Primärsysteme

Die in diesem Kapitel beschriebenen best practice für User Experience soll die Umsetzung im Primärsystem so unterstützen, dass der Abarbeitung der Anwendungsfälle für den Nutzer effizient erfolgen kann.

Die best practice für User Experience stellen eine Umsetzungsempfehlung dar. D.h. es ist dem Hersteller eines Primärsystems freigestellt, effizientere Lösungen zu implementieren, welche den Prozessen in den Primärsystemen entsprechen.

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. Hinweis: Die Rezeptanforderung aus der Liste werden jeweils als einzelne Nachricht verschickt. 
• 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. Die Ansicht soll filterbar sein nach, bspw. nach offene Anforderungen ja nach Arzt, nach Versichertem, nach Dauer der Anforderung, nach abgelehnten Anforderungen. Die Darstellung des Status erfolgt auf Basis der zuletzt zum Vorgang versendeten bzw. erhaltenen Nachricht.
• 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 automatischen Übernahme der Daten ist möglich.
• Das System soll den Nutzer über eingehende Antworten (auch Ablehnungen) 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 den Nutzer auf dringliche Anfragen hinweisen und regelmäßig erinnern. 
• 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 (z.B. von einer MFA) vorbereitete Antworten auf Rezeptanfragen gesammelt auf einen Klick zu beantworten (also E-Rezepte signieren, E-Rezepte einstellen und Antwort versenden). Hierbei müssen die Inhalte des Rezepts und die zu versendenden Antwort klar erkennbar sein. Der Signatur und Versandprozess soll den Nutzer nicht bei der weiteren Arbeit im System blockieren. 
• Das System soll den Nutzer benachrichtigen, wenn eine automatische Verarbeitung einer Nachricht nicht erfolgen konnte, und ihm in diesem Fall das PDF anzeigen.
• Das System soll dem Nutzer das PDF anzeigen, falls eine automatische Zuordnung des Nachrichtentyps fehlgeschlagen ist.

Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp]

Eine beispielhafte Umsetzung der oben ausgeführten Anforderungen wird im Demonstrator dargestellt: 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 Glossar

Tabelle 7: Wichtige Begriffe aus dem Kontext des Epics Rezeptanforderung in der Pflege

8.3 Referenzierte Dokumente

8.3.1 Dokumente der gematik

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

8.3.2 Weitere Dokumente

8.3.3 Weitere Quellen

8.4 Abbildungsverzeichnis

8.5 Tabellenverzeichnis