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 |
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
| Version | Stand | Kap./ Seite | Grund der Änderung, besondere Hinweise | Bearbeitung |
|---|---|---|---|---|
| 0.5.0 | 24.11.2022 | Arbeitsstand zur Information | gematik | |
| 1.0.0 | 10.05.2023 | Erweiterung um Rezeptanforderung für paraterale Zubereitung Integration in das App Transport Framework |
gematik | |
| 1.1.0 | 26.06.2023 | Szenario "Apotheke übernimmt Rezeptmanagement für Dauermedikation" überarbeitet | gematik |
Das Dokument beschreibt Prozesse, welche das Verordnen und Abgeben von E-Rezepten unterstützen. Es werden verschiedene Anwendungsszenarien betrachtet:
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:
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.
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.
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.
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:
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.
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.
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).
Als Versicherter möchte ich:
Als Mitarbeiter einer Pflegeeinrichtung oder einer Apotheke möchte ich:
Als Mitarbeiter einer Pflegeeinrichtung möchte ich:
Als Mitarbeiter einer Apotheke möchte ich:
Als verordnender Arzt möchte ich:
Tabelle 1: Wichtige Begriffe aus dem Kontext des Epics Rezeptanforderung
| Begriff | Bedeutung | Abhängigkeiten |
|---|---|---|
| Selbstabholer | Das aufgrund einer Rezeptanforderung erstellte E-Rezept wird durch den Versicherten selbst eingelöst. Der Versicherte sucht dafür eine Apotheke seiner Wahl aus. | Rezeptanforderung |
| Rezeptanforderung | Anforderung einer Pflegeeinrichtung oder einer Apotheke an eine verordnende LEI mit der Bitte um Ausstellung eines neue Rezepts |
Auslösendes Ereignis oder eine Bedarfsfeststellung |
| Rezeptanforderung: Storno |
Stornierung eines zuvor angeforderten Rezeptes durch eine Pflegeeinrichtung oder eine Apotheke bei der verordnenden LEI, bevor das zugehörige Rezept übermittelt wurde. |
Rezeptanforderung |
| Rezeptanforderung: Rezeptübermittlung |
Übermittlung der Informationen zum erstellten Rezept an die anfordernde Pflegeeinrichtung oder die Apotheke |
Rezeptanforderung |
| Rezeptanforderung: Ablehnung |
Ablehnung einer Rezeptanforderung durch die verordnende Leistungserbringerorganisation |
Rezeptanforderung |
| Verordnungsdatensatz | Sammlung von Informationen zum Patienten, zum verordnenden Arzt, zum Präparat, zu dessen Dosierung und Packungsgröße, die zur Ausstellung eines Rezepts notwendig sind. |
Rezeptanforderung |
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.
Als Apotheker möchte ich:
Als verordnender Arzt möchte ich:
Als Versicherter möchte ich:
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
| Begriff |
Bedeutung | Abhängigkeiten |
|---|---|---|
| Klärfall | Repräsentation aller Informationen bezüglich eines zu klärenden Sachverhaltes inklusive aller zugehörigen Dokumente im jeweiligen PS. | |
| Klärfallanfrage | standardisierte, durch die abgebende LEI an die verordnende LEI adressierte KIM-Nachricht | |
| Klärfallantwort | standardisierte, durch die verordnende LEI an die abgebende LEI adressierte KIM-Nachricht als Antwort auf eine eingegangene Klärfallanfrage | Enthält |
| Rezeptänderungsvorschlag | Unsignierter, von der abgebenden LEI erstellter Verordnungsdatensatz. Dient der Verdeutlichung vorgeschlagener Rezeptänderungen | Als Anhang enthalten in (bei Bedarf):
|
| akzeptierter Rezeptänderungsvorschlag | Unsignierter Verordnungsdatensatz. Es handelt sich entweder um einen unveränderten, akzeptierten Rezeptänderungsvorschlag oder um einen von der verordnenden LEI editierten Rezeptänderungsvorschlag. | Als Anhang enthalten in (bei Bedarf):
|
| Originalverordnung / Ursprungsverordnung | Unsignierter Verordnungsdatensatz. Es handelt sich um die ursprüngliche, dem Klärfall zugrundeliegende Verordnung und dient als Referenz im Rahmen der Prüfung durch die verordnende LEI. | Als Anhang enthalten in:
|
| Korrekturverordnung | Signierte, auf dem E-Rezept-Fachdienst aktivierte Verordnung. Es handelt sich dabei um den Ersatz für die Originalverordnung, sollte sich im Rahmen der Prüfung durch die verordnende LEI herausstellen, dass von der abgebenden LEI nicht durchführbare Änderungen notwendig sind. | Als Anhang enthalten in (bei Bedarf);
|
| Klärfallübersicht | Standardisiertes strukturiertes Dokument (FHIR), das alle Klärfallinformationen enthält und alle zugehörigen Dokumente referenziert. Dieses Dokument kann als Anhang in Klärfallanfragen und -antworten genutzt werden und dient der Automatisierung der Verarbeitung in den PS. | Als Anhang enthalten in:
|
| Antwortoptionen | Angaben zu den durch die abgebende LEI präferierten Informationen in der Klärfallantwort |
Als Versicherter möchte ich:
Als Verordnender möchte ich:
Als Apotheker möchte ich:
Dieses Kapitel bitte nach dem Ausleiten aus Polarion löschen.
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.
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.
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
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?
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
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:
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.
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
Abbildung 10: Übersicht Nutzung KIM-Nachrichten für E-Rezept
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.
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.
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
| Code | Display |
|---|---|
| eRezept_Rezeptanforderung;Rezeptanfrage | Anfrage an einen Arzt ein Rezept auszustellen |
| eRezept_Rezeptanforderung;Rezeptanfrage_Storno | Abbruch der Rezeptanfrage |
| eRezept_Rezeptanforderung;Rezeptbestaetigung | Bestätigung und Übermittlung eines ausgestellten Rezeptes |
| eRezept_Rezeptanforderung;Abgabeanfrage | Anfrage zur Erfüllung eines Rezeptes und Abgabe des Medikaments |
| eRezept_Rezeptanforderung;Abgabeanfrage_Storno | Abbruch der Rezeptanfrage |
| eRezept_Rezeptanforderung;Abgabebestaetigung | Bestätigung der Erfüllung und Abgabe eines Medikamentes |
| eRezept_ParenteraleZubereitung;Rezeptanfrage | Rezeptanfrage für eine parenterale Zubereitung |
| eRezept_ParenteraleZubereitung;Rezeptanfrage_Storno | Abbruch der Rezeptanfrage für eine parenterale Zubereitung |
| eRezept_ParenteraleZubereitung;Rezeptbestaetigung | Bestätigung und Übermittlung eines ausgestellten Rezeptes für eine parenterale Zubereitung |
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.
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.
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)
Primärsystem verordnende Leistungserbringerinstitution:
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)
Siehe auch Hinweise zu UX Best Practice in [gemILF_PS_eRp]
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.
| Kürzel | Erläuterung |
|---|---|
| ApoG | Apothekengesetz |
| ATF | App Transport Framework |
| KIM | Kommunikation im Medizinwesen |
| LEI | Leistungserbringerinstitution |
| SMC-B | Security Module Card Typ B, (Institutionskarte, Praxiskarte) |
| TI | Telematikinfrastruktur |
| VZD | Verzeichnisdienst der TI |
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.
| [Quelle] | Herausgeber: Titel |
| [gemGlossar] |
gematik: Glossar der Telematikinfrastruktur |
| [gemILF_PS_eRp] | gematik: Spezifikation Implementierungsleitfaden Primärsysteme – E-Rezept |
| [Quelle] | Herausgeber (Erscheinungsdatum): Titel |
| VUD/ADKA-Positionspapier |