Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

KIM-Nachrichten für das E-Rezept

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
660807
     
     

      
Stand
      
28.06.2023
     
     

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

• Anforderung von Folgerezepten für Dauermedikation in der Heimversorgung
• Anforderungen von Rezepten für parenterale Zubereitungen

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

Es sind folgenden Erweiterungen in zukünftigen Versionen geplant:

• Klärung von Nachfragen zu einer Verordnung von Apotheken zu Verordnenden

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 kurz gehalten 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 motiviert 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 Heimversorgung ist das Rezeptmanagement eine zentrale Aufgabe. Es existieren in der Praxis unterschiedliche Konstellationen. Der überwiegende Teil der stationär versorgten Patienten (Klient) überträgt die Medikationsgabe an eine Pflegeeinrichtung, diese ist damit für das Rezeptmanagement verantwortlich. Der Ablauf der Rezeptanforderung läuft heute meist über unsichere Kommunikationskanäle (Fax, E-Mail) bzw. wird durch aufwendige Botengänge erledigt. Durch die Digitalisierung des Rezeptformulars ergeben sich große 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. 

Hinweis: Die Anwendungsfälle wurden für den Einsatz in der stationären Pflegeeinrichtung konzipiert, können aber auch von ambulanten Einrichtungen genutzt werden, sofern passend und zulässig.

Fall 1: Die Pflegeeinrichtung übernimmt das Rezeptmanagement

Ein Mitarbeiter der Pflegeeinrichtung stellt Bedarf für ein Folgerezept fest (z.B. beim Stellen der Medikamente durch den Mitarbeiter 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 Bedarf (nach Dosierung, nach Vitalwertmessung, nach Bedarf). Der Arztpraxis werden die angeforderten Rezepte in einer Aufgabenliste im Praxisverwaltungssystem angezeigt, die eine schnelle Prüfung und Bearbeitung ermöglicht. Die Arztpraxis stellt das Rezept aus und übermittelt es zurück an die Pflegeeinrichtung oder lehnt die Anfrage ab. Die Pflegeeinrichtung leitet die Rezepte an eine Apotheke weiter, die die Medikamente dann bereitstellt. Optional kann die Apotheke der Pflegeeinrichtung per automatisch erzeugter Nachricht die Informationen zum abgegebenen Medikament zukommen lassen, falls diese von dem verordneten Medikament abweichen.

Je nach individueller vertraglicher Reglung ist es ebenfalls möglich, dass der Patient das Rezept selbst bei der Arztpraxis abholt und einlösen geht.

Sollte ein angefordertes Rezept nicht mehr benötigt werden (z.B. Bewohner 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).

Fall 2: Eine Apotheke übernimmt Rezeptmanagement für Dauermedikation

Eine stationäre Pflegeeinrichtung kann eine heimversorgende Apotheke nach § 12a ApoG mit der Versorgung mit Medikamenten und dem Rezeptmanagement für Dauermedikation beauftragen. In diesem Fall berechnet die Apotheke die Reichweite der Medikamente für die Bewohner der Pflegeeinrichtung. Die Apotheke benötigt rechtzeitig neue Rezepte, wenn das Ende der Reichweite in Sicht kommt. Diese kann die Apotheke über die Pflegeeinrichtung bei der behandelnden Arztpraxis anfordern. Der Arztpraxis werden die angeforderten Rezepte in einer Aufgabenliste im Praxisverwaltungssystem angezeigt, die eine schnelle Prüfung und Bearbeitung ermöglicht. Die Arztpraxis erstellt die angeforderten Rezepte und sendet sie zurück an die Pflegeeinrichtung, welche diese dann an die Apotheke (ggf. automatisiert) weiterleitetet. Wenn das Rezept nach ärztlicher Prüfung nicht benötigt wird, weil beispielsweise die Therapie angepasst wurde, kann die Arztpraxis die Anfrage ablehnen. Durch die Kommunikation über die Pflegeeinrichtung, kann diese beispielsweise Inhalte von neuen Verordnungen automatisch im System dokumentierten. Weiterhin kann die Apotheke der Pflegeeinrichtung per automatisch erzeugter Nachricht die Informationen zum abgegebenen Medikament zukommen lassen, falls diese von dem verordneten Medikament abweichen.

Sollte ein angefordertes Rezept nicht mehr benötigt werden (z.B. Bewohner wird ins Krankenhaus verlegt), oder wurde eine Anfrage fälschlicherweise verschickt, kann die Anfrage von der Apotheke oder der Pflegeeinrichtung 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).

