latest

PDF HTML Excel XML
latest






Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation

Datenmodell E-Rezept 




    

     

      Version
      1.11.0
     

     

      Revision
      1195464
     

     

      Stand
      14.04.2025
     

     

      Status
      freigegeben
     

     

      Klassifizierung
      öffentlich
     

     

      Referenzierung
      gemSpec_DM_eRp

Dokumentinformationen

Ä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
1.0.0 30.06.2020 Erstversion des Dokumentes gematik
1.0.1 06.07.2020 Aktualisierung Hinweis zu Dispensierinformation gematik
1.1.0 12.11.2020 Einarbeitung gemäß Änderungsliste P22.2 / Scope-Themen Systemdesign R4.0.1 gematik
1.2.0 19.02.2021 Einarbeitung gemäß Änderungsliste P22.5 gematik
1.3.0 07.10.2021 Einarbeitung gemäß Änderungslisten
E-Rezept_Maintenance_21.1 und  _21.2		 gematik
1.3.1 18.11.2021 redaktionelle Anpassung des Beispiels für Afo 19553-x
"... Sammlung von vier drei E-Rezept-Token ..."		 gematik
1.4.0 09.08.2022 Einarbeitung gemäß Änderungsliste E-Rezept_Maintenance_21.3, _21.4 und _22.2
Einarbeitung gemF_eRp_WF_LE, gemF_eRp_PKV und gemF_eRp_MVO		 gematik
1.4.1 26.10.2022 redaktionelle Anpassung: technische Korrektur der Beispiel-URLs unterhalb der Anforderung "A_22920 - Kodierung fullURL"
Diese Anpassung hat keine normativen Auswirkungen.		 gematik
1.5.0 07.12.2022 Einarbeitung gemäß Änderungsliste E-Rezept_Maintenance_22.3 gematik
1.6.0 02.05.2023 Einarbeitung gemäß Änderungsliste E-Rezept_Maintenance_22.5, E-Rezept_Maintenance_22.6 und gemF_eRp_altern_Zuweisung gematik
1.7.0 14.08.2023 Einarbeitung gemäß Änderungsliste E-Rezept-Maintenance_23.2 gematik
1.8.0 11.12.2023 Einarbeitung gemäß Änderungsliste E-Rezept_Maintenance 23.3 gematik
1.9.0 20.03.2024 Überarbeitung für die Umsetzung der E-Rezept-Funktionalität durch Kassen-Apps (Einarbeitung nach Kommentierung) gematik
1.10.0 13.09.2024 Anpassungen für Release E-Rezept_1_6_5, 
Einarbeitung gemäß Änderungsliste E-Rezept_Maintenance 24.1, gemF_eRp_ePA,  29.08.: gemF_eRp_DiGA		 gematik
1.11.0 14.04.2025 Einarbeitung gemäß Änderungsliste E-Rezept_24.2
Einarbeitung gemäß gemF_eRp_EU		 gematik

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zum Datenmodell der Anwendung E-Rezept für die erste Ausbaustufe (Muster 16 für apothekenpflichtige Arzneimittel und Sprechstundenbedarfe). Für eine Folgestufe sind insbesondere für die Parametrierung der Workflows des E-Rezept-Fachdienstes weitere Parameter vorgesehen. Diese werden in der ersten Stufe nicht benötigt und zu gegebener Zeit festgelegt.

1.2 Zielgruppe

Dieses Dokument richtet sich an Implementierer und Nutzer von Schnittstellen der Fachanwendung E-Rezept. Dies sind insbesondere der Hersteller des Produkttyps E-Rezept-Fachdienst, die Hersteller von Primärsystemen und der Hersteller des E-Rezept-Frontend des Versicherten.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z.B. gemPTV_ATV_Festlegungen, Produkttypsteckbrief, Leistungsbeschreibung) fest­gelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert wird in dem Dokument das Datenmodell von Produkttypen der Fachanwendung E-Rezept bereitgestellten (angebotenen) und genutzten Schnittstellen.

Die fachlichen Inhalte des Informationsmodells für die Fachanwendung E-Rezept, d.h. die Daten, die durch den Verordnenden bereitgestellt werden, werden durch die Bundesmantelvertragspartner festgelegt.

Die Vorgaben zur Abrechnung werden über den Rahmenvertrag § 129 Abs. 2 SGB V sowie über die Vereinbarung nach § 300 Abs. 3 SGB V festgelegt.

Diese fachlichen Inhalte sind nicht Teil des Scopes dieser Spezifikation.

1.5 Methodik

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

Sie werden im Dokument wie folgt dargestellt:
 <AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

2 Daten- und Informationsmodelle

2.1 FHIR-Ressourcen

Für die Spezifikation der Schnittstellen in dieser Anwendung wird der Standard FHIR (Fast Healthcare Interoperability Resources) verwendet. In FHIR werden Datenstrukturen und Elemente in "Ressourcen" beschrieben, welche über standardisierte Schnittstellen zwischen verschiedenen Komponenten übertragen werden können. Die Daten werden dabei in XML oder in JSON repräsentiert.

Die Standardisierungsgruppe HL7/FHIR definiert dafür unter https://www.hl7.org/fhir/index.html ein Framework für den interoperablen Austausch medizinischer Daten über RESTful Services. Dem 80:20-Ansatz folgend definiert der FHIR-Standard die groben Bedarfe der meisten fachlichen UseCases (80%) und überlässt es der jeweiligen Anwendung, ihre spezifischen Bedarfe eigenständig zu profilieren (20 %). 

