Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Fachmodul NFDM

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
14.05.2018
     
     

      
Status
      
in Bearbeitung
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FM_NFDM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Die Einarbeitung von P15.2 und P15.4.

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die spezifischen Anforderungen für den Produkttyp „Fachmodul NFDM“.

Das Fachmodul NFDM ist diejenige Komponente der Fachanwendung NFDM, welche alle Anwendungsfälle der Fachanwendung NFDM umsetzt, die über das Primärsystem angestoßen werden. Der Funktionsumfang wird definiert durch die Leistungsmerkmale NFDM-L_1 („Basisfunktionalität NFDM (Notfalldatensatz)“) und NFDM-L_2 („Persönliche Erklärungen NFDM“) der Fachanwendung NFDM. Diese wurden in [gemLH_NFDM] und in [gemSysL_NFDM] definiert und stellen dem Primärsystem eine Grundfunktionalität zur Verwaltung von Notfalldatensätzen (NFD) und Datensätzen für persönliche Erklärungen (DPE) zur Verfügung.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller des Produkttyps „Fachmodul NFDM“ sowie Hersteller und Anbieter von Produkttypen, die hierzu eine Schnittstelle besitzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Fachmodul NFDM bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation derjenigen Komponente beschrieben, die diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang A5).

Die vollständige Anforderungslage für das Fachmodul NFDM ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Konnektors verzeichnet, da das Fachmodul integraler Bestandteil des Konnektors ist.

Das hier spezifizierte Fachmodul NFDM ist nicht für den Einsatz in mobilen Kartenterminals vorgesehen. Das Fachmodul für mobile Kartenterminals (Fachmodul NFDM-mobil) wird im Dokument [gemSpec_FM_NFDM-mobil] spezifiziert.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche innerhalb der Textmarken angeführten Inhalte.

Hinweise zur Nomenklatur:

• Schnittstellen-, Operations-, Parameter- und Dateinamen sowie Bezeichner für Objekte auf der elektronischen Gesundheitskarte (eGK), Namen der referenzierten Technischen Use Cases (TUCs) des Konnektors und Extensible-Markup-Language(XML)-Elemente oder -Attribute werden in diesem Dokument in nicht-proportionaler Schriftart gesetzt.
• Hexadezimale Zahlen und Oktett-Strings werden in Hochkommata eingeschlossen (z. B. ´2F 03´).

Bezeichner für Objekte der eGK:

Da der Name der in [gemSpec_eGK_ObjSys] definierten Objekte der eGK nur dazu dient, das Objekt innerhalb der Spezifikation zu bezeichnen, nicht auf der Karte gespeichert ist und sich zudem die Namen für die für NFDM relevanten Objekte auf der eGK zwischen Generation 1+ (G1+) und Generation 2 (G2) unterscheiden, lassen sich die Objekte eindeutig nur über deren Attribut pwdIdentifier (für Passwortobjekte), fileIdentifier (für Elementary Files (EFs)) oder applicationIdentifier (für Dedicated Files (DFs)) referenzieren. Zudem ist der übergeordnete Ordner anzugeben, da ein File Identifier (FID) /Application Identifier (AID)/Password Identifier (PID) nur innerhalb eines Ordners eindeutig sein muss. Aus Gründen der Lesbarkeit werden in dieser Spezifikation Bezeichner eingeführt, für die in der folgenden Tabelle sowohl der Name (für eGK G1+ und eGK G2) als auch der FID/AID/PID mit dem übergeordneten Ordner angegeben sind.

Tabelle 1: Verwendete Bezeichner für Objekte der eGK

Legende zu den Berechtigungstabellen:

2 Systemüberblick