2.1.1 User Stories des Versicherten

Als Versicherter möchte ich:

• wenn es so mit meiner Pflegeeinrichtung besprochen ist, meine Rezepte bei meinem Arzt abholen und 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 Apotheke möchte ich:

• die Rezeptanforderung direkt aus der Medikationsdokumentation oder künftig auch dem elektronischen Medikationsplan eines Versicherten auslösen können, damit ich Zeit spare und keine händischen Rezept-Anforderungslisten führen muss.
• in meinem System erkennen können, für welche Medikamente ich schon eine neue Rezeptanforderung angefragt habe (und wann), sodass ich nicht zweimal die gleiche Anforderung absende.
• dass automatisch alle verfügbaren Informationen (zum Versicherten, dem benötigten Medikament, dem behandelnden Arzt) aus meinem System in der Anforderung übermittelt werden, um Verzögerungen durch notwendige Nachreichungen zu vermeiden.
• 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 Medikament/Rezept zuordenbar sind, um den Kommunikationsverlauf eindeutig nachvollziehen zu können.
• 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. 
• 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 des Arztes 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.2.1 Zusätzliche User Stories der Pflegeeinrichtung

Als Mitarbeiter einer Pflegeeinrichtung möchte ich:

• die Rezeptanforderung digital und ohne Medienbruch über einen sicheren Kommunikationskanal an eine Arztpraxis übermitteln können.
• in meinem System konfigurieren können, ob und nach welchen Regeln die Rückmeldung einer Arztpraxis auf eine Rezeptanfrage (Rezeptübermittlung bzw. Ablehnung) direkt an eine heimbeliefernde Apotheke weitergeleitet werden soll.
• in meinem System hinterlegen können, wenn bei einzelnen Versicherten die Rezepte bei Rezeptanforderungen von dem Versicherten selbst abgeholt und eingelöst werden sollen.
• dass der Versicherte das Rezept nur selbst per App, Ausdruck oder Gesundheitskarte einlösen kann, wenn ich es in der Rezeptanforderung angegeben habe.
• bei Rezeptübermittlung die Informationen aus der Verordnung 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.
• von der heimversorgenden Apotheke Informationen über das abgegebene Medikament 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 Apotheke möchte ich:

• die Rezeptanforderung digital und ohne Medienbruch über einen sicheren Kommunikationskanal über die Pflegeeinrichtung an eine Arztpraxis übermitteln können.
• die Pflegeeinrichtung, die ich betreue, immer die Informationen zum abgegebenen Medikament automatisch zugeschickt bekommt, wenn ich das Rezept beliefert habe. 

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 Medikament und Versicherten) in einer Aufgabenliste anzeigt, um die Anfragen schnell abarbeiten zu können.
• dass mein System aus der Anfrage die Rezepte so vorbereitet, dass ich sie nur noch prüfen und signieren muss, sodass ich keine Zeit darauf verwenden muss, die Informationen aus der Anfrage in das Verordnungsmodul abzutippen. 
• alle Anfragen einzeln einsehen und prüfen können, sodass ich die Rezepte bewusst ausstelle und mir keine Fehler unterlaufen. 
• dass die Aufgabenliste automatisch um stornierte Rezeptanforderungen bereinigt wird, sodass ich keine Arbeit mit bereits stornierten Anfragen habe.
• dass mein System automatisch versucht ein bereits signierte 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. 
• 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 senden können.
• 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 das Erstellen der angeforderten Rezepte und der Versand schnell abläuft und 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.
• 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 erfolgt die Herstellung und Abgabe von parenteralen Zubereitungen auf Basis eines Therapieplans noch bevor das zugehörige Rezept durch den behandelnden Arzt ausgestellt wird. Notwendig ist dies, da es im Rahmen der Zubereitungen zu kurzfristigen Änderungen kommen kann und möglichst termingenaue Lieferung notwendig sind (mehrfache Anpassung des Therapieplanes).