Die gematik nutzt die Spezifikation der RESTful API gemäß https://www.hl7.org/fhir/http.html und der ausgetauschten bzw. verwalteten Daten mittels FHIR-Ressourcen. Die spezifischen Bedarfe des E-Rezepts profiliert die gematik in einem Namespace https://gematik.de/fhir/erp . Das Portal simplifier.net wird für die Veröffentlichung der Profile verwendet, die über das Projekt "E-Rezept-Workflow" https://simplifier.net/erezept-workflow zur Einsicht und Validierung genutzt werden können. Außerdem werden die von der KBV definierten fachlichen Informationsobjekte des simplifier.net-Projekts "eRezept" https://simplifier.net/eRezept referenziert und genutzt.

A_22483-01 - Version FHIR-Package de.gematik.erezept-workflow

Die Produkttypen der Anwendung E-Rezept und Clientsystem des E-Rezept-Fachdienstes MÜSSEN das FHIR-Package de.gematik.erezept-workflow in der Version gemäß [FHIR Version] unterstützen. [<=]

A_22963 - Version FHIR-Package de.gematik.erezept-patientenrechnung

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN das FHIR-Package de.gematik.erezept-patientenrechnung in der Version gemäß [FHIR Version] unterstützen. [<=]

A_27189 - Version FHIR-Package de.gematik.erezept.eu

Die Produkttypen der Anwendung E-Rezept und Clientsysteme des E-Rezept-Fachdienstes MÜSSEN das FHIR-Package de.gematik.erezept.eu in der Version gemäß [FHIR Version] unterstützen. [<=]

A_25294 - Version FHIR-Package de.gematik.fhir.directory

Das E-Rezept-FdV MUSS das FHIR-Package de.gematik.fhir.directory in der Version gemäß [gemSpec_VZD_FHIR_Directory] unterstützen. [<=]

Die in in den Projekten erstellten Profile setzen auf den FHIR-Standard in der Version 4.0.1.

A_19295-01 - FHIR-Ressource Task

Die Produkttypen der Anwendung E-Rezept, das PS der verordnenden LEI und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource Task gemäß der Profilierung https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Task unterstützen. [<=]

A_19297-01 - FHIR-Ressource MedicationDispense

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource MedicationDispense gemäß der Profilierung https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_MedicationDispense unterstützen. [<=]

A_19298-01 - FHIR-Ressource AuditEvent

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource AuditEvent gemäß der FHIR-Profilierung https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_AuditEvent unterstützen. [<=]

A_19299-02 - FHIR-Ressource Communication

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource Communication gemäß der FHIR-Profilierungen 

unterstützen. [<=]

A_23028 - FHIR-Ressource Quittung

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource Quittung gemäß der FHIR-Profilierung https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Composition unterstützen. [<=]

A_19300-01 - FHIR-Ressource Bundle Quittung

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource Bundle gemäß der FHIR-Profilierung https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Bundle unterstützen. [<=]

A_23027 - FHIR-Ressource CloseOperationInputBundle

Die Produkttypen der Anwendung E-Rezept und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource CloseOprerationInputBundle https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_CloseOperationInputBundle gemäß der Profilierung  unterstützen. [<=]

A_20213-01 - FHIR-Ressource Bundle Verordnungsdatensatz

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource Bundle gemäß der FHIR-Profilierung https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundle unterstützen. [<=]

A_26060 - FHIR-Ressource Bundle DiGA-Verordnungsdatensatz

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource Bundle gemäß der FHIR-Profilierung https://fhir.kbv.de/StructureDefinition/KBV_PR_EVDGA_Bundle unterstützen. [<=]

A_22204 - FHIR-Ressource PKV-Abgabedatensatz

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource PKV-Abgabedatensatz gemäß der FHIR-Profilierung http://fhir.abda.de/eRezeptAbgabedaten/StructureDefinition/DAV-PKV-PR-ERP-AbgabedatenBundle  unterstützen.  [<=]

A_22205-01 - FHIR-Ressource ChargeItem

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource ChargeItem gemäß der FHIR-Profilierung https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_ChargeItem unterstützen. [<=]

A_22206-01 - FHIR-Ressource Consent

Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource Consent gemäß der FHIR-Profilierung https://gematik.de/fhir/erpchrg/StructureDefinition/GEM_ERPCHRG_PR_Consent unterstützen. [<=]

A_20745-01 - FHIR-Ressource Device

Die Produkttypen der Anwendung E-Rezept, das PS der verordnenden LEI und das PS der abgebenden LEI MÜSSEN die FHIR-Ressource Device gemäß der FHIR-Profilierung https://gematik.de/fhir/erp/StructureDefinition/GEM_ERP_PR_Device unterstützen.
[<=]

A_22216-01 - FHIR-Ressourcen Versionsangabe

