gemSpec_DM_eRp_V1.0.0







Elektronische Gesundheitskarte und Telematikinfrastruktur





Spezifikation

Datenmodell E-Rezept




    
Version 1.0.0
Revision 548770
Stand 30.06.2020
Status freigegeben
Klassifizierung öffentlich
Referenzierung gemSpec_DM_eRp

Dokumentinformationen

Hinweis:
Im Rahmen der Fortschreibung der Dokumente können sich noch Änderungen am Umgang mit den Dispensierinformationen ergeben.

Änderungen zur Vorversion

Es handelt sich um die Erstversion des Dokumentes.

Dokumentenhistorie

Version
Stand
Kap./ Seite
Grund der Änderung, besondere Hinweise
Bearbeitung
1.0.0 30.06.2020 freigegeben 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 apotkenpflichtige 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. Dokumentenlandkarte, 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 und  https://gematik.de/fhir/erx. 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_19295 - FHIR-Ressource Task

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

A_19297 - FHIR-Ressource MedicationDispense

Der E-Rezept-Fachdienst, das PS der abgebenden LEI und das E-Rezept-FdV MÜSSEN die FHIR-Ressource MedicationDispense gemäß der Profilierung  https://gematik.de/fhir/StructureDefinition/erxMedicationDispense unterstützen. [<=]

A_19298 - FHIR-Ressource AuditEvent

Der E-Rezept-Fachdienst und das E-Rezept-FdV MÜSSEN die FHIR-Ressource AuditEvent gemäß der FHIR-Profilierung  https://gematik.de/fhir/StructureDefinition/erxAuditEvent unterstützen. [<=]

A_19299 - FHIR-Ressource Communication

Der E-Rezept-Fachdienst, das PS der abgebenden LEI und das E-Rezept-FdV MÜSSEN die FHIR-Ressource Communication gemäß der FHIR-Profilierungen 

unterstützen. [<=]

A_19300 - FHIR-Ressource Bundle Quittung

Der E-Rezept-Fachdienst, das PS der abgebenden LEI und das E-Rezept-FdV MÜSSEN die FHIR-Ressource Bundle gemäß der FHIR-Profilierung  https://gematik.de/fhir/StructureDefinition/erxReceipt unterstützen. [<=]

A_20213 - FHIR-Ressource Bundle Versicherter

Der E-Rezept-Fachdienst und das E-Rezept-FdV MÜSSEN die FHIR-Ressource Bundle gemäß der FHIR-Profilierung https://fhir.kbv.de/StructureDefinition/KBV_PR_ERP_Bundle und https://gematik.de/fhir/StructureDefinition/erxComposition unterstützen. [<=]

A_19301 - FHIR-Ressource Organization

Der E-Rezept-Fachdienst, das PS der verordnenden LEI, das PS der abgebenden LEI und das E-Rezept-FdV MÜSSEN die FHIR-Ressource Organization gemäß der FHIR-Profilierung  https://gematik.de/fhir/StructureDefinition/erxOrganization unterstützen. [<=]

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 - 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 folgender Belegung gemäß "flowType" in https://gematik.de/fhir/CodeSystem/Flowtype :
"160" = Muster 16 (Apothekenpflichtige Arzneimittel)
"161" = Muster 16 (Sanitätsbedarf)
"162" = Muster 16 (Heilmittel)
"163" = Muster 16 (Hilfsmittel)
"164" = Muster 16 (Sprechstundenbedarf)
"165" = Muster 16 (Betäubungsmittel)
"166" = Muster 16 ("T-Rezepte")
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 10 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 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 2D-Code 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. [<=]

Beispiel für einen E-Rezept-Token:
"Task/4711/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea"

A_19553 - Generierung 2D-Code als Sammlung

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

  • 2D-Code-Daten = [ {E-Rezept 1}, {E-Rezept 2}, {E-Rezept 3} ]
zusammenfassen. [<=]