Das Fachmodul NFDM ist ein Produkttyp der Fachanwendung NFDM. Die Systemzerlegung der Fachanwendung NFDM in Komponenten und Produkttypen sowie deren Verteilung auf Produkttypen der Telematikinfrastruktur (TI) ist in [gemSysL_NFDM#2.1] definiert.

Das Fachmodul NFDM nutzt die angebotenen Basisdienste (Funktionsmerkmale) des Konnektors, wobei das Fachmodul NFDM integraler Bestandteil des Konnektors (Konnektor als Monolith) ist, d. h. die Spezifikationen des Konnektors (als Plattformkomponente) und des Fachmoduls NFDM sind zwar getrennt, werden aber von einem Hersteller in einer Gesamtkomponente umgesetzt. Die inneren (rein logischen) Schnittstellen zwischen Fachmodul und Konnektor sind von außen nicht erkennbar. Die folgende Abbildung zeigt die vom Fachmodul genutzten Basisdienste (Funktionsmerkmale) des Konnektors und ordnet – wenn vorhanden – die logischen Schnittstellennamen zu.

Abbildung 1: Vom Fachmodul genutzte Basisdienste des Konnektors

Das Fachmodul NFDM stellt seine Anwendungsfälle über folgende Schnittstellen dem Primärsystem zur Verfügung:

• I_NFD_Management für das Leistungsmerkmal NFDM-L_1
• I_DPE_Management für das Leistungsmerkmal NFDM-L_2.

Die Operationen der beiden Schnittstellen bilden die Anwendungsfälle der beiden Leistungsmerkmale gemäß folgender Tabelle ab.

Tabelle 2: Abbildung NFDM-Anwendungsfälle auf Operationen des Fachmoduls NFDM

Das Fachmodul NFDM bietet zwei Primärsystemschnittstellen (I_NFD_Management und I_DPE_Management) als Web-Services (NFDService und DPEService) an, wie im folgenden UML-Diagramm dargestellt. (NFD steht für „Notfalldatensatz“, DPE für „Datensatz ‚Persönliche Erklärungen’“)

Abbildung 2: Services Fachmodul NFDM

Jeder Service wird durch ein Web-Service-Description-Language(WSDL)-Dokument und zusätzliche Anforderungen an das Verhalten der angebotenen Web-Service-Schnittstellen in Kapitel 5.12 im Detail spezifiziert.

Logisch unterteilt sich das Fachmodul NFDM somit in die beiden Services „NFDService“ und „DPEService“.

Abbildung 3: Logische Zerlegung Fachmodul NFDM

Diese logische Unterteilung schreibt in keiner Art und Weise die spätere Implementierung durch den Hersteller vor. Der Hersteller kann seine interne Modularisierung des Fachmoduls NFDM frei wählen. Normativ wirksam ist ausschließlich das durch die Detailfestlegungen in Summe beschriebene Verhalten an der Primärsystemschnittstelle des Fachmoduls NFDM als integraler Bestandteil des Konnektors.

3 Systemkontext

3.1 Akteure und Rollen

Einzige direkt mit dem Fachmodul NFDM (als integraler Bestandteil des Konnektors) kommunizierende Akteure ist eine technische Komponenten, das Primärsystem. Das Primärsystem interagiert als Clientsystem mit dem Fachmodul NFDM, gehört aber selbst nicht zur TI. Nur im jeweiligen Kontext berechtigte Primärsysteme erhalten Zugriff auf die Funktionsmerkmale des Fachmoduls NFDM (vgl. Kapitel 5.3.1).

Fachliche Akteure (Arzt, Zahnarzt usw.) rufen mittels des Primärsystems die Operationen des Fachmoduls NFDM auf, um auf die eGK zuzugreifen. Über ihre Rolle, die technisch durch das Zugriffsprofil ihrer Smartcard repräsentiert wird, erhalten die Akteure die benötigte Berechtigung zum Zugriff (vgl. auch Kapitel 5.3.2).

3.2 Nachbarsysteme

Das Fachmodul ist integraler Bestandteil des Konnektors. Auf der logischen Ebene ist somit der Anwendungskonnektor als einbettende Komponente ein Nachbarsystem. Ein weiteres Nachbarsystem stellt das Primärsystem als Nutzer der Außenschnittstelle des Fachmoduls dar.

4 Zerlegung des Produkttyps

Eine weitere Untergliederung der Aufbaustruktur des Fachmoduls NFDM ist nicht erforderlich.

Die logische Zerlegung in Kapitel 2, Abbildung 3 ist nicht normativ und keine Vorgabe für die Implementierung durch den Hersteller. Normativ festgelegt ist lediglich das Außenverhalten des Fachmoduls NFDM.

5 Übergreifende Festlegungen

5.1 Technologien und Standards

Diese Festlegungen gelten nur für die eigentliche Nachricht mittels Simple Object Access Protocol (SOAP). Sind in der SOAP-Nachricht base64-encodierte XML-Elemente vorhanden, so können diese XML-Elemente andere Zeichencodierungen aufweisen.

5.2 Statusrückmeldung und Fehlerbehandlung

Tritt bei der Ausführung einer Operation des Fachmoduls ein Fehler auf, der  zum Abbruch der Operation führt, so wird dieser an das aufrufende Primärsystem über eine SOAP-Fault-Nachricht gemeldet.

Im Erfolgsfalle oder bei Fehlern, die nicht zum Abbruch der Operation führen, wird ein Status-Element gemäß [gemSpec_Kon#3.5.2] zurückgegeben.

Für das Fehlermanagement gelten neben den hier aufgeführten spezifischen Anforderungen für das Fachmodul NFDM die Anforderungen aus Kapitel 3 der übergreifenden Spezifikation [gemSpec_OM].

Details zu gematik-SOAP-Faults finden sich in [gemSpec_OM#3.2.3].

5.3 Berechtigungen

5.3.1 Primärsysteme

Das Fachmodul NFDM muss sicherstellen, dass nur im jeweiligen Nutzungskontext (Mandant, Arbeitsplatz, Sitzung) berechtigte Primärsysteme zur Ausführung der Operationen des Fachmoduls autorisiert werden (s. Übergreifende Erfolgsbedingungen ÜE2 und ÜE3 in Kapitel 5.11).

Zu diesem Zweck bietet der Konnektor den Fachmodulen den internen TUC_KON_000 „Prüfe Zugriffsberechtigung“ (vgl. [gemSpec_Kon#4.1.1.4.1]).

5.3.2 Fachliche Rollen

Die fachlichen Akteure, welche die Operationen des Fachmoduls NFDM aufrufen, um auf die eGK zuzugreifen, erhalten mittels ihrer fachlichen Rolle, die technisch durch das Zugriffsprofil ihrer Smartcard repräsentiert wird, die Autorisierung zur Ausführung einer Operation.

Für die Operationen des Fachmoduls sind in Kapitel 5.12 für jede fachliche Rolle (gemäß [gemSpec_PKI#Tab_PKI_254]) die Berechtigungen tabellarisch spezifiziert und weitere Anforderungen an die Umsetzung formuliert. Andere als in den Tabellen aufgeführte fachliche Rollen haben keinerlei Berechtigungen, Operationen des Fachmoduls NFDM auszuführen.

Die Berechtigungsregeln der Tabellen spiegeln in der Regel die Zugriffsregeln wieder, die vom Betriebssystem der eGK beim Zugriff der Fachmoduloperationen auf die Dateien der eGK durchgesetzt werden. Das Fachmodul muss in diesem Falle lediglich sicherstellen, dass die Zugriffsbedingungen (C2C-Authentisierung und ggf. PIN-Eingabe) sichergestellt sind. Ausnahmen von dieser Regel sind in den Tabellen gekennzeichnet (siehe „Legende zu den Berechtigungstabellen" in Kapitel 1.5). In diesen Fällen ist das Fachmodul selbst verantwortlich für die Durchsetzung der Berechtigung und kann sie nicht an das Betriebssystem der eGK delegieren. So hat z. B. laut Zugriffsbedingung auf der eGK der Arzt nach erfolgreicher C2C-Authentisierung mit seinem Heilberufsausweis (HBA) gegenüber der eGK die Berechtigung, auf den NFD lesend ohne PIN zuzugreifen. Das Fachmodul muss jedoch zusätzlich eine PIN-Verifikation anstoßen, falls EmergencyIndicator sowie UpdateIndicator den Wert false besitzen. Ebenso muss das Fachmodul NFDM die Rolle „Andere Heilberufe“ (umfasst z. B. Rettungsassistenten und Notfallsanitäter) außerhalb einer Notfallsituation (EmergencyIndicator ist nicht true) vom lesenden Zugriff auf die NFD ausschließen, obwohl dieser aufgrund der Zugriffsbedingungen der eGK grundsätzlich nach C2C-Authentisierung gewährt wird.

5.4 Transportsicherung

Die betriebliche Steuerung erfolgt über den relevanten Konfigurationsparameter des Konnektors (ANCL_TLS_MANDANTORY). Ist dieser gesetzt, so ist für die Kommunikation zwischen Clientsystem und Konnektor (und damit auch dem Fachmodul NFDM) ein TLS-gesicherter Kanal zu verwenden (vgl. [gemSpec_Kon#3.4.1]). Die Kommunikation des Primärsystems mit dem Fachmodul NFDM sollte aus Sicherheitsgründen verschlüsselt erfolgen. Falls diese Kommunikation unverschlüsselt erfolgt, übernimmt der Leistungserbringer die Verantwortung für die Sicherstellung der vertraulichen Umgebung (vgl. auch [gemSpec_Kon#2.7]).

Der Konnektor bietet zudem im Rahmen der Transportsicherung die Möglichkeit, eine Authentifizierung des Primärsystems zu erzwingen. Standardmäßig ist der relevante Konfigurationsparameter des Konnektors (ANCL_CAUT_MANDANTORY) so gesetzt, dass Clientsysteme sich gegenüber dem Konnektor (und damit auch dem Fachmodul NFDM) authentifizieren müssen. Über den Konfigurationsparameter ANCL_CAUT_MODE kann der Authentifizierungsmodus konfiguriert werden (vgl. [gemSpec_Kon#3.4.1]).

5.5 Unterstützte Generationen der eGK

Die zu unterstützenden Versionen der Karten ergeben sich aus den in der zu dieser Spezifikation gehörigen Dokumentenlandkarte aufgeführten zugelassenen Produkttypversionen.

5.6 Versionierung

Das Fachmodul NFDM ist integraler Bestandteil des Konnektors und Teil von dessen Firmware-Version. Bezüglich der Selbstauskunft gelten die Festlegungen in [gemSpec_Kon#TIP1-A_4812].

5.7 Protokollierung

5.7.1 Protokollierung im Fachmodul NFDM (Logging)

Das Fachmodul soll Protokolldateien im Konnektor ablegen, die eine Analyse technischer Vorgänge erlauben. Diese Protokolldateien sind dafür vorgesehen, aufgetretene Fehler zu identifizieren, die Performance zu analysieren und interne Abläufe zu beobachten. Dazu stellt der Konnektor den TUC_KON_271 „Schreibe Protokolleintrag“ des Protokollierungsdienstes zur Verfügung (siehe [gemSpec_Kon#4.1.10.4.1]).

Um die Anforderungen an den Datenschutz zu gewährleisten, dürfen weder medizinische noch personenbezogene Daten geschrieben werden.

Die Protokolldateien folgen einem einheitlichen Format, das vom Hersteller festgelegt und dokumentiert wird. Es muss geeignet sein, um automatische Auswertungen mit wenig Aufwand durch Dritte zu ermöglichen. Ein Vorbild ist das Weblog des Apache Webservers. Um mehrere Protokolleinträge zu korrelieren, soll bei Aufruf einer Operation, sprich Aufruf einer Schnittstelle, eine Vorgangsnummer gebildet werden. Diese Vorgangsnummer wird in allen Protokolleinträgen dieses Operationsaufrufs genutzt. Die Vorgangsnummer wird vom Konnektor pseudozufällig gebildet.

Der Zugriff auf Protokolldateien muss auf autorisierte Personen durch angemessene technische oder organisatorische Maßnahmen eingeschränkt werden. Die Zugriffseinschränkungen werden über Mechanismen des Konnektors umgesetzt. Die Logdateien können auf ein separates Speichermedium kopiert werden (siehe [gemSpec_Kon#TIP1-A_4716]).

Der TUC_KON_271 „Schreibe Protokolleintrag“ unterscheidet drei verschiedene Logging-Protokolle:

• Fachmodulprotokoll (eventType = „Op“): Das Fachmodulprotokoll soll die internen Ausführungsschritte enthalten, die einen Einblick in den internen Ablauf für Administratoren, Betreiber und Tester ermöglichen und die Analyse von Fehlersituationen erleichtern.
• Sicherheitsprotokoll (eventType = „Sec“): Das Sicherheitsprotokoll dient der Protokollierung von sicherheitsrelevanten Fehlern und Ereignissen.
• Performanceprotokoll (eventType = „Perf“): Das Performanceprotokoll dient dem Vergleich der tatsächlichen Ausführungszeiten des Fachmoduls NFDM und den Vorgaben aus [gemSpec_Perf].

Abhängig von der Schwere (Severity), werden die Einträge der drei Protokolle in folgende Klassen eingeteilt:

Tabelle 3: Tab_FM_NFDM_050 Einteilung der Protokolleinträge in Abhängigkeit der Schwere

Hinweis: Der Parameter „Schwere“ wird für einen Eintrag im Performanceprotokoll nicht verwendet.

5.7.2 Zugriffsprotokolleinträge auf der eGK

Die Zugriffsprotokolleinträge werden mittels TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ des Kartendienstes erstellt (siehe [gemSpec_Kon#4.1.5]).

5.8 Konfiguration und Datenspeicherung

Die Administration der Konfigurationsparameter erfolgt über die Managementschnittstelle des Konnektors (vgl. [gemSpec_Kon#4.3.4]).

5.9 Verwendung des Dienstverzeichnisdienstes

5.10 Meldungen am Kartenterminal

Aus Verwendung der o. g. Parameter resultieren folgende Terminal-Anzeigen.

Tabelle 13: Tab_FM_NFDM_037 – Terminal-Anzeigen für PIN-Eingabe

5.11 Übergreifende Erfolgs- und Nachbedingungen

Erfolgsbedingungen sind Bedingungen, die erfüllt sein müssen, damit eine Operation der NFDM-Services erfolgreich durchlaufen werden kann. Jede der Bedingungen wird von den Operationen im Rahmen der Verarbeitung überprüft. Der in [gemSysL_NFDM] im Rahmen der Anwendungsfallbeschreibungen genutzte Begriff „Vorbedingung“ wird nicht verwendet, da Vorbedingungen üblicherweise so definiert werden, dass sie erfüllt sein müssen, bevor die Operation aufgerufen werden kann.

Folgende übergreifende Erfolgsbedingungen gelten für alle Operationen der in Kapitel 6.1 und 6.2 definierten Services. Sie werden in allen Operationsspezifikationen des Kapitel 5.12 referenziert.

Tabelle 14: Tab_FM_NFDM_032 – Übergreifende Erfolgsbedingungen

Hier und im Folgenden ist mit SMC-B auch die Hardware-Security-Module(HSM)-Variante der Institutionenkarte Typ B gemeint, die hier als virtuelle Karte in einem virtuellen Kartenterminal verstanden wird.

Das folgende Aktivitätsdiagramm modelliert den Ablauf einer Prüfung der übergreifenden Erfolgsbedingung und wird in den Aktivitätsdiagrammen für die Abläufe der Operationen referenziert.

Abbildung 4: Abb_FM_NFDM_001 – Ablauf „Übergreifende Erfolgsbedingungen prüfen“

Folgende übergreifende Nachbedingungen gelten für alle Operationen der in Kapitel 5.12 definierten Services. Sie werden in allen Operationsspezifikationen des Kapitel 5.12 referenziert.

Tabelle 15: Tab_FM_NFDM_033 – Übergreifende Nachbedingungen

5.12 QES-Signatur des Notfalldatensatzes

Der Notfalldatensatz enthält gemäß [gemSpec_InfoNFDM#4] eine QES-Signatur. Die Erstellung und Prüfung der Signatur erfolgt über einen Basisdienst des Konnektors. Die Anforderungen der Nutzung des Basisdienstes zur Signaturerstellung und -prüfung sind in [gemRL_QES_NFDM] festgelegt.

6 Funktionsmerkmale

In diesem Kapitel wird die Primärsystemschnittstelle des Fachmoduls NFDM definiert. Für jede Operation wird das an der Schnittstelle sichtbare und damit testbare Verhalten und die Berechtigungen normativ in tabellarischer Form spezifiziert.

6.1 NFDService

Der Web Service „NFDService“ stellt seine Operationen dem Primärsystem über die im Folgenden spezifizierte Schnittstelle I_NFD_Management zur Verfügung. Schnittstelle I_NFD_Management

6.1.1.1 Schnittstellendefinition

Das Fachmodul bietet keine eigene Operation zur Signatur des NFD an, da der Signaturdienst des Konnektors an seiner Außenschnittstelle dem Primärsystem bereits mit dem Online Rollout Stufe 1 die Operation SignDocument zur Verfügung stellt (vgl. [gemSpec_Kon#4.1.8.5.1]).

6.1.1.1.1 ReadNFD

NFDM-A_2110 - Operation ReadNFD

Der NFDService des Fachmoduls NFDM MUSS die Operation ReadNFD gemäß Tabelle „Tab_FM_NFDM_005 – Operation ReadNFD“ anbieten.

Tabelle 17: Tab_FM_NFDM_005 – Operation ReadNFD

Name	ReadNFD
Beschreibung	Die Operation liest den NFD im Informationselement NFD der Datei EF.NFD von der durch den Parameter EhcHandle identifizierten eGK und gibt ihn über den Parameter NFDDocument an das aufrufende Primärsystem zurück.
Erfolgsbedingungen	Die Operation MUSS alle übergreifenden Erfolgsbedingungen aus Tabelle „Tab_FM_NFDM_032 – Übergreifende Erfolgsbedingungen“ und die folgenden überprüfen.
			Bedingung
	E1		Der NFD auf der eGK ist nicht verborgen, d. h. der Ordner DF.NFD der eGK darf als Wert des Attributs lifeCycleStatus nicht den Wert „deactivated“ haben.
	E2		Der auf der eGK gespeicherte NFD ist technisch konsistent, d. h. der Wert des Informationselements Status der Datei EF.StatusNFD gemäß [gemSpec_eGK_Fach_NFDM#2.2] der eGK ist „0“.
	E3		Die Version der internen Speicherstruktur (s. 6.1.2.2) der Dateien der Anwendung „Notfalldatensatz“ auf der eGK (NFD-Speicherstruktur) wird vom Fachmodul NFDM unterstützt.
	E4		Es ist ein gemäß [RFC1952] gzip-komprimierter NFD auf der eGK im Informationselement NFD der Datei EF.NFD gemäß [gemSpec_eGK_Fach_NFDM#2.1] gespeichert, d. h. das Informationselement Länge NFD der Datei EF.NFD der eGK hat einen Wert ungleich ´00 00´.
	E5		Der auf der eGK gespeicherte NFD ist valide gegen das XML-Schema für den NFD (s. [gemSpec_InfoNFDM#3]).
Aufrufparameter
	Name					Beschreibung
	Context					Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1]
	EhcHandle					Verweis auf die eGK, von der der NFD gelesen werden soll
	HpcHandle					Verweis auf LE-Karte (HBA/SMC-B), die zum Zugriff auf die eGK verwendet werden soll
	EmergencyIndicator					Gibt an, ob die Operation im Rahmen eines Notfalls aufgerufen wird
	UpdateIndicator					Gibt an, ob die Operation im Rahmen einer Aktualisierung des NFD aufgerufen wird
		Zusätzliche Konsistenzregeln
	A1	Die Werte der Elemente EmergencyIndicator und UpdateIndicator DÜRFEN NICHT beide true (bzw. 1) sein. (Der Wert false (bzw. 0) für beide Elemente gleichzeitig ist zulässig.)
Rückgabe
	Name					Beschreibung
	Status					Statusrückmeldung gemäß [gemSpec_Kon#3.5.2]
	NFDDocument					Von der eGK des Versicherten gelesener, dekomprimierter NFD inkl. qualifizierter elektronischer Signatur (QES)
	VerificationReport					Prüfbericht der QES-Prüfung des NFD gemäß [OASIS-VR]. Detailstruktur des Elements s. [gemSpec_Kon#4.1.8.5.2].
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die übergreifenden Nachbedingungen gemäß Tabelle „Tab_FM_NFDM_033 – Übergreifende Nachbedingungen“ und die folgenden erfüllen.
				Bedingung
	N1			Der NFD (Ausgabeparameter NFDDocument) ist dekomprimiert.
	N2			Die QES des NFD wurde  geprüft und ein Prüfbericht (Ausgabeparameter VerificationReport) erstellt.(Hier ist zu beachten, dass die Nachbedingung nicht die Gültigkeitder QES des NFD fordert. Gefordert ist nur die QES-Prüfung. Auch bei ungültiger QES ist der NFD zurückzugeben.)
Statusrückmeldungen	Falls die Operation erfolgreich bis zum Ende durchläuft, MUSS die Operation als Wert des Elements Status/Result „OK“ zurückgeben. Falls die QES ungültig ist oder die Prüfung der QES nicht vollständig durchgeführt werden konnte, die Teilprüfungen, die durchgeführt werden konnten, aber erfolgreich waren, MUSS das Element Status/Result den Wert „WARNING“ und das Element Status/Error die Fehlermeldung 5501 enthalten.
Ablauf	Der Ablauf der Operation ReadNFD, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FM_NFDM_003 – Ablauf ReadNFD“ modelliert. Die Umsetzung des Ablaufs mittels Aufrufen von TUCs des Konnektors und interner Operationen des Fachmoduls spezifiziert Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“. Der Hersteller kann von der Umsetzung bzw. den spezifizierten Abläufen (z. B. zum Zwecke der Performanceoptimierung) abweichen, falls dadurch das definierte Außenverhalten der Operation gewährleistet bleibt und die Performancevorgaben aus [gemSpec_Perf] eingehalten werden.
Fehlermeldungen	Für die generischen Fehlermeldungen finden sich die Attribute ErrorType, Severity, Fehlertext, Befüllung Details und Auslösende Bedingung in [gemSpec_OM#3.2.2]. Für die spezifischen Fehlermeldungen sind die Attribute ErrorType, Severity, Fehlertext und Befüllung Details in Tabelle „Tab_FM_NFDM_002 – Fehlermeldungen Fachmodul NFDM“ definiert. Generische Fehlercodes
	Code				Befüllung Details
	3				Der Detailtext MUSS Hinweise auf die konkrete Fehlerursache enthalten (z. B. die Fehlermeldung des XML-Parsers).
	108				Der Detailtext KANN den Fehler näher beschreiben.
	111				Der Detailtext KANN den Fehler näher beschreiben.
	113				Der Detailtext KANN den Fehler näher beschreiben.
	114				Der Detailtext KANN den Fehler näher beschreiben.
	Spezifische Fehlermeldungen
	Code				Auslösende Bedingung
	5001				ÜE7 ist nicht erfüllt.
	5002				Die fachliche Rolle ist gemäß Berechtigungsmatrix nicht berechtigt zum Ausführen der Operation.
	5003				E2 ist nicht erfüllt.
	5004				E3 ist nicht erfüllt.
	5006				Die Dekomprimierung des NFD ist gescheitert.
	5009				Die Kodierung (base64) des NFD ist gescheitert.
	5011				Die Berechtigungsregel konnte nicht ermittelt werden.
	5014				ÜE2 ist nicht erfüllt.
	5015				ÜE3 ist nicht erfüllt.
	5016				ÜE8 ist nicht erfüllt.
	5017				E5 ist nicht erfüllt.
	5018				Signaturprüfung abgebrochen
	5019				PIN-Verifikation gescheitert
	5020				E1 ist nicht erfüllt.
	5021				E4 ist nicht erfüllt.
	5500				Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.

Abbildung 5: Abb_FM_NFDM_003 – Ablauf ReadNFD

[<=]

6.1.1.1.2 WriteNFD

NFDM-A_2113 - Operation WriteNFD

Der NFDService des Fachmoduls NFDM MUSS die Operation WriteNFD gemäß Tabelle „Tab_FM_NFDM_008 – Operation WriteNFD“ anbieten.

Tabelle 19: Tab_FM_NFDM_008 – Operation WriteNFD

Name	WriteNFD
Beschreibung	Die Operation schreibt den ihr im Parameter NFDDocument übergebenen NFD auf die durch den Parameter EhcHandle identifizierte eGK in das Informationselement NFD der Datei EF.NFD.
Erfolgsbedingungen	Die Operation MUSS alle übergreifenden Erfolgsbedingungen aus Tabelle „Tab_FM_NFDM_032 – Übergreifende Erfolgsbedingungen“ und die folgenden überprüfen.
		Bedingung
	E1	Die NFD-Anwendung auf der eGK ist nicht verborgen, d. h. der Ordner DF.NFD der eGK darf als Wert des Attributs lifeCycleStatus nicht den Wert „deactivated“ haben.
	E2	Der übergebene NFD ist valide gegen das XML-Schema für den NFD (s. [gemSpec_InfoNFDM#3]).
	E3	Der übergebene NFD ist mit einer mathematisch gültigen Signatur signiert, die auf einem QES-konformen (qualifizierten) Zertifikat beruht.
	E4	Der Versicherte der eGK ist mit dem Versicherten des NFD identisch, d. h. die Versicherten-ID (die ersten zehn unveränderbaren Stellen der Krankenversichertennummer (KVNR)) im Feld organizationalUnitName des Subject Distinguished Name (SubjectDN) des Authentisierungszertifikats der eGK (gespeichert in der Datei EF.C.CH.AUT.R2048) ist die gleiche wie die im NFD im Element Versicherten_ID gespeicherte. Anmerkung: Es gibt zwei organizationalUnitName-Felder im SubjectDN. Das zehnstellige, alphanumerische Feld beinhaltet die Versicherten-ID (unveränderbarer Teil der Krankenversichertennummer), das andere, neunstellige numerische Feld das Institutionskennzeichen der Krankenversichertennummer (s. [gemSpec_PKI#5.1.3.1]).
	E5	Der übergebene NFD ist nicht größer als der auf der eGK im Informationselement NFD der Datei EF.NFD der eGK zur Verfügung stehende Speicherplatz.
Aufrufparameter
	Name				Beschreibung
	Context				Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1]
	EhcHandle				Verweis auf die eGK, auf die der NFD geschrieben werden soll
	HpcHandle				Verweis auf die LE-Karte (HBA/SMC-B), die zum Zugriff auf die eGK verwendet werden soll
	NFDDocument				Auf die eGK des Versicherten zu schreibender NFD inkl. QES
		Zusätzliche Konsistenzregeln
		Keine
Rückgabe
	Name				Beschreibung
	Status				Statusrückmeldung gemäß [gemSpec_Kon#3.5.2]
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die übergreifenden Nachbedingungen gemäß Tabelle „Tab_FM_NFDM_033 – Übergreifende Nachbedingungen“ und die folgenden erfüllen.
			Bedingung
	N1		Die Größe des NFD (Anzahl Oktette) ist im Informationselement Länge NFD der Datei EF.NFD der eGK gemäß [gemSpec_eGK_Fach_NFDM#2.1] gespeichert.
	N2		Der übergebene NFD ist inkl. gültiger QES gemäß [RFC1952] gzip-komprimiert auf der eGK im Informationselement NFD der Datei EF.NFD gemäß [gemSpec_eGK_Fach_NFDM#2.1] gespeichert.
	N3		Der Wert des Informationselementes Timestamp der Datei EF.StatusNFD der eGK ist aktualisiert.
	N4		Der Wert des Informationselements Version_Speicherstruktur der Datei EF.StatusNFD der eGK ist aktualisiert mit einer gemäß [gemSpec_eGK_Fach_NFDM#2.2] gültigen Versionsnummer.
	N5		Der Wert des Informationselement Status der Datei EF.StatusNFD der eGK ist „0“.
Statusrückmeldungen	Falls die Operation erfolgreich bis zum Ende durchläuft, MUSS die Operation als Wert des Elements Status/Result „OK“ zurückgeben.
Ablauf	Der Ablauf der Operation WriteNFD, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FM_NFDM_004 – Ablauf WriteNFD“ modelliert. Die Umsetzung des Ablaufs mittels Aufrufen von TUCs des Konnektors und interner Operationen des Fachmoduls spezifiziert Tabelle „Tab_FM_NFDM_026 – Umsetzung Ablaufaktivitäten WriteNFD“. Der Hersteller kann von der Umsetzung bzw. den spezifizierten Abläufen (z. B. zum Zwecke der Performanceoptimierung) abweichen, falls dadurch das definierte Außenverhalten der Operation gewährleistet bleibt und die Performancevorgaben aus [gemSpec_Perf] eingehalten werden.
Fehlermeldungen	Für die generischen Fehlermeldungen finden sich die Attribute ErrorType, Severity, Fehlertext, Befüllung Details und Auslösende Bedingung in [gemSpec_OM#3.2.2]. Für die spezifischen Fehlermeldungen sind die Attribute ErrorType, Severity, Fehlertext und Befüllung Details in Tabelle „Tab_FM_NFDM_002 – Fehlermeldungen Fachmodul NFDM“ definiert. Generische Fehlermeldungen
	Code			Befüllung Details
	3			Der Detailtext MUSS Hinweise auf die konkrete Fehlerursache enthalten (z. B. die Fehlermeldung des XML-Parsers).
	106			Der Detailtext KANN den Fehler näher beschreiben.
	107			Der Detailtext KANN den Fehler näher beschreiben.
	108			Der Detailtext KANN den Fehler näher beschreiben.
	112			Der Detailtext KANN den Fehler näher beschreiben.
	113			Der Detailtext KANN den Fehler näher beschreiben.
	114			Der Detailtext KANN den Fehler näher beschreiben.
	Spezifische Fehlermeldungen
	Code			Auslösende Bedingung
	5000			Die eGK ist defekt.
	5001			ÜE7 ist nicht erfüllt.
	5002			Die fachliche Rolle ist gemäß Berechtigungsmatrix nicht berechtigt zum Ausführen der Operation.
	5007			Die Dekodierung des NFD ist gescheitert.
	5008			E4 ist nicht erfüllt.
	5010			Die Komprimierung des NFD ist gescheitert.
	5011			Die Berechtigungsregel konnte nicht ermittelt werden.
	5013			E5 ist nicht erfüllt.
	5014			ÜE2 ist nicht erfüllt.
	5015			ÜE3 ist nicht erfüllt.
	5016			ÜE8 ist nicht erfüllt.
	5017			E2 ist nicht erfüllt.
	5019			PIN-Verifikation gescheitert.
	5020			E1 ist nicht erfüllt.
	5504			Die Signatur des NFD ist kryptographisch ungültig.
	5505			Das Signaturzertifikat des NFD ist nicht qualifiziert.
	5500			Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.