Elektronische Gesundheitskarte und Telematikinfrastruktur

Feature:

KIM-Nachrichten für das E-Rezept

Version
1.0.0
Revision
1509992
Stand
10.05.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 Dauermedikamentationen 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
• Zuweisung eines E-Rezeptes im Rahmen des Workflows mit Steuerung durch Leistungserbringern vom Verordnenden an eine Apotheke

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

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). 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. In diesem Prozess gibt es je nach individueller Absprache zwischen Arztpraxis, Pflegeeinrichtung, Apotheke und Patienten Abweichungen. Je nach individueller vertraglicher Reglung ist es ebenfalls möglich, dass die Rezepte direkt vom Arzt an eine benannte Apotheke übermittelt werden, oder der Patient das Rezept selbst bei der Arztpraxis abholt und einlösen geht.

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 fordert rechtzeitig neue Rezepte bei den Arztpraxen der behandelnden Ärzten an, wenn das Ende der Reichweite in Sicht kommt. Die Arztpraxis erstellt die angeforderten Rezepte aus und sendet diese an die Apotheke. Wenn das Rezept nach ärztlicher Prüfung nicht benötigt wird, weil beispielsweise die Therapie angepasst wurde, kann die Arztpraxis die Anfrage ablehnen. Falls gewünscht, kann die Pflegeeinrichtung in die Kommunikation zwischen Apotheke und Arztpraxis als "stiller Zuhörer" eingebunden werden und beispielsweise Inhalte von neuen Verordnungen automatisch zugesendet bekommen, sodass die Verordnung wie vom Arzt erstellt im System dokumentiert werden kann. Ebenso kann die Apotheke der Pflegeeinrichtung per automatisierter Nachricht die Informationen zum abgegebenen Medikament zukommen lassen, falls diese von dem verordneten Medikament abweichen.

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 User Stories der Pflegeeinrichtung und des abgebenden Leistungserbringers

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

• die Rezeptanforderung digital und ohne Medienbruch über einen sicheren Kommunikationskanal an die Arztpraxis übermitteln können.
• 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 beim Arzt angefragt habe (und wann), sodass ich nicht zweimal die gleiche Anforderung absende.
• dass die Rezeptanforderung an den richtigen Arzt, der bei dem Versicherten hinterlegt ist, gesendet wird, sodass es zu keinen Verwechslungen kommt.
• dass automatisch alle verfügbaren Informationen (zum Versicherten und dem benötigten Medikament) aus meinem System bei 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 oder Apotheke 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. 

2.1.2.1 Zusätzliche User Stories der Pflegeeinrichtung

Als Mitarbeiter einer Pflegeeinrichtung möchte ich:

• in meinem System hinterlegen können, ob bei Rezeptanforderungen die Rezepte an mich zurück oder direkt an die heimbeliefernde Apotheke gesendet werden sollen.
• 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 ist.
• bei Rezeptübermittlung mitgeschickte Anhänge in die Akte des Versicherten übertragen können, sodass diese immer vollständig ist.
• informiert werden, wenn der Arzt das angeforderte Rezept an die heimbeliefernde Apotheke gesendet hat und den Verordnungsinhalt, sowie die Information über das abgegebene Medikament für meine Dokumentation erhalten.

2.1.2.2 Zusätzliche User Stories der Apotheke

Als Mitarbeiter einer Apotheke möchte ich:

• dass die Pflegeeinrichtung, die ich betreue, immer den Inhalt der Verordnung automatisch zugeschickt bekommt, wenn der Arzt ein Folgerezept ausstellt.
• 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:

• alle notwendigen Informationen zu dem angeforderten Rezept (zum Medikament und Versicherten) in der Anfrage der Pflegeeinrichtung/Apotheke erhalten, 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. 
• zusätzliche Kontaktdaten der anfragenden Pflegeeinrichtung/Apotheke erhalten, um diese kurzfristig auch über andere Kommunikationskanäle innerhalb und außerhalb der Telematik 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 zusenden können.
• dass mein System das Rezept direkt dem richtigen Empfänger zusendet, 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 ablehnen können, wenn ich den Bedarf nicht nachvollziehen kann.
• dass mein System mich erinnert, wenn ich eine Anfrage länger als 3 Tage nicht bearbeitet habe, sodass die Anfrage im Arbeitsalltag nicht untergeht. 