Im Nachgang zur Abgabe wird ein E-Rezept benötigt, um die Abrechnung zu ermöglichen. Ein Mitwirken des Patienten für die Erstellung des E-Rezepts durch den Arzt und die Verarbeitung des E-Rezepts in der Apotheke ist nicht notwendig. Der Patient soll das E-Rezept sehen, jedoch nicht zuweisen oder löschen können.

Übermittlung der Information über KIM:

Im Rahmen eines VUD/ADKA-Positionspapieres wurde auf die Notwendigkeit hingewiesen, dass es für das Erstellen von E-Rezepten für parenterale Zubereitungen nach § 11 ApoG einer standardisierten Schnittstelle zwischen den Zytostatika-Herstellungsprogrammen der Apotheken und den KBV-zertifizierten Verordnungssystemen bedarf.

Die Rezeptanforderung soll als Kommunikationsmedium zur Übermittlung der notwendigen Informationen zwischen Apotheken und Verordnenden dienen, 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 Medikamente 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.
• , dass der Versicherte das Rezept nicht löschen oder einer Apotheke selbstständig zuweisen kann.
• 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 Medikamente in der E-Rezept-App sehen können.
• , dass ich für den Erhalt des Medikamentes nicht aktiv werden muss
• die Möglichkeit haben, Chargen-Informationen der verabreichten Medikamente nachvollziehen zu können.

Dieses Kapitel bitte nach dem Ausleiten aus Polarion löschen.

Bei der Belieferung von Rezepten kommt es in der Apotheke regelmäßig zu Unklarheiten, die vor einer Abgabe der jeweiligen Medikamente an die Patienten mit den verordnenden Ärzten aufgelöst werden müssen. Zwar dürfen Apotheken im Rahmen der zugelassenen Möglichkeiten Rezepte "heilen", dennoch werden in vielen Fällen zur Sicherheit und Dokumentation Rücksprachen mit dem Arzt gehalten.

Auch in Pflegeeinrichtungen kann es bei übermittelten Rezepten für die Bewohner zu Rückfragen an den verordnenden Arzt kommen, wenn etwa das Rezept von der Absprache in der Visite abweicht oder Dosierungshinweise fehlen oder unvollständig sind. 

Für die Lösung dieser Klärfälle werden bisher im Papierprozess zumeist die Kommunikationskanäle Telefon oder E-Mail im Rahmen des Austausches zwischen Apotheken und Ärzten verwendet (unsicher und unstrukturiert). Aufgrund der Heterogenität der Anfragen, die im Rahmen eines Klärfalls an eine Arztpraxis gestellt werden, muss jede Anfrage individuell geprüft und bearbeitet werden. Daher nehmen die Rücksprachen viel Zeit in Anspruch. 

Hier hilft es, Anfragen zu strukturieren und gleichzeitig eine sichere Kommunikation zu ermöglichen mit dem Ziel, alle beteiligten Akteure im Arbeitsalltag bei Klärfällen zu entlasten. 

Da die Klärfälle in der Arztpraxis nicht automatisiert beantwortet werden können (eine inhaltliche Prüfung und Rückmeldung ist notwendig) sollten diese Nachrichten nicht in dringenden Fällen genutzt werden. Es kann nicht sichergestellt werden, dass innerhalb weniger Minuten eine Rückmeldung erfolgt.

Wichtige Begriffe im Zusammenhang mit diesem Epic und deren Erläuterung:

Tabelle 2: Wichtige Begriffe aus dem Kontext des Epics Klärfall

Als Versicherter möchte ich:

• dass Klärfälle schnell und ohne meine Mitwirkung aufgelöst werden können, um meine Medikamente so schnell wie möglich zu erhalten.
• über das Löschen und Neuausstellen meiner E-Rezepte informiert werden, um den Überblick über meine Verordnungen zu behalten.

Als Verordnender möchte ich:

• alle notwendigen Informationen zum Klärfall (zum E-Rezept und Patient) bei der Nachricht sehen, um schnell antworten zu können.
• dass die Klärfallkommunikation auf ein spezifisches Rezept bezogen ist, damit der Informationsaustausch möglichst präzise ist und Unklarheiten vermieden werden.
• dass alle einem einzelnen Klärfall zugehörigen Nachrichten einander zuordenbar sind, um den Kommunikationsverlauf eindeutig nachvollziehen zu können.
• die vom Klärfall betroffene Originalverordnung in der Anfrage der Apotheke erhalten, um unabhängig von der Speicherung in meinen Systemen die ursprünglich verordnete Medikation einsehen zu können.
• erkennen können, ob die anfragende Apotheke eine Rückmeldung wünscht, um unnötige Kommunikationsschritte zu vermeiden.
• erkennen können, ob die anfragende Apotheke die Ausstellung eines neuen E-Rezeptes wünscht, um bei meinem Einverständnis darauf eingehen und vermeidbare Folgeanfragen zu umgehen.
• dass die Apotheke mir Vorschläge zu Rezeptänderungen zur Klärfallauflösung schicken kann, sodass ich diese nur noch prüfen muss.
• von der Apotheke erhaltene Vorschläge zu Rezeptänderungen visualisieren können, um einen besseren Überblick über die Alternativen zu erhalten.
• von der Apotheke erhaltene Vorschläge zu Rezeptänderungen anpassen können, um nicht auf die vorgeschlagenen Alternativen beschränkt zu sein.
• von der Apotheke erhaltene Vorschläge zu Rezeptänderungen nach meiner Prüfung und Anpassung akzeptieren und für die Generierung einer Antwort verwenden können, um das manuelle Erstellen von Antworten möglichst zu vermeiden.
• bei Bedarf neue E-Rezepte ausstellen und automatisch als Antwort auf die Klärfallanfrage an die Apotheke übermitteln können, um das Rezept nicht erneut vom Versicherten zuweisen lassen zu müssen.
• bei Bedarf von der Apotheke erhaltene Vorschläge zu Rezeptänderungen für das Ausstellen neuer E-Rezepte verwenden können, damit ich das Rezept bei Eignung nur noch signieren muss.
• bei Neuausstellung eines E-Rezeptes mit der Apotheke die Löschung des alten E-Rezeptes abstimmen können, um Mehrfachbelieferungen zu vermeiden.
• zusätzliche Kontaktdaten der anfragenden Apotheke erhalten, um diese kurzfristig auch auf über andere Kommunikationskanäle erreichen zu können.
• von meinem System regelmäßig an offene Fragen erinnert werden, damit ich diese noch beantworten kann und die Apotheke nicht zu lange auf meine Anfrage warten muss. 
• bei Bedarf die Klärfall-Nachrichten der Patientenakte mit einem Klick hinzufügen, damit die Information mir auch im Kontext der Behandlungsdokumentation angezeigt wird.
  
• NICHT durch diesen neuen Kommunikationsweg mit Nachrichten über jede kleine Rezeptänderungen überschwemmt werden, sondern nur wenn es wirklich relevant ist.
  
• Nachrichten, die mir nur zur Kenntnis geschickt werden, mit einem Klick entfernen können, sodass sie mich nicht im Arbeitsalltag stören.
  

Als Apotheker möchte ich:

• die Klärfallkommunikation mit einer Arztpraxis proaktiv aufnehmen können, um Verzögerungen in der Rezeptbelieferung zu minimieren.
• dass die Klärfallkommunikation auf ein spezifisches Rezept bezogen ist, damit der Informationsaustausch möglichst präzise ist und Unklarheiten vermieden werden.
• dass alle einem einzelnen Klärfall zugehörigen Nachrichten einander zuordenbar sind, um den Kommunikationsverlauf eindeutig nachvollziehen zu können.
• den Gegenstand der Rückfrage präzise mit den vorliegenden Informationen formulieren können, um die Anzahl der zu Auflösung des Klärfalls benötigten Kommunikationsschritte zu minimieren.
• kennzeichnen können, ob ich eine Rückmeldung seitens der Arztpraxis erwarte oder es sich lediglich um einen Hinweis handelt, um die Intention meiner Kontaktaufnahme deutlich herauszustellen.
• um die Neuausstellung eines E-Rezeptes bitten können, um die Bearbeitung auf Seiten der Arztpraxis zu beschleunigen. 
• dass alle für eine Klärfallbearbeitung in der Arztpraxis benötigten Daten in die Nachricht übernommen werden, um Verzögerungen durch notwendige Nachreichungen zu vermeiden.
• bei Erhalt einer Antwort auf eine Klärfallanfrage zweifelsfrei erkennen können, ob ein neuer E-Rezept-Token enthalten ist, um den Abruf des neuen Rezeptes am E-Rezept-Fachdienst automatisieren zu können.
• einen bis mehrere Vorschläge für Rezeptänderungen erfassen können, um präzise die aus Apothekensicht validen Alternativen zu kommunizieren.
• die Entscheidung der Arztpraxis und potentiell gewählten Alternativvorschlag in der Rückantwort der Arztpraxis eindeutig erkennen können, um Folgeanfragen zu vermeiden.
• bei Neuausstellung eines E-Rezeptes mit der Arztpraxis die Löschung des alten E-Rezeptes abstimmen können, um Mehrfachbelieferungen zu vermeiden.

