gemSpec_DM_eRp_V1.5.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Datenmodell E-Rezept

    

     

      
Version
      
1.5.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
07.12.2022
     
     

      
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

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

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

Die Codierung nach RFC-3986 bedeutet, dass URLs:

• im FQDN-Teil lediglich aus Ziffern und Buchstaben sowie einfachem Bindestrich und Punkt bestehen dürfen (bspw. für eine reguläre Expression zur Prüfung "(?=^.{4,253}$)(^((?!-)[a-zA-Z0-9-]{0,62}[a-zA-Z0-9]\.)+[a-zA-Z]{2,63}$)") und
• in der Pfadangabe und URL-Parametern gewisse Sonderzeichen in %-Codierung enthalten dürfen. Aus Sicherheitsgründen sollte auf die Nutzung von URL-Parametern verzichtet werden.

Beispiele:
http://praxis-dr-müller.de/123 muss umgewandelt werden zu http://xn--praxis-dr-mller-9vb.de/123 (keine Umlaute erlaubt)
http://praxis dr. meier.de/123 darf keine Leerzeichen enthalten http://praxisdr.meier.de/123 (bspw. Leerzeichen löschen)

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

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.

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.

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

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

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

}

Beispiel für eine Sammlung von drei E-Rezept-Token (für die Codierung als 2D-Code):
{
  "urls": [
    "Task/4711/$accept?ac=777bea0e13cc9c42ceec14aec3ddee2263325dc2c6c699db115f58fe423607ea",
    "Task/4712/$accept?ac=0936cfa582b447144b71ac89eb7bb83a77c67c99d4054f91ee3703acf5d6a629",
    "Task/4713/$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"]} 

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. 

Beispiel für Abrechnungsinformation-Token: 

"ChargeItem/200.100.000.000.004.30?ac=0037c20b8e893b690f07d784fcfcf38c748454c08253a8b2c0499347576ca612"

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

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

}

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.

2.5 Zugriffsprotokoll

3 Anhang A – Verzeichnisse

3.1 Abkürzungen

3.2 Glossar

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.

3.5.2 Weitere Dokumente