gemSpec_InfoNFDM_V1.6.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Informationsmodell

Notfalldaten-Management (NFDM)

    
     
      Version
      1.6.0
     
     
      Revision
      548770
     
     
      Stand
      02.03.2020
     
     
      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	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

Inhaltsverzeichnis

Dokumentinformationen
Inhaltsverzeichnis
1 Einordnung des Dokumentes
1.1 Zielsetzung
1.2 Zielgruppe
1.3 Geltungsbereich
1.4 Abgrenzungen
1.5 Methodik
1.5.1 Diagramme
1.5.2 Verwendung von Schlüsselworten
1.5.3 Umfang
2 Informationsmodell
2.1 Einordnung und Überblick
2.1.1 Allgemeine Hinweise
2.1.2 Grenzen eines XML-Schemas
2.1.3 Berechtigungsverwaltung
2.1.4 Choreographie des Notfalldatenprozesses
2.2 Infomodell des Notfalldatensatzes
2.3 Infomodell des Datensatzes persönlicher Erklärungen
3 XML-Schema (XSD) des Notfalldatensatzes
3.1 Einleitung
3.2 Ebene 0: root element „NFD_Document“
3.3 Ebene 1: element „Notfalldaten“
3.4 Ebene 2: element „NFD_Versicherter“
3.4.1 Ebene 3: element NFDM:Versicherter
3.4.1.1 Prüfung von Abweichungen bei Stammdaten des Versicherten
3.4.1.2 element „NFDM:Versicherten_ID“
3.4.1.3 element „NFDM:Geburtsdatum“
3.4.1.4 Element „NFDM:Vorname“
3.4.1.5 element „NFDM:Nachname“
3.4.1.6 element „NFDM:Vorsatzwort“
3.4.1.7 element „NFDM:Namenszusatz“
3.4.1.8 element „NFDM:Titel“
3.4.1.9 element „NFDM:Geschlecht“
3.4.2 Ebene 3: element „NFD_Behandelnder_Arzt_Institution“
3.4.2.1 attribute „BAI_Art“
3.4.2.2 element „NFD_BAI_Arzt_Nachname“
3.4.2.3 element „NFD_BAI_Arzt_Vorname“
3.4.2.4 element „NFD_BAI_Institution_Bezeichnung“
3.4.2.5 element „NFD_BAI_Arzt_Bezeichnung“
3.4.2.6 Ebene 4: element „NFD_BAI_Adresse“
3.4.2.7 Ebene 4: element „NFD_BAI_Kommunikation“
3.4.3 Ebene 3: element „NFD_Benachrichtigungskontakt“
3.4.3.1 element „NFD_BK_Bezeichnung“
3.4.3.2 element „NFD_BK_Nachname“
3.4.3.3 element „NFD_BK_Vorname“
3.4.3.4 element „NFD_BK_Kommunikation“
3.4.4 Ebene 3: element „NFD_Versicherter_Kommunikation“
3.4.4.1 element „NFD_Versicherter_Kommunikation“
3.4.4.2 Ebene 4: element „NFD_Versicherter_Kommunikation“
3.5 Ebene 2: element „NFD_Versicherter_Einwilligung“
3.5.1 Ebene 2: element „NFD_Versicherter_Einwilligung“
3.5.1.1 element „NFD_VE_Arzt_Nachname“
3.5.1.2 element „NFD_VE_Arzt_Vorname“
3.5.2 Ebene 3: element „NFD_VE_Adresse“
3.6 Ebene 2: element „NFD_Befunddaten“
3.6.1 Ebene 3: element „Besondere_Hinweise“
3.6.1.1 Ebene 4: element „Schwangerschaft“
3.6.1.1.1 element „Entbindungstermin_errechnet“
3.6.1.1.2 element „Schwangerschaft“
3.6.1.1.3 Ebene 5: element „diagnostiziert_indiziert“
3.6.1.2 Ebene 4: element „Implantate“
3.6.1.2.1 element „Datum_Implantation“
3.6.1.2.2 element „Implantate“
3.6.1.2.3 element „Typenbezeichnung“
3.6.1.2.4 Ebene 5: element „diagnostiziert_indiziert“
3.6.1.3 Ebene 4: element „Kommunikationsstoerungen“
3.6.1.3.1 element „Kommunikationsstoerung“
3.6.1.3.2 Ebene 5: element „diagnostiziert_indiziert“
3.6.1.4 Ebene 4: element „Weglaufgefaehrdung“
3.6.1.4.1 element „Weglaufgefaehrdung“
3.6.1.4.2 element „Weglaufgefaehrdung_Erlaeuterung“
3.6.1.4.3 Ebene 5: element „diagnostiziert_indiziert“
3.6.1.5 Ebene 4: element „Sonstige_Hinweise“
3.6.1.5.1 element „sonstige_Hinweise“
3.6.1.5.2 Ebene 5: element „diagnostiziert_indiziert“
3.6.2 Ebene 3: element „Allergien_Unvertraeglichkeiten"
3.6.2.1 element „Substanz“
3.6.2.2 element „Reaktion“
3.6.2.3 Ebene 4: element „diagnostiziert_indiziert“
3.6.3 Ebene 3: element „Diagnosen“
3.6.3.1 element „Diagnose_Code“
3.6.3.2 element „Diagnose_Text“
3.6.3.3 element „Diagnose_Zeitpunkt“
3.6.3.4 element „Diagnosesicherheit“
3.6.3.5 element „Seitenlokalisation“
3.6.3.6 Ebene 4: element „Diagnose_Code_System“
3.6.3.6.1 element „Kennzeichen_Code_System“
3.6.3.6.2 Ebene 4: element „diagnostiziert_indiziert“
3.7 Ebene 2: element „NFD_Medikationseintrag“
3.7.1 Ebene 3: element „diagnostiziert_indiziert“
3.7.2 Ebene 2: element „M“
3.7.3 Ebene 3: element „W“
3.7.4 Ebene 3: element „R“
3.8 Ebene 2: element „NFD_Freiwillige_Zusatzinformationen“
3.8.1 element „Freiwillige_Zusatzinformationen“
3.9 Wiederverwendbare Elemente
3.9.1 element „NFD_BAI_Adresse“
3.9.1.1 element „NFDM:Postleitzahl“
3.9.1.2 element „NFDM:Ort“
3.9.1.3 element „NFDM:Strasse“
3.9.1.4 element „NFDM:Hausnummer“
3.9.1.5 element „NFDM:Anschriftenzusatz“
3.9.1.6 element „NFDM:Wohnsitzlaendercode“
3.9.2 element „NFD_BAI_Kommunikation“
3.9.2.1 element „NFDM:Telefonnummer“
3.9.2.2 element „NFDM:Faxnummer“
3.9.2.3 element „NFDM:E-Mail“
3.9.3 element „diagnostiziert_indiziert“
3.9.3.1 element „DI_Arzt“
3.9.3.1.1 element „DI_Arzt_Name“
3.9.3.1.2 element „DI_Arzt_Fachgebiet“
3.9.3.1.3 element „DI_Arzt_Ort“
3.9.3.2 element „DI_Institution“
3.9.3.2.1 element „DI_Institution_Name“
3.9.3.2.2 element „DI_Institution_Fachabteilung“
3.9.3.2.3 element „DI_Institution_Ort“
4 Signaturdaten
4.1 Ebene 1: element „SignatureArzt“
4.2 Kurzbeschreibung der Signatur
5 XML-Schema (XSD) des Datensatzes persönlicher Erklärungen
5.1 Einleitung
5.2 Randbedingungen
5.3 Ebene 0: root element „DPE_Document“
5.4 Ebene 1: element „Persoenliche Erklaerungen“
5.5 Ebene 2: element „DPE_Versicherter“
5.5.1 Ebene 3: element NFDM:Versicherter
5.5.1.1 element „NFDM:Versicherten_ID“
5.5.1.2 element „NFDM:Geburtsdatum“
5.5.1.3 element „NFDM:Vorname“
5.5.1.4 element „NFDM:Nachname“
5.5.1.5 element „NFDM:Vorsatzwort“
5.5.1.6 element „NFDM:Namenszusatz“
5.5.1.7 element „NFDM:Titel“
5.5.1.8 element „NFDM:Geschlecht“
5.6 Ebene 2: element „DPE_Versicherter_Einwilligung“
5.6.1 element „DPE_VE_Arzt_Nachname“
5.6.2 element „DPE_VE_Arzt_Vorname”
5.6.3 element „DPE_VE_Ablageort”
5.7 Ebene 2: element „DPE_Gewebe_Organspendeerklaerung“
5.7.1 element „DPE_GO_Beschreibung”
5.7.2 element „DPE_GO_Ablageort”
5.8 Ebene 2: element „DPE_Vorsorgevollmacht“
5.8.1.1 element „DPE_Vorsorgevollmacht“
5.8.1.2 element „DPE_VV_Beschreibung”
5.8.1.3 element „DPE_VV_Ablageort”
5.8.2 Ebene 3: element DPE_VV_Bevollmaechtigter
5.8.2.1 element „DPE_VV_E-Mail”
5.8.2.2 element „DPE_VV_Faxnummer”
5.8.2.3 element „DPE_VV_Name_Bevollmaechtigter”
5.8.2.4 element „DPE_VV_Vorname_Bevollmaechtigter”
5.8.2.5 element „DPE_VV_Telefon_Bevollmaechtigter”
5.8.2.6 element „DPE_VV_Adresse_Bevollmaechtigter”
5.9 Ebene 2: element „DPE_Patientenverfuegung“
5.9.1 element „DPE_PV_Ablageort”
5.9.2 element „DPE_PV_Beschreibung”
6 Anhang A – Verzeichnisse
6.1 Abkürzungen
6.2 Glossar
6.3 Abbildungsverzeichnis
6.4 Tabellenverzeichnis
6.5 Referenzierte Dokumente
6.5.1 Dokumente der gematik
6.5.2 Weitere Dokumente
7 Anhang B
7.1 Anforderungszusammenhang – Eingangsanforderungen
7.2 Anforderungszusammenhang – Ausgangsanforderungen

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.

Aus den Regelungen des § 291 a SGB V ergibt sich, dass die Versicherten ihre Bereitschaft zur Ablage bzw. Nutzung von notfallrelevanten Daten und Daten zu persönlichen Erklärungen gegenüber den Berechtigten erklären müssen.

Zu unterscheiden ist in diesem Zusammenhang zwischen „Einwilligung“ und „Einverständnis“ zur Nutzung von NFDM. Die Einwilligung ist grundsätzlicher Art und vom Versicherten explizit zu erteilen. Die Erteilung muss dauerhaft auf der eGK dokumentiert werden. Das Einverständnis wird fallweise durch den Versicherten erteilt, z.B. in der Arztpraxis dem Leistungserbringer gegenüber.

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:

Abbildung 1: Abb_INFO_001 Ablauf der Anlage für Notfalldaten

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.

2.2 Infomodell des Notfalldatensatzes

Abbildung 2: Abb_INFO_002 Technisches Informationsmodell für notfallrelevante medizinische Informationen

NFDM-A_2333 - Technisches Informationsmodell notfallrelevante medizinische Informationen (XSD)

Das Fachmodul NFDM MUSS das im Dokument [gemSpec_InfoNFDM] definierte Modell "Technisches Informationsmodell für notfallrelevante medizinische Informationen" gemäß dem XML-Schema umsetzen.
[<=]

2.3 Infomodell des Datensatzes persönlicher Erklärungen

Abbildung 3: Abb_INFO_003 Technisches Informationsmodell für persönliche Erklärungen

NFDM-A_2334 - Technisches Informationsmodell persönliche Erklärungen des Versicherten (XSD)

Das Fachmodul NFDM MUSS das im Dokument [gemSpec_InfoNFDM] definierte Modell "Technische Informationsmodell für persönliche Erklärungen des Versicherten" gemäß dem XML-Schema umsetzen.
[<=]

3 XML-Schema (XSD) des Notfalldatensatzes

3.1 Einleitung

Für das XML-Schema des Notfalldatensatzes gelten die folgenden Randbedingungen:

XSD-Vorgaben zu übergreifenden Elementen (NFDM_Common) werden über einen „import“ angezogen. Diese Elemente werden sowohl für den Notfalldatensatz als auch für den Datensatz persönlicher Erklärungen genutzt und haben der Präfix „NFDM“. Es handelt sich hierbei um
- NFDM:Adresse
- NFDM:Kommunikationsdaten
- NFDM:Versicherter
Elemente, deren Bedeutung identisch ist, die jedoch sowohl im Notfalldatensatz als auch im Datensatz persönlicher Erklärungen verwendet werden, sind am entsprechenden Präfix (NFD_ bzw. DPE_) zu erkennen.

Die Zeichenkodierung des XSD für den Notfalldatensatz erfolgt nach ISO 8859-15 [NFDM-A_2080].

NFDM-A_2080 - PS: Zeichenkodierung in ISO 8859-15

Das Primärsystem MUSS sicherstellen, dass die Daten des Notfalldatenmanagements (NFD und DPE) nach dem Standard ISO 8859-15 kodiert und gespeichert werden.
[<=]