Beispiel für eine Sammlung von E-Rezept-Token:
[
  {"Task/4711/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea"},
  {"Task/4712/$accept?ac=0936cfa582b447144b71ac89eb7bb83a77c67c99d4054f91ee3703acf5d6a629"},
  {"Task/4713/$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.4 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 - FHIR CodeSystem FLOWTYPE

Der E-Rezept-Fachdienst, das PS der abgebenden LEI und das E-Rezept-FdV MÜSSEN das FHIR CodeSystem FLOWTYPE gemäß der FHIR-Profilierung https://gematik.de/fhir/CodeSystem/Flowtype  in https://simplifier.net/erezept-workflow/flowtype  beim Ausführen der Operation $create verwenden. 
[<=]

A_19445 - 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="Apotheke"}
Task.ExpiryDate = <Zeitpunkt der QES.Erstellung Bundle.signature.when> + 92 Kalendertage
Task.AcceptDate = <Zeitpunkt der QES.Erstellung Bundle.signature.when> + 30 Kalendertage
Task.PrescriptionType.valueCoding.display = "Muster 16 (Apothekenpflichtige Arzneimittel)"
161 Task.performerType = ##Festlegung erfolgt in einer Folgestufe##
Task.ExpiryDate = ##Festlegung erfolgt in einer Folgestufe##
Task.AcceptDate = ##Festlegung erfolgt in einer Folgestufe##
Task.PrescriptionType.valueCoding.display = "Muster 16 (Sanitätsbedarf)"
162 Task.performerType = ##Festlegung erfolgt in einer Folgestufe##
Task.ExpiryDate = ##Festlegung erfolgt in einer Folgestufe##
Task.AcceptDate = ##Festlegung erfolgt in einer Folgestufe##
Task.PrescriptionType.valueCoding.display = "Muster 16 (Heilmittel)"
163 Task.performerType = ##Festlegung erfolgt in einer Folgestufe## 
Task.ExpiryDate = ##Festlegung erfolgt in einer Folgestufe##
Task.AcceptDate = ##Festlegung erfolgt in einer Folgestufe##
Task.PrescriptionType.valueCoding.display = "Muster 16 (Hilfsmittel)"
164 Task.performerType = [ {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display = "Apotheke", text = "Lieferant"}, {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Öffentliche Apotheke"} ]
Task.ExpiryDate = <Zeitpunkt der QES.Erstellung Bundle.signature.when> + 92 Kalendertage
Task.AcceptDate = <Zeitpunkt der QES.Erstellung Bundle.signature.when> + 30 Kalendertage
Task.PrescriptionType.valueCoding.display = "Muster 16 (Sprechstundenbedarf)"
165 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Apotheke"}
Task.ExpiryDate = ##Festlegung erfolgt in einer Folgestufe##
Task.AcceptDate = ##Festlegung erfolgt in einer Folgestufe##
Task.PrescriptionType.valueCoding.display = "Muster 16 (Betäubungsmittel)"
166 Task.performerType = {coding.system="urn:ietf:rfc:3986", coding.code="1.2.276.0.76.4.54", coding.display="Apotheke"}
Task.ExpiryDate = ##Festlegung erfolgt in einer Folgestufe##
Task.AcceptDate = ##Festlegung erfolgt in einer Folgestufe##
Task.PrescriptionType.valueCoding.display = "Muster 16 (T-Rezepte)"

damit dem Versicherten Informationen über die Gültigkeit (Erstattungsfrist durch die Kasse = AcceptDate, Einlösefrist = ExpiryDate) des E-Rezepts angezeigt werden und der Workflow auf Basis der gewählten Parameter gesteuert werden kann. [<=]

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

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

  • Task.AcceptDate = <Zeitpunkt der QES.Erstellung Bundle.signature.when> + 3 Werktage (Montag bis Samstag, ausgenommen bundeseinheitliche Feiertage)
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_Rechtsgrundlage  in Bundle.Composition den code="04" 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.5 Zugriffsprotokoll

A_19296 - 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äß http://terminology.hl7.org/CodeSystem/audit-event-type 
  • AuditEvent.subType: aus dem ValueSet https://www.hl7.org/fhir/valueset-audit-event-sub-type.html  gemäß http://hl7.org/fhir/restful-interaction 
    • "create" beim Hinzufügen/Speichern/Anlegen eines Datenobjekts mit Versichertenbezug (mit Außnahme 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äß https://www.hl7.org/fhir/valueset-audit-event-action.html 
  • AuditEvent.recorded: aktuelle Systemzeit des E-Rezept-Fachdienstes
  • AuditEvent.outcome: Ergebnis der aufgerufenen Operation gemäß https://www.hl7.org/fhir/valueset-audit-event-outcome.html (0 = Erfolg, 4 = Fehler auf Clientseite, 8 = Serverfehler) 
  • AuditEvent.agent.type: Fester Wert "humanuser" aus  http://terminology.hl7.org/CodeSystem/extra-security-role-type 
  • AuditEvent.agent.name Lesbarer Name aus Identity-Token des Zugreifenden, der die zu protokollierende Aktion getriggert hat, z.B. "Praxis Dr. Müller, Bahnhofstr. 78" oder Versicherter z.B. "Max Mustermann"
  • AuditEvent.agent.who KVNR bzw. Telematik-ID des zugreifenden Nutzers aus Identity-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 betroffene Datenobjekt Task, AuditEvent oder MedicationDispense zum Abruf
  • AuditEvent.entity.name = Eintrag der KVNR des betroffenen Versicherten aus dem Identifier des protokollierten Datenobjekts (String)
[<=]

3 Anhang A – Verzeichnisse

3.1 Abkürzungen

Kürzel
Erläuterung
API application programming interface
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. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

      [Quelle]
      Herausgeber: Titel
      [gemGlossar] gematik: Glossar der Telematikinfrastruktur 

      3.5.2 Weitere Dokumente

      [Quelle]
      Herausgeber (Erscheinungsdatum): Titel
      [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
      [Simplifier] Profilierung der FHIR Ressourcen im Projekt E-Rezept
      https://simplifier.net/erezept-workflow 
      [AM-RL] Arzneimittel-Richtlinie - Gemeinsamer Bundesausschuss
      https://www.g-ba.de/richtlinien/3/ 
      [JSON] Grundlagen JSON-Notation
      https://www.json.org/json-de.html