Die Produkttypen der Anwendung E-Rezept und Clientsystem des E-Rezept-Fachdienstes MÜSSEN alle generierten FHIR-Ressourcen mit der Versionsnummer gemäß [datatypes.html#canonical] im Feld Ressource.meta.profile kennzeichnen, zu dessen aktuell gültiger Profilversion sie mutmaßlich validieren. [<=]

A_26237 - FHIR-Ressourcen - Ressource-ID in fullUrl

Die Produkttypen der Anwendung E-Rezept und Clientsysteme des E-Rezept-Fachdienstes MÜSSEN bei der Erstellung einer FHIR-Ressource die ID der fullURL (Bundle.entry.fullurl) der Ressource auf die ID der Ressource (Bundle.entry.resource.id) setzen. [<=]

A_26238 - FHIR-Ressourcen - Format fullUrl

Die Produkttypen der Anwendung E-Rezept und Clientsysteme des E-Rezept-Fachdienstes MÜSSEN bei der Erstellung einer FHIR-Ressource die von FHIR vorgegebene Regex zur Bildung von fullUrls (Bundle.entry.fullUrl) einhalten. [<=]

Der von FHIR vorgegebene Regex ist hier zu finden: https://hl7.org/fhir/R4/references.html#regex .

Lediglich in Canonicals für die Angabe des FHIR-Profils ist das Sonderzeichen "|" für die zusätzliche Angabe der Versionsnummer zulässig.

2.1.1 Zeitliche Gültigkeit von FHIR-Ressourcen

A_23384-03 - E-Rezept-Fachdienst - Prüfung Gültigkeit FHIR Ressourcen

Der E-Rezept-Fachdienst MUSS bei der Prüfung der zeitlichen Gültigkeit einer FHIR Ressource den Wert aus dem Element gemäß folgender Tabelle zugrunde legen.

Bezeichnung Package
 FHIR Profil(e)
 Operation/ Endpunkt Element/Zeitpunkt
KBV Verordnungs-datensatz kbv.ita.erp KBV_PR_ERP_Prescription $activate MedicationRequest.authoredOn
KBV Verordnungs-datensatz DiGA kbv.itv.evdga KBV_PR_EVDGA_HealthAppRequest $activate DeviceRequest.authoredOn
Communication de.gematik.erezept-workflow.r4 GEM_ERP_PR_Communication_DispReq
GEM_ERP_PR_Communication_InfoReq
GEM_ERP_PR_Communication_Reply
GEM_ERP_PR_Communication_Representative		 POST /Communication Zeitpunkt des Aufrufs der Operation am E-Rezept-Fachdienst
Abgabe-informationen de.gematik.erezept-workflow.r4 GEM_ERP_PR_PAR_CloseOperation_InputGEM_ERP_PR_PAR_DispenseOperation_Input
 $dispense,
$close		 Das im Parameters enthaltene jüngste MedicationDispense.whenHandedOver
PKV Patienten-rechnung
 de.gematik.erezept-patientenrechnung.r4 GEM_ERPCHRG_PR_ChargeItem
GEM_ERPCHRG_PR_Consent		 POST /ChargeItem
PUT /ChargeItem
POST /Consent		 Zeitpunkt des Aufrufs der Operation am E-Rezept-Fachdienst
PKV Abgabedaten-satz
 de.abda.eRezeptAbgabedatenPKV DAV_PKV_PR_ERP_Abgabeinformationen POST /ChargeItem
PUT /ChargeItem		 MedicationDispense.whenHandedOver
[<=]

Die zeitliche Gültigkeit der Versionen des Packages "kbv.ita.erp" ist in [KBV_ITA_VGEX_Technische_Anlage_ERP] beschrieben.
Die zeitliche Gültigkeit der Versionen der Packages "de.gematik.erezept-workflow.r4" wird in [TA7_Anhang2] beschrieben.
Die zeitliche Gültigkeit der Versionen der Packages "de.abda.eRezeptAbgabedatenPKV" wird in [TA_DAV_PKV] beschrieben.

A_23333 - E-Rezept - Übergangszeit Packages "kbv.ita.erp 1.0.2"

Der E-Rezept-Fachdienst MUSS beim Aufruf der Operation zum Einstellen eines E-Rezeptes durch den Verordnenden für eine Übergangszeit von 6 Monaten nach Gültigkeitsbeginn des Packages "kbv.ita.erp 1.1.0" die vorherige Version des Packages "kbv.ita.erp 1.0.2" weiterhin unterstützen, um den verordnenden Leistungserbringerinstitutionen die Möglichkeit zu geben, das bereitgestellte Update auszurollen. [<=]

2.2 E-Rezept-ID

Die E-Rezept-ID wird durch den E-Rezept-Fachdienst beim Anlegen eines Tasks für den Workflow des E-Rezepts erstellt.

A_19217-01 - Aufbau E-Rezept-ID

Der E-Rezept-Fachdienst MUSS E-Rezept-IDs erzeugen und verwalten, welche der Syntax "aaa.bbb.bbb.bbb.bbb.cc" und der folgenden Semantik genügen

Bedeutung Datentyp
aaa E-Rezept-Typ alphanummerisch, mit der Belegung gemäß "flowType" in https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_FlowType
bbb.bbb.bbb.bbb fortlaufende Rezeptnummer nummerisch, 12-stellig
cc Prüfnummer
Verfahren gemäß [ISO 7064]		 nummerisch
damit Tippfehler in der manuellen Erfassung erkannt werden können und die E-Rezept-ID über 11 Jahre eine eineindeutige Zuordnung zwischen allen Datenobjekten im E-Rezept-Workflow erlaubt. [<=]

A_19218 - Prüfung E-Rezept-ID

Alle Produkttypen, die eine E-Rezept-ID aus externen Systemen einlesen oder von Benutzern entgegen nehmen, MÜSSEN die E-Rezept-ID gegen ihre Prüfziffer nach dem Modulo-97-Verfahren gemäß [ISO 7064] prüfen und bei Ungültigkeit die Weiterverarbeitung verhindern, damit Benutzerfehleingaben vor der Verarbeitung erkannt werden. [<=]

2.2.1 Beispielrechnung

Im Folgenden wird das Modulo-97-Verfahren an zwei Beispielen verdeutlicht.

2.2.1.1 Prüfzifferberechnung für "160.000.000.000.123.xx"
  1. step 1 in [ISO 7064]: mit 100 multiplizieren -> 16000000000012300
  2. step 2 in [ISO 7064]: Modulo bilden -> 16000000000012300 mod 97 = 22
  3. step 3 in [ISO 7064]: 98 - 22 = 76
  4. "160.000.000.000.123.76"
2.2.1.2 Prüfung von "160.000.000.000.123.76"
  1. Modulo 97 bilden -> 16000000000012376 mod 97 = 1
  2. Ist das Ergebnis = 1, ist die Prüfziffer korrekt, falls das Ergebnis ungleich eins ist, ist die Zahl ungültig
2.2.1.3 Prüfzifferberechnung für "160.123.456.789.123.xx"
  1. step 1 in [ISO 7064]: mit 100 multiplizieren -> 16012345678912300
  2. step 2 in [ISO 7064]: Modulo bilden -> 16012345678912300 mod 97 = 40
  3. step 3 in [ISO 7064]: 98 - 40= 58
  4. "160.123.456.789.123.58"
2.2.1.4 Prüfung von "160.123.456.789.123.58"
  1. Modulo 97 bilden -> 16012345678912358 mod 97 = 1
  2. Ist das Ergebnis = 1, ist die Prüfziffer korrekt, falls das Ergebnis ungleich eins ist, ist die Zahl ungültig
2.2.1.5 Prüfung von "160.123.465.789.123.58" (Zahlendreher bei 56 -> 65)
  1. Modulo 97 bilden -> 16012346578912358 mod 97 = 51
  2. Die Rezept-ID ist ungültig, da das Ergebnis der Modulo-Operation ungleich 1 ist.

2.3 2D-Code

2.3.1 2D-Code für E-Rezept-Token

Um ein E-Rezept beliefern zu können, muss die Apotheke das Wissen um die Referenz des steuernden Tasks und den AccessCode zum Nachweis der Berechtigung erlangen. Diese beiden Datenfelder, URL des Tasks und AccessCode, werden vom Versicherten zur Verfügung gestellt. Die Bereitstellung kann als E-Rezept-Nachricht über den E-Rezept-Fachdienst oder als 2D-Code erfolgen. Die Bereitstellung als 2D-Code erfolgt entweder über das Abscannen des Codes von einem Papierausdruck oder vom Display des E-Rezept-FdV, welches den Code auf dem Display des Geräts des Versicherten anzeigt.

A_19554 - Datenstruktur Einlöseinformationen für E-Rezept

Das E-Rezept-FdV und das PS der verordnenden LEI MÜSSEN zum Erstellen eines E-Rezept-Token die ID auf einen Task zusammen mit dem AccessCode des Tasks aus den lokal verfügbaren Informationen eines E-Rezepts als URL in der Form:

  • 2D-Code-Daten = "Task/" + Task.id  + "/$accept?ac=" + AccessCode
zusammenstellen, damit diese Zeichenkette als Referenz in einer E-Rezept-Nachricht und in einem JSON-Array für die Generierung eines 2D-Codes verwendet werden kann. [<=]

Beispiel für E-Rezept-Einlöseinformationen (z.B. für Nutzung als Referenz in Communication-Ressource):
"Task/160.000.000.000.123.76/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea"

A_19553-01 - Generierung 2D-Code als Sammlung

Das E-Rezept-FdV MUSS eine Sammlung von einer und bis zu drei E-Rezept-Referenzen als Array in JSON-Notation gemäß [JSON] der folgenden Form

  • 2D-Code-Daten = { "urls": [ "E-Rezept 1", "E-Rezept 2", "E-Rezept 3" ] }
zusammenfassen, um daraus einen 2D-Code generieren zu können. [<=]

Beispiel für genau ein E-Rezept-Token (für die Codierung als 2D-Code):

{
  "urls": [ "Task/160.000.000.000.123.76/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea" ]

}

Beispiel für eine Sammlung von drei E-Rezept-Token (für die Codierung als 2D-Code):
{
  "urls": [
    "Task/160.000.000.000.123.76/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea",
    "Task/160.123.456.789.123.58/$accept?ac=0936cfa582b447144b71ac89eb7bb83a77c67c99d4054f91ee3703acf5d6a629",
    "Task/160.000.346.211.638.15/$accept?ac=d3e6092ae3af14b5225e2ddbe5a4f59b3939a907d6fdd5ce6a760ca71f45d8e5"
  ]

} 

Der Datentyp der Task.id erlaubt bis zu 64 Zeichen zur Angabe einer ID des Tasks. Mit der zulässigen Maximallänge ergibt sich folgendes Beispiel, aus dem die maximale Datengröße für einen 2D-Datamatrix-Code ergibt (Umbrücke und Leerzeichen werden im Sinne der Datenkomprimierung entfernt).

{"urls":["Task/1234567891011121314151617181920212223242526272829303132333435361/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea","Task/1234567891011121314151617181920212223242526272829303132333435362/$accept?ac=0936cfa582b447144b71ac89eb7bb83a77c67c99d4054f91ee3703acf5d6a629","Task/1234567891011121314151617181920212223242526272829303132333435363/$accept?ac=d3e6092ae3af14b5225e2ddbe5a4f59b3939a907d6fdd5ce6a760ca71f45d8e5"]} 

A_19543 - Generierung DataMatrix-Code

Das E-Rezept-FdV und das PS der verordnenden LEI MÜSSEN die Datenstruktur für 2D-Code-Daten in eine DataMatrix-Darstellung gemäß ISO/IEC 16022:2006 überführen können. [<=]

2.3.2 2D-Code für Abrechnungsinformation-Token

Um auf Wunsch des Versicherten den PKV-Abgabedatensatz ändern zu können, muss die Apotheke das Wissen um die Referenz des ChargeItem und den AccessCode zum Nachweis der Berechtigung erlangen. Diese Informationen werden vom Versicherten zur Verfügung gestellt. Die Bereitstellung kann als Nachricht über den E-Rezept-Fachdienst oder durch Abscannen als 2D-Code vom Display der E-Rezept-FdV erfolgen. 

A_22729 - Datenstruktur Zugriffsinformationen für Abrechnungsinformation

Das E-Rezept-FdV MUSS zum Erstellen eines Token für die Zugriffsinformationen für eine Abrechnungsinformation die ID auf einen ChargeItem zusammen mit dem AccessCode zum Ändern aus den lokal verfügbaren Informationen einer Abrechnungsinformation als URL in der Form: 2D-Code-Daten = "ChargeItem/" + ChargeItem.id  + "?ac=" + AccessCode zusammenstellen, damit diese Zeichenkette als Referenz in einer E-Rezept-Nachricht oder für die Generierung eines 2D-Codes verwendet werden kann. [<=]

Beispiel für Abrechnungsinformation-Token: 

"ChargeItem/200.100.000.000.004.30?ac=0037c20b8e893b690f07d784fcfcf38c748454c08253a8b2c0499347576ca612"

A_22730 - Generierung 2D-Code Abrechnungsinformation-Token

Das E-Rezept-FdV MUSS einen Abrechnungsinformation-Token in JSON-Notation gemäß [JSON] der folgenden Form

  • 2D-Code-Daten = { "urls": [ "Abrechnungsinformation" ] }
darstellen, um daraus einen 2D-Code generieren zu können. [<=]

Beispiel für die Codierung als 2D-Code:

{
  "urls": [ "ChargeItem/200.100.000.000.004.30?ac=0037c20b8e893b690f07d784fcfcf38c748454c08253a8b2c0499347576ca612" ]

}

2.4 Zugriffsberechtigung für Einlösen im europäischen Ausland

A_27097 - Format Zugriffscode

Produkttypen der Anwendung E-Rezept MÜSSEN, wenn sie einen Zugriffscode für das Einlösen im europäischen Ausland verarbeiten, folgende Formatvorgaben für den Zugriffscode einhalten:

  • String mit Gesamtlänge von 6 Zeichen,
  • erlaubte Zeichen: a-z, A-Z, 0-9.
[<=]

2.5 E-Rezept Typ

Der E-Rezept Typ wird in dem Parameter flowType festgehalten. Dieser gibt an, von welchem Typ das elektronische Rezept ist, und steuert den entsprechenden Workflow.

A_19324-01 - FHIR CodeSystem FLOWTYPE

Die Produkttypen der Anwendung E-Rezept, das PS der verordnenden LEI und das PS der abgebenden LEI MÜSSEN das FHIR CodeSystem FLOWTYPE gemäß https://gematik.de/fhir/erp/CodeSystem/GEM_ERP_CS_FlowType unterstützen.  [<=]

A_19445-10 - FHIR FLOWTYPE für Prozessparameter

Der E-Rezept-Fachdienst MUSS in Abhängigkeit des Task-Parameters FLOWTYPE und dem in der http-POST-Operation /Task/<id>/$activate übergebenen, gültig signierte E-Rezept-Bundle die Attribute des zu erzeugenden Tasks wie folgt belegen:  

FLOWTYPE Attributierung des zu erzeugenden Tasks
160 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.PrescriptionType.valueCoding.display = "Muster 16 (Apothekenpflichtige Arzneimittel)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
162
  • Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.59", coding.display="Kostenträger"}
  • Task.PrescriptionType.valueCoding.display = "Muster 16 (Digitale Gesundheitsanwendungen)
  • Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
  • Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
169 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.flowType.valueCoding.display = "Muster 16 (Direkte Zuweisung)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
200 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.flowType.valueCoding.display = "PKV (Apothekenpflichtige Arzneimittel)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
209 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"}
Task.flowType.valueCoding.display = "PKV (Direkte Zuweisung)"

wenn MedicationRequest.extension:Mehrfachverordnung.extension:Kennzeichen = false:
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
sonst
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.AcceptDate =  MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
damit dem Versicherten Informationen über die Gültigkeit (Erstattungsfrist durch die Kostenträger = AcceptDate, Einlösefrist = ExpiryDate) des E-Rezepts angezeigt werden und der Workflow auf Basis der gewählten Parameter gesteuert werden kann. [<=]

A_19517-02 - FHIR FLOWTYPE für Prozessparameter - Abweichende Festlegung für Entlassrezept

Der E-Rezept-Fachdienst MUSS nach der Feststellung der Prozessparameter gemäß A_19445 die folgenden Parameter mit abweichenden Werten belegen:

  • Task.AcceptDate = <Datum der QES.Erstellung Bundle.signature.when> + 2 Werktage (Montag bis Samstag, ausgenommen bundeseinheitliche Feiertage) (Abweichende Regelungen durch den Gemeinsamen Bundesausschuss (G-BA) sind zu beachten.)
wenn das in der http-POST-Operation /Task/<id>/$activate übergebene, gültig signierte E-Rezept-Bundle in der Extension  https://fhir.kbv.de/StructureDefinition/KBV_EX_FOR_Legal_basis in Bundle.Composition den code="04" oder "14" des Code-Systems https://fhir.kbv.de/CodeSystem/KBV_CS_SFHIR_KBV_STATUSKENNZEICHEN ("Entlassmanagement-Kennzeichen") enthält
und die übrigen Prozessparameter unverändert übernehmen, damit der Prozess für das E-Rezept mit den abweichenden Festlegungen für das Entlassrezept gemäß Arzneimittelrichtlinie [AM-RL] umgesetzt wird. [<=]

2.6 Zugriffsprotokoll

A_19296-04 - E-Rezept-Fachdienst - Inhalt Protokolleintrag

Der E-Rezept-Fachdienst MUSS einen Protokolleintrag mit den folgenden Werten befüllen:

  • AuditEvent.text: Generierung eines HTML-<div>-Elements mit lesbarer Beschreibung in einfacher Sprache,
  • AuditEvent.type: Fester Wert rest gemäß [CodeSystem: Audit Event ID],
  • AuditEvent.subtype: aus dem ValueSet [ValueSet http://hl7.org/fhir/ValueSet/audit-event-sub-type] gemäß [CodeSystem http://hl7.org/fhir/restful-interaction]:
    • create beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Ausnahme von AuditEvent- und Communication-Ressource),
    • read beim lesenden Zugriff auf ein Datenobjekt mit Versichertenbezug,
    • update, wenn das Datenobjekt mit Versichertenbezug geändert/aktualisiert wird,
    • delete, wenn das Datenobjekt mit Versichertenbezug manuell oder automatisch gelöscht wird,
  • AuditEvent.action: analog AuditEvent.subType (C, R, U, D) gemäß [ValueSet http://hl7.org/fhir/ValueSet/audit-event-action],
  • AuditEvent.recorded: aktuelle Systemzeit des E-Rezept-Fachdienstes,
  • AuditEvent.outcome: Ergebnis der aufgerufenen Operation gemäß [ValueSet http://hl7.org/fhir/ValueSet/audit-event-outcome] (0 = Erfolg, 4 = Fehler auf Clientseite, 8 = Serverfehler),
  • AuditEvent.agent.type: Fester Wert humanuser bzw. bei Übermittlung an ePA oder NCPeH-FD dataprocessor aus [CodeSystem: Security Role Type (Experimental)],
  • AuditEvent.agent.name: Lesbarer Name aus ID_TOKEN des Zugreifenden, der die zu protokollierende Aktion getriggert hat, z.B. "Praxis Dr. Müller, Bahnhofstr. 78" oder Versicherter z.B. "Max Mustermann" bzw. bei Übermittlung an ePA "E-Rezept-Fachdienst",
  • AuditEvent.agent.who: KVNR bzw. Telematik-ID des zugreifenden Nutzers aus ID_TOKEN, der diesen Protokolleintrag ausgelöst hat,
  • AuditEvent.agent.requestor: Fester Wert false, da keine Protokolleinträge von außen erzeugt werden,
  • AuditEvent.soure.site: Fester Wert E-Rezept-Fachdienst,
  • AuditEvent.soure.observer: Device-Informationen des E-Rezept-Fachdienstes (status, serialnumber=gemäß Release),
  • AuditEvent.entity.what: Referenz auf das durch den Abruf betroffene Datenobjekt Task, ChargeItem, MedicationDispense, Consent oder Objekt der Zugriffsberechtigung,
  • AuditEvent.entity.name: Eintrag der KVNR des betroffenen Versicherten aus dem Identifier des protokollierten Datenobjekts (String),
  • AuditEvent.entity.description: Rezept-ID als Identifier, wird übernommen aus MedicationDispense, ChargeItem oder Task bzw. Consent.category.coding.code bei Anlegen oder Löschen eines Consent bzw. countryCode bei Anlegen oder Löschen einer Zugriffsberechtigung.
[<=]

2.7 Nachrichten zwischen E-Rezept-FdV und abgebender LEI

2.7.1 E-Rezept einer Apotheke zuweisen

A_23876 - E-Rezept - Nachrichtenaustausch - E-Rezept einer Apotheke zuweisen - Datenstruktur Nachricht

Das E-Rezept-FdV, der E-Rezept-Fachdienst und das PS der abgebenden LEI MÜSSEN für den Anwendungsfall "E-Rezept einer Apotheke zuweisen" Nachrichten mit der Datenstruktur gemäß TAB_eRpDM_002 in der contentString-Eigenschaft des GEM_ERP_PR_Communication_DispReq-Profils unterstützen. 

Tabelle 1 : TAB_eRpDM_002 E-Rezept einer Apotheke zuweisen

Attribut verpflichtend Beschreibung zulässige Werte Beispiel
version ja Gibt die Version des JSON an. Aktuell immer 1. Kann im weiteren Lebenszyklus verändert werden. nummerisch, bis zu 6 Stellen 1
supplyOptionsType ja Wird gemäß des Servicerequests gesetzt, den der Nutzer wählt.
Die für den Nutzer zur Auswahl stehenden Services gibt die Apotheke vor, indem sie den servicespezifischen Zuweisungs-Endpunkt angibt, oder nicht.		 onPremise, shipment, delivery onPremise
name nein Name des Versicherten. 100 Stellen,
UTF-8		 Dr. Maximilian von Muster
address nein String-Array der Zeilen einer Adresse. Sie ist im JSON in der korrekten Reihenfolge anzugeben und auch auszulesen.

"onPremise": Adresse des Versicherten laut Rezept
"delivery"/"shipment": Adresse des Lieferungsempfänger

mindestens: Strasse+Hausnummer, PLZ+Ort werden gesetzt		 Array von Strings je 500 Stellen UTF-8 "address": [    "wohnhaft bei Emilia Fischer",    "Bundesallee 312",    "123. OG",    "12345 Berlin"  ]
hint nein Hinweis, den der Versicherte mit angeben kann. 500 Stellen,
UTF-8		 Bitte im Morsecode klingeln: -.-.
phone nein Telefonnummer  32 Stellen,
UTF-8		 004916094858168
[<=]

2.7.2 Nachricht durch Abgebenden übermitteln

A_23877 - E-Rezept - Nachrichtenaustausch - Nachricht durch Abgebenden übermitteln - Datenstruktur Nachricht

Das E-Rezept-FdV, der E-Rezept-Fachdienst und das PS der abgebenden LEI MÜSSEN für den Anwendungsfall "Nachricht durch Abgebenden übermitteln" Nachrichten mit der folgenden Datenstruktur in der contentString-Eigenschaft des GEM_ERP_PR_Communication_Reply unterstützen.

Tabelle 2 : TAB_eRpDM_003 Nachricht als Apotheke an einen Versicherten schicken

Attribut verpflichtend Beschreibung zulässige Werte Beispiel
version ja Gibt die Version des JSON an. Aktuell immer 1. Kann im weiteren Lebenszyklus verändert werden. nummerisch, bis zu 6 Stellen 1
supplyOptionsType ja Wird gemäß des Servicerequests gesetzt, den der Nutzer wählt.
Die für den Nutzer zur Auswahl stehenden Services gibt die Apotheke vor, indem sie den servicespezifischen Zuweisungs-Endpunkt angibt, oder nicht.		 onPremise, shipment, delivery onPremise
info_text nein Zusätzlicher Freitext des Versicherten an die Apotheke 500 Stellen,
UTF-8		 Wir möchten Sie informieren, dass Ihre bestellten Medikamente zur Abholung bereitstehen. Den Abholcode finden Sie anbei.
url nein Einbettung einer externen URL ausschließlich für das Einlösen von E-Rezepten in einer externen Bestellplattform 500 Stellen,
URL gemäß RFC3986, 
 https://www.meine-apotheke.de/pickup/59b52340-7a6a-430d-99ea-45a8e5cd03f6
pickUpCodeHR nein menschenlesbarer Abholcode
Nur bei supplyOptionsType "onPremise". Wenn gesetzt, wird dem Nutzer der Inhalt des "pickUpCodeHR" optisch hervorgehoben angezeigt.		 8 Stellen, UTF-8 12315615
pickUpCodeDMC nein maschinenlesbarer Abholcode (Data-Matrix-Code)
Nur bei supplyOptionsType "onPremise". Wenn gesetzt, kann sich der Nutzer den Inhalt als Data-Matrix-Code anzeigen lassen. Der Inhalt wird gemäß ISO/IEC 16022:2006 von der App in einen DMC gewandelt. Fehlt die Interpretation, so wird der Code als Freitext angezeigt.		 128 Stellen, UTF-8 5346a991-c5c6-49c8-b87b-4cdd255bbde4 
[<=]

2.7.3 Einlösen ohne Anmelden am E-Rezept-Fachdienst

Die Message beinhaltet folgende Informationen

  • Telematik-ID der adressierten Apotheke
  • Transaktions-ID
  • verschlüsselte Nachricht des Versicherten

Die Nachricht des Versicherten enthält folgende Informationen:

A_22784-01 - E-Rezept - Einlösen ohne Anmelden - Datenstruktur Nachricht

Das E-Rezept-FdV und das PS der abgebenden LEI MÜSSEN für den Anwendungsfall "Einlösen ohne Anmelden am E-Rezept-Fachdienst im E-Rezept-FdV" Nachrichten mit der folgenden Datenstruktur unterstützen.

Tabelle 3 : TAB_eRpDM_001 Einlösen ohne Anmelden - Datenstruktur Nachricht 

Attribut verpflichtend Beschreibung zulässige Werte Beispiel
version ja Gibt die Version des JSON an. Aktuell immer 2. Kann im weiteren Lebenszyklus verändert werden. nummerisch, bis zu 6 Stellen 2
supplyOptionsType ja Wird gemäß des Servicerequests gesetzt, den der Nutzer wählt.
Die für den Nutzer zur Auswahl stehenden Services gibt die Apotheke vor, indem sie den servicespezifischen Zuweisungs-Endpunkt angibt, oder nicht.		 onPremise, shipment, delivery shipment
name nein Das E-Rezept-FdV erlaubt dem Nutzer bei supplyOptionsType shipment oder delivery die Angabe eines alternativen Namen.
Ansonsten gilt der Name auf dem E-Rezept.		 Text und Ziffern
50 Stellen
UTF-8
 Max Müller
address nein Das E-Rezept-FdV erlaubt dem Nutzer bei supplyOptionsType shipment oder delivery die Angabe einer alternativen Belieferungsadresse.
Ansonsten gilt die Adresse auf dem E-Rezept.

Der Array enthält Straße, Hausnummer, PLZ, Ort
 Text und Ziffern
je Teil: 50 Stellen
UTF-8
 "Bundesallee", "312", "12345", "Berlin"
hint nein Optionale Angaben, die der Nutzer unterstützt durch das E-Rezept-FdV tätigen kann, die bei der Auslieferung hilfreich sind.
Nur bei supplyOptionsType shipment oder delivery
 Text 500 Stellen
UTF-8
 Bitte im Morsecode klingeln: -.-.
text nein Freitext, den der Nutzer App-unterstützt eingeben kann. Text 500 Stellen
UTF-8
 Bitte zusätzlich Wicky Hustensaft, 500ml
phone nein, siehe Beschreibung Telefonnummer des Versicherten
Das E-Rezept-FdV stellt sicher, dass bei supplyOptionsType shipment oder delivery mindestens eine Kontaktinformation (E-Mail oder Telefon) übermittelt wird		 25 Stellen
UTF-8
 004916094858168
mail nein, siehe Beschreibung E-Mail-Adresse des Versicherten
Das E-Rezept-FdV stellt sicher, dass bei supplyOptionsType shipment oder delivery mindestens eine Kontaktinformation (E-Mail oder Telefon) übermittelt wird		 RFC-5322-konforme E-Mail-Adresse max@musterfrau.de
transactionID ja Eindeutige ID zur Identifikation der Transaktion für Fehleranalyse und ggf. spätere Funktionserweiterung RFC 4122 ee63e415-9a99-4051-ab07-257632faf985
taskID ja TaskID 22 Stellen
UTF-8
 160.123.456.789.123.58
accessCode ja AccessCode 64 Stellen
UTF-8
 777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea
[<=]

3 Anhang A – Verzeichnisse

3.1 Abkürzungen

Kürzel
 Erläuterung
API application programming interface
DiGA Digitale Gesundhaitsanwendung
FdV Frontend des Versicherten
FHIR Fast Healthcare Interoperable Resources
HTML Hypertext Markup Language
JSON JavaScript Object Notation
KVNR 10-stelliger Anteil der Krankenversichertennummer ("Versicherten-ID")
LEI Leistungserbringerinstitution
PS Primärsystem
QES Qualifizierte Elektronische Signatur
URL Uniform Resource Locator
XML Extensible Markup Language

3.2 Glossar

Begriff
 Erläuterung
Funktionsmerkmal Der Begriff beschreibt eine Funktion oder auch einzelne, eine logische Einheit bildende Teilfunktionen der TI im Rahmen der funktionalen Zerlegung des Systems.

Das Glossar wird als eigenständiges Dokument (vgl. [gemGlossar]) zur Verfügung gestellt.

3.3 Abbildungsverzeichnis

    3.4 Tabellenverzeichnis

    3.5 Referenzierte Dokumente

    3.5.1 Dokumente der gematik

    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 
    [gemSpec_VZD_FHIR_Directory] gematik: Spezifikation Verzeichnisdienst FHIR-Directory
    [FHIR Version]  https://github.com/gematik/api-erp/blob/master/docs/erp_fhirversion.adoc#e-rezept-fhir-package-versionsmanagement  

    3.5.2 Weitere Dokumente

    [Quelle]
    		 Herausgeber (Erscheinungsdatum): Titel
    [AM-RL]   Arzneimittel-Richtlinie - Gemeinsamer Bundesausschuss
    https://www.g-ba.de/richtlinien/3/ 
    [ISO 7064] Berechnungsverfahren Prüfsumme (Check character systems) ISO 7064 im Modulo-97-Verfahren
    https://www.iso.org/obp/ui/#iso:std:iso-iec:7064:ed-1:v1:en 
    Kapitel 8.4 Simplified procedure
    [JSON] Grundlagen JSON-Notation
    https://www.json.org/json-de.html 
    [KBV_ITA_VGEX_Technische_Anlage_ERP] KBV: TECHNISCHE ANLAGE ZUR ELEKTRONISCHEN ARZNEIMITTELVERORDNUNG (E16A)
    [Simplifier] Profilierung der FHIR Ressourcen im Projekt E-Rezept
    https://simplifier.net/erezept 
    https://simplifier.net/erezept-workflow 
    https://simplifier.net/erezept-patientenrechnung 
    https://simplifier.net/erezeptabgabedatenpkv 
    https://simplifier.net/VZD-FHIR-Directory 
    [TA7_Anhang2] Anhang 2 – FHIR Versionen zur Technischen Anlage 7 zur Arzneimittelabrechnungsvereinbarung gemäß § 300 Absatz 3 SGB V
    [TA_DAV_PKV] Technische Anlage zur Arzneimittelabrechnungsvereinbarung zur Übermittlung und Abrechnung elektronischer Verordnungen zwischen PKV-Verband und DAV