Tabelle 1: Wichtige Begriffe aus dem Kontext des Epics Rezeptanforderung

2.2 Rezeptanforderungen für parenterale 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.

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.1 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.1.1 Rezeptanforderung durch Pflegeeinrichtung

3.1.1.1 Standardfall ohne Versichertenbeteiligung

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, je nach Wunsch der Pflegeeinrichtung, die Informationen zum E-Rezept zurück an die Pflegeeinrichtung bzw. an eine vorgegebene Apotheke. Falls die Pflegeeinrichtung die Rezeptinformation erhält, leitet 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.1.1.2 Spezialfall mit Versichertenbeteiligung

Die Rezeptanforderung wird durch die Pflegeeinrichtung initiiert. Die Pflegeeinrichtung sendet die Rezeptanforderung an den Verordnenden mit dem Hinweis, dass der Versicherte das Rezept selbst einlöst. Der Verordnende erstellt ein E-Rezept (Workflow 160/200). 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.1.2 Rezeptanforderung durch (Rahmenvertrags-)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 an den Verordnenden. Der Verordnende erstellt ein E-Rezept (Workflow mit Steuerung durch Leistungserbinger (169 bzw. 209)) und sendet die Informationen zum Rezept zurück an die Apotheke. Die Apotheke sendet nach der Belieferung des Rezeptes die Informationen zum E-Rezept 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.1.3 Rezeptanforderung für parenterale Zubereitungen

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

3.1.4 Fachliches Informationsmodell Rezeptanforderung und -übermittlung

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. 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 die 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 die Konsumierung 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 Rezeptanforderung

5.1.1 Informationsmodell

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.1.2 Aufbau der KIM-Nachricht

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 2 : 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.1.3 Erstellen von E-Rezepten

In der Kommunikation zu einer Rezeptanforderung wird mitgeteilt, wem die Informationen zum erstellten E-Rezept übermittelt wird. Dies kann eine Pflegeeinrichtung, eine Apotheke oder der Versicherte sein. Wenn der Versicherte das E-Rezept erhalten soll, um selbst eine Apotheke seiner Wahl für das Einlösen des E-Rezeptes zu wä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 Apotheke oder Pflegeeinrichtung übermittelt werden, dann muss ein E-Rezept des Workflows 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.

5.1.4 User Experience

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 System (Pflege/Apotheke)

• Übernahme von Daten aus der Patientenakte des Primärsystems in die Rezeptanforderung (Versicherter, behandelnder Arzt, Medikament, ...)
• Automatisches Ermitteln der KIM-Adresse der verordnenden Leistungserbringerinstitutionen aus dem VZD oder der Patientenakte des Primärsystems
• Darstellung einer Liste von Vorgängen mit Rezeptanforderungen mit Status
• Notification für Nutzer bei eingehenden Antwortnachrichten
• Zuordnung von Antwortnachrichten zur Rezeptanforderung und zusammenhängende Darstellung des Kommunikationsverlaufes

Primärsystem verordnende Leistungserbringerinstitution:

• Übernahme der Daten aus der KIM-Nachricht in das Primärsystem
• Verbinden der Daten mit der zugehörigen Patientenakte im Primärsystem
• Erstellen eines Verordnungsdatensatzes zur Rezeptanforderung, welche dem Verordnenden zum Prüfen vorgelegt werden
• Darstellung der Rezeptanforderungen in einer Aufgabenliste
• Darstellen von Abweichungen zwischen Rezeptanforderung und ggf. zuvor verschriebenen Rezepten, um das Prüfen zu unterstützen
• Notification der Nutzer bei eingehenden Rezeptanforderungen
• Erinnerungsfunktion für noch nicht abgeschlossene Rezeptanforderungen
• automatisiertes Erstellen der Antwortnachricht
• Ermitteln der Empfängersdresse für die Antwortnachricht aus der Rezeptanforderung

siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp]

Primärsystem abgebende Leistungserbringerinstitution (Apothekenverwaltungssystem)

• Übernahme der Daten aus der KIM-Nachricht in das Primärsystem
• Notification der Nutzer bei eingehenden zugewiesenen E-Rezepten

Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp]

6 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.

7 Anhang A – Verzeichnisse

7.1 Abkürzungen

7.2 Referenzierte Dokumente

7.2.1 Dokumente der gematik

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

7.2.2 Weitere Dokumente

7.3 Abbildungsverzeichnis

7.4 Tabellenverzeichnis