Dieses Kapitel bitte nach dem Ausleiten aus Polarion löschen.

3 Fachliches Konzept

Im fachlichen Konzept werden Nachrichten erarbeitet, welche im Kontext des E-Rezepts dezentral zwischen den Beteiligten versendet und empfangen werden. Die Nachrichten werden dabei stark 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.2 Use Cases für Rezeptanforderungen

Im Prozess der Rezeptanforderung wird in einer initialen Nachricht Rezeptanforderung sowie allen nachfolgenden Nachrichten genau ein E-Rezept adressiert. Die Nachrichten können über die in der Nachricht enthaltene Vorgangs_ID durch die verarbeitenden System in Verbindung gebracht werden.

3.2.1 UC1: Rezeptanforderung durch Pflegeeinrichtung

Die Rezeptanforderung wird durch die Pflegeeinrichtung initiiert. Die Pflegeeinrichtung sendet die Rezeptanforderung an den Verordnenden. Der Verordnende erstellt ein E-Rezept (Workflow mit Steuerung durch Leistungserbinger (169 bzw. 209)) und sendet die Informationen zum E-Rezept zurück an die Pflegeeinrichtung. Wenn die Pflegeeinrichtung die Rezeptinformation erhält, leitet sie diese sie an die heimversorgende Apotheke weiter.

Der Verordnende kann die Rezeptanforderung ablehnen.

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 1: Sequenzdiagramm Rezeptanforderung durch Pflegeeinrichtung

Folgende fachlichen Informationseinheiten können an diesem Ablauf beteiligt sein und enthalten dabei Detailinformationen:

Abbildung 2: beteiligte fachliche Informationseinheiten in diesem Ablauf

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/200) und sendet die Informationen zur Verordnung, jedoch ohne den E-Rezept-Token, zurück an die Pflegeeinrichtung.

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

Der Verordnende kann die Rezeptanforderung ablehnen.

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 3: Sequenzdiagramm Rezeptanforderung durch Pflegeeinrichtung (Selbstabholer)

Folgende fachlichen Informationseinheiten können an diesem Ablauf beteiligt sein und enthalten dabei Detailinformationen:

Abbildung 4: beteiligte fachliche Informationseinheiten in diesem Ablauf

Offener Punkt: Ist die Übermittlung der Dispensierinformation an die Pflegeeinrichtung möglich/notwendig?

3.2.3 UC3: Rezeptanforderung der heimversorgenden Apotheke

Die Rezeptanforderung wird durch die Apotheke initiiert. Das ist möglich, sofern ein Rahmenvertrag zwischen Apotheke und Pflegedienst nach § 12a ApoG vorliegt. Dieses bildet die rechtliche Voraussetzung und ist somit Vorbedingung für diesen Use Case.

Die Apotheke sendet die Rezeptanforderung mit allen relevanten Informationen an die Pflegeeinrichtung. Die Pflegeeinrichtung leitet die Rezeptanforderung an den Verordnenden weiter. Das Weiterleiten kann automatisiert erfolgen.

Der Verordnende erstellt ein E-Rezept (Workflow mit Steuerung durch Leistungserbinger (169 bzw. 209)) und sendet die Informationen zum Rezept zurück an die Pflegeeinrichtung. Diese leitet die Informationen zum E-Rezept an die Apotheke weiter. Das Weiterleiten kann automatisch erfolgen.

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

