Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Fachmodul NFDM

    

     

      
Version
      
1.6.3
     
     

      
Revision
      
983072
     
     

      
Stand
      
05.07.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FM_NFDM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

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 Kapitel 9.5).

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.

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 Afo-ID und der Textmarke 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, fallsEmergencyIndicator 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.

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.