Der Zielnamensraum ist vorgegeben und im Schema angeführt (Beispiel: http://ws.gematik.de/fa/nfds/common/NFDM_Common/v1.0). Änderungen am Namensraum werden durch die gematik definiert und verbindlich gesetzt.

Der Aufbau des XML-Schemas für die Notfalldaten ist auf mehrere Ebenen aufgeteilt. Bedingt durch rechtsrelevante und fachliche Angaben zum Erstellen des eigentlichen Datensatzes sind dadurch Staffelungen über viele Ebenen notwendig. Die folgenden Graphiken verdeutlichen die Staffelungen und geben gleichzeitig eine Nomenklatur der Bezeichnungen an, mit der die weiteren Abschnitte in Kapitel 3 besser lesbar werden sollen.

Abbildung 4: Abb_INFO_004 Ebenen 0 bis 2 des XSD

Abbildung 5: Abb_INFO_005 Ebene 2 bis 4 des XSD (Versicherter)

Abbildung 6: Abb_INFO_006 Ebene 2 bis 3 des XSD (Einwilligung)

Abbildung 7: Abb_INFO_007 Ebene 2 bis 6 des XSD (Befunddaten - Hinweise)

Abbildung 8: Abb_INFO_008 Ebene 2 bis 4 des XSD (Befunddaten - Allergien)

Abbildung 9: Abb_INFO_009 Ebene 2 bis 4 des XSD (Befunddaten - Diagnosen)

Abbildung 10: Abb_INFO_010 Ebene 2 bis 4 des XSD (Medikationsdaten)

Die folgenden Teilkapitel beschreiben die eigentlichen Detailinformationen für jedes Feld des Datensatzes. Zu Beginn jeder Beschreibung ist eine Graphik des entsprechenden Elements aus dem XML-Schema eingefügt, deren Einzelelemente im Anschluss daran beschrieben werden.

3.2 Ebene 0: root element „NFD_Document“

Abbildung 11: Abb_INFO_011 root element NFD_Document

Die Ebene 0 bedient zwei Elemente, von denen im Folgenden nur das Element „NFD:Notfalldaten“ in vollem Umfang beschrieben wird.

element name	NFD_Document
type
content	complex
maxLength
minOccurs
maxOccurs
pattern
Schlüssel-verzeichnis
Beschreibung	Dokument mit medizinisch relevanten Informationen für den Notfall sowie der entsprechenden Signaturinformation.
Kommentar

attribute name	NFD_Version
type	String
use	Required
Beschreibung
Kommentar	Angabe über die Version des Datensatzes. Die Versionierung ist nicht Gegenstand des vorliegenden Dokuments.

3.3 Ebene 1: element „Notfalldaten“

Abbildung 12: Abb_INFO_012 element Notfalldaten

element name	Notfalldaten
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Medizinisch relevante Informationen für den Notfall
Kommentar

attribute name	ID_NFD
type	string
fixed	1.2.276.0.76.7.8
use	required
Beschreibung	Identifier in der gematik-Objektnomenklatur
Kommentar	Angleichung an eMP/AMTS

attribute name	ID
type	ID
use	required
Beschreibung	ID zur Referenzierung durch die Signatur
Pattern
Kommentar

attribute name	NFD_letzte_Aktualisierung_date
type	date
use	required
Beschreibung	Information über das Datum des letzten schreibenden Zugriffs auf die NFD der eGK
Kommentar	Der Schreibvorgang wird nach den Vorgaben des [gemSpec_FM_NFDM#6] „WriteNFD“ durchgeführt. Es kann immer nur ein Datensatz zum NFD auf der eGK vorhanden sein.

attribute name	NFD_letzte_Aktualisierung_time
type	time
use	required
Beschreibung	Information die Zeit des letzten schreibenden Zugriffs auf die NFD der eGK
Kommentar	Der Schreibvorgang wird nach den Vorgaben des [gemSpec_FM_NFDM#6] „WriteNFD“ durchgeführt. Es kann immer nur ein Datensatz zum NFD auf der eGK vorhanden sein. Angleichung an eMP/AMTS

Die Notfalldaten des Versicherten unterliegen strengen Anforderungen des Datenschutzes. Keinesfalls dürfen sie unmittelbar nach dem Stecken der eGK automatisch und ohne die Zustimmung des Versicherten (per PIN-Eingabe, wenn die entsprechenden Voraussetzungen vorliegen) ausgelesen und angezeigt werden [NFDM-A_2332].

NFDM-A_2332 - PS: Verbot des automatischen Lesens und Anzeigens des NFD bei Stecken der eGK

Das Primärsystem MUSS sicherstellen, dass Notfalldaten beim Stecken der eGK des Versicherten nicht automatisch ausgelesen oder angezeigt werden.
[<=]

3.4 Ebene 2: element „NFD_Versicherter“

Abbildung 13: Abb_INFO_013 element NFD_Versicherter

element name	NFD_Versicherter
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Gesamtheit der Verwaltungsdaten des Versicherten
Kommentar

3.4.1 Ebene 3: element NFDM:Versicherter

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:NFDM="http://ws.gematik.de/fa/nfds/common/NFDM_Common/v1.0" targetNamespace="http://ws.gematik.de/fa/nfds/common/NFDM_Common/v1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.0">

Die aktuell geltenden Beschreibungen und Kommentare zu den einzelnen Feldern der Stammdaten können den Vorgaben der Fachanwendung VSDM (aktuell https://fachportal.gematik.de/spezifikationen/online-produktivbetrieb/schemata-wsdl-und-andere-dateien/ entnommen werden.)

3.4.1.1 Prüfung von Abweichungen bei Stammdaten des Versicherten

Es ist erforderlich, dass die Angaben zum Namen und zum Vornamen des Versicherten, die auf der eGK aufgedruckt sind, mit den Angaben übereinstimmen, die im Zuge der Anlage oder Änderung des NFD erfasst bzw. gelesen werden.

Hierbei ist zu berücksichtigen, dass vom Kostenträger kein Online-Update auf den VSD-Container erfolgt, falls eine neue eGK bereitgestellt wird, z. B. im Fall einer Namensänderung durch Heirat des Versicherten.

Es kann demnach die Situation eintreten, dass der Versicherte noch keine neue eGK mit den korrekten Stammdaten besitzt, jedoch einen NFD anlegen lassen möchte.

Hierfür lassen sich folgende Fallkonstellationen unterscheiden:

Der Versicherte informiert den Leistungserbringer, dass der auf der eGK aufgedruckte Name nicht mehr aktuell ist.
Es bleibt der Entscheidung des Arztes bzw. des Mitarbeiters der medizinischen Institution oder des Versicherten überlassen, ob nach einem entsprechenden Hinweis durch den Versicherten für den Versicherten ein NFD im Primärsystem angelegt wird (Proto-NFD), der bereits diese Abweichung (Namensänderung) berücksichtigt und vom Arzt signiert wird. Dieser Proto-NFD wird jedoch zu diesem Zeitpunkt nicht auf die eGK geschrieben; es wird auch kein weiterer Stammdatensatz für diesen Versicherten („Doublette“) angelegt.

Der Proto-NFD kann erst dann auf die eGK geschrieben werden, wenn der Versicherte bei einem erneuten Besuch beim Arzt seine neue eGK vorlegt. (Eine erneute) Signierung ist nicht erforderlich.

Der Versicherte gibt die Namensänderung nicht bekannt, der im Primärsystem daraufhin angelegte NFD wird, da die Namensdaten auf der eGK mit denen des NFD identisch sind, auf die eGK geschrieben.

Bei einem Folgebesuch des Versicherten mit der neuen eGK muss dann der NFD im Primärsystem geändert und auf die neue eGK geschrieben werden.

Arzt und Versicherter verfahren ähnlich wie im Fall a), jedoch wird lediglich der medizinische Teil des NFD angelegt und im Primärsystem zwischengespeichert. Die Versichertenstammdaten des NFD werden erst bei einem Folgebesuch des Versicherten – mit seiner neuen eGK – mit den korrekten Daten vervollständigt und dem Arzt zur Signierung bereitgestellt. Anschließend kann der NFD auf die neue eGK geschrieben werden.

Das Primärsystem soll den Arzt soweit wie möglich bei der Erkennung von Unterschieden in den Namensangaben unterstützen und ihn in geeigneter Weise darauf hinweisen können [NFDM-A_2026].

Da für den Datensatz der persönlichen Erklärungen ebenfalls Versichertenstammdaten genutzt werden, gelten dort die gleichen Bedingungen (Kapitel 5.5.1)

Abbildung 14: Abb_INFO_014 element NFDM:Versicherter

element name	NFDM:Versicherter
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Stammdaten des Versicherten
Kommentar	Die Daten entsprechen in Aufbau und Verwendung den bei VSDM verwendeten Strukturen. Somit ist es möglich, bereits bestehende Verfahren zur Übernahme der Stammdaten weiterzuverwenden. Es handelt sich bei den verwendeten Stammdaten jedoch nur um eine Teilmenge der Versichertenstammdaten; es wird nicht der gesamte Umfang der VSD abgebildet. Im XSD der Notfalldaten werden die XSD-Strukturen der Versichertenstammdaten über „import“ aus einer separaten Schemadatei angezogen. Zur Vermeidung fehlerhafter Eingaben ist es empfehlenswert, bei Neuanlage des Notfalldatensatzes bzw. bei Änderung der Stammdaten diese Daten des Versicherten automatisch aus dem Primärsystem in den Notfalldatensatz zu übernehmen. Werden die Angaben zum Versicherten nicht automatisch aus den im Primärsystem abgelegten VSD übernommen, muss zusätzlich darauf geachtet werden, dass die Angaben denen des eGK-Aufdrucks entsprechen. [NFDM-A_2015, NFDM-A_2026]. NFDM-A_2015 PS: Übernahme von Stammdaten aus dem Primärsystem Das Primärsystem SOLL zur Unterstützung des Anwenders die dort bereits vorhandenen Stammdaten des Versicherten übernehmen, soweit dies für die Vorbereitung entsprechender Schreibzugriffe auf die eGK erforderlich ist (z. B. Neuanlage des Datensatzes).

3.4.1.2 element „NFDM:Versicherten_ID“

element name	NFDM:Versicherten_ID
type	NFDM:Versicherten_ID
content	simple
maxLength	10
minOccurs	1
maxOccurs	1
pattern	<xs:pattern value="[A-Z][0-9]{8}[0-9]"/>
Schlüssel-verzeichnis
Beschreibung	Die Versicherten_ID ist der 10-stellige unveränderliche Teil der 30-stelligen Krankenversichertennummer.
Kommentar	Beschreibung des Aufbaus unter Verwendung von [gemSysL_VSDM]: 1. Stelle: Alpha-Zeichen (Wertebereich A - Z, ohne Umlaute), 2. bis 9. Stelle: 8-stellige lfd. Zählnummer (Eine Ziffernfolge, in der mehr als drei gleiche Ziffern hintereinander auftreten, ist auszuschließen), 10. Stelle: Prüfziffer Bei Abweichungen anderer Datenfelder der VSD des Versicherten von denen des Notfalldatensatzes ist die Versicherten_ID die einzige sichere Identifikationsquelle.

3.4.1.3 element „NFDM:Geburtsdatum“

element name	NFDM:Geburtsdatum
Type	ISO8601Date
Content	Simple
maxLength
minOccurs	1
maxOccurs	1
Pattern	YYYYMMDD
Schlüssel-verzeichnis	ISO-8601 (für Datumsformatierung), als Grundlage
Beschreibung	Zur Identifikation des Versicherten notwendige Information.
Kommentar	Änderungsvorlage entsprechend: ftp://ftp.kbv.de/ita-update/Abrechnung/KBV_ITA_VGEX_Datensatzbeschreibung_KVDT.pdf, Version 5.05, 21.10.2014, FK 3103 Geburtsdaten in der Form YYYYMM00, YYYY0000 und 00000000 sind mögliche Eingabewerte, da unvollständige Geburtsdaten nicht ausgeschlossen werden können.

3.4.1.4 Element „NFDM:Vorname“

element name	NFDM:Vorname
Type	string
Content	simple
maxLength	45
minOccurs	1
maxOccurs	1
Pattern
Schlüssel-verzeichnis
Beschreibung	Zur Identifikation des Versicherten notwendige Information.
Kommentar	NFDM-A_2026 PS: Prüfung der Namensangaben der eGK im Vergleich zum Notfalldatensatz Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Notfalldatensatz den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen. Eine Abweichung zwischen den Namensangaben der eGK (Aufdruck) und den NFD-Namensangaben ist nicht zulässig.

3.4.1.5 element „NFDM:Nachname“

element name	NFDM:Nachname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Zur Identifikation des Versicherten notwendige Information.
Kommentar	NFDM-A_2026 PS: Prüfung der Namensangaben der eGK im Vergleich zum Notfalldatensatz Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Notfalldatensatz den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen. Eine Abweichung zwischen den Namensangaben der eGK (Aufdruck) und den NFD-Namensangaben ist nicht zulässig.

3.4.1.6 element „NFDM:Vorsatzwort“

element name	NFDM:Vorsatzwort
type	string
content	simple
maxLength	20
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	z.B. „von“, „da silva“, „van den“. Mehrere Vorsatzwörter werden durch Leerzeichen getrennt angegeben.

3.4.1.7 element „NFDM:Namenszusatz“

element name	NFDM:Namenszusatz
type	string
content	simple
maxLength	20
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	z.B. „Freifrau“, „Junker“, „Gräfin“. Mehrere Namenzusätze werden durch Leerzeichen getrennt angegeben.

3.4.1.8 element „NFDM:Titel“

element name	NFDM:Titel
type	string
content	simple
maxLength	20
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Akademischer Grad des Versicherten.
Kommentar	Mehrere Titel werden durch Leerzeichen getrennt angegeben.

3.4.1.9 element „NFDM:Geschlecht“

element name	NFDM:Geschlecht
type	string
content	simple
maxLength	1
minOccurs	1
maxOccurs	1
pattern	M,W, D oder X (VSDM nur A-Z, Prüfung nicht im XSD)
Schlüssel-verzeichnis
Beschreibung
Kommentar	Angleichung an eMP/AMTS

Die Redundanz der Stammdaten des Versicherten zwischen den VSD und den NFD/DPE ist nicht vermeidbar, denn der Aspekt der Patientensicherheit überwiegt die Aspekte der Redundanzfreiheit; vgl. hierzu [Arbeitskonzept_Bundesärztekammer#3.3 Beschreibung der notfallrelevanten medizinischen Information], Seite 21.

3.4.2 Ebene 3: element „NFD_Behandelnder_Arzt_Institution“

Abbildung 15: Abb_INFO_015 element NFD_Behandelnder_Arzt

element name	NFD_Behandelnder_Arzt_Institution
type
content	complex
maxLength
minOccurs	0
maxOccurs	3
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Verwendung ist optional. Es können die Angaben des Primärsystems verwendet werden. Werden Angaben zum behandelnden Arzt gemacht, müssen Daten zum Nachnamen des Arztes sowie als Kommunikationsinformation mindestens eine Telefonnummer erfasst werden. [NFDM-A_2022] NFDM-A_2022 PS: Verbindlichkeit von Informationen zu Personendaten (behandelnder Arzt) Werden Angaben zum behandelnden Arzt (BAI_Art = Arzt) erfasst, MUSS das Primärsystem sicherstellen, dass der Nachname des Arztes sowie mindestens eine Telefonnummer erfasst werden.

3.4.2.1 attribute „BAI_Art“

attribute name	BAI_Art
type	string
use	required
pattern	Arzt\|Institution
Beschreibung
Kommentar	NFDM-A_2139 PS: PS: Vorbelegung bei BAI_Art = Arzt Wenn ‚BAI_Art’ = „Arzt“, dann MÜSSEN ‚NFD_BAI_Arzt_Nachname’ und ‚NFD_BAI_Kommunikation’ erfasst werden . NFDM-A_2140 PS: PS: Vorbelegung bei BAI_Art = Institution Wenn ‚BAI_Art’ = „Institution“, dann SOLL ‚NFD_BAI_Institution_Bezeichnung’ zusätzlich zum Nachnamen und der Kommunikation erfasst werden . Mit der Unterscheidung kann eine entsprechende Vorbelegung im Primärsystem gesteuert werden.

3.4.2.2 element „NFD_BAI_Arzt_Nachname“

element name	NFD_BAI_Arzt_Nachname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Nachname des Arztes, der (sich selbst) als behandelnder Arzt einträgt.
Kommentar

3.4.2.3 element „NFD_BAI_Arzt_Vorname“

element name	NFD_BAI_Arzt_Vorname
type	string
content	simple
maxLength	45
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Vorname des Arztes, der (sich selbst) als behandelnder Arzt einträgt.
Kommentar

3.4.2.4 element „NFD_BAI_Institution_Bezeichnung“

element name	NFD_BAI_Institution_Bezeichnung
type	string
content	simple
maxLength	45
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Bezeichnung einer Institution, z. B. auch Krankenhausname.
Kommentar

3.4.2.5 element „NFD_BAI_Arzt_Bezeichnung“

element name	NFD_BAI_Arzt_Bezeichnung
type	string
content	simple
maxLength	45
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Fachrichtung des Arztes
Kommentar

3.4.2.6 Ebene 4: element „NFD_BAI_Adresse“

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.4.2.7 Ebene 4: element „NFD_BAI_Kommunikation“

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.4.3 Ebene 3: element „NFD_Benachrichtigungskontakt“

Abbildung 16: Abb_INFO_016 element NFD_Benachrichtigungskontakt

element name	NFD_Benachrichtigungskontakt
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Verwendung ist optional. Es können die Angaben des Primärsystems verwendet werden. Werden Angaben zum Benachrichtigungskontakt gemacht, müssen Daten zu Bezeichnung und Nachnamen des Kontakts sowie als Kommunikationsinformation mindestens eine Telefonnummer erfasst werden. [NFDM-A_2023] NFDM-A_2023 PS: Verbindlichkeit von Informationen zu Personendaten (Benachrichtigungskontakt) Werden Angaben zum Benachrichtigungskontakt erfasst, MUSS das Primärsystem sicherstellen, dass Bezeichnung und Nachname des Kontakts erfasst werden. NFDM-A_2021 PS: Verbindlichkeit von Kommunikationsdaten für Notfalldatensatz Wenn Kommunikationsdaten für einen Notfalldatensatz angelegt oder Kommunikationsdaten eines bestehenden Notfalldatensatzes geändert werden, MUSS das Primärsystem sicherstellen, dass mindestens eine Telefonnummer erfasst wird.

3.4.3.1 element „NFD_BK_Bezeichnung“

element name	NFD_BK_Bezeichnung
type	string
content	simple
maxLength	50
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Bezeichnung des Kontakts, z. B. Tochter.
Kommentar

3.4.3.2 element „NFD_BK_Nachname“

element name	NFD_BK_Nachname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.4.3.3 element „NFD_BK_Vorname“

element name	NFD_BK_Vorname
type	string
content	simple
maxLength	45
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.4.3.4 element „NFD_BK_Kommunikation“

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.4.4 Ebene 3: element „NFD_Versicherter_Kommunikation“

Abbildung 17: Abb_INFO_017 element NFD_Versicherter_Kommunikation

3.4.4.1 element „NFD_Versicherter_Kommunikation“

element name	NFD_Versicherter_Kommunikation
type	NFD_Kommunikationsdaten
content
maxLength
minOccurs	0
maxOccurs	3
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.4.4.2 Ebene 4: element „NFD_Versicherter_Kommunikation“

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.5 Ebene 2: element „NFD_Versicherter_Einwilligung“

Abbildung 18 Abb_INFO_018 element NFD_Versicherter_Einwilligung

element name	NFD_Versicherter_Einwilligung
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Angaben zur Einwilligung des Versicherten in die Nutzung der Notfalldaten.
Kommentar	Zieht der Versicherte seine Einwilligung in die Anlage und Nutzung der Notfalldaten zurück, ist der Notfalldatensatz zu löschen. Hierbei sind jedoch rechtliche Vorgaben in Bezug auf die Dokumentationspflicht des Arztes zu beachten, so dass der Datensatz dem Anwender nicht mehr zur unmittelbaren Verfügung steht und die Verarbeitung der Daten im Primärsystem des Anwender eingeschränkt wird. Somit sind sie nur noch für den vorgesehenen Zweck des rechtlichen Nachweises nutzbar. Dies ist bei der Implementierung zu beachten. [NFDM-A_2035] NFDM-A_2035 PS: Sperrung von NFD bei Widerruf der Einwilligung Das Primärsystem MUSS bei Widerruf der Einwilligung durch den Versicherten sicherstellen, dass der Notfalldatensatz im Rahmen der Löschung der Notfalldaten im Primärsystem des Arztes abgelegt und dort die Verarbeitung gemäß § 35 Abs. 3 BDSG i.V.m. Artikel 18 DSGVO eingeschränkt wird.

3.5.1 Ebene 2: element „NFD_Versicherter_Einwilligung“

3.5.1.1 element „NFD_VE_Arzt_Nachname“

element name	NFD_VE_Arzt_Nachname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Name des Arztes, bei dem die Erklärung der Einwilligung zur Nutzung der NFD auf eGK erteilt wurde.
Kommentar

3.5.1.2 element „NFD_VE_Arzt_Vorname“

element name	NFD_VE_Arzt_Vorname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.5.2 Ebene 3: element „NFD_VE_Adresse“

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6 Ebene 2: element „NFD_Befunddaten“

Abbildung 19: Abb_INFO_019 element NFD_Befunddaten

element name	NFD_Befunddaten
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Gesamtheit der Befunddaten des Versicherten.
Kommentar

3.6.1 Ebene 3: element „Besondere_Hinweise“

Abbildung 20: Abb_INFO_020 element Besondere_Hinweise

element name	Besondere_Hinweise
type	Besondere_Hinweise
content	Complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.6.1.1 Ebene 4: element „Schwangerschaft“

Abbildung 21: Abb_INFO_021 element Schwangerschaft

element name	Schwangerschaft
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Angabe dieser Befunddaten ist optional. Werden Daten erfasst, ist die Angabe der Schwangerschaft verpflichtend.

3.6.1.1.1 element „Entbindungstermin_errechnet“

element name	Entbindungstermin_errechnet
type	date
content	simple
maxLength
minOccurs	0
maxOccurs	1
pattern	YYYYMMDD
Schlüssel-verzeichnis	ISO-8601 (für Datumsformatierung)
Beschreibung
Kommentar	Das Primärsystem sollte einen entsprechenden Hinweis ausgeben, falls beim Lesen des Notfalldatensatzes festgestellt wird, dass der errechnete Termin bereits überschritten ist. Der NFD sollte daraufhin vom Arzt aktualisiert werden.

3.6.1.1.2 element „Schwangerschaft“

element name	Schwangerschaft
type	boolean
content	simple
maxLength
minOccurs	1
maxOccurs	1
pattern	0\|1
Schlüssel-verzeichnis
Beschreibung
Kommentar	0 = keine Angabe 1 = ja Eine Schwangerschaft kann nicht zwingend ausgeschlossen werden, wenn kein „ja“ gegeben ist. Insofern ist nur die Auswahl „keine Angabe“ zulässig. Angleichung an eMP/AMTS

3.6.1.1.3 Ebene 5: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6.1.2 Ebene 4: element „Implantate“

Abbildung 22: Abb_INFO_022 element Implantate

element name	Implantate
type
content	Complex
maxLength
minOccurs	0
maxOccurs	10
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Zahnärztliche Implantate werden nicht erfasst. Die Angabe dieser Befunddaten ist optional. Werden Daten erfasst, ist die Angabe der Implantate verpflichtend.

3.6.1.2.1 element „Datum_Implantation“

element name	Datum_Implantation
type	string
content	Simple
maxLength	15
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Das Datumsfeld muss es ermöglichen, auch frei wählbare Angaben, z. B. „Anfang 2015“ oder „April 1999“ zu erfassen. Deshalb ist eine feste Formatierung im ISO-Format leider nicht durchsetzbar. Empfehlung ist, die ISO8601 zu nutzen

3.6.1.2.2 element „Implantate“

element name	Implantate
type	String
content	Simple
maxLength	50
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Mit Implantaten sind in den Körper eingepflanzte künstliche oder aus anderen Geweben bestehende Materialien einschließlich Endoprothesen und ggf. auch Exoprothesen (z.B. Herzschrittmacher einschl. Defibrillatoren, Stents, tiefe Hirnstimulatoren, Kunstherzen, Portkatheter, Cochlea- und Retinaimplantate, gelenkersetzende Implantate) sowie in Neuro- und Unfallchirurgie zur Rekonstruktion verwendete Materialien gemeint.

3.6.1.2.3 element „Typenbezeichnung“

element name	Typenbezeichnung
type	string
content	simple
maxLength	60
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Ergänzende Informationen zu Implantaten.
Kommentar

3.6.1.2.4 Ebene 5: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6.1.3 Ebene 4: element „Kommunikationsstoerungen“

Abbildung 23: Abb_INFO_023 element Kommunikationsstoerungen

element name	Kommunikationsstoerungen
type
content	complex
maxLength
minOccurs	0
maxOccurs	3
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Angabe dieser Befunddaten ist optional. Werden Daten erfasst, ist die Angabe der Kommunikationsstörung verpflichtend.

3.6.1.3.1 element „Kommunikationsstoerung“

element name	Kommunikationsstoerung
type	string
content	simple
maxLength	50
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Ablage von Diagnosen oder Symptomen, die auf eine Einschränkung der Kommunikationsfähigkeit des Patienten hinweisen.
Kommentar	Angabe z.B. von Presbyakusis oder Demenz.

3.6.1.3.2 Ebene 5: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6.1.4 Ebene 4: element „Weglaufgefaehrdung“

Abbildung 24: Abb_INFO_024 element Weglaufgefaehrdung

element name	Weglaufgefaehrdung
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Angabe dieser Befunddaten ist optional. Werden Daten erfasst, sind alle Angaben der Weglaufgefährdung verpflichtend.

3.6.1.4.1 element „Weglaufgefaehrdung“

element name	Weglaufgefaehrdung
type	string
content	simple
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Hinweis auf Episoden aus der Vorgeschichte des Versicherten, in denen er oder sie sich einer Eigengefährdung aussetzte, indem er oder sie sich ohne ausreichende räumliche, zeitliche, situative oder die eigene Person betreffende Orientierung vom Aufenthaltsort entfernte.
Kommentar	0 = keine Angabe 1 = ja

3.6.1.4.2 element „Weglaufgefaehrdung_Erlaeuterung“

element name	Weglaufgefaehrdung_Erlaeuterung
type	string
content	simple
maxLength	175
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Eintrag über die näheren Umstände, in denen der Versicherte sich der Eigengefährdung durch Weglaufen ausgesetzt hat.
Kommentar

3.6.1.4.3 Ebene 5: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6.1.5 Ebene 4: element „Sonstige_Hinweise“

Abbildung 25: Abb_INFO_025 element Sonstige_Hinweise

element name	Sonstige_Hinweise
type
content	complex
maxLength
minOccurs	0
maxOccurs	3
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Angabe dieser Befunddaten ist optional. Werden Daten erfasst, ist die Angabe sonstiger Hinweise verpflichtend.

3.6.1.5.1 element „sonstige_Hinweise“

element name	sonstige_Hinweise
type	string
content	simple
maxLength	175
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Freitextfeld für beliebige medizinische Informationen, die durch den Arzt als notfallrelevant identifiziert sind und gesetzt werden.
Kommentar

3.6.1.5.2 Ebene 5: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6.2 Ebene 3: element „Allergien_Unvertraeglichkeiten"

Abbildung 26: Abb_INFO_026 element Allergien_Unvertraeglichkeiten

element name	Allergien_Unvertraeglichkeiten
type
content	complex
maxLength
minOccurs	0
maxOccurs	10
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Angabe dieser Befunddaten ist optional.

3.6.2.1 element „Substanz“

element name	Substanz
type	string
content	simple
maxLength	50
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Freitextfeld zur Erfassung von Informationen zu Fertigarzneimitteln oder Wirkstoffen oder sonstigen Inhaltsstoffen aus Arzneimitteln, auf die allergisch reagiert wird.
Kommentar	Weitere Allergieformen, die nicht auf Arzneimittel (Fertigarzneimittel, Wirkstoffe und sonstige Inhaltsstoffe) zurückzuführen sind, werden hier nicht erfasst.

3.6.2.2 element „Reaktion“

element name	Reaktion
type	string
content	simple
maxLength	75
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Freitextfeld zur Schilderung der Symptome, die als allergische Reaktion auf die angeführten Substanzen, Fertigarzneimittel oder Wirk- und Inhaltsstoffe auftreten.
Kommentar

3.6.2.3 Ebene 4: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.6.3 Ebene 3: element „Diagnosen“

Abbildung 27: Abb_INFO_027 element Diagnosen

element name	Diagnosen
type
content	complex
maxLength
minOccurs	0
maxOccurs	20
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Jede einzutragende Diagnose muss über einen beschreibenden Text verfügen. Wird ein Code_System verwendet, z. B. ICD-10, dann kann auf die im Primärsystem vorhandenen Informationen zurückgegriffen werden. Hierbei sind jedoch ggf. die Längenbeschränkungen auf Grund der Größe des element „Diagnose_Text“ zu berücksichtigen. Wird der im Primärsystem vorhandene Text übernommen und verwendet, dann darf das element „Diagnose_Text“ nicht mehr durch den Arzt überschrieben werden [NFDM-A_2027]. Damit sollen Ungenauigkeiten verhindert werden, ohne jedoch grundsätzlich auszuschließen, dass der Arzt die Information auch ohne Verwendung eines Code-Systems eingeben kann. NFDM-A_2027 PS: Kein überschreiben von automatisiert erfassten Diagnosetexten Das Primärsystem MUSS sicherstellen, dass nach automatisierter Übernahme eines Diagnosetextes (unter Verwendung der entsprechenden Diagnose_Code-Vorgaben) eine manuelle Änderung dieser Information durch den Arzt nicht mehr möglich ist, ohne dass die gesamte Diagnoseinformation erneut erfasst wird.

3.6.3.1 element „Diagnose_Code“

element name	Diagnose_Code
type	string
content	simple
maxLength	10
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis	Bei ICD-10 z.B. „F13.07“
Beschreibung	Codes des verwendeten Diagnose_Code_Systems.
Kommentar	Die Angabe eines Code-Systems ist optional. Wird jedoch ein Code-System verwendet, dann muss dieses Feld gefüllt werden. Wird der Diagnose_Code aus einem System übernommen, darf das Feld „Diagnose_Text“ nicht mehr für Anwendereingaben zugänglich sein. Der zum Code gehörende Text wird vom System im Feld „Diagnose_Text“ abgelegt.

3.6.3.2 element „Diagnose_Text“

element name	Diagnose_Text
type	string
content	simple
maxLength	255
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Inhaltsangabe des verwendeten Diagnose_Codes bzw. Freitexteingabe, wenn kein Codiersystem verwendet wird.
Kommentar	Die textuelle Beschreibung kann sehr umfangreich sein. Ggf. ist hier einzukürzen.

3.6.3.3 element „Diagnose_Zeitpunkt“

element name	Diagnose_Zeitpunkt
type	string
content	simple
maxLength	15
minOccurs	0
maxOccurs	1
pattern	Empfehlung: YYYY-MM-DD
Schlüssel-verzeichnis	Empfehlung: ISO-8601 (für Datumsformatierung)
Beschreibung	Der Arzt trägt in diesem Feld das Datum der Diagnose ein.
Kommentar	Auf Grund der Vielzahl der Möglichkeiten der Datumsabbildung (YYYYMMDD, Quartalsangaben, einfache Jahreszahl, usw.) ist es nicht möglich, eine Formatierungsvorgabe in Anlehnung an die ISO8601 zu machen. Die Angabe eines Diagnosedatums kann, da lange zurückliegend, nicht immer als präzises Datum erwartbar sein. Damit es dem Arzt möglich ist, auch unformatierte Daten wie z.B. „Q3/1999“ oder „September 2014“ einzugeben, wurde auf eine ISO-kompatible Vorgabe verzichtet. Soweit es die Umsetzung im Primärsystem zulässt, lautet die Empfehlung für die Ablage des Datums im Datensatz „YYYY-MM-DD“. Die Darstellung im Primärsystem ist davon nicht betroffen.

3.6.3.4 element „Diagnosesicherheit“

element name	Diagnosesicherheit
type	string
content	simple
maxLength	1
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis	OID = 1.2.276.0.76.3.1.1.5.1.21
Beschreibung	Die Diagnosesicherheit gibt an, wie sicher eine gestellte Diagnose ist. Es handelt sich hier um Zusatzkennzeichen zur Diagnose (ICD-10), die vorwiegend im ambulanten Bereich verwendet werden.
Kommentar	Code und Bezeichnung: A = ausgeschlossen G = gesicherte Diagnose V = Verdacht auf/zum Ausschluss von Z = Zustand nach

3.6.3.5 element „Seitenlokalisation“

element name	Seitenlokalisation
type	string
content	simple
maxLength	1
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis	OID = 1.2.276.0.76.3.1.1.5.1.22
Beschreibung	Angaben zur Lokalisation (Seitigkeit - links, rechts, beidseitig) von Erkrankungen. Zusatzangabe zur Spezifikation der Diagnosen (ICD-10) oder Operationen und Prozeduren (OPS) bei paarigen Organen oder Körperteilen.
Kommentar	Code und Bezeichnung: B = beiderseits L = links R = rechts

3.6.3.6 Ebene 4: element „Diagnose_Code_System“

Abbildung 28: Abb_INFO_028 element Diagnose_Code_System

element name	Diagnose_Code_System
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar
attribute name	DC_Version
type	string
use	optional
Beschreibung
Kommentar	Angabe einer Versionierung möglich, falls sich diese Information nicht aus dem verwendeten Code-System selbst ergibt.

3.6.3.6.1 element „Kennzeichen_Code_System“

element name	Kennzeichen_Code_System
type	string
content	simple
maxLength	15
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis	z.B. ICD-10-GM-2012 ID = 1.2.276.0.76.5.409
Beschreibung	Internationale Klassifikation der Krankheiten und verwandter Gesundheitsprobleme (ICD), 10. Revision, German Modification ICD-10-GM Version 2012 DIMDI, BMG
Kommentar	Wird ein Code-System genutzt, ist dieses Feld auszufüllen. Die OID für das ICD-10-System ändert sich in Abhängigkeit vom Objekt selbst, d.h. die OID für 2011 ist abweichend von der für 2012 usw. (Quelle: http://www.dimdi.de und Suche nach „ICD-10“)

3.6.3.6.2 Ebene 4: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 „Wiederverwendbare Elemente“.

3.7 Ebene 2: element „NFD_Medikationseintrag“

Abbildung 29: Abb_INFO_029 element NFD_Medikationseintrag

element name	NFD_Medikationseintrag
type
content	complex
maxLength
minOccurs	0
maxOccurs	20
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Angabe der Medikationsdaten ist optional. Es kann pro Mediationseintrag entweder eine Medikation oder eine Rezeptur erfasst werden. Die separate Freitextzeile des eMP wird im NFD nicht verwendet. Hinweis: Es ist darauf zu achten, dass die Einzelinformationen des Datensatzes so erfasst bzw. bereitgestellt werden, dass der am Ende auf der eGK abgelegte XML-Satz auch für die auslesende Seite bereits – soweit möglich – vollumfänglich existiert, z. B. die Angabe eines Handelsnamens (Feld „a“) auch bei Angabe der PZN (Feld „p“). Ungeachtet der Tatsache, dass ein auslesendes Primärsystem diese Informationen aus der eigenen Datenbank bereitstellen könnte, muss auch für den Versicherten beim Auslesen seines NFD im Rahmen von AdV die Gesamtinformation vorhanden sein. Befüllung/Format: Falls für eine Medikation eine PZN angegeben ist, müssen auch alle über die PZN aus einer Arzneimitteldatenbank ableitbaren Attribute (inklusive Wirkstoffe) angegeben werden. Die Inhalte müssen dann entweder der Arzneimitteldatenbank entsprechen oder sind vom Anwender anders zu belegen.

NFDM-A_2381 - Technisches Informationsmodell Relevanz "Validitätskriterium"

Das Fachmodul NFDM MUSS die im Dokument gemSpec_InfoNFDM im Modell "Technisches Informationsmodell für notfallrelevante medizinische Informationen" als "Validitätskriterium" hinterlegten annotations umsetzen.
[<=]

3.7.1 Ebene 3: element „diagnostiziert_indiziert“

Die Beschreibung des Elements befindet sich in Kapitel 3.9 “Wiederverwendbare Elemente“.

3.7.2 Ebene 2: element „M“

Abbildung 30: Abb_INFO_030 element M

element name	M
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Medikation
Kommentar	Es muss mindestens ein Attribut oder Wirkstoffe angegeben sein.

Die Medikationseinträge folgen der Codierungsvorlage aus eMP/AMTS; es sind jedoch einige attributes nicht zur Verwendung im NFD vorgesehen.

Beschreibungen folgen den Einträgen im Datenmodell des eMP/AMTS.

Die folgenden attributes sind Bestandteil des NFD:

attribute name	p
type	int
name	Modifizierte PZN
use	optional
minInclusive	1
maxInclusive	99999999
Beschreibung	Pharmazentralnummer einer Fertigarzneimittelpackung
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: nach Code-System in Attribut ps

attribute name	ps
type	string
name	Code-System PZN
use	optional
fixed	BMP v2.5, Kap 8.3.1, Tab 3
minLength	1
maxLength	30

Beschreibung	Code-System für die PZN
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: BMP v2.5, Kapitel 8.3.1, Tabelle 3, fixed Validitätskriterium: Falls das Attribut p angegeben ist, muss auch das Attribut ps angegeben werden. Falls das Attribut p nicht angegeben ist, darf das Attribut ps nicht angegeben werden.

attribute name	a
type	string
name	Arzneimittelname
use	optional
minLength	1
maxLength	50
Beschreibung	Freitextliche Bezeichnung eines Fertigarzneimittels
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext

attribute name	f
type	string
name	Darreichungsform Code
use	optional
Length	3
pattern	[A-Z]{3}
Beschreibung	Darreichungsform als IFA Code
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: nach Code-System in Attribut fs Validitätskriterium: Die Attribute f und fd dürfen nicht gleichzeitig angegeben werden.

attribute name	fs
type	string
name	Darreichungsform Code-System
use	optional
fixed	1.2.276.0.76.3.1.1.5.2.40
minLength	1
maxLength	30
Beschreibung	Code-System für die Darreichungsform
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: OID, BMP v2.5, Anhang 3, fixed Validitätskriterium: Falls das Attribut f angegeben ist, muss auch das Attribut fs angegeben werden. Falls das Attribut f nicht angegeben ist, darf das Attribut fs nicht angegeben werden.

attribute name	fd
type	string
name	Darreichungsform Freitext
use	optional
minLength	1
maxLength	7
Beschreibung	Beschreibung: Darreichungsform als Freitext, entweder definiert oder fehlend (dann bei Ausdruck ggf. aus PZN abgeleitet)
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext Validitätskriterium: Die Attribute f und fd dürfen nicht gleichzeitig angegeben werden.

attribute name	m
type	NFD:dosierungTyp
name	Dosierschema morgens
use	optional
minLength	1
maxLength	4
pattern	([1-9]\d{0,3})\|([1-9]\d,\d)\|(\d,\d{1,2})\|1/8\|1/2\|2/3\|1/3\|1/4\|3/4
Beschreibung	Dosierung als 4-teiliges Schema (morgens)
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Wenn nicht angegeben = "0" Validitätskriterium: Die Attribute m und t dürfen nicht gleichzeitig angegeben werden.

attribute name	d
type	NFD:dosierungTyp
name	Dosierschema mittags
use	optional
minLength	1
maxLength	4
pattern	([1-9]\d{0,3})\|([1-9]\d,\d)\|(\d,\d{1,2})\|1/8\|1/2\|2/3\|1/3\|1/4\|3/4
Beschreibung	Dosierung als 4-teiliges Schema (mittags)
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Wenn nicht angegeben = "0" Validitätskriterium: Die Attribute m und t dürfen nicht gleichzeitig angegeben werden.

attribute name	v
type	NFD:dosierungTyp
name	Dosierschema abends
use	optional
minLength	1
maxLength	4
pattern	([1-9]\d{0,3})\|([1-9]\d,\d)\|(\d,\d{1,2})\|1/8\|1/2\|2/3\|1/3\|1/4\|3/4
Beschreibung	Dosierung als 4-teiliges Schema (abends)
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Wenn nicht angegeben = "0" Validitätskriterium: Die Attribute m und t dürfen nicht gleichzeitig angegeben werden.

attribute name	h
type	NFD:dosierungTyp
name	Dosierschema zur Nacht
use	optional
minLength	1
maxLength	4
pattern	([1-9]\d{0,3})\|([1-9]\d,\d)\|(\d,\d{1,2})\|1/8\|1/2\|2/3\|1/3\|1/4\|3/4
Beschreibung	Dosierung als 4-teiliges Schema (zur Nacht)
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Wenn nicht angegeben = "0" Validitätskriterium: Die Attribute m und t dürfen nicht gleichzeitig angegeben werden.

attribute name	t
type	string
name	Dosierschema Freitext
use	optional
minLength	1
maxLength	20
Beschreibung	Freitextdosierung
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext Validitätskriterium: Das Attribut t darf nicht gleichzeitig mit den Attributen m, d, v und h angegeben werden.

attribute name	du
type	string
name	Dosiereinheit strukturiert
use	optional
pattern	[#0-9a-v]
Beschreibung	Dosiereinheit kodiert lt. Anhang 4 des BMP, Version 2.5 (http://applications.kbv.de/keytabs/ita/schluesseltabellen.asp)
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: nach Code-System in Attribut dus Validitätskriterium: Die Attribute du und dud dürfen nicht gleichzeitig angegeben werden.

attribute name	dus
type	string
name	Dosiereinheit Code-System
use	optional
fixed	1.2.276.0.76.3.1.1.5.2.41
minLength	1
maxLength	30
Beschreibung	Code-System der Dosiereinheit
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: OID, BMP v2.5, Anhang 4, fixed Validitätskriterium: Falls das Attribut du angegeben ist, muss auch das Attribut dus angegeben werden. Falls das Attribut du nicht angegeben ist, darf das Attribut dus nicht angegeben werden.

attribute name	dud
type	string
name	Dosiereinheit Freitext
use	optional
minLength	2
maxLength	20
Beschreibung	Dosiereinheit als Freitext
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext Validitätskriterium: Die Attribute du und dud dürfen nicht gleichzeitig angegeben werden.

attribute name	i
type	string
name	Hinweise
use	optional
minLength	1
maxLength	80
Beschreibung	Hinweise zur Anwendung, Lagerung, Einnahme, etc
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext, maximal ein manueller Umbruch kann mit einer Tilde ("~") gekennzeichnet werden Validitätskriterium: Das Attribut i darf nicht mehr als ein Tildezeichen enthalten ("~").

3.7.3 Ebene 3: element „W“

Abbildung 31: Abb_INFO_031 element W

element name	W
type
content	complex
maxLength
minOccurs	0
maxOccurs	n
pattern
Schlüssel-verzeichnis
Beschreibung	Wirkstoff/-stärke
Kommentar	Validitätskriterium: Falls das Attribut p angegeben ist, muss mindestens ein Element W mit den Attributen w und (s oder gwe) angegeben werden.

Die folgenden attributes sind Bestandteil des NFD:

attribute name	w
type	string
name	Wirkstoff
use	required
minLength	1
maxLength	80
Beschreibung	Bezeichnung eines Wirkstoffes
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext

attribute name	s
type	string
name	Wirkstärke Freitext
use	optional
minLength	1
maxLength	15
Beschreibung	Bezeichnung der Wirkstärke
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: Freitext Validitätskriterium: Die Attribute s und gwe dürfen nicht gleichzeitig angegeben werden.

attribute name	gwe
type	string
name	Wirkstärke strukturiert
use	optional
minLength	1
maxLength	15
Beschreibung	Strukturierte Darstellung einer Wirkstärke
Kommentar	Angleichung an eMP/AMTS Befüllung/Format: [Wirkstoffmenge mit Wirkstoffmengeneinheit]/[Bezugsgrößenmenge mit Bezugsgrößenmengeneinheit] z.B. „5mg/1ml“ Validitätskriterium: Die Attribute s und gwe dürfen nicht gleichzeitig angegeben werden

3.7.4 Ebene 3: element „R“

Abbildung 32: Abb_INFO_033 element R

element name	R
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Rezeptur
Kommentar	Angleichung an eMP/AMTS

Das folgende Feld wird im NFD verwendet.

attribute name	t
type	string
name	Rezeptur
use	optional
Beschreibung	Rezeptur
Kommentar	Angleichung an eMP/AMTS Beschreibung: Text ohne Bezug zu einem Medikationseintrag Befüllung/Format: Freitext, maximal 1 manueller Umbruch kann mit einer Tilde ("~") gekennzeichnet werden Validitätskriterium: Das Attribut t darf nicht mehr als 1 Tildezeichen enthalten ("~").

3.8 Ebene 2: element „NFD_Freiwillige_Zusatzinformationen“

Abbildung 33: Abb_INFO_034 element NFD_Freiwillige_Zusatzinformationen

element name	NFD_Freiwillige_Zusatzinformationen
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Zusätzliche Angaben auf Wunsch des Versicherten.
Kommentar

3.8.1 element „Freiwillige_Zusatzinformationen“

element name	Freiwillige_Zusatzinformationen
type	string
content	simple
maxLength	100
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9 Wiederverwendbare Elemente

Die folgende type „NFD_Adresse“ wird an unterschiedlichen Stellen des Notfalldatensatzes verwendet. Die Beschreibung erfolgt aus Gründen der Übersichtlichkeit nur einmal.

3.9.1 element „NFD_BAI_Adresse“

element name	NFD_BAI_Adresse
type	NFD_Adresse
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Adressdaten des behandelnden Arztes bzw. der Institution und des Ortes der Erteilung der Einwilligung des Versicherten.
Kommentar	Es werden keine Adressdaten des Versicherten abgelegt. Die Einwilligung des Versicherten bezieht sich bei Notfalldaten immer auf den Ort des Leistungserbringers, bei dem die Einwilligung des Versicherten erteilt wurde.

3.9.1.1 element „NFDM:Postleitzahl“

element name	NFDM:Postleitzahl
type	string
content	simple
maxLength	10
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.1.2 element „NFDM:Ort“

element name	NFDM:Ort
type	string
content	simple
maxLength	40
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.1.3 element „NFDM:Strasse“

element name	NFDM:Strasse
type	string
content	simple
maxLength	46
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.1.4 element „NFDM:Hausnummer“

element name	NFDM:Hausnummer
type	string
content	simple
maxLength	9
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.1.5 element „NFDM:Anschriftenzusatz“

element name	NFDM:Anschriftenzusatz
type	string
content	simple
maxLength	40
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.1.6 element „NFDM:Wohnsitzlaendercode“

element name	NFDM:Wohnsitzlaendercode
type	string
content	simple
maxLength	3
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.2 element „NFD_BAI_Kommunikation“

element name	NFD_BAI_Kommunikation
type	NFD_Kommunikationsdaten
content	complex
maxLength
minOccurs	1
maxOccurs	3
pattern
Schlüssel-verzeichnis
Beschreibung	Kommunikationsdaten des behandelnden Arztes bzw. der Institution.
Kommentar	Werden Angaben zu Kommunikationsdaten gemacht, ist es erforderlich, dass zumindest eine Telefonnummer angegeben wird. Optional sind E-Mail und Faxnummer. [NFDM-A_2021]. NFDM-A_2021 PS: Verbindlichkeit von Kommunikationsdaten für Notfalldatensatz Wenn Kommunikationsdaten für einen Notfalldatensatz angelegt oder Kommunikationsdaten eines bestehenden Notfalldatensatzes geändert werden, MUSS das Primärsystem sicherstellen, dass mindestens eine Telefonnummer erfasst wird.

3.9.2.1 element „NFDM:Telefonnummer“

element name	NFDM:Telefonnummer
type	string
content	simple
maxLength	25
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.2.2 element „NFDM:Faxnummer“

element name	NFDM:Faxnummer
type	string
content	simple
maxLength	25
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.2.3 element „NFDM:E-Mail“

element name	NFDM:E-Mail
type	string
content	simple
maxLength	40
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.3 element „diagnostiziert_indiziert“

Abbildung 34: Abb_INFO_035 element diagnostiziert_indiziert

element name	diagnostiziert_indiziert
type	Diagnose_Indikation
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Für jeden Eintrag in den Notfalldaten, der das element „diagnostiziert_indiziert“ beinhaltet, kann eine Information abgelegt werden. Diese Information wird als Dokumentation eines Fremdeintrages (Befund) bzw. einer Fremdindikation (Arzneimittel) gewertet. Wird der Notfalldatensatz neu angelegt, ist diese Angabe optional. Werden weitere Einträge zum Notfalldatensatz erfasst, können die Daten des Arztes, der aktuell den Datensatz bearbeitet, vom Primärsystem übernommen und angezeigt werden (sofern diese Informationen vorliegen) [NFDM-A_2024]. Liegen bei der Anzeige des Feldes von der eGK bereits Daten vor, so sind diese anzuzeigen. NFDM-A_2024 PS: Vorbefüllung des elements "diagnostiziert_indiziert" mit Daten des Primärsystems. Wenn ein Notfalldatensatz angelegt wird, der das element "diagnostiziert_indiziert" beinhaltet, KANN das Primärsystem die entsprechenden Daten des bearbeitenden Arztes bereitstellen und anzeigen. Wird ein bereits angelegter Notfalldatensatz, der diese Informationen enthält, in den entsprechend zutreffenden Details geändert, kann der ändernde Arzt diese Angaben überschreiben [NFDM-A_2084]. NFDM-A_2084 PS: Änderung des elements "diagnostiziert_indiziert" mit Daten des Primärsystems. Wenn ein Notfalldatensatz, der von der eGK gelesen wurde, geändert wird, SOLL das Primärsystem es ermöglichen, dass der den Notfalldatensatz aktuell bearbeitende Arzt bereits vorhandene Informationen des elements "diagnostiziert_indiziert" mit seinen Angaben überschreiben kann.

attribute name	DI_Art
type	string
use	required
pattern	Arzt\|Institution
Beschreibung	Typus des Diagnosestellers
Kommentar

3.9.3.1 element „DI_Arzt“

Abbildung 35: Abb_INFO_036 element DI_Arzt

element name	DI_Arzt
type	DI_Arzt
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.3.1.1 element „DI_Arzt_Name“

element name	DI_Arzt_Name
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Belegung für dieses element kann aus den Daten des Primärsystems übernommen werden, sofern diese Angaben vorliegen.

3.9.3.1.2 element „DI_Arzt_Fachgebiet“

element name	DI_Arzt_Fachgebiet
type	String
content	Simple
maxLength	35
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	z.B. Onkologie Die Belegung für dieses element kann aus den Daten des Primärsystems übernommen werden, sofern diese Angaben vorliegen.

3.9.3.1.3 element „DI_Arzt_Ort“

element name	DI_Arzt_Ort
type	string
content	simple
maxLength	40
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Belegung für dieses element kann aus den Daten des Primärsystems übernommen werden, sofern diese Angaben vorliegen.

3.9.3.2 element „DI_Institution“

Abbildung 36: Abb_INFO_037 element DI_Institution

element name	DI_Institution
type	DI_Institution
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

3.9.3.2.1 element „DI_Institution_Name“

element name	DI_Institution_Name
type	string
content	simple
maxLength	75
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Belegung für dieses element kann aus den Daten des Primärsystems übernommen werden, sofern diese Angaben vorliegen.

3.9.3.2.2 element „DI_Institution_Fachabteilung“

element name	DI_Institution_Fachabteilung
type	string
content	simple
maxLength	3540
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	z.B. Onkologie Die Belegung für dieses element kann aus den Daten des Primärsystems übernommen werden, sofern diese Angaben vorliegen.

3.9.3.2.3 element „DI_Institution_Ort“

element name	DI_Institution_Ort
type	string
content	simple
maxLength	40
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Belegung für dieses element kann aus den Daten des Primärsystems übernommen werden, sofern diese Angaben vorliegen.

4 Signaturdaten

Die für den Notfalldatensatz erforderlichen Signaturdaten werden in einem Element abgelegt, das sich auf den Notfalldatensatz bezieht. Zu jedem Notfalldatensatz gehört genau ein Signaturdatensatz.

4.1 Ebene 1: element „SignatureArzt“

Abbildung 37: Abb_INFO_038 element SignatureArzt

element name	SignatureArzt
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Kommentar
Beschreibung	Signaturinformationen zu medizinisch relevanten Informationen für den Notfall.

4.2 Kurzbeschreibung der Signatur

Die folgenden Hinweise sind informativer Natur.

Eine wesentliche Vorgabe an das System „Notfalldaten-Management“ ist der Einsatz einer qualifizierten elektronischen Signatur, die jedoch nur für die Notfalldaten erforderlich ist. Die Daten der persönlichen Erklärungen hingegen, dürfen vom Arzt nicht mit einer Signatur versehen werden [NFDM-A_114, NFDM-A_167].

Für den Notfalldatensatz wird eine detached-Signatur nach dem Verfahren XAdES benötigt. Sie wird vom Konnektor erzeugt; das Element „SignatureArzt“ wird hierfür an den Konnektor leer übergeben. Das Primärsystem stellt sicher, dass dieses Feld ungefüllt an den Konnektor geht.

Signaturen werden bei Signaturvorgängen des NFD immer neu erstellt, somit kann es jeweils nur eine gültige Signatur des NFD geben.

Der Signaturvorgang muss abgeschlossen sein bevor die Operation „WriteNFD“ des Fachmoduls ausgeführt werden kann.

Im Zuge der Erstellung des NFD durch den Arzt ist es erforderlich, dass dem Arzt sämtliche signaturrelvanten, medizinischen Daten angezeigt werden bevor der Signaturprozess abschließend durchgeführt wird.

Es ist nicht erforderlich, dass der Signatur- und der Schreibvorgang auf der eGK unmittelbar aufeinanderfolgen. Es ist im Gegenteil sicherzustellen, dass der eigentliche Schreibvorgang auf der eGK des Versicherten zeitlich und räumlich getrennt von der Signaturerstellung erfolgen kann. Somit ist es dann auch der Mitarbeiterin der medizinischen Institution (Sprechstundehilfe) möglich, den vom Arzt bereitgestellten und signierten NFD endgültig auf die eGK des Versicherten zu schreiben. Damit ist der Arzt entlastet und ist nicht notwendigerweise gezwungen, den Schreibvorgang selbst durchzuführen [NFDM-A_113].

5 XML-Schema (XSD) des Datensatzes persönlicher Erklärungen

5.1 Einleitung

Für das XML-Schema des Datensatzes der persönlichen Erklärungen des Versicherten gelten die folgenden Randbedingungen:

XSD-Vorgaben zu übergreifenden Elementen werden über einen „import“ angezogen. Diese Elemente werden sowohl für den Notfalldatensatz als auch für den Datensatz persönlicher Erklärungen genutzt und haben der Präfix „NFDM“. Es handelt sich hierbei um
- NFDM:Adresse
- NFDM:Versicherter
Elemente, deren Bedeutung identisch ist, die jedoch sowohl im Notfalldatensatz als auch im Datensatz persönlicher Erklärungen verwendet werden, sind am entsprechenden Präfix (NFD_ bzw. DPE_ ) zu erkennen.
Die Zeichenkodierung des XSD für den Datensatz persönlicher Erklärungen erfolgt nach ISO 8859-15

siehe: NFDM-A_2080 - PS: Zeichenkodierung in ISO 8859-15

Der Aufbau des XML-Schemas für die persönlichen Erklärungen des Versicherten ist auf insgesamt 4 Ebenen aufgebaut.

Abbildung 38: Abb_INFO_039 Ebenen der DPE

5.2 Randbedingungen

Im Unterschied zu den Notfalldaten werden die Daten der persönlichen Erklärungen des Versicherten nicht vom Arzt signiert. Dessen ungeachtet ist bis zur Einführung der AdV nur der Arzt selbst in der Lage, die Daten der persönlichen Erklärungen entsprechend dem Wunsch des Versicherten anzulegen bzw. entsprechend zu ändern, auszulesen
oder zu löschen.

Wenn der Versicherte im Rahmen eines Arztbesuchs seine Notfalldaten oder seine Daten zu persönlichen Erklärungen bearbeiten lassen möchte bzw. der Arzt die Notfalldaten einsehen möchte, gelten folgende Regeln, die durch das Primärsystem umzusetzen sind:

Beim Aufruf oder einer Bearbeitung der Daten der persönlichen Erklärungen dürfen niemals gleichzeitig auch die Notfalldaten der eGK des Versicherten ausgelesen und angezeigt werden. [NFDM-A_2039]

NFDM-A_2039 - PS: Verbot des automatischen Lesens und Anzeige von DPE zusammen mit NFD

Das Primärsystem MUSS sicherstellen, dass Daten persönlicher Erklärungen des Versicherten nicht automatisch und in einer Aktion zusammen mit Notfalldaten ausgelesen und angezeigt werden.
[<=]

Die einzelnen Erklärungsarten können unabhängig voneinander gelesen oder bearbeitet werden. Auch hier muss bei der Umsetzung darauf geachtet werden, dass die Vorgänge wieder unabhängig von den Notfalldaten zu halten sind. Es muss darüber hinaus auch eine getrennte Bearbeitung der Erklärungsarten möglich sein [NFDM-A_2038]

NFDM-A_2038 - PS: Separate Behandlung der Erklärungen zu DPE

Das Primärsystem MUSS die Möglichkeit der separaten Durchführung der Anlage, Änderung, Nutzung und Löschung von Daten persönlicher Erklärungen des Versicherten unabhängig von der Art der Erklärungen und unabhängig vom Notfalldatensatz sicherstellen.
[<=]

Es ist nicht zulässig, die Daten der persönlichen Erklärungen automatisch und unmittelbar nach dem Stecken der eGK des Versicherten auszulesen oder anzuzeigen [NFDM-A_2331].

NFDM-A_2331 - PS: Verbot des automatischen Lesens und Anzeigens der DPE bei Stecken der eGK

Das Primärsystem MUSS sicherstellen, dass Daten persönlicher Erklärungen beim Stecken der eGK des Versicherten nicht automatisch ausgelesen oder angezeigt werden.
[<=]

Beim Schreiben des DPE ist zu beachten, dass die einzelnen Erklärungsarten nie separat sondern nur als gesamter Datensatz schreibbar sind und immer nur in einem Container vorliegen.

Die DPE verfügen über eine separate Einwilligung. Die Einwilligung aus dem NFD ist nicht ausreichend, da der Versicherte auch ohne NFD über DPE verfügen kann.

Die Anmerkungen, die im Zusammenhang mit den Stammdaten des Versicherten bei NFD (Kapitel 3.4.1.1) gelten, sind auch für die DPE zu berücksichtigen.

5.3 Ebene 0: root element „DPE_Document“

Abbildung 39: Abb_INFO_040 root element DPE_Document

element name	DPE_Document
type
content	complex
maxLength
minOccurs
maxOccurs
pattern
Schlüssel-verzeichnis
Beschreibung	Gesamtheit der persönlichen Erklärungen des Versicherten. Die Informationen hierzu sind nur Verweise auf Ablageorte. Es werden keine rechtlich verbindlichen Dokumente gespeichert.
Kommentar

attribute name	DPE_Version
type	string
use	required
Beschreibung	Information über die Version des Datensatzes.
Kommentar

5.4 Ebene 1: element „Persoenliche Erklaerungen“

Abbildung 40: Abb_INFO_041 element Persoenliche Erklaerungen

element name	Persoenliche Erklaerungen
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Informationen über Erklärungen des Versicherten, die nicht medizinisch notfallrelevant sind.
Kommentar

attribute name	DPE_letzte_Aktualisierung
type	date
use	required
Beschreibung	Information über Datum des letzten, schreibenden Zugriffs auf die DPE der eGK
Kommentar

attribute name	ID_DPE
type	string
fixed	1.2.276.0.76.7.9
use	required
Beschreibung	Identifier in der gematik-Objektnomenklatur
Kommentar	Angleichung an eMP/AMTS

attribute name	DPE_letzte_Aktualisierung_time
type	time
use	required
Beschreibung	Information die Zeit des letzten schreibenden Zugriffs auf die DPE der eGK
Kommentar	Der Schreibvorgang wird nach den Vorgaben des [gemSpec_FM_NFDM#6] „WriteDPE“ durchgeführt. Es kann immer nur ein Datensatz zu DPE auf der eGK vorhanden sein. Angleichung an eMP/AMTS

attribute name	DPE_letzte_Aktualisierung_date
type	date
use	required
Beschreibung	Information über das Datum des letzten schreibenden Zugriffs auf die DPE der eGK
Kommentar	Der Schreibvorgang wird nach den Vorgaben des [gemSpec_FM_NFDM#6] „WriteDPE“ durchgeführt. Es kann immer nur ein Datensatz zu DPE auf der eGK vorhanden sein.

5.5 Ebene 2: element „DPE_Versicherter“

diagram

Abbildung 41: Abb_INFO_042 element DPE_Versicherter

element name	DPE_Versicherter
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Gesamtheit der Verwaltungsdaten des Versicherten.
Kommentar	Die Formatierung ist identisch zu den Angaben in NFD.

5.5.1 Ebene 3: element NFDM:Versicherter

Das Element wird aus dem Schema „NFDM_Common.xsd“ angezogen.

Abbildung 42: Abb_INFO_043 element NFDM:Versicherter

element name	NFDM:Versicherter
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Stammdaten des Versicherten
Kommentar	Die Daten entsprechen in Aufbau und Verwendung den bei VSDM verwendeten Strukturen. Somit ist es möglich, bereits bestehende Verfahren zur Übernahme der Stammdaten weiterzuverwenden. Es handelt sich bei den verwendeten Stammdaten jedoch nur um eine Teilmenge der Versichertenstammdaten; es wird nicht der gesamte Umfang der VSD abgebildet. Im XSD der DPE werden die XSD-Strukturen der Versichertenstammdaten über „import“ aus einer separaten Schemadatei angezogen. Zur Vermeidung fehlerhafter Eingaben ist es empfehlenswert, bei Neuanlage des Datensatzes der persönlichen Erklärungen bzw. bei Änderung der Stammdaten diese Daten des Versicherten automatisch aus dem Primärsystem in den DPE zu übernehmen. Werden die Angaben zum Versicherten nicht automatisch aus den im Primärsystem abgelegten VSD übernommen, muss darauf geachtet werden, dass die Angaben denen des eGK-Aufdrucks entsprechen. [NFDM-A_2015] NFDM-A_2015 PS: Übernahme von Stammdaten aus dem Primärsystem Das Primärsystem SOLL zur Unterstützung des Anwenders die dort bereits vorhandenen Stammdaten des Versicherten übernehmen, soweit dies bei entsprechenden Schreibzugriffen auf die eGK erforderlich ist (z.B. Neuanlage des Datensatzes).

5.5.1.1 element „NFDM:Versicherten_ID“

element name	NFDM:Versicherten_ID
type	NFDM:Versicherten_ID
content	simple
maxLength	10
minOccurs	1
maxOccurs	1
pattern	<xs:pattern value="[A-Z][0-9]{8}[0-9]"/>
Schlüssel-verzeichnis
Beschreibung	Die Versicherten_ID ist der 10-stellige unveränderliche Teil der 30-stelligen Krankenversichertennummer.
Kommentar	Beschreibung des Aufbaus unter Verwendung von [gemSysL_VSDM]: 1. Stelle: Alpha-Zeichen (Wertebereich A - Z, ohne Umlaute), 2. bis 9. Stelle: 8-stellige lfd. Zählnummer (Eine Ziffernfolge, in der mehr als drei gleiche Ziffern hintereinander auftreten, ist auszuschließen), 10. Stelle: Prüfziffer Bei Abweichungen anderer Datenfelder der VSD des Versicherten von denen des Notfalldatensatzes ist die Versicherten_ID die einzige sichere Identifikationsquelle.

5.5.1.2 element „NFDM:Geburtsdatum“

element name	NFDM:Geburtsdatum
Type	date
Content	simple
maxLength
minOccurs	1
maxOccurs	1
Pattern	YYYYMMDD
Schlüssel-verzeichnis	ISO-8601 (für Datumsformatierung), als Grundlage
Beschreibung	Zur Identifikation des Versicherten notwendige Information.
Kommentar	Änderungsvorlage entsprechend: ftp://ftp.kbv.de/ita-update/Abrechnung/KBV_ITA_VGEX_Datensatzbeschreibung_KVDT.pdf, Version 5.05, 21.10.2014, FK 3103 Geburtsdaten in der Form YYYYMM00, YYYY0000 und 00000000 sind mögliche Eingabewerte, da unvollständige Geburtsdaten nicht ausgeschlossen werden können.

5.5.1.3 element „NFDM:Vorname“

element name	NFDM:Vorname
Type	string
Content	simple
maxLength	45
minOccurs	1
maxOccurs	1
Pattern
Schlüssel-verzeichnis
Beschreibung	Zur Identifikation des Versicherten notwendige Information.
Kommentar	NFDM-A_2138 PS: Prüfung der Namensangaben der eGK im Vergleich zum Datensatz persönlicher Erklärungen Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Datensatz persönlicher Erklärungen den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen. Eine Abweichung zwischen den Namensangaben der eGK (Aufdruck) und den DPE-Namensangaben ist nicht zulässig.

5.5.1.4 element „NFDM:Nachname“

element name	NFDM:Nachname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Zur Identifikation des Versicherten notwendige Information.
Kommentar	NFDM-A_2138 PS: Prüfung der Namensangaben der eGK im Vergleich zum Datensatz persönlicher Erklärungen Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Datensatz persönlicher Erklärungen den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen. Eine Abweichung zwischen den Namensangaben der eGK (Aufdruck) und den DPE-Namensangaben ist nicht zulässig.

5.5.1.5 element „NFDM:Vorsatzwort“

element name	NFDM:Vorsatzwort
type	string
content	simple
maxLength	20
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	z.B. „von“, „da silva“, „van den“. Mehrere Vorsatzwörter werden durch Leerzeichen getrennt angegeben.

5.5.1.6 element „NFDM:Namenszusatz“

element name	NFDM:Namenszusatz
type	string
content	simple
maxLength	20
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	z.B. „Freifrau“, „Junker“, „Gräfin“. Mehrere Namenzusätze werden durch Leerzeichen getrennt angegeben.

5.5.1.7 element „NFDM:Titel“

element name	NFDM:Titel
type	string
content	simple
maxLength	20
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Akademischer Grad des Versicherten.
Kommentar	Mehrere Titel werden durch Leerzeichen getrennt angegeben.

5.5.1.8 element „NFDM:Geschlecht“

element name	NFDM:Geschlecht
type	string
content	simple
maxLength	1
minOccurs	1
maxOccurs	1
pattern	M,W oder X (VSDM nur A-Z, Prüfung nicht im XSD)
Schlüssel-verzeichnis
Beschreibung
Kommentar	Angleichung an eMP/AMTS

5.6 Ebene 2: element „DPE_Versicherter_Einwilligung“

Abbildung 43 Abb_INFO_044 element DPE_Versicherter_Einwilligung

element name	DPE_Versicherter_Einwilligung
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Zieht der Versicherte seine Einwilligung in die Anlage und Nutzung der Daten persönliche Erklärungen zurück, ist der Datensatz komplett zu löschen. Eine Aufteilung in die unterschiedlichen Typen der Erklärungen ist nicht zulässig. In der Umgebung eines Leistungserbringers ist es erforderlich, dass das Primärsystem die Anlage der Einwilligung durchsetzt; eine verpflichtende Anlage (mandatory) kann vom Datenmodell nicht vorgesehen werden, da Umgebungen zu Wahrung der Versichertenrechte (AdV) die Anlage einer Einwilligung nicht erfordern.

5.6.1 element „DPE_VE_Arzt_Nachname“

element name	DPE_VE_Arzt_Nachname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.6.2 element „DPE_VE_Arzt_Vorname”

element name	DPE_VE_Arzt_Vorname
type	string
content	simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.6.3 element „DPE_VE_Ablageort”

element name	DPE_VE_Ablageort
type	DPE_Adresse
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der type DPE_Adresse ist in seinem Aufbau identisch mit dem bereits für NFD definierten Adresstypen. Der type ist in Kapitel 3.9 „Wiederverwendbare Elemente“ beschrieben.
Kommentar	Die Einwilligung ist in der Umgebung des Leistungserbringers die Voraussetzung für die Anlage von Daten der persönlichen Erklärungen. Sie darf nicht vom Datensatz getrennt werden.

5.7 Ebene 2: element „DPE_Gewebe_Organspendeerklaerung“

Abbildung 44: Abb_INFO_045 element DPE_Gewebe_Organspendeerklaerung

element name	DPE_Gewebe_Organspendeerklaerung
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Hinterlegung eines Hinweises auf den Ablageort einer Gewebe- bzw. Organspendeerklärung ist freiwillig für den Versicherten. Wird eine entsprechende Erklärung gegeben, ist eine kurze Beschreibung beizufügen.

attribute name	DPE_GO_letzte_Aktualisierung
type	date
use	required
Beschreibung
Kommentar

5.7.1 element „DPE_GO_Beschreibung”

element name	DPE_GO_Beschreibung
type	string
content	simple
maxLength	200
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der Versicherte wird befragt, z.B. „Falls Sie eine Erklärung zur Organ- und Gewebespende ausgefüllt haben – wo bewahren Sie diese auf?“ (Zitat aus [Arbeitskonzept_Bundesärztekammer], Seite 20)
Kommentar	„Anm.: Der Hinweis auf den Ablageort einer Organ- und Gewebespendeerklärung sagt nichts über den Inhalt dieser Erklärung aus. Es ist z.B. möglich, dass die Information auf der eGK auf eine schriftliche Erklärung hinweist, in welcher der Patient erklärt, dass er eine Organ- und Gewebespende ablehnt.“ (Zitat aus [Arbeitskonzept_Bundesärztekammer], Seite 20)

5.7.2 element „DPE_GO_Ablageort”

element name	DPE_GO_Ablageort
type	DPE_Adresse
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der type DPE_Adresse ist in seinem Aufbau identisch mit dem bereits für NFD definierten Adresstypen. Der type ist in Kapitel 3.9 „Wiederverwendbare Elemente“ beschrieben.
Kommentar	Der Ablageort ist eine freiwillige Angabe, da hier die Adresse des Versicherten angegeben werden kann.

5.8 Ebene 2: element „DPE_Vorsorgevollmacht“

Abbildung 45: Abb_INFO_046 element DPE_Vorsorgevollmacht

element name	DPE_Vorsorgevollmacht
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Hinterlegung eines Hinweises auf den Ablageort einer Vorsorgevollmachtserklärung ist freiwillig für den Versicherten. Wird eine entsprechende Erklärung gegeben, ist eine kurze Beschreibung beizufügen.

5.8.1.1 element „DPE_Vorsorgevollmacht“

attribute name	DPE_VV_letzte_Aktualisierung
type	date
use	required
Beschreibung
Kommentar

5.8.1.2 element „DPE_VV_Beschreibung”

element name	DPE_VV_Beschreibung
type	string
content	simple
maxLength	200
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der Versicherte wird befragt, z.B. “Falls Sie eine Vorsorge-Vollmacht ausgefüllt haben – wo bewahren Sie diese auf und wer ist als Betreuer genannt?“ (Zitat aus [Arbeitskonzept_Bundesärztekammer], Seite 21)
Kommentar	“Anm.: Der Hinweis auf eine Vorsorge-Vollmacht sagt nichts über den Regelungsbereich dieser Erklärung aus.” (Zitat aus [Arbeitskonzept_Bundesärztekammer], Seite 21)

5.8.1.3 element „DPE_VV_Ablageort”

element name	DPE_VV_Ablageort
type	DPE_Adresse
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der type DPE_Adresse ist in seinem Aufbau identisch mit dem bereits für NFD definierten Adresstypen. Der type ist in Kapitel 3.9 „Wiederverwendbare Elemente“ beschrieben.
Kommentar

5.8.2 Ebene 3: element DPE_VV_Bevollmaechtigter

Abbildung 46: Abb_INFO_047 element DPE_VV_Bevollmaechtigter

element name	DPE_VV_Bevollmaechtigter
type
content	complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.8.2.1 element „DPE_VV_E-Mail”

element name	DPE_VV_E-Mail
type	string
content	simple
maxLength	40
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.8.2.2 element „DPE_VV_Faxnummer”

element name	DPE_VV_Faxnummer
type	string
content	simple
maxLength	25
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.8.2.3 element „DPE_VV_Name_Bevollmaechtigter”

element name	DPE_VV_Name_Bevollmaechtigter
type	String
content	Simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.8.2.4 element „DPE_VV_Vorname_Bevollmaechtigter”

element name	DPE_VV_Vorname_Bevollmaechtigter
type	String
content	Simple
maxLength	45
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.8.2.5 element „DPE_VV_Telefon_Bevollmaechtigter”

element name	DPE_VV_Telefon_Bevollmaechtigter
type	String
content	Simple
maxLength	25
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar

5.8.2.6 element „DPE_VV_Adresse_Bevollmaechtigter”

element name	DPE_VV_Adresse_Bevollmaechtigter
type	DPE_Adresse
content	Complex
maxLength
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der type DPE_Adresse ist in seinem Aufbau identisch mit dem bereits für NFD definierten Adresstypen. Der type ist in Kapitel 3.9 „Wiederverwendbare Elemente“ beschrieben.
Kommentar

5.9 Ebene 2: element „DPE_Patientenverfuegung“

Abbildung 47: Abb_INFO_048 element DPE_Patientenverfuegung

element name	DPE_Patientenverfuegung
type
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung
Kommentar	Die Hinterlegung eines Hinweises auf den Ablageort einer Patientenverfügungserklärung ist freiwillig für den Versicherten. Wird eine entsprechende Erklärung gegeben, ist eine kurze Beschreibung beizufügen.

attribute name	DPE_PV_letzte_Aktualisierung
type	date
use	required
Beschreibung
Kommentar

5.9.1 element „DPE_PV_Ablageort”

element name	DPE_PV_Ablageort
type	DPE_Adresse
content	complex
maxLength
minOccurs	0
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der type DPE_Adresse ist in seinem Aufbau identisch mit dem bereits für NFD definierten Adresstypen. Der type ist in Kapitel 3.9 „Wiederverwendbare Elemente“ beschrieben.
Kommentar

5.9.2 element „DPE_PV_Beschreibung”

element name	DPE_PV_Beschreibung
type	string
content	simple
maxLength	200
minOccurs	1
maxOccurs	1
pattern
Schlüssel-verzeichnis
Beschreibung	Der Versicherte wird befragt, z.B. „Falls Sie eine Patienten-Verfügung ausgefüllt haben – wo bewahren Sie diese auf?“ (Zitat aus [Arbeitskonzept_Bundesärztekammer], Seite 20)
Kommentar	„Anm.: Der Hinweis auf eine Patientenverfügung sagt nichts über den Inhalt dieser Erklärung aus.“ (Zitat aus [Arbeitskonzept_Bundesärztekammer], Seite 20)

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

Abkürzung	Bedeutung
AdV	Anwendungen des Versicherten
AMTS	Arzneimitteltherapiesicherheit
BMP	Bundeseinheitlicher Medikationsplan
DPE	Datensatz persönliche Erklärung
eGK	elektronische Gesundheitskarte
eMP	elektronischer Medikationsplan
NFD	Notfalldatensatz
NFDM	Notfalldatenmanagement
PIN	Personal Identification Number
PS	Primärsystem
PZN	Pharmazentralnummer
VSD	Versichertenstammdaten
VSDM	Versichertenstammdatenmanagement
XML	Extensible Markup Language
XSD	Extensible Schema Definition

6.2 Glossar

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

6.3 Abbildungsverzeichnis

Abbildung 1: Abb_INFO_001 Ablauf der Anlage für Notfalldaten
Abbildung 2: Abb_INFO_002 Technisches Informationsmodell für notfallrelevante medizinische Informationen
Abbildung 3: Abb_INFO_003 Technisches Informationsmodell für persönliche Erklärungen
Abbildung 4: Abb_INFO_004 Ebenen 0 bis 2 des XSD
Abbildung 5: Abb_INFO_005 Ebene 2 bis 4 des XSD (Versicherter)
Abbildung 6: Abb_INFO_006 Ebene 2 bis 3 des XSD (Einwilligung)
Abbildung 7: Abb_INFO_007 Ebene 2 bis 6 des XSD (Befunddaten - Hinweise)
Abbildung 8: Abb_INFO_008 Ebene 2 bis 4 des XSD (Befunddaten - Allergien)
Abbildung 9: Abb_INFO_009 Ebene 2 bis 4 des XSD (Befunddaten - Diagnosen)
Abbildung 10: Abb_INFO_010 Ebene 2 bis 4 des XSD (Medikationsdaten)
Abbildung 11: Abb_INFO_011 root element NFD_Document
Abbildung 12: Abb_INFO_012 element Notfalldaten
Abbildung 13: Abb_INFO_013 element NFD_Versicherter
Abbildung 14: Abb_INFO_014 element NFDM:Versicherter
Abbildung 15: Abb_INFO_015 element NFD_Behandelnder_Arzt
Abbildung 16: Abb_INFO_016 element NFD_Benachrichtigungskontakt
Abbildung 17: Abb_INFO_017 element NFD_Versicherter_Kommunikation
Abbildung 18 Abb_INFO_018 element NFD_Versicherter_Einwilligung
Abbildung 19: Abb_INFO_019 element NFD_Befunddaten
Abbildung 20: Abb_INFO_020 element Besondere_Hinweise
Abbildung 21: Abb_INFO_021 element Schwangerschaft
Abbildung 22: Abb_INFO_022 element Implantate
Abbildung 23: Abb_INFO_023 element Kommunikationsstoerungen
Abbildung 24: Abb_INFO_024 element Weglaufgefaehrdung
Abbildung 25: Abb_INFO_025 element Sonstige_Hinweise
Abbildung 26: Abb_INFO_026 element Allergien_Unvertraeglichkeiten
Abbildung 27: Abb_INFO_027 element Diagnosen
Abbildung 28: Abb_INFO_028 element Diagnose_Code_System
Abbildung 29: Abb_INFO_029 element NFD_Medikationseintrag
Abbildung 30: Abb_INFO_030 element M
Abbildung 31: Abb_INFO_031 element W
Abbildung 32: Abb_INFO_033 element R
Abbildung 33: Abb_INFO_034 element NFD_Freiwillige_Zusatzinformationen
Abbildung 34: Abb_INFO_035 element diagnostiziert_indiziert
Abbildung 35: Abb_INFO_036 element DI_Arzt
Abbildung 36: Abb_INFO_037 element DI_Institution
Abbildung 37: Abb_INFO_038 element SignatureArzt
Abbildung 38: Abb_INFO_039 Ebenen der DPE
Abbildung 39: Abb_INFO_040 root element DPE_Document
Abbildung 40: Abb_INFO_041 element Persoenliche Erklaerungen
Abbildung 41: Abb_INFO_042 element DPE_Versicherter
Abbildung 42: Abb_INFO_043 element NFDM:Versicherter
Abbildung 43 Abb_INFO_044 element DPE_Versicherter_Einwilligung
Abbildung 44: Abb_INFO_045 element DPE_Gewebe_Organspendeerklaerung
Abbildung 45: Abb_INFO_046 element DPE_Vorsorgevollmacht
Abbildung 46: Abb_INFO_047 element DPE_VV_Bevollmaechtigter
Abbildung 47: Abb_INFO_048 element DPE_Patientenverfuegung

6.4 Tabellenverzeichnis

Tabelle 1: informative Liste der Eingangsanforderungen
Tabelle 2 informative Liste der Ausgangsanforderungen

6.5 Referenzierte Dokumente

6.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 passende jeweils gültige Versionsnummer sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

[Quelle]	Herausgeber (Erscheinungsdatum): Titel
[gemGlossar]	gematik: Glossar der Telematikinfrastruktur
[gemLH_NFDM]	Projektteam NFDM: Lastenheft Notfalldaten-Management
[gemSysL_NFDM]	gematik: Systemspezifisches Konzept Notfalldaten-Management (NFDM)
[gemSpec_Kon]	gematik: Spezifikation Konnektor
[gemSpec_FM_NFDM]	gematik: Spezifikation Fachmodul NFDM

6.5.2 Weitere Dokumente

[Quelle]	Herausgeber (Erscheinungsdatum): Titel
[Diagnose_HL7_Implementierung]	Darstellung von Diagnosen auf Basis der HL7 Clinical Document Architecture Rel. 2 für das deutsche Gesundheitswesen, Implementierungsleitfaden, Version 1.1 Dokumenten-OID: 1.2.276.0.76.7.4
[gemLH_NFDM]	Projekt NFDM: Lastenheft Notfalldaten-Management (NFDM)
[VHitG_Arztbrief_V1.5]	Implementierungsleitfaden Arztbrief auf Basis der HL7 Clinical Document Architecture, Release 2, für das deutsche Gesundheitswesen, Version 1.50 Vorgelegt vom VHitG Dokumenten-OID: 1.2.276.0.76.3.1.13.7.5
[VHitG_Arztbrief_V1.5_Addendum]	Addendum zum Arztbrief V1.50 auf Basis der HL7 Clinical Document Architecture, Release 2, für das deutsche Gesundheitswesen, Darstellung Medikation, Implementierungsleitfaden, Version 1 Vorgelegt vom VHitG Dokumenten-OID 1.2.276.0.76.3.1.13.7.22
[Ärzteblatt_2010]	Empfehlung der Bundesärztekammer und der Zentralen Ethikkommission bei der Bundesärztekammer zum Umgang mit Vorsorgevollmacht und Patientenverfügung in der ärztlichen Praxis.
[Medikationsplan]	Spezifikation für einen patientenbezogenen Medikationsplan. Koordinierungsgruppe zur Umsetzung und Fortschreibung des Aktionsplanes zur Verbesserung der Arzneimitteltherapiesicherheit in Deutschland Version 2.0, 15.12 2013
[Arbeitskonzept_Bundesärztekammer]	Arbeitskonzept Notfalldatenmanagement (NFDM), Version 1.05 von 2011
[Prozessbeschreibung]	Prozessbeschreibung zum Einsatz des Notfalldatenmanagements in der klinischen Praxis, Version 1.0, 2012, vorgelegt von der Bundesärztekammer
[RFC2119]	RFC 2119 (März 1997): Key words for use in RFCs to indicate Requirement Levels S. Bradner, http://www.ietf.org/rfc/rfc2119.txt

7 Anhang B

Die folgenden Tabellen stellen überblicksartig zusammen, welche Anforderungen im Dokument beschrieben wurden. Normative Geltung haben lediglich die im Text entsprechend gekennzeichneten Anforderungen.

7.1 Anforderungszusammenhang – Eingangsanforderungen

Tabelle 1: informative Liste der Eingangsanforderungen

AFO-ID	Quelle	Beschreibung	Umgesetzt durch
NFDM-A_128	[gemLH_NFDM]	Das Primärsystem MUSS es dem Benutzer ermöglichen, relevante Daten aus seiner medizinischen Dokumentation automatisch in den Notfalldatensatz zu übernehmen.	NFDM-A_2015
NFDM-A_107	[gemLH_NFDM]	Die Fachanwendung NFDM MUSS die Arbeitsabläufe zur Nutzung ihrer Daten unter Beachtung der Rahmenbedingungen des Lastenheftes NFDM (Kapitel 3) durch Sicherstellung der Benutzbarkeit bestmöglich unterstützen.	NFDM-A_2021 NFDM-A_2022 NFDM-A_2023 NFDM-A_2024 NFDM-A_2025 NFDM-A_2026 NFDM-A_2027 NFDM-A_2028 NFDM-A_2029 NFDM-A_2080 NFDM-A_2138 NFDM-A_2139 NFDM-A_2140
NFDM-A_104	[gemLH_NFDM]	Die Fachanwendung NFDM MUSS es dem Berechtigten ermöglichen, den Notfalldatensatz des Versicherten über das Primärsystem von der eGK des Versicherten zu löschen.	NFDM-A_2035
NFDM-A_174	[gemLH_NFDM]	Das Primärsystem MUSS sicherstellen, dass persönliche Erklärungen des Versicherten unabhängig voneinander und unabhängig vom Notfalldatensatz geschrieben, gelesen, geändert und gelöscht werden können.	NFDM-A_2038
NFDM-A_175	[gemLH_NFDM]	Das Primärsystem DARF NICHT persönliche Erklärungen des Versicherten automatisch (z.B. in einer Aktion zusammen mit dem Notfalldatensatz) lesen und anzeigen. (Der Benutzer muss das Lesen und Anzeigen von persönlichen Erklärungen des Versicherten explizit anfordern.)	NFDM-A_2039 NFDM-A_2331
NFDM-A_105	[gemLH_NFDM]	Die Fachanwendung NFDM MUSS das fachliche Informationsmodell für den Notfalldatensatz umsetzen.	NFDM-A_2333 NFDM-A_2381
NFDM-A_164	[gemLH_NFDM]	Die Fachanwendung NFDM MUSS das fachliche Informationsmodell für persönliche Erklärungen umsetzen.	NFDM-A_2334
NFDM-A_110	[gemLH_NFDM]	Die Fachanwendung NFDM MUSS sicherstellen, dass der Berechtigte den Notfalldatensatz des Versicherten nur auf explizite Anforderung mit Hilfe des Primärsystems von der eGK des Versicherten lesen kann.	NFDM-A_2332

7.2 Anforderungszusammenhang – Ausgangsanforderungen

Tabelle 2 informative Liste der Ausgangsanforderungen

AFO-ID	Beschreibung	erfüllt
NFDM-A_2333	Das Fachmodul NFDM MUSS das im Dokument gemSpec_InfoNFDM definierte Modell "Technisches Informationsmodell für notfallrelevante medizinische Informationen" gemäß dem XML-Schema umsetzen.	NFDM-A_105
NFDM-A_2381	Das Fachmodul NFDM MUSS die im Dokument gemSpec_InfoNFDM im Modell "Technisches Informationsmodell für notfallrelevante medizinische Informationen" als "Validitätskriterium" hinterlegten annotations umsetzen.	NFDM-A_105
NFDM-A_2334	Das Fachmodul NFDM MUSS das im Dokument gemSpec_InfoNFDM definierte Modell "Technische Informationsmodell für persönliche Erklärungen des Versicherten" gemäß dem XML-Schema umsetzen.	NFDM-A_164
NFDM-A_2015	Das Primärsystem SOLL zur Unterstützung des Anwenders die dort bereits vorhandenen Stammdaten des Versicherten übernehmen, soweit dies bei entsprechenden Schreibzugriffen auf die eGK erforderlich ist (z.B. Neuanlage des Notfalldatensatzes).	NFDM-A_128
NFDM-A_2021	Wenn Kommunikationsdaten für einen Notfalldatensatz angelegt oder Kommunikationsdaten eines bestehenden Notfalldatensatzes geändert werden, MUSS mindestens eine Telefonnummer erfasst werden.	NFDM-A_107
NFDM-A_2022	Werden Angaben zum behandelnden Arzt (BAI_Art = Arzt) erfasst, MUSS das Primärsystem sicherstellen, dass der Nachname des Arztes sowie mindestens eine Telefonnummer erfasst werden.	NFDM-A_107
NFDM-A_2023	Werden Angaben zum Benachrichtigungskontakt erfasst, MUSS das Primärsystem sicherstellen, dass Bezeichnung und Nachname des Kontakts erfasst wird.	NFDM-A_107
NFDM-A_2024	Wenn ein Notfalldatensatz angelegt wird, der das element "diagnostiziert_indiziert" beinhaltet, KANN das Primärsystem die entsprechenden Daten des bearbeitenden Arztes bereitstellen und anzeigen.	NFDM-A_107
NFDM-A_2026	Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Notfalldatensatz den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen.	NFDM-A_107
NFDM-A_2027	Das Primärsystem MUSS sicherstellen, dass nach automatisierter Übernahme eines Diagnosetextes (unter Verwendung der entsprechenden Diagnose_Code-Vorgaben) eine manuelle Änderung dieser Information durch den Arzt nicht mehr möglich ist, ohne dass die gesamte Diagnoseinformation erneut erfasst wird.	NFDM-A_107
NFDM-A_2035	Das Primärsystem MUSS bei Widerruf der Einwilligung durch den Versicherten sicherstellen, dass der Notfalldatensatz im Rahmen der Löschung der Notfalldaten im Primärsystem des Arztes abgelegt und dort zur weiteren Verwendung gem. § 35 Abs. 3 BDSG gesperrt wird.	NFDM-A_104
NFDM-A_2038	Das Primärsystem MUSS die Möglichkeit der separaten Durchführung der Anlage, Änderung, Nutzung und Löschung von Daten persönlicher Erklärungen des Versicherten unabhängig von der Art der Erklärungen und unabhängig vom Notfalldatensatz sicherstellen.	NFDM-A_174
NFDM-A_2039	Das Primärsystem MUSS sicherstellen, dass Daten persönlicher Erklärungen des Versicherten nicht automatisch und in einer Aktion zusammen mit Notfalldaten ausgelesen und angezeigt werden.	NFDM-A_175
NFDM-A_2080	Das Primärsystem MUSS sicherstellen, dass die Daten des Notfalldatenmanagements (NFD und DPE) nach dem Standard ISO 8859-15 kodiert und gespeichert werden.	NFDM-A_107
NFDM-A_2084	Wenn ein Notfalldatensatz, der von der eGK gelesen wurde, geändert wird, SOLL das Primärsystem es ermöglichen, dass der den Notfalldatensatz aktuell bearbeitende Arzt bereits vorhandene Informationen des elements "diagnostiziert_indiziert" mit seinen Angaben überschreiben kann.	NFDM-QUE_2001 [Prozessbeschreibung]
NFDM-A_2138	Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Datensatz persönlicher Erklärungen den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen.	NFDM-A_107
NFDM-A_2139	Wenn ‚BAI_Art’ = „Arzt“, dann MÜSSEN ‚NFD_BAI_Arzt_Nachname’ und ‚NFD_BAI_Kommunikation’ erfasst werden.	NFDM-A_107
NFDM-A_2140	Wenn ‚BAI_Art’ = „Institution“, dann SOLL ‚NFD_BAI_Institution_Bezeichnung’ zusätzlich zum Nachnamen und der Kommunikation erfasst werden.	NFDM-A_107
NFDM-A_2331	Das Primärsystem MUSS sicherstellen, dass Daten persönlicher Erklärungen beim Stecken der eGK des Versicherten nicht automatisch ausgelesen oder angezeigt werden.	NFDM-A_175
NFDM-A_2332	Das Primärsystem MUSS sicherstellen, dass Notfalldaten beim Stecken der eGK des Versicherten nicht automatisch ausgelesen oder angezeigt werden.	NFDM-A_110

NFDM-A_2015 - PS: Übernahme von Stammdaten aus dem Primärsystem

Das Primärsystem SOLL zur Unterstützung des Anwenders die dort bereits vorhandenen Stammdaten des Versicherten übernehmen, soweit dies für die Vorbereitung entsprechender Schreibzugriffe auf die eGK erforderlich ist (z.B. Neuanlage des Datensatzes). [<=]

NFDM-A_2021 - PS: Verbindlichkeit von Kommunikationsdaten für Notfalldatensatz

Wenn Kommunikationsdaten für einen Notfalldatensatz angelegt oder Kommunikationsdaten eines bestehenden Notfalldatensatzes geändert werden, MUSS das Primärsystem sicherstellen, daß mindestens eine Telefonnummer erfaßt wird. [<=]

NFDM-A_2022 - PS: Verbindlichkeit von Informationen zu Personendaten (behandelnder Arzt)

Werden Angaben zum behandelnden Arzt (BAI_Art = Arzt) erfaßt, MUSS das Primärsystem sicherstellen, daß der Nachname des Arztes sowie mindestens eine Telefonnummer erfaßt werden. [<=]

NFDM-A_2023 - PS: Verbindlichkeit von Informationen zu Personendaten (Benachrichtigungskontakt)

Werden Angaben zum Benachrichtigungskontakt erfaßt, MUSS das Primärsystem sicherstellen, daß Bezeichnung und Nachname des Kontakts erfaßt werden. [<=]

NFDM-A_2024 - PS: Vorbefüllung des elements "diagnostiziert_indiziert" mit Daten des Primärsystems.

Wenn ein Notfalldatensatz angelegt wird, der das element "diagnostiziert_indiziert" beinhaltet, KANN das Primärsystem die entsprechenden Daten des bearbeitenden Arztes bereitstellen und anzeigen. [<=]

NFDM-A_2026 - PS: Prüfung der Namensangaben der eGK im Vergleich zum Notfalldatensatz

Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Notfalldatensatz den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen. [<=]

NFDM-A_2027 - PS: Kein überschreiben von automatisiert erfaßten Diagnosetexten

Das Primärsystem MUSS sicherstellen, daß nach automatisierter Übernahme eines Diagnosetextes (unter Verwendung der entsprechenden Diagnose_Code-Vorgaben) eine manuelle Änderung dieser Information durch den Arzt nicht mehr möglich ist, ohne daß die gesamte Diagnoseinformation erneut erfaßt wird. [<=]

NFDM-A_2028 - PS: Notwendigkeit von Einheitsangaben bei Wirkstoffen

Das Primärsystem MUSS sicherstellen, daß bei der Erfassung von Wirkstoffmengen (Arzneimittel) die entsprechende Einheit ebenfalls erfaßt wird. [<=]

NFDM-A_2029 - PS: Notwendigkeit von Einheitsangaben bei Bezugsmengen

Das Primärsystem MUSS sicherstellen, daß bei der Erfassung von Bezugsmengen (Arzneimittel) die entsprechende Einheit ebenfalls erfaßt wird. [<=]

NFDM-A_2035 - PS: Sperrung von NFD bei Widerruf der Einwilligung

Das Primärsystem MUSS bei Widerruf der Einwilligung durch den Versicherten sicherstellen, daß der Notfalldatensatz im Rahmen der Löschung der Notfalldaten im Primärsystem des Arztes abgelegt und dort die Verarbeitung gemäß § 35 Abs. 3 BDSG i.V.m. Artikel 18 DSGVO eingeschränkt wird. [<=]

NFDM-A_2036 - PS: Basisfunktionalität NFD

Das Primärsystem MUSS die Anlage, Änderung, Nutzung und Löschung von Notfalldaten ermöglichen. [<=]

NFDM-A_2037 - PS: Basisfunktionalität DPE

Das Primärsystem MUSS die Anlage, Änderung, Nutzung und Löschung von Daten der persönlichen Erklärungen des Versicherten unterstützen. [<=]

NFDM-A_2084 - PS: Änderung des elements "diagnostiziert_indiziert" mit Daten des Primärsystems.

Wenn ein Notfalldatensatz, der von der eGK gelesen wurde, geändert wird, SOLL das Primärsystem es ermöglichen, daß der den Notfalldatensatz aktuell bearbeitende Arzt bereits vorhandene Informationen des elements "diagnostiziert_indiziert" mit seinen Angaben überschreiben kann. [<=]

NFDM-A_2138 - PS: Prüfung der Namensangaben der eGK im Vergleich zum Datensatz persönlicher Erklärungen

Das Primärsystem SOLL bei Änderungen zu Namensangaben des Versicherten im Datensatz persönlicher Erklärungen den Arzt auf die Notwendigkeit einer Prüfung der Namensangaben (eGK) per Augenschein hinweisen. [<=]

NFDM-A_2139 - PS: Vorbelegung bei BAI_Art = Arzt

Wenn ‚BAI_Art’ = „Arzt“, dann MÜSSEN ‚NFD_BAI_Arzt_Nachname’ und ‚NFD_BAI_Kommunikation’ erfaßt werden. [<=]

NFDM-A_2140 - PS: Vorbelegung bei BAI_Art = Institution

Wenn ‚BAI_Art’ = „Institution“, dann SOLL ‚NFD_BAI_Institution_Bezeichnung’ zusätzlich zum Nachnamen und der Kommunikation erfaßt werden. [<=]

Version	1.6.0
Revision	548770
Stand	02.03.2020
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_InfoNFDM