Der Verordnende kann die Rezeptanforderung ablehnen.

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 Apotheke

Folgende fachlichen Informationseinheiten können an diesem Ablauf beteiligt sein und enthalten dabei Detailinformationen:

Abbildung 6: beteiligte fachliche Informationseinheiten in diesem Ablauf

3.2.4 UC4: Rezeptanforderung für anwendungsfertige Zytostatikazubereitungen

Die KIM-Kommunikation zur Rezeptanforderung für parenterale 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 parenteralen 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 durch die Apotheke nach dem Start der Zubereitung initiiert. Fall_ID und Patienten_ID können vom Zytostatika-Programm oder der Taxierungssoftware gesetzt werden und dienen der Zuordnung der Rezeptanforderung im anfordernden System. Diese ID's bleiben in der Antwort des Verordnenden erhalten.

Das Apothekensystem sendet die Rezeptanforderung an das Primärsystem der verordnenden LEI. Das Primärsystem erstellt aus der Rezeptanforderung eine Verordnung und legt diese dem Verordnenden zur Bestätigung vor. 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 das E-Rezept noch nicht ausgestellt hat. Sie erhält eine Stornierungsquittung für eine durch das Verordnungssystem bestätigte Stornierung (Gutfall: Stornierung war möglich) oder für eine abgelehnte Stornierung (Ablehnungsfall: Stornierung war nicht möglich). 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.

Abbildung 7: Sequenzdiagramm Rezeptanforderung durch Apotheke

Folgende fachlichen Informationseinheiten können an diesem Ablauf beteiligt sein und enthalten dabei Detailinformationen:

Abbildung 8: beteiligte fachliche Informationseinheiten in diesem Ablauf

Hier erfolgt eine logische Detaillierung der zuvor beschriebenen fachlichen Informationseinheiten:

Abbildung 9: logische Struktur der Informationseinheiten

Für die fachlichen Informationseinheiten Rezeptanforderung_Ablehnung, Rezeptanforderung_Storno und Verordnung_Dispensierung ist eine weitere Unterstruktur hier nicht erforderlich.

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,
• die referenzierten Profile bzw. Profilversionen zum Zeitpunkt der Erstellung der Ressource gültig sind und nicht durch neuere Profile bzw. Profilversionen abgelöst wurden.

Abbildung 10: Ü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/FHIR-Ressourcen und die Beschreibung von Use Cases, die eine mögliche, dezentrale Umsetzung der Kommunikation zwischen den Beteiligten mittels KIM aufzeigt.

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.

Hinweis: Die Erweiterung des gematik Referenzvalidators um das Package https://simplifier.net/erezept-servicerequest erfolgt nach Finalisierung des Package, d.h. wenn die Packages des Status active erhalten.

Es wird empfohlen, dass für das Erzeugen von FHIR-Ressourcen zur Implementierungszeit der Referenzvalidator eingesetzt wird, um damit die laufende Entwicklungsarbeit zu unterstützen. Hier ergibt sich keine Notwendigkeit einer Integration, der Validator kann als Standalone-Konsolenanwendung für laufende Tests von Implementierungen eingesetzt werden.

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.1.1 Rezeptanforderung FHIR-Projekt

Für diese Use Cases liegt eine FHIR Shorthand-basierte Profilierung in Form eines Simplifier-Projekts auf der Simplifier-Website: https://simplifier.net/erezept-servicerequest/  vor.

Neben der Profilierung befindet sich in diesem Projekt ein Implementation Guide für Rezeptanforderungen: https://simplifier.net/guide/erp-servicerequest-implementation-guide?version=current . Dieser enthält ein Mapping des Informationsmodells mit fachlicher Informationseinheiten auf FHIR-Objekte in tabellarischer Übersichtsform.

5.2 Vorgaben zu KIM-Nachrichten

Für die Übermittlung der Rezeptanforderung wird das App Transport Framework (ATF) genutzt. Das ATF kapselt die Rezeptanforderung und ermöglicht eine Rückmeldung des Empfängers an den Sender einer Nachricht, ob die Nachricht verarbeitbar ist. Bei negativer Prüfung kann eine strukturierte Fehlermeldung an den Sender übermittelt werden.

