Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
Datenmodell E-Rezept
| Version | 1.4.0 |
| Revision | 548770 |
| Stand | 09.08.2022 |
| Status | freigegeben |
| Klassifizierung | öffentlich |
| Referenzierung | gemSpec_DM_eRp |
Ä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.20 | Erstversion des Dokumentes | gematik | |
| 1.0.1 | 06.07.20 | Aktualisierung Hinweis zu Dispensierinformation | gematik | |
| 1.1.0 | 12.11.20 | Einarbeitung gemäß Änderungsliste P22.2 / Scope-Themen Systemdesign R4.0.1 | gematik | |
| 1.2.0 | 19.02.21 | Einarbeitung gemäß Änderungsliste P22.5 | gematik | |
| 1.3.0 | 07.10.21 | Einarbeitung gemäß Änderungslisten E-Rezept_Maintenance_21.1 und _21.2 |
gematik | |
| 1.3.1 | 18.11.21 | redaktionelle Anpassung des Beispiels für Afo 19553-x "... Sammlung von vier drei E-Rezept-Token ..." |
gematik | |
| 1.4.0 | 09.08.22 | 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 |
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.
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.
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) festgelegt 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.
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.
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
[<=]
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_22483 - Version FHIR-Package de.gematik.erezept-workflow
Die Produkttypen der Anwendung E-Rezept und das PS der verordnenden und abgebenden LEI MÜSSEN das FHIR-Package de.gematik.erezept-workflow in der Version gemäß [FHIR Version] unterstützen. [<=]
Die in beiden Projekten erstellten Profile setzen auf den FHIR-Standard in der Version 4.0.1.
A_19295 - 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/StructureDefinition/erxTask unterstützen. [<=]
A_19297 - 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/StructureDefinition/erxMedicationDispense unterstützen. [<=]
A_19298 - FHIR-Ressource AuditEvent
Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource AuditEvent gemäß der FHIR-Profilierung https://gematik.de/fhir/StructureDefinition/erxAuditEvent unterstützen. [<=]
A_19299-01 - 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
A_19300 - 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/StructureDefinition/erxReceipt unterstützen. [<=]
A_20213 - FHIR-Ressource Bundle Versicherter
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 und https://gematik.de/fhir/StructureDefinition/erxComposition 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 - FHIR-Ressource ChargeItem
Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource ChargeItem gemäß der FHIR-Profilierung https://gematik.de/fhir/StructureDefinition/erxChargeItem unterstützen. [<=]
A_22206 - FHIR-Ressource Consent
Die Produkttypen der Anwendung E-Rezept MÜSSEN die FHIR-Ressource Consent gemäß der FHIR-Profilierung https://gematik.de/fhir/StructureDefinition/erxConsent unterstützen. [<=]
A_20745 - 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/StructureDefinition/erxDevice unterstützen. [<=]
A_22216 - FHIR-Ressourcen Versionsangabe
Die Produkttypen der Anwendung E-Rezept und das PS der verordnenden und abgebenden LEI MÜSSEN alle generierten FHIR-Ressourcen mit der Versionsnummer gemäß https://www.hl7.org/fhir/datatypes.html#canonical im Feld Ressource.meta.profile kennzeichnen, zu dessen aktuell gültiger Profilversion sie mutmaßlich validieren. [<=]
A_22920 - Kodierung fullURL
Die Produkttypen der Anwendung E-Rezept und das PS der verordnenden und abgebenden LEI, welche fullURLs in FHIR-Objekten erstellen, MÜSSEN diese URLs gemäß [RFC3986] für FHIR-Datentyp "URI" codieren. [<=]
Die Codierung nach RFC-3986 bedeutet, dass URLs:
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.
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 der Belegung gemäß "flowType" in https://gematik.de/fhir/CodeSystem/Flowtype |
| bbb.bbb.bbb.bbb | fortlaufende Rezeptnummer | nummerisch, 12-stellig |
| cc | Prüfnummer Verfahren gemäß [ISO 7064] |
nummerisch |
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. [<=]
Im Folgenden wird das Modulo-97-Verfahren an zwei Beispielen verdeutlicht.
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:
Beispiel für E-Rezept-Einlöseinformationen (z.B. für Nutzung als Referenz in Communication-Ressource):
"Task/4711/$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
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"]}
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. [<=]
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
Beispiel für die Codierung als 2D-Code:
{
"urls": [ "ChargeItem/200.100.000.000.004.30?ac=0037c20b8e893b690f07d784fcfcf38c748454c08253a8b2c0499347576ca612" ]
}
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
Die Produkttypen der Anwendung E-Rezept, das PS der verordnenden LEI und das PS der abgebenden LEI MÜSSEN das FHIR CodeSystem FLOWTYPE gemäß der FHIR-Profilierung https://gematik.de/fhir/CodeSystem/Flowtype in https://simplifier.net/erezept-workflow/flowtype unterstützen.
[<=]
A_19445-08 - 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
sonstTask.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage |
| 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
sonstTask.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 28 Kalendertage
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
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
sonstTask.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
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
sonstTask.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 3 Kalendermonate
wenn MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end angegeben
Task.ExpiryDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
sonst
Task.AcceptDate = MedicationRequest.extension:Mehrfachverordnung.extension:Zeitraum.value[x]:valuePeriod.end
Task.ExpiryDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage
Task.AcceptDate = <Datum der QES.Erstellung im Signaturobjekt> + 365 Kalendertage |
A_19517-02 - 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:
A_19296-02 - E-Rezept-Fachdienst - Inhalt Protokolleintrag
Der E-Rezept-Fachdienst MUSS einen Protokolleintrag mit den folgenden Werten befüllen:
| 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 |
| 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.
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 |
| [FHIR Version] | https://github.com/gematik/api-erp/blob/master/docs/erp_fhirversion.adoc#e-rezept-fhir-package-versionsmanagement |
| [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 |