latest
Elektronische Gesundheitskarte und Telematikinfrastruktur
Informationsmodell
Notfalldaten-Management (NFDM)
Version | 1.7.0 |
Revision | 983072 |
Stand | 26.08.2022 |
Status | freigegeben |
Klassifizierung | öffentlich |
Referenzierung | gemSpec_InfoNFDM |
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 |
25.10.16 |
Basis Online-Rollout (Stufe 2.1) |
gematik |
|
1.1.0 |
05.10.17 |
Änderungen zur Anpassung an eMP/AMTS in Bezug auf die Medikationsdateneinträge (gelb) |
P73 |
|
1.2.0 | 15.12.17 | Synchronisation mit eMP/AMTS (Übernahme der Änderungen durch BMP v2.4) und kleinere Korrekturen | gematik | |
1.3.0 | 14.05.18 | Anpassung lt. P15.2 und P15.4 | gematik | |
1.4.0 | 26.10.18 | Anpassung lt. P15.9 |
gematik | |
1.5.0 | 28.06.19 | Anpassung lt. P17.4 | gematik | |
Anpassung lt. P21.1 | gematik | |||
1.6.0 | 02.03.20 | freigegeben | gematik | |
1.7.0 | 26.08.22 | 2.1.3 5.6 5.6.3 |
Einarbeitung CI_Maintenance_22.4: Kapitelanpassungen durch Wegfall mehrerer spezieller gesetzlicher Rahmenbedingungen aus § 291a SGB V zur Erteilung von Einwilligung und der schriftlichen Hinterlegung dieser | gematik |
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
Ziel des Dokumentes ist es, dem Leser Detailinformationen über die dem Notfalldatensatz zu Grunde liegenden XML-Schemata (NFD_Document.XSD und DPE_Document.XSD) zu geben. Das XSD selbst ist im Wesentlichen ohne „annotations“ aufgebaut. Zum Verständnis der „elements“ sind deshalb weiterführende Informationen notwendig. Im Gegensatz zu annotations werden im vorliegenden Dokument auch erklärende Hinweise gegeben, sofern sie dem besseren Verständnis von Anforderungen bzw. Zusammenhängen dienen.
1.2 Zielgruppe
Das Dokument richtet sich an Hersteller des Produkttyps „Fachmodul NFDM“(Im Folgenden wird die Zielgruppe auch im Sinne eines potentiellen Herstellers von Primärsystemen verstanden.).
1.3 Geltungsbereich
Das Dokument dient der angegebenen Zielgruppe als ergänzende Grundlage für die Entwicklung von Endanwendersystemen bzw. den entsprechenden Tests.
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
Das Dokument bezieht sich inhaltlich auf den Produkttypen „Fachmodul NFDM“.
Das „Fachmodul NFDM“ spezifiziert den NFDService. Über die dort aufgeführte Schnittstelle „I_NFD_Mangement“ werden base64-codierte SOAP-Nachrichten ausgetauscht. Für die Daten des Notfalldatensatzes (NFD) werden zusätzlich Signaturdaten für eine qualifizierte Signatur erforderlich. Ähnliches (jedoch ohne Signaturerfordernis) gilt für die Daten persönlicher Erklärungen.
Die Verfahrensweise des Nachrichtenaustauschs, der Prüfung und ggf. Fehlerbehandlung wird in der Fachmodulspezifikation [gemSpec_FM_NFDM] definiert. Die Fachdaten, sowohl der Notfalldaten als auch der persönlichen Erklärungen, werden als XML-Dateien übertragen, die dem im vorliegenden Dokument beschriebenen XSD entsprechen müssen.
1.5 Methodik
1.5.1 Diagramme
Die Beschreibung der einzelnen Elemente des XML-Schemas wird über die Abbildung der Diagramme von Elementgruppen und eine nachfolgende, tabellarische Darstellung der Elementeigenschaften erbracht. Den Beschreibungen vorangestellt sind im Kapitel 2.2 und 2.3 die graphischen Abbildungen des Datenmodells für den NFD bzw. den DPE.
1.5.2 Verwendung von Schlüsselworten
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.
Anforderungen werden im Dokument wie folgt dargestellt:
Dabei umfasst die Anforderung sämtliche innerhalb der Textmarken angeführten Inhalte.
Im Dokument werden Bezeichnungen verwendet, die aus der Beschreibung des XSD abgeleitet sind, z.B. „element“ und „attribute“. Diese Bezeichnungen werden in Kleinbuchstaben geschrieben, da sie in XML in Englisch verwendet werden.
1.5.3 Umfang
Das Dokument beschreibt drei Blöcke, die in separaten XSD-Dateien vorliegen. Diese sind:
- „NFD_Document“ mit den Elementen „Notfalldaten“ und „SignatureArzt“ sowie
- „DPE_Document“
- „NFDM_Common“ (mit Informationen, die für NFD_Document und DPE_Document gleichermaßen relevant sind)
2 Informationsmodell
2.1 Einordnung und Überblick
2.1.1 Allgemeine Hinweise
Die Unterteilung des fachlichen Informationsmodells in die Darstellung von „notfallrelevanten medizinischen Informationen“ und „persönlichen Erklärungen“ wurde für das technische Informationsmodell beibehalten.
Die Daten des Notfalldaten-Managements werden als komprimierte XML-Dateien auf der eGK in zwei getrennten Containern abgelegt. Die Notfalldaten werden zusammen mit den Signaturdaten im Container EF.Notfalldatensatz abgelegt.
Die Daten der persönlichen Erklärungen werden im Container EF.PersönlicheErklärungen abgelegt.
Für jedes Element der relevanten XML-Schemata werden im Dokument die Definition, beschreibende Detailinformationen und, soweit nötig, Erklärungen beigefügt.
Als Grundlagendokumente wurden neben den Vorgaben der Bundesärztekammer und Hinweisen der Arzneimittelkommission der deutschen Ärzteschaft auch weitere, bereits durch andere Organisationen erstellte Unterlagen verwendet. Die dort dokumentierten Spezifikationen sind öffentlich verwendbar. Es handelt sich um:
- Arztbrief V1.50, Implementierungsleitfaden,
Dokumenten-OID 1.2.276.0.76.3.1.13.7.5 [VHitG_Arztbrief_V1.5] - Addendum zum Arztbrief V1.50, Darstellung Medikation, Implementierungsleitfaden, Version 1,
Dokumenten-OID 1.2.276.0.76.3.1.13.7.22 [VHitG_Arztbrief_V1.5_Addendum] - Darstellung von Diagnosen auf Basis der HL7 Clinical Document Architecture Rel.2 für das deutsche Gesundheitswesen V1.1, Implementierungsleitfaden,
Dokumenten-OID 1.2.276.0.76.7.4 [Diagnosen_HL7_Implementierung]E - Empfehlung der Bundesärztekammer und der Zentralen Ethikkommission bei der Bundesärztekammer zum Umgang mit Vorsorgevollmacht und Patientenverfügung in der ärztlichen Praxis. [Ärzteblatt_2010]
- Spezifikation für einen patientenbezogenen Medikationsplan, Version 2.0 [Medikationsplan]
Wenn im Text nicht anders angegeben, sind Angaben zu Datenformaten und Plausibilitätsprüfungen unter Berücksichtigung der o. a. Dokumente spezifiziert.
Das XSD „NFD_Document“ beinhaltet zwei Elemente, von denen das element „Notfalldaten“ im Kapitel 3 „XML-Schema (XSD) des Notfalldatensatzes“ eingehend beschrieben wird. Das element „SignatureArzt“ wird im Kapitel 4 „Signaturdaten“ überblicksartig dargestellt. Die Beschreibung der notwendigen Elemente steht auf http://www.w3.org/TR/2002/REC-xmldsig-core-20020212 zur Verfügung.
2.1.2 Grenzen eines XML-Schemas
XML-Schemata bieten die Möglichkeit, schon bei der Definition der Elemente durch Festlegung der property „minOcc“ auf einen Wert > 0, eine Grundprüfung auf Befüllung der Elemente durchzuführen. Je mehr Elemente mit dieser Angabe versehen sind, desto besser kann schon durch das Schema sichergestellt werden, dass der Datensatz gefüllt wird. Für die Kapitel 3 (XSD des Notfalldatensatzes) und 5 (XSD des Datensatzes persönlicher Erklärungen) ist zu beachten, dass nur ein geringer Anteil der Elemente diese Vorabprüfung unterstützt, obgleich in einigen Fällen Wertelisten hinterlegt sind. Dadurch soll der Leistungserbringer in seiner Arbeit unterstützt werden, ohne jedoch durch notwendige Eingaben („mandatory“) übermäßig belastet zu werden. Das vorliegende Dokument gibt in Einzelfällen ergänzende Hinweise zur Handhabung besonderer Elemente.
2.1.3 Berechtigungsverwaltung
Für die eGK der unterschiedlichen Generationen (G2) gelten dementsprechend angepasste Zugriffsregeln, insbesondere in Bezug auf die PIN.CH, MRPIN.NFD und MPRIN.DPE.
Die Regeln für den lesenden und schreibenden Zugriff auf die Daten zum Notfalldatensatz bzw. zu den persönlichen Erklärungen werden im Fachmodul [gemSpec_FM_NFDM] dargestellt.
Die Einwilligung ist grundsätzlicher Art und vom Versicherten gegenüber dem Leistungserbringer zu erteilen. Die Erteilung muss dauerhaft auf der eGK dokumentiert und im Primärsystem protokolliert werden.
Die Regeln zur Erteilung rechtswirksamer Erklärungen sind nicht Gegenstand des vorliegenden Dokuments, jedoch werden im NFD und DPE die Einwilligungsinformationen abgelegt.
2.1.4 Choreographie des Notfalldatenprozesses
Die wesentlichen Schritte zur (Erst-)Anlage eines Notfalldatensatzes lassen sich überblicksartig wie folgt darstellen:
Diese Abfolge soll lediglich die möglichen Interaktionen zwischen den beteiligten Akteuren skizzieren und stellt keine Vorgabesequenz dar. Die Ablaufsteuerung selbst obliegt dem Primärsystem.
Im Lastenheft zum Notfalldaten-Management [gemLH_NFDM] und in der Systemlösung [gemSysL_NFDM] sind bestimmte Vorgaben zum Systemverhalten festgelegt. Eine wichtige Forderung ist dahingehend präzisiert, dass die Vorgänge zum Signieren eines NFD räumlich und zeitlich getrennt vom eigentlichen Schreiben auf die eGK ermöglicht werden müssen (NFDM-A_113 „Trennung Signieren und Schreiben NFD“). Damit soll vermieden werden, dass der Arzt während der medizinischen Behandlung (innerhalb derer auch die Anlage des NFD stattfindet) nicht nur den Grunddatenbestand für den NFD zusammenstellt und signiert sondern auch direkt im Anschluss daran auf die eGK schreiben muss. Diesen Schreibvorgang kann problemfrei auch der Mitarbeiter der medizinischen Institution zu einem späteren Zeitpunkt außerhalb des Behandlungsraumes vornehmen. Diese Entzerrung entlastet zum einen den Arzt, zum anderen ist es nicht erforderlich, dass die eGK des Versicherten (erneut) im Behandlungsraum in ein Kartenterminal gesteckt wird. Möchte jedoch der Arzt selbst sofort auch den Schreibvorgang vornehmen, so ist dies durch die Lastenheftanforderung nicht verhindert.
Zu beachten ist in diesem Zusammenhang, dass ein Schreiben des NFD unter bestimmten Bedingungen die Eingabe einer PIN.CH des Versicherten erforderlich macht(Das ist immer dann der Fall, wenn in Abhängigkeit von der Kartengeneration der eGK, die PIN.CH des Versicherten initialisiert bzw. die MRPIN.NFD aktiviert (flagEnabled=true) wurde.). Die Prüfung der Eingabenotwendigkeit wird durch die TI jedoch nicht zu Beginn des Erfassungsvorgangs des NFD durchgeführt sondern erst dann, wenn der eigentliche Schreibvorgang gestartet wird und der TUC_KON_012 „PIN verifizieren“ ausgeführt wird.
In Abhängigkeit von der bereits erwähnten Zeitgestaltung bei der Erfassung/Signierung des Datensatzes sollte darauf geachtet werden, dass der Versicherte zu einem möglichst frühen Erfassungszeitpunkt erkennt, dass er eine PIN eingeben muss. Hierfür kann das Primärsystem eine entsprechende Hilfestellung für den Arzt geben, z. B. durch einen kurzen Hinweis, der Arzt möge den Versicherten fragen, ob er eine initialisierte/aktivierte PIN besitzt bzw. ob er diese PIN auch zur Verfügung hat. Fehlt diese Information zum Zeitpunkt des Schreibens auf die eGK, ist möglicherweise die Anlage des NFD umsonst erfolgt, da der NFD ohne PIN in diesem Fall nicht auf die eGK geschrieben werden kann.