Elektronische Gesundheitskarte und Telematikinfrastruktur
Informationsmodell
Notfalldaten-Management (NFDM)
Version |
1. |
Revision |
|
Stand |
|
Status |
freigegeben |
Klassifizierung |
öffentlich |
Referenzierung |
gemSpec_InfoNFDM |
Dokumentinformationen
Änderungen zur Vorversion
Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
1.0.0 |
25.10.16 |
|
Basis Online-Rollout (Stufe 2.1) |
gematik |
1.1.0 |
05.10.17 |
|
Änderungen zur Anpassung an eMP/AMTS in Bezug auf die Medikationsdateneinträge (gelb) |
P73 |
1.2.0 |
15.12.17 |
|
Synchronisation mit eMP/AMTS (Übernahme der Änderungen durch BMP v2.4) und kleinere Korrekturen |
gematik |
1.3.0 |
14.05.18 |
|
Anpassung lt. P15.2 und P15.4 |
gematik |
1.4.0 |
26.10.18 |
|
Anpassung lt. P15.9 |
gematik |
1.5.0 |
28.06.19 |
|
Anpassung lt. P17.4 |
gematik |
|
|
|
Anpassung lt. P21.1 |
gematik |
1.6.0 |
02.03.20 |
|
freigegeben |
gematik |
1.7.0 |
26.08.22 |
2.1.3 |
Einarbeitung CI_Maintenance_22.4: Kapitelanpassungen durch Wegfall mehrerer spezieller gesetzlicher Rahmenbedingungen aus § 291a SGB V zur Erteilung von Einwilligung und der schriftlichen Hinterlegung dieser |
gematik |
1.5.2 Verwendung von Schlüsselworten
2.1.2 Grenzen eines XML-Schemas
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.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.9 element „NFDM:Geschlecht“
3.4.2 Ebene 3: element „NFD_Behandelnder_Arzt_Institution“
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.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.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.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.3 element „diagnostiziert_indiziert“
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.1 Ebene 1: element „SignatureArzt“
4.2 Kurzbeschreibung der Signatur
5 XML-Schema (XSD) des Datensatzes persönlicher Erklärungen
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.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”
7.1 Anforderungszusammenhang – Eingangsanforderungen
7.2 Anforderungszusammenhang – Ausgangsanforderungen
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.
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.).
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.
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.
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.
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)
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.
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 explizitgegenüber dem Leistungserbringer 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überund im Primärsystem protokolliert werden.
Die Regeln zur Erteilung rechtswirksamer Erklärungen sind nicht Gegenstand des vorliegenden Dokuments, jedoch werden im NFD und DPE die Einwilligungsinformationen abgelegt.
2.1.4 Choreographie des Notfalldatenprozesses
Die wesentlichen Schritte zur (Erst-)Anlage eines Notfalldatensatzes lassen sich überblicksartig wie folgt darstellen:
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
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
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. |
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. |
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. 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]: |
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 |
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. |
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. |
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. |
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. 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. |
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 . |
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. 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 |
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 |
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. |
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. |
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 |
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. |
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. |
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. 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. |
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. |
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: |
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: |
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 |
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. |
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. |
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“.
|
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 |
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 |
attribute name |
a |
type |
string |
name |
Arzneimittelname |
use |
optional |
minLength |
1 |
maxLength |
50 |
Beschreibung |
Freitextliche Bezeichnung eines Fertigarzneimittels |
Kommentar |
Angleichung an eMP/AMTS |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
attribute name |
t |
type |
string |
name |
Dosierschema Freitext |
use |
optional |
minLength |
1 |
maxLength |
20 |
Beschreibung |
Freitextdosierung |
Kommentar |
Angleichung an eMP/AMTS |
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 |
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 |
attribute name |
dud |
type |
string |
name |
Dosiereinheit Freitext |
use |
optional |
minLength |
2 |
maxLength |
20 |
Beschreibung |
Dosiereinheit als Freitext |
Kommentar |
Angleichung an eMP/AMTS |
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 |
|
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 |
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 |
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 |
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 |
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 |
|
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 |
|
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. 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_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 |
|
|
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 |
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 |
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. |
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
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
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. |
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. |
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.
<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:
|
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. 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]: |
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 |
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. |
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. |
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. |
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 |
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.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 |
|
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.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 |
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) |
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 |
Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.
Abbildung 1: Abb_INFO_001 Ablauf der Anlage für Notfalldaten
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
Tabelle 1: informative Liste der Eingangsanforderungen
Tabelle 2 informative Liste der Ausgangsanforderungen
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 |
[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 |
[gemLH_NFDM] |
Projekt NFDM: Lastenheft Notfalldaten-Management (NFDM) |
[VHitG_Arztbrief_V1.5] |
Implementierungsleitfaden |
[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 |
[Ä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. |
[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): |
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_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_105 |
[gemLH_NFDM] |
Die Fachanwendung NFDM MUSS das fachliche Informationsmodell für den Notfalldatensatz umsetzen. |
NFDM-A_2333 |
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 |
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. [<=]