Für den Implementation Guide des ATF siehe https://simplifier.net/guide/atf-implementation-guide/Home?version=current .

Für das Datenmodell des ATF siehe https://simplifier.net/app-transport-framework/ .

Der Sender einer KIM-Nachricht in der Kommunikation zu einer Rezeptanforderung MUSS das App Transport Framework benutzen.

Der Sender einer KIM-Nachricht in der Kommunikation zu einer Rezeptanforderung MUSS eine KIM-Dienstkennung gemäß TAB_KIMDienstkennung_Rezeptanforderung verwenden.

Tabelle 3: TAB_KIMDienstkennung_Rezeptanforderung KIM-Dienstkennung für Rezeptanforderung

Siehe auch https://fachportal.gematik.de/toolkit/dienstkennung-kim-kom-le 

Der Empfänger einer KIM-Nachricht, welche das App Transport Framework nutzt, MUSS für die Empfangsbestätigung an den Sender die KIM-Dienstkennung "atf;Empfangsbestaetigung" verwenden.

5.3.3 Workflow-Typen von E-Rezepten

In der Kommunikation zu einer Rezeptanforderung wird mitgeteilt, wem die Informationen zum erstellten E-Rezept übermittelt wird. Dies kann die anfordernde Pflegeeinrichtung oder der Versicherte sein. Wenn der Versicherte das E-Rezept erhalten soll, um selbst eine Apotheke für das Einlösen des E-Rezeptes auszuwählen, dann muss ein E-Rezept des Workflow 160 bzw. 200 erstellt werden. Sollen die Informationen zum E-Rezept-Token gemäß der Rezeptanforderung an eine Pflegeeinrichtung übermittelt werden, dann muss ein E-Rezept des Workflows mit Steuerung durch Leistungserbringer (169 bzw. 209) erstellt werden.

Das PS der verordnenden LEI MUSS falls für die Rezeptanforderung ServiceRequest.orderDetail.code ungleich #issue-prescription gilt, ein E-Rezept für einen Workflow mit Steuerung durch den Leistungserbinger erstellen.

6 Best practice UX Primärsysteme

Die Kommunikation zur Rezeptanforderung mit strukturierten Daten soll eine automatisierte Verarbeitung der KIM-Nachrichten zu ermöglichen.

Folgende Aspekte sollen hierbei beachtet werden:

Rezept-anforderndes Primärsystem (Pflegeeinrichtung/Apotheke)

• Der Nutzer soll eine Rezeptanforderung aus der Medikationsdokumentation heraus auslösen können.
• Der Nutzer soll in einer Liste gesammelte Rezeptanforderungen für verschiedene Patienten 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, Medikament, ...)
• 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 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, Medikament 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ängende Darstellung, sodass de Nutzer diesen nachvollziehen kann.
• Der Nutzer soll Informationen zur Verordnung und dem abgegebenen Medikament 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 eingehenden Antworten des Verordnenden benachrichtigen.
• Das System der Pflegeeinrichtung soll dem Nutzer ermöglichen, Regeln für die Weiterleitung von Rezeptanforderungen zu definieren, nach denen die Anforderungen an den betreuenden Arzt automatisch weitergeleitet werden.
• 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 alle Informationen zum angeforderten Rezept aus der Anfrage übernehmen und das E-Rezept soweit wie möglich vorbereiten, sodass der Nutzer nur noch prüfen und signieren muss.
• Das System soll Inhalte von neuen Rezeptanforderung mit zuvor verschriebenen Rezepten vergleichen und die Unterschiede dem Nutzer anzeigen, sodass Abweichungen leicht auffallen.
• Das System soll die Antwortnachrichten sofort und ohne weiteren Klick nach der Signatur des E-Rezepts an den richtigen Empfänger versenden. Der Empfänger soll automatisch aus der Rezeptanforderung übernommen werden. 
• Das System soll den Nutzer über eingehenden 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 Rezepte automatisch löschen, wenn Rezeptanfragen storniert werden und das Rezept bereits 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.

Ein Beispiel für die Darstellung einer Rezeptanforderung in der Aufgabenliste:

Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp]

Primärsystem abgebende Leistungserbringerinstitution (Apothekenverwaltungssystem)

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

Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp]

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.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis