gemSpec_FM_NFDM_V1.6.3
Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
Fachmodul NFDM
Version | 1.6.3 |
Revision | 959388 |
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
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
1.1.0 |
04.10.2017 |
freigegeben |
gematik |
|
1.2.0 |
18.12.2017 |
Entfernung LE-AdV, Einarbeitung freigegebener Änderungen |
gematik |
|
1.3.0 |
14.05.2018 |
Einarbeitung P15.2 und P15.4 |
gematik |
|
1.4.0 |
26.10.2018 |
Einarbeitung P15.9 |
gematik | |
1.5.0 | 08.04.2019 |
Einarbeitung Änderungsliste P18.1 |
gematik |
|
1.6.0 | 08.06.2019 | Einarbeitung P19.1 | gematik | |
1.6.1 | 19.02.2021 | Einarbeitung Änderungsliste P22.5 | gematik | |
1.6.2 | 30.06.2021 | Einarbeitung Konn_Maintenance_21.3 | gematik | |
1.6.3 | 05.07.2024 | Einarbeitung Konn_24.1 | gematik |
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
Objekt
|
G 2.0
|
G 2.1
|
|
---|---|---|---|
Bezeichner
|
FID o. AID o. PID
|
Bezeichner des überg. DF
|
Bezeichner des überg. DF
|
MF
|
´D276 0001 4480 00´
|
|
|
DF.ESIGN
|
´A000000167 455349474E´
|
MF
|
MF
|
EF.Version2
|
´2F 10´
|
MF
|
MF
|
EF.C.CH.AUT.R2048/ E256
|
´C5 00´/ ´C5 04´
|
DF.ESIGN
|
DF.ESIGN
|
DF.HCA
|
´D276000001 02´
|
MF
|
MF
|
EF.Logging
|
´D0 06´
|
DF.HCA
|
DF.HCA
|
DF.NFD
|
´D276 0001 4407´
|
DF.HCA
|
DF.HCA
|
EF.NFD
|
´D0 10´
|
DF.NFD
|
DF.NFD
|
EF.StatusNFD
|
´D0 0E´
|
DF.NFD
|
DF.NFD
|
DF.DPE
|
´D276 0001 4408´
|
DF.HCA
|
DF.HCA
|
EF.DPE
|
´D0 1B´
|
DF.DPE
|
DF.DPE
|
EF.StatusDPE
|
´D0 18´
|
DF.DPE
|
DF.DPE
|
PIN.CH
|
´01´
|
MF
|
MF
|
MRPIN.NFD
|
´03´
|
DF.NFD
|
MF
|
MRPIN.NFD_READ
|
´07´
|
DF.NFD
|
MF
|
MRPIN.DPE
|
´04´
|
DF.DPE
|
MF
|
MRPIN.DPE_READ
|
´08´
|
DF.DPE
|
nicht vorhanden
|
Legende zu den Berechtigungstabellen:
j bzw. n = Bedingung für die Berechtigungsregel erfüllt bzw. nicht erfüllt - = Bedingung irrelevant für die Berechtigungsregel x = autorisiert zur Ausführung der Operation nach vorausgegangener erfolgreicher gegenseitiger Card-to-Card(C2C)-Authentisierung der beteiligten Karten $PIN(x) = autorisiert zur Ausführung der Operation nach Verifikation der durch „$PIN“ bezeichneten Personal Identification Number (PIN) der eGK --- = keine Berechtigung zur Ausführung der Operation [FM] = Berechtigung wird nicht vom Betriebssystem der eGK, sondern vom Fachmodul NFDM durchgesetzt Die Bedingung „MRPIN.NFD aktiviert“ bzw. „MRPIN.DPE aktiviert“ bedeutet, dass das Attribut flagEnabled des jeweiligen Multireferenz-Passwortobjekts der eGK den Wert true hat (TUC_KON_022 „Liefere PIN-Status“ liefert nicht DISABLED als pinStatus). Die Spaltenüberschriften R1, R2, R3, R4 bezeichnen nummerierte Regeln der Berechtigungstabelle als Entscheidungstabelle. |
---|
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
Anwendungsfall aus [gemSysL_NFDM] |
Operation Fachmodul |
---|---|
I_NFD_Management |
|
NFDM-UC_100 NFD auf eGK schreiben |
WriteNFD |
NFDM-UC_101 NFD von eGK lesen |
ReadNFD |
NFDM-UC_102 NFD von eGK löschen |
EraseNFD |
I_DPE_Management |
|
NFDM_UC_200 DPE auf eGK schreiben |
WriteDPE |
NFDM_UC_201 DPE von eGK lesen |
ReadDPE |
NFDM_UC_202 DPE von eGK löschen |
EraseDPE |
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
NFDM-A_2086 - Web Services konform zu [BasicProfile1.2]
Das Fachmodul NFDM MUSS die für die Clientsystemschnittstelle definierten Web-Services konform zu [BasicProfile1.2] anbieten. Abweichend von R1012 in [BasicProfile1.2] MUSS das Fachmodul NFDM nur die Zeichenkodierung 8-Bit Universal Character Set Transformation Format (UTF-8) unterstützen. Andere Kodierungen MUSS das Fachmodul NFDM mit einem Fehler beantworten. [<=]
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].
NFDM-A_2089 - Protokollierung inkl. Trace-Struktur
Das Fachmodul NFDM MUSS während der Verarbeitung auftretende Fehler inkl. der Trace-Struktur protokollieren. [<=]
NFDM-A_2090 - Transport Fehlermeldungen als gematik-SOAP-Fault
Das Fachmodul NFDM MUSS Fehlermeldungen, die im Rahmen einer über die Web-Service-Schnittstelle aufgerufenen Operation auftreten, an das Primärsystem mittels gematik-SOAP-Faults melden. [<=]
Details zu gematik-SOAP-Faults finden sich in [gemSpec_OM#3.2.3].
NFDM-A_2091 - Zurückverfolgbarkeit von Fehlerketten
Das Fachmodul NFDM MUSS sicherstellen, dass bei Fehlermeldungen, die von einer Operation der Web-Service-Schnittstelle zurückgegeben werden, die jeweilige Fehlerkette zurück verfolgbar ist. [<=]
NFDM-A_2092 - Vorgaben spezifische Fehlermeldungen
Das Fachmodul NFDM MUSS sicherstellen, dass alle spezifischen Fehlermeldungen den Vorgaben gemäß Tabelle „Tab_FM_NFDM_002 – Fehlermeldungen Fachmodul NFDM“ genügen. [<=]
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.
A_25869 - Fachmodul NFDM - andere Heilberufe
Das Fachmodul NFDM MUSS Zugriffe für "andere Heilberufe" für genau folgende professionOID gemäß Tab_PKI_402-* zulassen.
- Hebamme
- Physiotherapeut/-in
- Ergotherapeut/-in
- Logopäde/Logopädin
- Podologe/Podologin
- Ernährungstherapeut/-in
- Notfallsanitäter/-in
- Gesundheits- und Krankenpfleger/-in
- Gesundheits- und Kinderkrankenpfleger/-in
- Altenpfleger/-in
- Pflegefachfrauen und Pflegefachmänner
5.4 Transportsicherung
NFDM-A_2093 - Verfügbarkeit Transportsicherung
Das Fachmodul NFDM MUSS die Verschlüsselung der Kommunikation anbieten, indem es die durch den Konnektor bereitgestellte Funktionalität zur Transportsicherung an der Primärsystemschnittstelle nutzt.
[<=]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
NFDM-A_2094 - Unterstützte Generationen der eGK
Das Fachmodul NFDM MUSS alle Versionen der eGK der Generationen G2 und höher unterstützen, die ihm bekannt sind. Das Fachmodul NFDM DARF NICHT die Generationen G0, G1 und G1+ unterstützen.
Falls die ermittelte Kartenversion kleiner als alle zu unterstützenden Kartenversionen ist oder die ermittelte Kartenversion nicht bekannt und kleiner als die größte zu unterstützende Kartenversion ist, MUSS das Fachmodul von einer inkompatiblen Karte ausgehen und die weitere Verarbeitung der Karte unmittelbar abbrechen.
Falls die ermittelte Kartenversion größer als alle dem Fachmodul NFDM bekannten Kartenversionen ist, MUSS das Fachmodul von einer kompatiblen Karte ausgehen und versuchen, diese zu verarbeiten. [<=]
Die zu unterstützenden Versionen der Karten ergeben sich aus den in der zu dieser Spezifikation gehörigen Dokumentenlandkarte aufgeführten zugelassenen Produkttypversionen.
A_25877 - FM_NFDM Funktion bei nicht personalisierten RSA-Zertifikaten
Das Fachmodul NFDM MUSS seine Operationen mit einer G2.1 eGK fehlerfrei ausführen, auch wenn auf dieser keine RSA-Zertifikate personalisiert sind. [<=]
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]).
NFDM-A_2406 - Protokollierung
Das Fachmodul NFDM MUSS Protokolleinträge mittels TUC_KON_271 „Schreibe Protokolleintrag“ in die Protokolldateien persistieren.
[<=]Um die Anforderungen an den Datenschutz zu gewährleisten, dürfen weder medizinische noch personenbezogene Daten geschrieben werden.
NFDM-A_2095 - Verbot Protokollierung medizinischer Daten
Das Fachmodul NFDM DARF NICHT medizinische Daten protokollieren. Die gesetzlich vorgeschriebene Zugriffsprotokollierung auf der eGK bleibt hiervon unberührt.
[<=]
NFDM-A_2096 - Verbot Protokollierung Schlüsselmaterial
Das Fachmodul NFDM DARF NICHT geheimes Schlüsselmaterial protokollieren.
[<=]NFDM-A_2097 - Verbot Protokollierung personenbezogener Daten
Das Fachmodul NFDM DARF NICHT personenbezogene Daten des Versicherten, protokollieren.
[<=]
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.
NFDM-A_2098 - Einheitliches Protokollierungsformat
Das Fachmodul NFDM MUSS Protokolleinträge in einem einheitlichen, dokumentierten Format erstellen, um eine automatisierte Auswertung zu ermöglichen.
[<=]
NFDM-A_2371 - Zusammenfassung mehrerer Protokolleinträge mittels Vorgangsnummer
Das Fachmodul NFDM MUSS sicherstellen, dass sich alle zu einem Operationsaufruf zugehörigen Protokolleinträge über eine Vorgangsnummer korrelieren lassen.
[<=]
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
Schwere (Severity) |
Klasse (entspricht …) |
---|---|
Debug |
Debug (~ Debug-Protokoll) |
Info |
Ablauf/Ereignis (~ Ablaufprotokoll) |
Warning, Error, Fatal |
Fehler (~ Fehlerprotokoll) |
NFDM-A_2101 - Fachmodulprotokoll (Ablauf)
Das Fachmodul NFDM MUSS die internen Ausführungsschritte der Operationsaufrufe im Fachmodulprotokoll mit mindestens den folgenden Parametern erfassen:
Tabelle 4: Tab_FM_NFDM_051 – Parameter des Ablaufprotokolls
Feld |
Beschreibung |
---|---|
eventType |
„Op“ |
Schwere |
„Info“ |
Vorgangsnummer |
Zeichenkette zur Korrelation der zugehörigen Protokolleinträge |
Zeitpunkt |
Zeitpunkt der Erstellung des Protokolleintrags |
Bezeichnung |
vollständiger Name des Ausführungsschrittes |
Beschreibung |
Details zum Ausführungsschritt inklusive Ergebnis |
Pin-Eingabe |
Beschreibung bei erfolgter PIN-Eingabe inklusive Ergebnis |
Eingangsparameter |
Werte der Eingangsparameter, falls vorhanden |
NFDM-A_2099 - Fachmodulprotokoll (Fehler)
Das Fachmodul NFDM MUSS unabhängig vom ErrorType alle lokal erkannten und Remote-Fehler der Severity „Warning“, „Error“ oder „Fatal“ im Fachmodulprotokoll mit mindestens den folgenden Parametern erfassen:
Tabelle 5: Tab_FM_NFDM_052 – Parameter des Fehlerprotokolls
Feld |
Beschreibung |
---|---|
eventType |
„Op“ |
Schwere |
„Warning“, „Error“, „Fatal“ |
Vorgangsnummer |
Zeichenkette zur Korrelation der zugehörigen Protokolleinträge |
Zeitpunkt |
Zeitpunkt der Erstellung des Protokolleintrags |
Fehlercode |
Fehlercode des aufgetretenen Fehlers |
CardHandle |
CardHandle der betroffenen eGK |
Fehlerdetails |
Weiterführende Details zum Fehler |
[<=]
NFDM-A_2103 - Fachmodulprotokoll (Debug)
Falls nicht im Produktivbetrieb laufend, KANN das Fachmodul NFDM für Testzwecke im Fachmodulprotokoll Debug-Einträge mit mindestens den folgenden Parametern erfassen:
Tabelle 6: Tab_FM_NFDM_053 – Parameter des Debug-Protokolls
Feld |
Beschreibung |
---|---|
eventType |
„Op“ |
Schwere |
„Debug“ |
NFDM-A_2100 - Sicherheitsprotokoll (SecurityLog)
Das Fachmodul NFDM MUSS sicherheitsrelevante Fehler und Ereignisse über den Protokollierungsdienst des Konnektors im Sicherheitsprotokoll des Konnektors mindestens mit den folgenden Parametern erfassen:
Tabelle 7: Tab_FM_NFDM_054 – Parameter des Sicherheitsprotokolls
Feld |
Beschreibung |
---|---|
eventType |
„Sec“ |
Schwere |
„Info“, „Warning“, „Error“, „Fatal“ |
Vorgangsnummer |
Zeichenkette zur Korrelation der zugehörigen Protokolleinträge |
Name der Operation |
Name der untersuchten Operation |
Bezeichnung |
Bezeichnung des sicherheitsrelevanten Fehlers oder Ereignisses |
Beschreibung |
Details des sicherheitsrelevanten Fehlers oder Ereignisses |
NFDM-A_2102 - Performanceprotokoll
Das Fachmodul NFDM MUSS alle zur Kontrolle der Performancevorgaben benötigten, mindestens aber die nachfolgenden, Parameter der Operationsaufrufe im Performanceprotokoll erfassen:
Tabelle 8: Tab_FM_NFDM_055 – Parameter des Performanceprotokolls
Feld |
Beschreibung |
---|---|
eventType |
„Perf“ |
Vorgangsnummer |
Zeichenkette zur Korrelation der zugehörigen Protokolleinträge |
Name der Operation |
Name der untersuchten Operation |
Startzeitpunkt |
Startzeitpunkt der Operation |
Dauer |
Dauer der Operation in ms |
Beschreibung |
Ergänzende Informationen zur gemessenen Aktion |
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]).
NFDM-A_2135 - Zugriffsprotokollierung auf der eGK
Das Fachmodul NFDM MUSS die in Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ definierten Werte für die Informationselemente eines Zugriffsprotokolleintrags auf der eGK verwenden.
Tabelle 9: Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK
Operation |
Data Type |
Type of Access |
Timestamp, Actor-ID, Actor-Name |
|
---|---|---|---|---|
ReadNFD |
2 |
N |
Lesen im Notfall |
gemäß Tabelle „Tab_Karten _Fach_TIP_010 _Struktur“ in [gemSpec_Karten_Fach _TIP#4.1] |
A |
Lesen zum Zwecke der Aktualisierung |
|||
Lesen außerhalb des Notfalls und der Aktualisierung... |
||||
R |
...bei aktivierter MRPIN.NFD |
|||
r |
bei nicht aktivierter MRPIN.NFD |
|||
WriteNFD |
2 |
W |
||
EraseNFD |
2 |
E |
||
ReadDPE |
3 |
N |
Lesen im Notfall |
|
A |
Lesen zum Zwecke der Aktualisierung |
|||
Lesen außerhalb des Notfalls und der Aktualisierung... |
||||
R |
...bei aktivierter MRPIN.DPE |
|||
r |
bei nicht aktivierter MRPIN.DPE |
|||
WriteDPE |
3 |
W |
||
EraseDPE |
3 |
E |
5.8 Konfiguration und Datenspeicherung
NFDM-A_2104 - Übergreifende Konfigurationsparameter
Das Fachmodul NFDM MUSS die in Tabelle „Tab_FM_NFDM_001 – Übergreifende Konfigurationsparameter“ genannten Parameter dem Administrator über die Managementschnittstelle des Konnektors zur Konfiguration anbieten.
Tabelle 10: Tab_FM_NFDM_001 – Übergreifende Konfigurationsparameter
ReferenzID |
Belegung |
Bedeutung |
---|---|---|
FM_NFDM_LOG_LEVEL |
Debug, Info, Warning, Error, Fatal |
Gibt die Mindestschwere zu protokollierender Einträge im Fehlerprotokoll an. |
FM_NFDM_LOG_DAYS |
X Tage |
Anzahl an Tagen, wie lange Protokolleinträge gespeichert werden müssen; Protokolleinträge dürfen nicht länger gespeichert werden |
FM_NFDM_LOG_PERF |
Boolean |
Gibt an, ob das Performance-Protokoll für das Fachmodul NFDM geführt werden soll. |
Die Administration der Konfigurationsparameter erfolgt über die Managementschnittstelle des Konnektors (vgl. [gemSpec_Kon#4.3.4]).
NFDM-A_2105 - Verbot der persistenten Speicherung medizinischer Daten
Das Fachmodul NFDM DARF NICHT medizinische Daten des Versicherten persistent speichern.
[<=]5.9 Verwendung des Dienstverzeichnisdienstes
NFDM-A_2106 - Service-Informationen für Dienstverzeichnisdienste
Das Fachmodul NFDM MUSS die Service-Informationen seiner Services (NFDService und DPEService) während der Bootup-Phase des Konnektors in den Dienstverzeichnisdienst des Konnektors gemäß dem XML-Schema [ServiceInformation.xsd] mit den in Tabelle „Tab_FM_NFDM_003 – Service-Informationen NFDM-Service“ definierten Werten für die Elemente und Attribute des XML-Schemas einbringen.
Tabelle 11: Tab_FM_NFDM_003 – Service-Informationen NFDM-Services
Element/Attribut |
NFDService |
DPEService |
---|---|---|
ServiceInformation/Service /@Name |
NFDService | DPEService |
ServiceInformation/Service /Abstract |
NFD auf eGK verwalten | DPE auf eGK verwalten |
ServiceInformation/Service/Versions /Version/@TargetNamespace |
aktueller Namensraumbezeichner aus Tabelle „Tab_FM_NFDM_049 – WSDL-Schnittstellenbeschreibung NFDService | aktueller Namensraumbezeichner aus Tabelle „Tab_FM_NFDM_034 – WSDL-Schnittstellenbeschreibung DPEService“ |
ServiceInformation/Service/Versions /Version/@Version |
aktuelle Versionsnummer aus Tabelle „Tab_FM_NFDM_049 – WSDL-Schnittstellenbeschreibung NFDService“ |
aktuelle Versionsnummer aus Tabelle „Tab_FM_NFDM_034 – WSDL-Schnittstellenbeschreibung DPEService“ |
ServiceInformation/Service/Versions /Version/Abstract |
Initiale Version | Initiale Version |
ServiceInformation/Service/Versions /Version/Endpoint/@Location |
Absoluter URL des über Hypertext Transfer Protocol (HTTP) erreichbaren Dienstes | Absoluter URL des über HTTP erreichbaren Dienstes |
ServiceInformation/Service/Versions /Version/EndpointTLS/@Location |
Absoluter URL des über HTTP Secure (HTTPS) erreichbaren Dienstes | Absoluter URL des über HTTPS erreichbaren Dienstes |
ServiceInformation/Service/Versions /Version/WSDL/@Location |
(optional) Absoluter URL der WSDL-Beschreibung | (optional) Absoluter URL der WSDL-Beschreibung |
[<=]
5.10 Meldungen am Kartenterminal
NFDM-A_2107 - Meldungen am Kartenterminal
Alle Operationen des Fachmoduls NFDM MÜSSEN Verlaufsmeldungen mindestens beim Start der Verarbeitung, vor und nach Kartenzugriffen auf die fachlichen eGK-Objekte und vor dem Ende der Verarbeitung an das Kartenterminal senden, in dem die eGK gesteckt ist.
[<=]
NFDM-A_2108 - Terminalanzeigen für PIN-Eingabe
Das Fachmodul NFDM MUSS im Rahmen der PIN-Eingaben am Kartenterminal bei Operationen des Fachmoduls die in Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe“ definierten Werte als Parameter für die PIN-Verifizierung gemäß [gemSpec_Kon#TUC_KON_012] verwenden.
Tabelle 12: Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe
Operation | Parameter actionName |
---|---|
ReadNFD |
Notfalldaten•0x0Blesen |
WriteNFD |
Notfalldaten•0x0Bschreiben |
EraseNFD |
Notfalldaten•0x0Blöschen |
ReadDPE |
Pers.•0x0BErklärungen•0x0Blesen |
WriteDPE |
Pers.•0x0BErklärungen•0x0Bschreiben |
EraseDPE |
Pers.•0x0BErklärungen•0x0Blöschen |
Zeichensatz gemäß ISO 646DE/DIN 66003-Codierung. Max. 32 Zeichen für actionName Leerzeichen werden als „•“ dargestellt. Die Zeilenumbrüche in der Spalte „ Parameter actionName“ sind editorisch bedingt. |
[<=]
Aus Verwendung der o. g. Parameter resultieren folgende Terminal-Anzeigen.
Tabelle 13: Tab_FM_NFDM_037 – Terminal-Anzeigen für PIN-Eingabe
Operation |
Terminalanzeige in LE-Umgebung |
---|---|
ReadNFD |
PIN•0x0Bfür•0x0BNotfalldaten•0x0Blesen 0x0FPIN.eGK: |
WriteNFD |
PIN•0x0Bfür•0x0BNotfalldaten•0x0Bschreiben 0x0FPIN.eGK: |
EraseNFD |
PIN•0x0Bfür•0x0BNotfalldaten•0x0Blöschen 0x0FPIN.eGK: |
ReadDPE |
PIN•0x0Bfür•0x0BPers.•0x0BErklärungen•0x0Blesen 0x0FPIN.eGK: |
WriteDPE |
PIN•0x0Bfür•0x0BPers.•0x0BErklärungen•0x0Bschreiben 0x0FPIN.eGK: |
EraseDPE |
PIN•0x0Bfür•0x0BPers.•0x0BErklärungen•0x0Blöschen 0x0FPIN.eGK: |
0x0B und 0x0F (Sollbruchstellen bzw. Trennung zwischen Nachricht und PIN-Prompt) sind Trennzeichen gemäß [SICCT#5.6.1]. Zeichensatz gemäß ISO 646DE/DIN 66003-Codierung. Max. 48 Zeichen Text + 10 Zeichen PIN-Prompt bei Input Max. 48 Zeichen bei Output Leerzeichen werden als „•“ dargestellt. Die Zeilenumbrüche in der Spalte „Terminalanzeige“ sind editorisch bedingt. |
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
Bedingung |
|
---|---|
ÜE1 |
Die übergebenen Werte der Parameter sind gültig gemäß dem XML-Schema für den jeweiligen Service und den zusätzlichen Konsistenzregeln der jeweiligen Operation. |
ÜE2 |
Das aufrufende Primärsystem bzw. Fachmodul ist im angegebenen Nutzungskontext (Mandant, Arbeitsplatz, Sitzung) berechtigt (autorisiert), auf die lokal gesteckte eGK zuzugreifen. |
ÜE3 |
Das aufrufende Primärsystem bzw. Fachmodul ist im angegebenen Nutzungskontext (Mandant, Arbeitsplatz, User-Id (für HBA)) berechtigt (autorisiert), auf den HBA bzw. die Secure Module Card B (SMC-B) zuzugreifen. |
ÜE4 |
Die Gesundheitsanwendung der eGK (DF.HCA) ist nicht gesperrt (= ist nicht deaktiviert). |
ÜE5 |
Die beteiligte eGK hat keine ältere Versionsnummer als die der Generation 2. |
ÜE6 |
Die durch das Zugriffsprofil der beteiligten LE-Karte (HBA bzw. SMC-B) repräsentierte fachliche Rolle ist berechtigt zur Ausführung der Operation. |
ÜE7 |
Die beteiligte Leistungserbringer(LE)-Karte (HBA bzw. SMC-B) ist freigeschaltet. |
ÜE8 |
Die beteiligten Smartcards sind echt. |
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 6.1 und 6.2 definierten Services.
Tabelle 15: Tab_FM_NFDM_033 – Übergreifende Nachbedingungen
Bedingung |
|
---|---|
ÜN1 |
Ein Zugriffsprotokolleintrag gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ ist als Record im EF.Logging auf der eGK geschrieben. |
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.
NFDM-A_2382 - Nutzung der Signaturrichtlinie NFDM
Das Fachmodul NFDM MUSS dem Konnektor die Signaturrichtlinie SR_DF_NFDM_NOTFALLDATEN aus [gemRL_QES_NFDM] zur Verfügung stellen.
[<=]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
NFDM-A_2109 - NFDService
Das Fachmodul NFDM MUSS dem Primärsystem den Web Service „NFDService“ gemäß Tabelle „Tab_FM_NFDM_004 – NFDService“ anbieten.
Tabelle 16: Tab_FM_NFDM_004 – NFDService
Name |
NFDService |
|
---|---|---|
Version |
1.0.0 |
|
Namensraum |
aktueller Namensraumbezeichner aus Tabelle „Tab_FM_NFDM_049 – WSDL-Schnittstellenbeschreibung NFDService“ |
|
Namensraum-Kürzel |
NFD |
|
Operationen |
Name |
Kurzbeschreibung |
ReadNFD |
NFD von eGK lesen |
|
WriteNFD |
NFD auf eGK schreiben |
|
EraseNFD |
NFD von eGK löschen |
|
WSDL |
[NFDService.wsdl] |
|
XML-Schema |
[NFDService.xsd] |
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]. |
|||
VerificationResult |
Das Element Sig:VerificationResult enthält das Ergebnis der Prüfung als Ampel, den Typ des zugehörigen angenommenen Signaturzeitpunkts und der angenommene Signaturzeitpunkt selbst. 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. |
|||
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. |
|||
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
NFDM-A_2112 - Berechtigungsregeln ReadNFD
Die Operation ReadNFD des Fachmoduls NFDM MUSS die in der Tabelle „Tab_FM_NFDM_023 – Berechtigungsregeln ReadNFD“ spezifizierten Berechtigungsregeln durchsetzen.
Tabelle 18: Tab_FM_NFDM_023 – Berechtigungsregeln ReadNFD
Berechtigungsregeln ReadNFD |
|
|
|
|
|
---|---|---|---|---|---|
Bedingungen |
|||||
|
EmergencyIndicator = true |
j |
n |
n |
n |
UpdateIndicator = true |
- |
j |
n |
n |
|
MRPIN.NFD aktiviert |
- |
- |
j |
n |
|
Berechtigungen |
|||||
Arzt |
x |
x |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Arzt |
x |
x |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Krankenhaus |
x |
x |
MRPIN.NFD(x) |
x |
|
Zahnarzt |
x |
x |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Zahnarzt |
x |
x |
MRPIN.NFD(x) |
x |
|
Apotheker |
--- [FM] |
--- [FM] |
MRPIN. |
MRPIN. |
|
Mitarbeiter Apotheke |
--- |
--- |
MRPIN. |
MRPIN. |
|
Psychotherapeut |
--- [FM] |
--- [FM] |
MRPIN. |
MRPIN. |
|
Anderer Heilberuf |
x |
--- |
MRPIN. |
MRPIN. |
|
Versicherter |
--- |
--- |
--- |
--- |
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) 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. |
Abbildung 6: Abb_FM_NFDM_004 – Ablauf WriteNFD
[<=]
NFDM-A_2115 - Berechtigungsregeln WriteNFD
Die Operation WriteNFD des Fachmoduls NFDM MUSS die in der Tabelle „Tab_FM_NFDM_010 – Berechtigungsregeln WriteNFD“ spezifizierten Berechtigungsregeln durchsetzen.
Tabelle 20: Tab_FM_NFDM_010 – Berechtigungsregeln WriteNFD
Berechtigungsregeln WriteNFD |
|
|
|
---|---|---|---|
Bedingungen |
|||
MRPIN.NFD aktiviert |
j |
n |
|
Berechtigungen |
|||
Arzt |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Arzt |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Krankenhaus |
MRPIN.NFD(x) |
x |
|
Zahnarzt |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Zahnarzt |
MRPIN.NFD(x) |
x |
|
Apotheker |
--- |
--- |
|
Mitarbeiter Apotheke |
--- |
--- |
|
Psychotherapeut |
--- |
--- |
|
Anderer Heilberuf |
--- |
--- |
|
Versicherter |
--- |
--- |
6.1.1.1.3 EraseNFD
NFDM-A_2116-01 - Operation EraseNFD
Der NFDService des Fachmoduls NFDM MUSS die Operation EraseNFD gemäß Tabelle „Tab_FM_NFDM_011 – Operation EraseNFD“ anbieten.
Tabelle 21: Tab_FM_NFDM_011 – Operation EraseNFD
Name |
EraseNFD |
|||
---|---|---|---|---|
Beschreibung |
Die Operation löscht den NFD im Informationselement NFD der Datei EF.NFD der durch den Parameter EhcHandle identifizierten eGK. |
|||
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. |
|||
Aufrufparameter |
||||
Name |
Beschreibung |
|||
Context |
Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] |
|||
EhcHandle |
Verweis auf die eGK, von der der NFD gelöscht werden soll |
|||
HpcHandle |
Verweis auf die LE-Karte (HBA/SMC-B), die zum Zugriff auf die eGK verwendet werden soll |
|||
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 |
Der Wert des Informationselements Länge NFD der Datei EF.NFD der eGK ist ´00 00´. |
|||
N2 |
Der NFD im Informationselement NFD der Datei EF.NFD der eGK ist gelöscht, d.h. alle ursprünglich vom NFD belegten Oktette sind mit ´00´ (NULL) überschrieben worden. |
|||
N3 |
Der Wert des Informationselements 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 Informationselements 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 EraseNFD, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FM_NFDM_005 – Ablauf EraseNFD“ modelliert. Die Umsetzung des Ablaufs mittels Aufrufen von TUCs des Konnektors und interner Operationen des Fachmoduls spezifiziert Tabelle „Tab_FM_NFDM_027 – Umsetzung zu Ablaufaktivitäten EraseNFD“. 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). |
|||
108 |
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. |
|||
5011 |
Die Berechtigungsregel konnte nicht ermittelt werden. |
|||
5012 |
Löschen des NFD (technisch) gescheitert. |
|||
5014 |
ÜE2 ist nicht erfüllt. |
|||
5015 |
ÜE3 ist nicht erfüllt. |
|||
5016 |
ÜE8 ist nicht erfüllt. |
|||
5019 |
PIN-Verifikation gescheitert. |
|||
5020 |
E1 ist nicht erfüllt. |
|||
5500 |
Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird. |
Abbildung 7: Abb_FM_NFDM_005 – Ablauf EraseNFD
[<=]
NFDM-A_2118 - Berechtigungsregeln EraseNFD
Die Operation EraseNFD des Fachmoduls NFDM MUSS die in der Tabelle „Tab_FM_NFDM_013 – Berechtigungsregeln EraseNFD“ spezifizierten Berechtigungsregeln durchsetzen.
Tabelle 22: Tab_FM_NFDM_013 – Berechtigungsregeln EraseNFD
Berechtigungsregeln EraseNFD |
R1 |
R2 |
|
---|---|---|---|
Bedingungen |
|||
|
MRPIN.NFD aktiviert |
j |
n |
Berechtigungen |
|||
|
Arzt |
MRPIN.NFD(x) |
x |
Mitarbeiter Arzt |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Krankenhaus |
MRPIN.NFD(x) |
x |
|
Zahnarzt |
MRPIN.NFD(x) |
x |
|
Mitarbeiter Zahnarzt |
MRPIN.NFD(x) |
x |
|
Apotheker |
--- |
--- |
|
Mitarbeiter Apotheke |
--- |
--- |
|
Psychotherapeut |
--- |
--- |
|
Anderer Heilberuf |
--- |
--- |
|
Versicherter |
--- |
--- |
6.1.1.2 Umsetzung
Die folgenden Unterkapitel beschreiben die Umsetzung der Operationsabläufe des NFDService mittels der aufzurufenden TUCs, die der Konnektor Fachmodulen zur Verfügung stellt, oder internen Operationen des Fachmoduls. Tabellarisch wird jeder Aktion der Aktivitätsdiagramme entweder ein bzw. mehrere TUC des Konnektors zugeordnet oder – falls keine aktionsrelevante Dienstfunktionalität vom Konnektor bereitgestellt wird – eine interne Funktion benannt und deren Aufgabe beschrieben. Werden nicht explizit im Fehlerfalle zurückzugebende Fehlermeldungen genannt, werden die Fehlermeldungen der aufgerufenen TUCs zurückgegeben.
6.1.1.2.1 ReadNFD
Tabelle 23: Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD
1
|
Parameter auf Gültigkeit und Konsistenz prüfen |
|||
---|---|---|---|---|
NFDM:checkArguments |
||||
Eingangsdaten |
||||
Alle Werte der Aufrufparameter der Operation |
||||
Beschreibung |
||||
Die übergebenen Parameter werden auf Gültigkeit gemäß XML-Schema für den Service und Konsistenz gemäß zusätzlichen Konsistenzregeln geprüft. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 3 ab. |
||||
2
|
Zugriffsberechtigung auf eGK prüfen |
|||
|
TUC_KON_000 „Prüfe Zugriffsberechtigung“ |
|||
Eingangsdaten |
||||
mandantId |
Context.MandantId |
|||
clientSystemId |
Context.ClientSystemId |
|||
workplaceId |
Context.WorkplaceId |
|||
userId |
- |
|||
ctId |
- |
|||
cardHandle |
EhcHandle |
|||
needCardSession |
true |
|||
allWorkplaces |
false |
|||
serviceName |
Bei Aufruf durch Primärsystem über SOAP: NFDService |
|||
Beschreibung |
||||
Mittels des TUC-Aufrufs wird überprüft, ob der aufrufende Client (identifiziert über clientSystemId) berechtigt (autorisiert) ist, innerhalb des Mandanten (identifiziert durch mandantId) über den Arbeitsplatz (identifiziert durch workplaceId) auf die lokal gesteckte eGK (identifiziert durch cardHandle) zuzugreifen. Dabei wird gleichzeitig sichergestellt, dass die benötigte Kartensitzung der eGK vom Arbeitsplatz workplaceId gestartet wurde. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5014 ab. |
||||
3
|
Zugriffsberechtigung auf HBA/SMC-B prüfen |
|||
|
TUC_KON_000 „Prüfe Zugriffsberechtigung |
|||
Eingangsdaten |
||||
mandantId |
Context.MandantId |
|||
clientSystemId |
Context.ClientSystemId |
|||
workplaceId |
Context.WorkplaceId |
|||
userId |
für HBA: Context.UserId für SMC-B: - |
|||
ctId |
- |
|||
cardHandle |
HpcHandle |
|||
needCardSession |
true |
|||
allWorkplaces |
false |
|||
serviceName |
Bei Aufruf durch Primärsystem über SOAP: NFDService |
|||
Beschreibung |
||||
Mittels des TUC-Aufrufs wird überprüft, ob der aufrufende Client (identifiziert über clientSystemId) berechtigt (autorisiert) ist, innerhalb des Mandanten (identifiziert durch mandantId) über den Arbeitsplatz (identifiziert durch workplaceId) auf den/die durch cardHandle identifizierten HBA/SMC-B zuzugreifen. Dabei wird der Zugriff auf den HBA verhindert, wenn es eine Kartensitzung zum selben Primärsystem, aber einer anderen userId gibt, deren Sicherheitszustand erhöht ist. Für eine SMC-B wird sichergestellt, dass es sich um eine im Mandanten verwaltete SMC-B handelt. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5015 ab. |
||||
4 |
Sperrung Gesundheitsanwendung auf eGK prüfen |
|||
4.1
|
TUC_KON_026 „Liefere CardSession“ |
|||
Eingangsdaten |
||||
mandantId |
Context.MandantId |
|||
clientSystemId |
Context.ClientSystemId |
|||
cardHandle |
EhcHandle |
|||
userId |
- |
|||
Beschreibung |
||||
Für die eGK ist die Sitzung zu ermitteln. Diese wird für den Aufruf des TUCs im nächsten Teilschritt benötigt. |
||||
4.2
|
TUC_KON_018 „eGK-Sperrung prüfen“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
checkHcaOnly |
true |
|||
Beschreibung |
||||
Über den TUC wird geprüft, ob die Gesundheitsanwendung der eGK, also der Ordner DF.HCA deaktiviert (= gesperrt) ist. Ist die Gesundheitsanwendung gesperrt, bricht die Operation mit Fehler 114 ab. |
||||
5
|
Version der eGK prüfen |
|||
5.1
|
TUC_KON_254 "Liefere Ressourcendetails" |
|||
Eingangsdaten |
||||
clientSystemId |
Context.MandantId |
|||
mandantId |
Context.ClientSystemId |
|||
workplaceId |
Context.WorkplaceId |
|||
cardTerminalId (optional) |
- |
|||
slotId (optional/zulässig nur, wenn auch cardTerminalId angegeben ist) |
- |
|||
cardHandle (optional) |
EhcHandle |
|||
iccsn (optional) |
- |
|||
Beschreibung |
||||
Der Aufruf des TUC liefert ein Informationsobjekt CARD:Card zur über EhcHandle referenzierten eGK äquivalent zur Rückgabe der Operation GetResourceInformation zurück. Dieses Card-Objekt enthält die Versionsinformationen des Betriebssystems und Objektsystems der zugehörigen Karte. |
||||
5.2
|
NFDM:checkEgkVersion |
|||
Eingangsdaten |
||||
In 5.1 ermittelte Version der eGK |
||||
Beschreibung |
||||
Es wird überprüft, ob das Fachmodul die durch die in 5.1 gelesenen Versionsnummern der eGK repräsentierte eGK-Generation unterstützt. Ist dies nicht der Fall, bricht die Operation mit Fehler 113 ab. |
||||
6 |
Berechtigungsregel ermitteln |
|||
6.1 |
TUC_KON_022 „Liefere PIN-Status“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
pinRef |
MRPIN.NFD |
|||
Beschreibung |
||||
Über die Abfrage des PIN-Status wird ermittelt, ob die MRPIN.NFD aktiviert (Der Rückgabewert von TUC_KON_022 für pinStatus ist nicht DISABLED) ist. Für alle anderen Rückgabewerte des TUC_KON_022 für pinStatus wird von einer aktivierten MRPIN.NFD ausgegangen. Dieser Teilschritt ist nur notwendig, wenn zur Bestimmung der Berechtigungsregel zusätzlich die Bedingung bezüglich aktivierter Multireferenz-PIN relevant ist. |
||||
6.2
|
NFDM:getAccessRule |
|||
Eingangsdaten |
||||
EmergencyIndicator, UpdateIndicator und ggf. in 6.1 ermittelter PIN-Status |
||||
Beschreibung |
||||
Es wird die Berechtigungsregel gemäß Berechtigungstabelle ermittelt. |
||||
Tritt in diesem Schritt ein Fehler auf, bricht die Operation mit Fehler 5011 ab. |
||||
7
|
Berechtigung fachliche Rolle prüfen |
|||
7.1
|
TUC_KON_026 “Liefere CardSession” |
|||
Eingangsdaten |
||||
mandantId |
Context.MandantId |
|||
clientSystemId |
Context.ClientSystemId |
|||
cardHandle |
HpcHandle |
|||
userId |
für HBA: Context.UserId für SMC-B: - |
|||
Beschreibung |
||||
Für die LE-Karte ist die Sitzung zu ermitteln. Diese wird für den Aufruf des TUCs im nächsten Teilschritt benötigt. |
||||
7.2
|
TUC_KON_036 „LiefereFachlicheRolle“ |
|||
Eingangsdaten |
||||
cardSession |
In 7.1 ermittelte Kartensitzung der LE-Karte |
|||
Beschreibung |
||||
Der TUC liefert die fachliche Rolle gemäß [gemSpec_PKI#Tab_PKI_254] zurück. |
||||
7.3
|
NFDM:checkRoleAccessRights |
|||
Eingangsdaten |
||||
In 6.2 ermittelte Berechtigungsregel und in 7.2 ermittelte fachliche Rolle |
||||
Beschreibung |
||||
Es wird überprüft, ob die ermittelte fachliche Rolle gemäß der ermittelten Berechtigungsregel zugriffsberechtigt ist. Ist die fachliche Rolle nicht zugriffsberechtigt, bricht die Verarbeitung mit Fehler 5002 ab. |
||||
8
|
Freischaltung HBA/SMC-B prüfen |
|||
|
Die Prüfung der Freischaltung HBA/SMC-B erfolgt implizit in 9. Ist die LE-Karte nicht freigeschaltet, sind die Zugriffsbedingungen auf der LE-Karte für eine Durchführung der C2C-Authentisierung in 9 nicht erfüllt. Der in 9 aufgerufene TUC_KON_005 „Card-to-Card authentisieren“ gibt in diesem Fall den Fehler 4085 zurück. |
|||
9
|
Authentizität und Echtheit der beteiligten Karten mittels C2C prüfen |
|||
|
TUC_KON_005 „Card-to-Card authentisieren“ |
|||
Eingangsdaten |
||||
sourceCardSession |
In 7.1 ermittelte Kartensitzung der LE-Karte |
|||
targetCardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
authMode |
gegenseitig |
|||
Beschreibung |
||||
Durch Aufruf des TUCs wird eine gegenseitige C2C-Authentisierung zwischen eGK und LE-Karte durchgeführt, bei der sich die beiden Karten gegenseitig ihre Echtheit und Authentizität als Smartcards des Gesundheitswesens nachweisen. Gibt der TUC den Fehler 4085 (Zugriffsbedingungen nicht erfüllt) zurück, bedeutet dies, die LE-Karte ist nicht freigeschaltet und die Operation bricht mit Fehler 5001 ab. Bei allen anderen Fehlern, die der TUC zurückgibt, bricht die Operation mit Fehler 5016 ab. |
||||
10
|
Zugriffsprotokolleintrag auf eGK G 2.0 schreiben |
|||
Falls es sich um eine eGK G 2.0 handelt. |
||||
10.1 |
TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
sourceCardSession |
In 7.1 ermittelte Kartensitzung der LE-Karte |
|||
dataType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
|||
accessType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
|||
Beschreibung |
||||
Ein Zugriffsprotokolleintrag wird als Record in die Datei EF.Logging auf der eGK geschrieben. Tritt bei der Zugriffsprotokollierung ein Fehler auf, bricht die Operation mit Fehler 108 ab. |
||||
11 |
Autorisierung des Versicherten mittels PIN-Verifikation einholen |
|||
Falls Berechtigungsregel für die fachliche Rolle eine PIN-Verifikation fordert. |
||||
|
TUC_KON_012 „PIN verifizieren“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
workplaceID |
Context.WorkplaceID |
|||
pinRef |
für fachliche Rollen Arzt, Zahnarzt: MRPIN.NFD für fachliche Rollen Apotheker, Mitarbeiter Apotheke, Psychotherapeut, Versicherter: MRPIN.NFD_READ |
|||
actionName |
Wert von actionName für diese Operation gemäß Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe |
|||
verificationType |
Sitzung |
|||
Beschreibung |
||||
Es wird die PIN für lesenden Zugriff auf den NFD auf der eGK verifiziert. Dabei wird der fachliche Akteur am Display des Kartenterminals aufgefordert, die entsprechende PIN einzugeben (Terminalanzeigen s. Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe“), falls er dies nicht bereits im Rahmen der Kartensitzung getan hat. Die PIN-Eingabe erfolgt über das PIN-Pad des Kartenterminals. Tritt hier ein Fehler auf, bricht die Operation mit Fehler 5019 ab. |
||||
12 |
Zugriffsprotokolleintrag auf eGK schreiben |
|||
Falls es sich um eine eGK G 2.1 oder höher handelt. |
||||
12.1
|
TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
sourceCardSession |
In 7.1 ermittelte Kartensitzung der LE-Karte |
|||
dataType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
|||
accessType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
|||
Beschreibung |
||||
Ein Zugriffsprotokolleintrag wird als Record in die Datei EF.Logging auf der eGK geschrieben. Tritt bei der Zugriffsprotokollierung ein Fehler auf, bricht die Operation mit Fehler 108 ab. |
||||
13
|
NFD-Anwendung der eGK auf Sichtbarkeit prüfen |
|||
|
Die Prüfung, ob die NFD-Anwendung auf der eGK verborgen ist, erfolgt implizit in 14. TUC_KON_202 „LeseDatei“ gibt beim Versuch, den deaktivierten Ordner DF.NFD der eGK zu selektieren, um die darin befindliche Datei EF.StatusNFD zu lesen, den Fehlercode 4086 zurück, woraufhin die Operation mit Fehler 5020 abbricht. |
|||
14
|
Technische Konsistenz des NFD auf eGK prüfen |
|||
14.1
|
TUC_KON_202 „LeseDatei“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 0E´ |
|||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||
folder |
´D276 0001 4407´ |
|||
offset |
- |
|||
length |
- |
|||
Beschreibung |
||||
Es werden alle Informationselemente der Datei EF.StatusNFD der eGK gelesen. Gibt der TUC_KON_202 „LeseDatei“ den Fehlercode 4086 zurück, bricht die Operation mit Fehler 5020 ab. Tritt dabei ein anderer Lesefehler auf, bricht die Operation mit Fehler 111 ab. |
||||
14.2 |
NFDM:checkConsistency |
|||
Eingangsdaten |
||||
In 14.1 aus der Datei EF.StatusNFD gelesene Daten (= alle Informationselemente) |
||||
Beschreibung |
||||
Es wird überprüft, ob der Wert des Informationselements Status der Eingangsdaten „0“ ist. Ist der Wert „0“, ist der NFD technisch konsistent und die Verarbeitung läuft weiter. Ist der Wert „1“, ist der Fehler 5003 mit dem Wert des Informationselements Timestamp der Eingangsdaten im Detailtext zurückzugeben. Ist der Wert weder „0“ noch „1“ gemäß [gemSpec_eGK_Fach_NFDM#2.2], so wurde noch kein NFD angelegt. Die Operation bricht daher mit dem Fehler 5021 ab. |
||||
15 |
Version der NFD-Speicherstruktur der eGK prüfen |
|||
|
NFDM:checkContainerVersion |
|||
Eingangsdaten |
||||
In 14.1 aus der Datei EF.StatusNFD gelesene Daten (= alle Informationselemente) |
||||
Beschreibung |
||||
Es wird überprüft, ob dem Fachmodul die im Informationselement Version_Speicherstruktur der Eingangsdaten gespeicherte Versionsnummer der NFD-Speicherstruktur der eGK bekannt ist. Ist dies nicht der Fall, bricht die Operation mit Fehler 5004 ab. |
||||
16 |
Existenz NFD auf eGK prüfen |
|||
|
Die Prüfung, ob ein NFD auf der eGK existiert, erfolgt implizit in 17. In 17 werden alle Daten aus der Datei EF.NFD (= alle Informationselemente) der eGK gelesen. Das Informationselement Länge NFD enthält die Größe (Anzahl Oktette) des im Informationselement NFD gespeicherten NFD. Nur wenn ein Wert für dieses Informationselement gesetzt ist und dieser ungleich ´00 00´ ist, existiert ein NFD auf der eGK. |
|||
17
|
NFD von eGK lesen |
|||
17.1
|
TUC_KON_202 „LeseDatei“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 10´ |
|||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||
folder |
´D276 0001 4407´ |
|||
offset |
- |
|||
length |
- |
|||
Beschreibung |
||||
Es werden die Daten aus beiden Informationselementen (Länge NFD und NFD) der Datei EF.NFD der eGK gelesen. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 111 ab. |
||||
17.2 |
NFDM:checkSize |
|||
Eingangsdaten |
||||
In 17.1 aus der Datei EF.NFD der eGK gelesene Daten (die beiden Informationselemente Länge NFD und NFD) |
||||
Beschreibung |
||||
Es wird das Informationselement Länge NFD der in 17.1 gelesenen Daten als Größe des NFD (Anzahl Oktette) ausgewertet. Ist die Größenangabe ´00 00´, bedeutet dies, es existiert kein NFD auf der eGK. In diesem Fall bricht die Operation mit Fehler 5021 ab. |
||||
17.3 |
NFDM:extractNfd |
|||
Eingangsdaten |
||||
In 17.1 aus der Datei EF.NFD der eGK gelesene Daten (die beiden Informationselemente Länge NFD und NFD) |
||||
Beschreibung |
||||
Die dem Informationselement Länge NFD folgende und der in 17.2 ausgewerteten Größe entsprechende Anzahl Oktette wird als NFD zur Weiterverarbeitung extrahiert. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 111 ab. |
||||
18 |
NFD dekomprimieren |
|||
|
NFDM:decompress |
|||
Eingangsdaten |
||||
Der in 17.3 extrahierte NFD |
||||
Beschreibung |
||||
Der NFD wird dekomprimiert. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 5006 ab. |
||||
19
|
NFD gegen [NFD_Document.xsd] validieren |
|||
|
Die Validierung des NFD gegen das XML-Schema [NFD_Document.xsd] ist in Schritt 20 inkludiert. TUC_KON_151 „QES Dokumentensignatur prüfen“ beinhaltet einen internen Aufruf von TUC_KON_080 „Dokument validieren“. |
|||
20
|
QES des NFD prüfen |
|||
|
TUC_KON_151 „QES Dokumentensignatur prüfen“ |
|||
Eingangsdaten |
||||
signedDocument |
Der in 18 dekomprimierte NFD als Inhalt des Elements Base64XML eines SIG:Document-Elements |
|||
signatureObject |
||||
|
/SignaturePtr/@WhichDocument |
Wert desID-Attributs (NFD_DOC_ID) des SIG:Document-Elements des Parameters signedDocument |
||
|
/SignaturePtr/@XPath |
/NFD_Document/SignatureArzt |
||
optionalInputParams |
||||
ReturnVerificationReport |
mit gemäß Standardvorgaben des Schemas belegte Unterelemente |
|||
certificates |
- (Das Zertifikat ist in der XML-Signatur enthalten.) |
|||
workplaceId |
Context.WorkplaceId |
|||
xmlSchemas |
[NFD_Document.xsd] |
|||
includeRevocationInfo |
false |
|||
Beschreibung |
||||
Die QES des NFD wird mittels des TUCs geprüft und der NFD gegen das XML-Schema [NFD_Document.xsd] validiert. TUC_KON_151 ruft intern TUC_KON_080 „Dokument validieren“ auf, um die Gültigkeit des NFD gegen sein XML Schema zu prüfen. Bricht TUC_KON_151 mit Fehler 4022 oder 4023 des TUC_KON_080 ab, so bricht die Operation mit Fehler 5017 ab. Liefert der TUC_KON_151 als VerificationResult INVALID oder INCONCLUSIVE, wird die Verarbeitung fortgeführt, jedoch zusätzlich zum VerificationReport an 22 eine Warning mit Fehlercode 5501 übergeben. Bricht TUC_KON_151 die Verarbeitung mit einem Fehler ab, bricht die Operation mit Fehler 5018 ab. |
||||
21 |
NFD kodieren |
|||
|
NFDM:encode |
|||
Eingangsdaten |
||||
Der in 20 QES-geprüfte NFD |
||||
Beschreibung |
||||
Der NFD wird base64-kodiert. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 5009 ab. |
||||
22 |
Response mit gültigen Antwortparametern zusammenstellen |
|||
|
NFDM:prepareResponse |
|||
Eingangsdaten |
||||
In 21 kodierter NFD, in 20 vom TUC_KON_151 „QES-Dokumentensignatur prüfen“ zurückgegebener VerificationReport und ggf. von den Basisdiensten des Konnektors erhaltene Warnings. |
||||
Beschreibung |
||||
Zusammenstellung einer gültigen Response (Rückgabe und Statusrückmeldung) gemäß Tabelle „Tab_FM_NFDM_005 – Operation ReadNFD“ |
6.1.1.2.2 WriteNFD
Tabelle 24: Tab_FM_NFDM_026 – Umsetzung Ablaufaktivitäten WriteNFD
1-3
|
Identisch zu 1-3 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||||
---|---|---|---|---|---|
4 |
Sperrung Gesundheitsanwendung auf eGK prüfen |
||||
4.1
|
TUC_KON_026 „Liefere CardSession“ |
||||
Eingangsdaten |
|||||
mandantId |
Context.MandantId |
||||
clientSystemId |
Context.ClientSystemId |
||||
cardHandle |
EhcHandle |
||||
userId |
- |
||||
Beschreibung |
|||||
Für die eGK ist die Sitzung zu ermitteln. Diese wird für den Aufruf des TUCs im nächsten Teilschritt benötigt. |
|||||
4.2 |
TUC_KON_018 „eGK-Sperrung prüfen“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
checkHcaOnly |
false |
||||
Beschreibung |
|||||
Über den TUC wird geprüft, ob die Gesundheitsanwendung der eGK, also der Ordner DF.HCA deaktiviert (= gesperrt) ist und ob das Zertifikat C.CH.AUT der eGK zeitlich gültig und nicht gesperrt ist. Der Aufruf des TUC schließt die Gültigkeitsprüfung der eGK aus Schritt 10 mit ein. Ist die Gesundheitsanwendung gesperrt, bricht die Operation mit Fehler 114 ab. Ist das Zertifikat nicht gültig (Ergebnis der Offline-Prüfung „ungültig), bricht die Operation mit Fehler 107 ab. Ist das Zertifikat gesperrt (Sperrstatus = „gesperrt“), bricht die Operation mit Fehler 106 ab. |
|||||
5 |
Identisch zu 5 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||||
6
|
Berechtigungsregel ermitteln |
||||
6.1 |
Identisch zu 6.1 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||||
6.2
|
NFDM:getAccessRule |
||||
Eingangsdaten |
|||||
In 5 ermittelte Version der eGK und ggf. in 6.1 ermittelter PIN-Status |
|||||
Beschreibung |
|||||
Es wird die Berechtigungsregel gemäß der für die eGK-Generation relevanten Berechtigungstabelle ermittelt. |
|||||
Tritt in diesem Schritt ein Fehler auf, bricht die Operation mit Fehler 5011 ab. |
|||||
7
|
Berechtigung fachliche Rolle prüfen |
||||
|
Erfolgt implizit durch das Betriebssystem der eGK beim Zugriff auf Dateien der eGK. Gibt in den folgenden Schritten einer der TUCs zum Zugriff auf die eGK den Fehler 4085 zurück, bricht die Operation mit Fehler 5002 ab. |
||||
8-9
|
Identisch zu 8-9 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||||
|
|||||
10 |
Gültigkeit der eGK prüfen |
||||
|
Erfolgt implizit bereits durch Aufruf von TUC_KON_018 in Schritt 4.2 |
||||
11 |
NFD dekodieren |
||||
|
NFDM:decode |
||||
Eingangsdaten |
|||||
Der Wert des Aufrufparameters NFDDocument |
|||||
Beschreibung |
|||||
Der base64-kodierte NFD wird dekodiert. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5007 ab. |
|||||
12 |
NFD validieren |
||||
|
NFDM:validateDocument |
||||
Eingangsdaten |
|||||
Der in 11 dekodierte NFD |
|||||
Beschreibung |
|||||
Die Validierung des NFD besteht aus zwei einzelnen Schritten: · Das Fachmodul prüft das Dokument auf seine Wohlgeformtheit und gegen das XML-Schema [NFD_Document.xsd]. · Das Fachmodul prüft das Dokument gegen alle in [gemSpec_InfoNFDM] aufgeführten Validitätskriterien. Schlägt die Validierung fehl, bricht das Fachmodul NFDM die Operation mit dem Fehler 5017 ab. |
|||||
13
|
Signatur des NFD kryptographisch prüfen |
||||
|
TUC_KON_162 „Kryptographische Prüfung der XML-Dokumentensignatur“ |
||||
Eingangsdaten |
|||||
signedDocument |
NFDDocument als Inhalt des Elements Base64XML eines SIG:Document-Elements |
||||
signatureObject |
|||||
|
/SignaturePtr/@XPath |
/NFD_Document/SignatureArzt |
|||
Beschreibung |
|||||
Mittels des TUC wird die die Signatur kryptographisch geprüft. Der TUC liefert true als Wert des Ausgabeparameters Result, wenn die Signaturprüfung erfolgreich war. Ist die Signatur (kryptographisch) ungültig, liefert der TUC false. In diesem Falle bricht die Operation mit Fehler 5504 ab. |
|||||
14 |
Signaturzertifikat des NFD auf QES-Konformität prüfen |
||||
14.1 |
NFDM:extractSignerCert |
||||
Eingangsdaten |
|||||
Der in 12 validierte NFD |
|||||
Beschreibung |
|||||
Das base64-codierte Signaturzertifikat des NFD wird extrahiert (Wert des Elements /NFD_Document/SignatureArzt/Signature/KeyInfo/X509Data/X509Certificate). |
|||||
14.2
|
NFDM:decode |
||||
Eingangsdaten |
|||||
Das in 14.1 extrahierte Signaturzertifikat |
|||||
Beschreibung |
|||||
Das base64-kodierte Signaturzertifikat wird dekodiert. |
|||||
14.3 |
NFDM:extractQcStatements |
||||
Eingangsdaten |
|||||
Das in 14.2 decodierte Signaturzertifikat |
|||||
Beschreibung |
|||||
Der Wert der Extension QCStatements des Signaturzertifikats wird extrahiert Die Verweise auf die Dokumente, welche die Zertifikatsprofile der HBA-Zertifikate definieren, finden sich in [gemSpec_PKI#5.2]. |
|||||
14.4 |
NFDM:checkQcStatement |
||||
Eingangsdaten |
|||||
Der in 14.3 aus dem Signaturzertifikat extrahierte Wert der Extension QCStatements. |
|||||
Beschreibung |
|||||
Es wird geprüft, ob der in 14.3 aus dem Signaturzertifikat extrahierte Wert der Extension QCStatements ein QCStatement zur QES-Konformität (OID id-etsi-qcs-QcCompliance (0.4.0.1862.1.1)) enthält. Ist kein solcher Wert vorhanden, bricht die Operation die Verarbeitung mit Fehler 5505 ab. |
|||||
Tritt in diesem Schritt ein Fehler auf, bricht die Operation mit Fehler 5505 ab. |
|||||
15 |
Versicherten-ID des NFD prüfen |
||||
15.1
|
NFDM:extractNfdInsurantId |
||||
Eingangsdaten |
|||||
Der in 12 validierte NFD |
|||||
Beschreibung |
|||||
Die Versicherten-ID (Wert des Elements /NFD_Document/Notfalldaten/NFD_Versicherter/Versicherter/Versicherten_ID) wird aus dem NFD extrahiert. |
|||||
15.2 |
TUC_KON_034 „Zertifikatsinformationen extrahieren“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
qes |
false |
||||
Beschreibung |
|||||
Durch den TUC-Aufruf wird das Zertifikat C.CH.AUT von der eGK gelesen und sowohl das Zertifikat als auch der Wert des im folgenden Schritt benötigten SubjectDN an das Fachmodul zurückgeliefert. Die Struktur des SubjectDN ist in [gemSpec_PKI#5.1.2] und [gemSpec_PKI#5.1.3.1] definiert. |
|||||
15.3
|
NFDM:extractCertInsurantId |
||||
Eingangsdaten |
|||||
Der in 15.2 gelesene SubjectDN des in 15.2 gelesenen Zertifikats |
|||||
Beschreibung |
|||||
Aus SubjectDN wird die Versicherten-ID im Feld mit dem Namen organizationalUnitName extrahiert. Anmerkung: Es gibt zwei organizationalUnitName-Felder. 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]). |
|||||
15.4
|
NFDM:checkInsurantIdsForEquality |
||||
Eingangsdaten |
|||||
In 15.1 aus dem NFD extrahierte Versicherten-ID und die in 15.3 aus dem in15.2 gelesenen Zertifikat extrahierte Versicherten-ID |
|||||
Beschreibung |
|||||
Die beiden extrahierten Versicherten-IDs werden auf Gleichheit getestet. Sind die beiden IDs nicht gleich, bricht die Operation mit Fehler 5008 ab. |
|||||
16 |
NFD komprimieren |
||||
|
NFDM:compress |
||||
Eingangsdaten |
|||||
Der in 12 validierte NFD |
|||||
Beschreibung |
|||||
Der in 12 validierte NFD wird komprimiert. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5010 ab. |
|||||
17 |
Zugriffsprotokolleintrag auf eGK schreiben |
||||
Falls es sich um eine eGK G 2.0 handelt. |
|||||
17.1 |
TUC_KON_026 “Liefere CardSession” |
||||
Eingangsdaten |
|||||
mandantId |
Context.MandantId |
||||
clientSystemId |
Context.ClientSystemId |
||||
cardHandle |
HpcHandle |
||||
userId |
für HBA: Context.UserId für SMC-B: - |
||||
Beschreibung |
|||||
Für die LE-Karte ist die Sitzung zu ermitteln. Diese wird für den Aufruf des TUCs im nächsten Teilschritt benötigt. |
|||||
17.2 |
TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
sourceCardSession |
In 17.1 ermittelte Kartensitzung der LE-Karte |
||||
dataType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
||||
accessType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
||||
Beschreibung |
|||||
Ein Zugriffsprotokolleintrag wird als Record in die Datei EF.Logging auf der eGK geschrieben. Tritt bei der Zugriffsprotokollierung ein Fehler auf, bricht die Operation mit Fehler 108 ab. |
|||||
18
|
Autorisierung des Versicherten mittels PIN-Verifikation einholen |
||||
Falls Berechtigungsregel für die fachliche Rolle eine PIN-Verifikation fordert |
|||||
|
TUC_KON_012 „PIN verifizieren“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
workplaceID |
Context.WorkplaceID |
||||
pinRef |
für fachliche Rollen Arzt, Mitarbeiter Arzt, Mitarbeiter Krankenhaus, Zahnarzt, Mitarbeiter Zahnarzt: MRPIN.NFD |
||||
actionName |
Wert von actionName für diese Operation gemäß Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe |
||||
verificationType |
Sitzung |
||||
Beschreibung |
|||||
Es wird die PIN für schreibenden Zugriff auf den NFD auf der eGK verifiziert. Dabei wird der fachliche Akteur am Display des Kartenterminals aufgefordert, die entsprechende PIN einzugeben (Terminalanzeigen s. Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe“), falls er dies nicht bereits im Rahmen der Kartensitzung getan hat. Die PIN-Eingabe erfolgt über das PIN Pad des Kartenterminals. Tritt hier ein Fehler auf, bricht die Operation mit Fehler 5019 ab. |
|||||
19 |
Zugriffsprotokolleintrag auf eGK schreiben |
||||
Falls es sich um eine eGK G 2.1 oder höher handelt. |
|||||
19.1 |
TUC_KON_026 “Liefere CardSession” |
||||
Eingangsdaten |
|||||
mandantId |
Context.MandantId |
||||
clientSystemId |
Context.ClientSystemId |
||||
cardHandle |
HpcHandle |
||||
userId |
für HBA: Context.UserId für SMC-B: - |
||||
Beschreibung |
|||||
Für die LE-Karte ist die Sitzung zu ermitteln. Diese wird für den Aufruf des TUCs im nächsten Teilschritt benötigt. |
|||||
19.2
|
TUC_KON_006 „Datenzugriffsaudit eGK schreiben“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
sourceCardSession |
In 19.1 ermittelte Kartensitzung der LE-Karte |
||||
dataType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
||||
accessType |
gemäß Tabelle „Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK“ |
||||
Beschreibung |
|||||
Ein Zugriffsprotokolleintrag wird als Record in die Datei EF.Logging auf der eGK geschrieben. Tritt bei der Zugriffsprotokollierung ein Fehler auf, bricht die Operation mit Fehler 108 ab. |
|||||
20 |
NFD-Anwendung der eGK auf Sichtbarkeit prüfen |
||||
|
Die Prüfung, ob die NFD-Anwendung auf der eGK verborgen ist, erfolgt implizit in 21. TUC_KON_203 „SchreibeDatei“ gibt beim Versuch, den deaktivierten Ordner DF.NFD der eGK zu selektieren, um in die darin befindliche Datei EF.StatusNFD zu schreiben, den Fehlercode 4086 zurück, woraufhin die Operation mit Fehler 5020 abbricht. |
||||
21 |
NFD-Status-Flag auf eGK setzen |
||||
|
TUC_KON_203 „SchreibeDatei“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 0E´ |
||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
||||
folder |
´D276 0001 4407´ |
||||
offset |
0 |
||||
length |
1 |
||||
dataToBeWritten |
„1“ |
||||
Beschreibung |
|||||
Zur „Transaktionssicherung“ wird das Status-Flag des NFD-Status-Containers (Wert des Informationselements Status der Datei EF.StatusNFD der eGK) vor Beginn des Schreibvorgangs des NFD auf „1“ gesetzt. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode '6581' der eGK zurück, bricht die Operation mit Fehler 5000 ab. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 4086 zurück, bricht die Operation mit Fehler 5020 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
|||||
22
|
Größe des NFD auf eGK schreiben |
||||
22.1
|
NFDM:determineSize |
||||
Eingangsdaten |
|||||
Der in 16 komprimierte NFD |
|||||
Beschreibung |
|||||
Die Größe (Anzahl Oktette) des NFD wird bestimmt. |
|||||
22.2
|
Das Schreiben der in 22.1 ermittelten Größe des NFD auf die eGK erfolgt zusammen mit dem Schreiben des NFD in 23. |
||||
23
|
NFD auf eGK schreiben |
||||
23.1
|
NFDM:concatenate |
||||
Eingangsdaten |
|||||
Die in 22.1 ermittelte Größe (Anzahl Oktette) des NFD und der NFD |
|||||
Beschreibung |
|||||
Die in 22.1 ermittelte Größenangabe wird konkateniert mit dem an 23.1 übergebenen NFD. Die Struktur entspricht [gemSpec_eGK_Fach_NFDM#2.1]). Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
|||||
23.2
|
TUC_KON_203 „SchreibeDatei“ |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 10´ |
||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
||||
folder |
´D276 0001 4407´ |
||||
offset |
- |
||||
length |
- |
||||
dataToBeWritten |
In 23.1 konkatenierte Oktettkette |
||||
Beschreibung |
|||||
Die in 23.1 konkatenierte Oktettkette (Größenangabe und NFD) wird auf die eGK in die Datei EF.NFD geschrieben. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. Hierbei wird die Größe (Anzahl Oktette) des NFD geprüft. Ist die Größe des NFD größer als der in der Datei EF.NFD entsprechend des Objektsystems der eGK zur Verfügung stehende Speicherplatz, liefert der TUC den Fehler 4247. In diesem Fall wird Schritt 24 ausgeführt und die Operation mit dem Fehler 5013 abgebrochen. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
|||||
24 |
NFD-Status-Flag auf eGK zurücksetzen |
||||
Falls die Größenprüfung beim Aufruf von TUC_KON_203 "SchreibeDatei" in 23.2 mit Fehler 4247 endete. |
|||||
24.1
|
TUC_KON_203 „SchreibeDatei |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 0E´ |
||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
|||||
folder |
´D276 0001 4407´ |
||||
offset |
0 |
||||
length |
1 |
||||
dataToBeWritten |
„0“ |
||||
Beschreibung |
|||||
Mit Beendigung des Schreibvorgangs des NFD auf die eGK wird das NFD-Status-Flag (Wert des Informationselements Status der Datei EF.StatusNFD der eGK) wieder zurück auf „0“ gesetzt. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
|||||
24.2 |
Die Operation bricht mit dem Fehler 5013 ab. |
||||
25
|
NFD-Zeitstempel auf eGK aktualisieren |
||||
25.1
|
TUC_KON_351 „Liefere Systemzeit“ |
||||
Eingangsdaten |
|||||
Keine |
|||||
Beschreibung |
|||||
Der TUC-Aufruf liefert die aktuelle Systemzeit des Konnektors. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
|||||
25.2
|
NFDM:formatSystemTime |
||||
Eingangsdaten |
|||||
Im vorherigem Teilschritt ermittelte Systemzeit |
|||||
Beschreibung |
|||||
Die Systemzeit wird für das Schreiben in das Informationselement Timestamp der Datei EF.StatusNFD auf der eGK gemäß [gemSpec_eGK_Fach_NFDM#2.2] formatiert (14 Oktette; YYYYMMDDhhmmss). Das eigentliche Schreiben des NFD-Zeitstempels in das Informationselement Timestamp der Datei EF.StatusNFD der eGK erfolgt aus Performancegründen in 27.2. Dort wird die Oktettkette zur Befüllung der Datei EF.StatusNFD als Ganzes in die Datei EF.StatusNFD der eGK geschrieben. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
|||||
26
|
Versionsnummer NFD-Speicherstruktur der eGK auf eGK aktualisieren |
||||
|
Das Aktualisieren der Versionsnummer der NFD-Speicherstruktur der eGK erfolgt implizit im nächsten Schritt. Dort wird die Oktettkette zur Befüllung der Datei EF.StatusNFD als Ganzes in die Datei EF.StatusNFD auf der eGK geschrieben. |
||||
27 |
NFD-Status-Flag auf eGK zurücksetzen |
||||
27.1
|
NFDM:concatenate |
||||
Eingangsdaten |
|||||
In 25.2 formatierter NFD-Zeitstempel, Versionsnummer der NFD-Speicherstruktur der eGK, gemäß derer der NFD auf die eGK geschrieben wird. |
|||||
Beschreibung |
|||||
Die Oktettkette für den NFD-Status-Container der eGK wird gemäß [gemSpec_eGK_Fach_NFDM#2.2] konkateniert, wobei das Informationselement Version_XML mit 5 Oktetten des Wertes ´00´ zu befüllen ist und das Informationselement Status den Wert „0“ erhält. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
|||||
27.2
|
TUC_KON_203 „SchreibeDatei |
||||
Eingangsdaten |
|||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 0E´ |
||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
||||
folder |
´D276 0001 4407´ |
||||
offset |
- |
||||
length |
- |
||||
dataToBeWritten |
In 27.1. konkatenierte Oktettkette |
||||
Beschreibung |
|||||
Mit Beendigung des Schreibvorgangs des NFD auf die eGK wird das NFD-Status-Flag (Wert des Informationselements Status der Datei EF.StatusNFD der eGK) wieder zurück auf „0“ gesetzt und der NFD-Zeitstempel sowie die Versionsnummer der NFD-Speicherstruktur der eGK gemäß [gemSpec_eGK_Fach_NFDM#2.2] aktualisiert. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
|||||
28 |
Response mit gültigen Antwortparametern zusammenstellen |
||||
|
NFDM:prepareResponse |
||||
Eingangsdaten |
|||||
Ggf. von den Basisdiensten des Konnektors erhaltene Warnings. |
|||||
Beschreibung |
|||||
Zusammenstellung einer gültigen Response (Rückgabe und Statusrückmeldung) gemäß Tabelle „Tab_FM_NFDM_008 – Operation WriteNFD“ |
6.1.1.2.3 EraseNFD
Tabelle 25: Tab_FM_NFDM_027 – Umsetzung zu Ablaufaktivitäten EraseNFD
1-9 |
Übergreifende Erfolgsbedingungen prüfen |
|
---|---|---|
|
Identisch zu 1-9 von WriteNFD (s. Tabelle „Tab_FM_NFDM_026 – Umsetzung Ablaufaktivitäten WriteNFD“) |
|
10
|
Zugriffsprotokolleintrag auf eGK G 2.0 schreiben |
|
Identisch zu 10 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
11
|
Autorisierung des Versicherten mittels PIN-Verifikation einholen |
|
Falls Berechtigungsregel für die fachliche Rolle eine PIN-Verifikation fordert |
||
TUC_KON_012 „PIN verifizieren“ |
||
Eingangsdaten |
||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|
workplaceID |
Context.WorkplaceID |
|
pinRef |
MRPIN.NFD |
|
actionName |
Wert von actionName für diese Operation gemäß Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe |
|
verificationType |
Sitzung |
|
Beschreibung |
||
Es wird die PIN für den löschenden Zugriff auf den NFD auf der eGK verifiziert. Dabei wird der fachliche Akteur am Display des Kartenterminals aufgefordert, die entsprechende PIN einzugeben (Terminalanzeigen s. Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN- Eingabe“), falls er dies nicht bereits im Rahmen der Kartensitzung getan hat. Die PIN-Eingabe erfolgt über das PIN Pad des Kartenterminals. Tritt hier ein Fehler auf, bricht die Operation mit Fehler 5019 ab. |
||
12
|
Zugriffsprotokolleintrag auf eGK schreiben |
|
Identisch zu 12 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
13
|
NFD-Anwendung der eGK auf Sichtbarkeit prüfen |
|
|
Die Prüfung, ob die NFD-Anwendung verborgen ist, erfolgt implizit im nächsten Schritt. TUC_KON_202 „LeseDatei“ gibt beim Versuch, die verborgene (deaktivierte) Anwendung DF.NFD auf der eGK zu selektieren, um die Versionsnummer der NFD-Speicherstruktur der eGK aus dem Informationselement Status der Datei EF.StatusNFD der eGK zu lesen, den Fehlercode 4086 zurück, woraufhin die Operation mit Fehler 5020 abbricht. |
|
14
|
NFD-Status-Flag auf eGK setzen |
|
|
TUC_KON_203 „SchreibeDatei“ |
|
Eingangsdaten |
||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 0E´ |
|
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|
folder |
´D276 0001 4407´ |
|
offset |
0 |
|
length |
1 |
|
dataToBeWritten |
1 |
|
Beschreibung |
||
Zur „Transaktionssicherung“ wird das Status-Flag des NFD-Status-Containers (Wert des Informationselements Status der Datei EF.StatusNFD der eGK) vor Beginn des Löschvorgangs des NFD auf „1“ gesetzt. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 5012 ab. |
||
15 |
Größenangabe NFD auf eGK auf 0 setzen |
|
|
Das Setzen der Größenangabe für den NFD auf der eGK auf 0 erfolgt implizit in 16. |
|
16 |
NFD von eGK löschen |
|
|
TUC_KON_204 „LöscheDateiInhalt“ |
|
Eingangsdaten |
||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 10´ |
|
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|
folder |
´D276 0001 4407´ |
|
offset |
- |
|
Beschreibung |
||
Der Inhalt der Datei EF.NFD der eGK wird durch Oktette mit dem Wert ´00´ (NULL) überschrieben. Dadurch wird einerseits der Inhalt des Informationselement Länge NFD mit ´00 00´ überschrieben und zudem die Daten des im Informationselement NFD gespeicherten NFD „gelöscht“, d. h. mit ´00´ (NULL) überschrieben. Gibt der TUC_KON_204 „LöscheDateiInhalt“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 5012 ab. |
||
17
|
NFD-Zeitstempel auf eGK aktualisieren |
|
17.1 |
TUC_KON_351 „Liefere Systemzeit“ |
|
Eingangsdaten |
||
Keine |
||
Beschreibung |
||
Der TUC liefert die aktuelle Systemzeit des Konnektors. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5012 ab. |
||
17.2
|
NFDM:formatSystemTime |
|
Eingangsdaten |
||
Im vorherigen Teilschritt ermittelte Systemzeit |
||
Beschreibung |
||
Die Systemzeit wird für das Schreiben in das Informationselement Timestamp der Datei EF.StatusNFD der eGK gemäß [gemSpec_eGK_Fach_NFDM#2.2] formatiert (14 Oktette; YYYYMMDDhhmmss). Das eigentliche Schreiben des NFD-Zeitstempels in das Informationselement Timestamp der Datei EF.StatusNFD der eGK erfolgt aus Performancegründen in 19.2. Dort wird die Oktettkette aus NFD-Status-Flag und NFD-Zeitstempel als Ganzes in die Datei EF.StatusNFD der eGK geschrieben. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5012 ab. |
||
18 |
Versionsnummer NFD-Speicherstruktur der eGK auf eGK aktualisieren |
|
|
Das Aktualisieren der Versionsnummer der NFD-Speicherstruktur der eGK erfolgt implizit im nächsten Schritt. Dort wird die Oktettkette zur Befüllung des NFD-Status-Containers als Ganzes in die Datei EF.StatusNFD der eGK geschrieben. |
|
19
|
NFD-Status-Flag auf eGK zurücksetzen |
|
19.1
|
NFDM:concatenate |
|
Eingangsdaten |
||
In 17.2 formatierter NFD-Zeitstempel, Versionsnummer der NFD-Speicherstruktur der eGK, gemäß derer auf die eGK geschrieben wird. |
||
Beschreibung |
||
Die Oktettkette für den NFD-Status-Container der eGK wird gemäß [gemSpec_eGK_Fach_NFDM#2.2] konkateniert, wobei das Informationselement Version_XML mit Oktetten des Wertes ´00´ zu befüllen ist und das Informationselement Status den Wert „0“ erhält. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5012 ab. |
||
19.2. |
TUC_KON_203 „SchreibeDatei“ |
|
Eingangsdaten |
||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 0E´ |
|
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|
folder |
´D276 0001 4407´ |
|
offset |
||
length |
||
dataToBeWritten |
In 20.1 konkatenierte Oktettkette |
|
Beschreibung |
||
Mit Beendigung des Löschvorgangs des NFD auf der eGK wird das NFD-Status-Flag (Wert des Informationselements Status der Datei EF.StatusNFD der eGK) wieder zurück auf „0“ gesetzt und der NFD-Zeitstempel sowie die Versionsnummer der NFD-Speicherstruktur der eGK aktualisiert. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 5012 ab. |
||
20
|
Response mit gültigen Antwortparametern zusammenstellen |
|
|
NFDM:prepareResponse |
|
Eingangsdaten |
||
Ggf. von den Basisdiensten des Konnektors erhaltene Warnings |
||
Beschreibung |
||
Zusammenstellung einer gültigen Response (Rückgabe und Statusrückmeldung) gemäß Tabelle „Tab_FM_NFDM_011 – Operation EraseNFD“ |
6.1.2 Artefakte
6.1.2.1 Schnittstellenbeschreibung
Mit dieser Spezifikation wird die in Tabelle 26 mit Versionsnummer angegebene Schnittstellenbeschreibung ausgeliefert. Die referenzierten XML-Schema definieren die Nachrichtenstruktur (Eingangs- und Ausgabeparameter der Operationen).
Tabelle 26: Tab_FM_NFDM_049 – WSDL-Schnittstellenbeschreibung NFDService
Name der WSDL-Datei |
NFDService.wsdl |
---|---|
Version |
1.0.0 |
Zielnamensraum |
http://ws.gematik.de/conn/nfds/NFDService/WSDL/v1.0 |
verwendete XML-Schemata |
NFDService.xsd (s. Tabelle 27) TelematikError.xsd (s. [gemSpec_OM#A5.3]) |
Die folgende Tabelle gibt die Versionsnummer und den Namensraumbezeichner des mit dieser Spezifikation ausgelieferten XML-Schema an, welches in der WSDL-Schnittstellenbeschreibung für den NFDService referenziert wird.
Tabelle 27: Tab_FM_NFDM_039 – XML-Schema des NFDService
Name der XML-Schema-Datei |
NFDService.xsd |
---|---|
Version des XML-Schemas |
1.0.1 |
Zielnamensraum |
http://ws.gematik.de/conn/nfds/NFDService/v1.0 |
6.1.2.2 NFD-Speicherstruktur auf der eGK
Die NFD-Speicherstruktur der eGK wird in [gemSpec_eGK_Fach_NFDM] definiert. Die Version der NFD-Speicherstruktur wird im Informationselement Version_Speicherstruktur der Datei EF.StatusNFD der eGK gespeichert.
6.1.2.3 Der NFD auf der eGK
Der NFD ist auf der eGK in einer eigenen Datei (EF.NFD) gemäß [RFC1952] gzip-komprimiert gespeichert. Die XML-Struktur des NFD ist in [gemSpec_InfoNFDM#3] definiert.
6.1.3 Testunterstützung
Zur Unterstützung von Tests im Zusammenhang mit dem Funktionsmerkmal werden keine gesonderten Festlegungen getroffen.
6.1.4 Hardwaremerkmale
Das Funktionsmerkmal setzt keine besonderen Hardwaremerkmale voraus.
6.2 DPEService
Der Web Service „DPEService“ stellt seine Operationen dem Primärsystem über die im Folgenden spezifizierte Schnittstelle I_DPE_Management zur Verfügung.
6.2.1 Schnittstelle I_DPE_Management
6.2.1.1 Schnittstellendefinition
NFDM-A_2119 - DPEService
Das Fachmodul NFDM MUSS dem Primärsystem den Web Service „DPEService“ gemäß Tabelle „Tab_FM_NFDM_014 – DPEService“ anbieten.
Tabelle 28: Tab_FM_NFDM_014 – DPEService
Name |
DPEService |
|
---|---|---|
Version |
1.0.0 |
|
Namensraum |
aktueller Namensraumbezeichner aus Tabelle „Tab_FM_NFDM_034 – WSDL-Schnittstellenbeschreibung DPEService |
|
Namensraum-Kürzel |
DPE |
|
Operationen |
Name |
Kurzbeschreibung |
ReadDPE |
DPE von eGK lesen |
|
WriteDPE |
DPE auf eGK schreiben |
|
EraseDPE |
DPE von eGK löschen |
|
WSDL |
[DPEService.wsdl] |
|
XML-Schema |
[DPEService.xsd] |
6.2.1.1.1 ReadDPE
NFDM-A_2120 - Operation ReadDPE
Der DPEService des Fachmoduls NFDM MUSS die Operation ReadDPE gemäß Tabelle „Tab_FM_NFDM_015 – Operation ReadDPE“ anbieten.
Tabelle 29: Tab_FM_NFDM_015 – Operation ReadDPE
Name |
ReadDPE |
|||
---|---|---|---|---|
Beschreibung |
Die Operation liest den DPE im Informationselement DPE der Datei EF.DPE von der durch den Parameter EhcHandle identifizierten eGK und gibt ihn über den Parameter DPEDocument 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 DPE auf der eGK ist nicht verborgen, d. h. der Ordner DF.DPE der eGK darf als Wert des Attributs lifeCycleStatus nicht den Wert „deactivated“ haben. |
|||
E2 |
Der auf der eGK gespeicherte DPE ist technisch konsistent, d. h. der Wert des Informationselement Status der Datei EF.StatusDPE der eGK ist „0“. |
|||
E3 |
Die Version der internen Speicherstruktur (s. 6.2.2.2) der Dateien der Anwendung „Datensatz Persönliche Erklärungen“ der eGK (DPE-Speicherstruktur) wird vom Fachmodul NFDM unterstützt. |
|||
E4 |
Es ist ein gemäß [RFC1952] gzip-komprimierter DPE auf der eGK im Informationselement DPE der Datei EF.DPE gemäß [gemSpec_eGK_Fach_NFDM#3.1] gespeichert, d. h. das Informationselement Länge DPE der Datei EF.DPE der eGK hat einen Wert ungleich ´00 00´. |
|||
E5 |
Der auf der eGK gespeicherte DPE ist valide gegen das XML-Schema für den DPE (s. [gemSpec_InfoNFDM#5]). |
|||
Aufrufparameter |
||||
Name |
Beschreibung |
|||
Context |
Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] |
|||
EhcHandle |
Verweis auf die eGK, von der der DPE gelesen werden soll |
|||
HpcHandle |
Verweis auf die 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 DPE 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] |
|||
DPEDocument |
Von der eGK des Versicherten gelesener, dekomprimierter DPE |
|||
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 DPE (Ausgabeparameter DPEDocument) ist dekomprimiert. |
|||
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 ReadDPE, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FM_NFDM_006 – Ablauf ReadDPE“ modelliert. Die Umsetzung des Ablaufs mittels Aufrufen von TUCs des Konnektors und interner Operationen des Fachmoduls spezifiziert Tabelle „Tab_FM_NFDM_028 – Umsetzung Ablaufaktivitäten ReadDPE“. 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. |
|||
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. |
|||
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 |
|||
5019 |
PIN-Verifikation gescheitert. |
|||
5103 |
E2 ist nicht erfüllt. |
|||
5104 |
E3 ist nicht erfüllt. |
|||
5106 |
Die Dekomprimierung des DPE ist gescheitert. |
|||
5109 |
Die Kodierung des DPE ist gescheitert. |
|||
5114 |
E5 ist nicht erfüllt. |
|||
5120 |
E1 ist nicht erfüllt. |
|||
5121 |
E4 ist nicht erfüllt. |
|||
5500 |
Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird. |
Abbildung 8: Abb_FM_NFDM_006 – Ablauf ReadDPE
NFDM-A_2122 - Berechtigungsregeln ReadDPE
Die Operation ReadDPE des Fachmoduls NFDM MUSS die in der Tabelle „Tab_FM_NFDM_024 – Berechtigungsregeln ReadDPE“ spezifizierten Berechtigungsregeln durchsetzen.
Tabelle 30: Tab_FM_NFDM_024 – Berechtigungsregeln ReadDPE
Berechtigungsregeln ReadDPE |
R1 |
R2 |
R3 |
R4 |
|
---|---|---|---|---|---|
Bedingungen |
|||||
EmergencyIndicator = true |
j |
n |
n |
n |
|
UpdateIndicator = true |
- |
j |
n |
n |
|
MRPIN.DPE aktiviert |
- |
- |
j |
n |
|
Berechtigungen |
|||||
Arzt |
x |
x |
MRPIN.DPE(x) |
x |
|
Mitarbeiter Arzt |
x |
x |
MRPIN.DPE(x) |
x |
|
Mitarbeiter Krankenhaus |
x |
x |
MRPIN.DPE(x) |
x |
|
Mitarbeiter Zahnarzt |
--- |
--- |
--- |
--- |
|
Zahnarzt |
--- |
--- |
--- |
--- |
|
Apotheker |
--- |
--- |
--- |
--- |
|
Mitarbeiter Apotheke |
--- |
--- |
--- |
--- |
|
Psychotherapeut |
--- |
--- |
--- |
--- |
|
Anderer Heilberuf |
--- |
--- |
--- |
--- |
|
Versicherter |
--- |
--- |
--- |
--- |
[<=]
6.2.1.1.2 WriteDPE
NFDM-A_2123 - Operation WriteDPE
Der DPEService des Fachmoduls NFDM MUSS die Operation WriteDPE gemäß Tabelle „Tab_FM_NFDM_017 – Operation WriteDPE“ anbieten.
Tabelle 31: Tab_FM_NFDM_017 – Operation WriteDPE
Name |
WriteDPE |
|||
---|---|---|---|---|
Beschreibung |
Die Operation schreibt den ihr im Parameter DPEDocument übergebenen DPE auf die durch den Parameter EhcHandle identifizierte eGK in das Informationselement DPE der Datei EF.DPE. |
|||
Erfolgsbedingungen |
Die Operation MUSS alle übergreifenden Erfolgsbedingungen aus Tabelle „Tab_FM_NFDM_032 – Übergreifende Erfolgsbedingungen“ und die folgenden überprüfen. |
|||
Bedingung |
||||
E1 |
Der DPE auf der eGK ist nicht verborgen, d. h. der Ordner DF.DPE der eGK darf als Wert des Attributs lifeCycleStatus nicht den Wert „deactivated“ haben. |
|||
E2 |
Der übergebene DPE ist valide gegen das XML-Schema für den DPE (s. [gemSpec_InfoNFDM#5]). |
|||
E3 |
Der Versicherte der eGK ist mit dem Versicherten des DPE 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) ist die gleiche wie die im DPE 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]). |
|||
E4 |
Der DPE ist nicht größer als der auf der eGK im Informationselement DPE der Datei EF.DPE 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 DPE geschrieben werden soll |
|||
HpcHandle |
Verweis auf die LE-Karte (HBA/SMC-B), die zum Zugriff auf die eGK verwendet werden soll |
|||
DPEDocument |
Auf die eGK des Versicherten zu schreibender DPE |
|||
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 DPE in Oktett ist im Informationselement Länge DPE der Datei EF.DPE der eGK gemäß [gemSpec_eGK_Fach_NFDM#3.1] gespeichert. |
|||
N2 |
Der übergebene DPE ist gemäß [RFC1952] gzip-komprimiert auf der eGK im Informationselement DPE der Datei EF.DPE gemäß [gemSpec_eGK_Fach_NFDM#3.1] gespeichert. |
|||
N3 |
Der Wert des Informationselements Timestamp der Datei EF.StatusDPE der eGK ist aktualisiert. |
|||
N4 |
Der Wert des Informationselements Version_Speicherstruktur der Datei EF.StatusDPE der eGK ist aktualisiert mit einer gemäß [gemSpec_eGK_Fach_NFDM#3.2] gültigen Versionsnummer. |
|||
N5 |
Der Wert des Informationselement Status der Datei EF.StatusDPE 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 WriteDPE, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FM_NFDM_007 – Ablauf WriteDPE“ modelliert. Die Umsetzung des Ablaufs mittels Aufrufen von TUCs des Konnektors und interner Operationen des Fachmoduls spezifiziert Tabelle „Tab_FM_NFDM_029 – Umsetzung Ablaufaktivitäten WriteDPE“. 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. |
|||
5107 |
Die Dekodierung des DPE ist gescheitert. |
|||
5108 |
E3 ist nicht erfüllt. |
|||
5014 |
ÜE2 ist nicht erfüllt. |
|||
5015 |
ÜE3 ist nicht erfüllt. |
|||
5016 |
ÜE8 ist nicht erfüllt. |
|||
5019 |
PIN-Verifikation gescheitert. |
|||
5110 |
Die Komprimierung des DPE ist gescheitert. |
|||
5011 |
Die Berechtigungsregel konnte nicht ermittelt werden. |
|||
5113 |
E4 ist nicht erfüllt |
|||
5114 |
E2 nicht erfüllt. |
|||
5120 |
E1 ist nicht erfüllt. |
|||
5500 |
Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird. |
Abbildung 9: Abb_FM_NFDM_007 – Ablauf WriteDPE
[<=]
NFDM-A_2125 - Berechtigungsregeln WriteDPE
Die Operation WriteDPE des Fachmoduls NFDM MUSS die in der Tabelle „Tab_FM_NFDM_019 – Berechtigungsregeln WriteDPE“ spezifizierten Berechtigungsregeln durchsetzen.
Tabelle 32: Tab_FM_NFDM_019 – Berechtigungsregeln WriteDPE
Berechtigungsregeln WriteDPE |
|
|
|
---|---|---|---|
Bedingungen |
|||
MRPIN.DPE aktiviert |
j |
n |
|
Berechtigungen |
|||
Arzt |
MRPIN.DPE(x) |
x |
|
Mitarbeiter Arzt |
MRPIN.DPE(x) |
x |
|
Mitarbeiter Krankenhaus |
MRPIN.DPE(x) |
x |
|
Zahnarzt |
--- |
--- |
|
Mitarbeiter Zahnarzt |
--- |
--- |
|
Apotheker |
--- |
--- |
|
Mitarbeiter Apotheke |
--- |
--- |
|
Psychotherapeut |
--- |
--- |
|
Anderer Heilberuf |
--- |
--- |
|
Versicherter |
--- |
--- |
[<=]
6.2.1.1.3 EraseDPE
NFDM-A_2126-01 - Operation EraseDPE
Der DPEService des Fachmoduls NFDM MUSS die Operation EraseDPE gemäß Tabelle „Tab_FM_NFDM_020 – Operation EraseDPE“ anbieten.
Tabelle 33: Tab_FM_NFDM_020 – Operation EraseDPE
Name |
EraseDPE |
|||
---|---|---|---|---|
Beschreibung |
Die Operation löscht den DPE im Informationselement DPE der Datei EF.DPE der durch den Parameter EhcHandle identifizierten eGK. |
|||
Erfolgsbedingungen |
Die Operation MUSS alle übergreifenden Erfolgsbedingungen aus Tabelle „Tab_FM_NFDM_032 – Übergreifende Erfolgsbedingungen“ und die folgenden überprüfen. |
|||
Bedingung |
||||
E1 |
Der DPE auf der eGK ist nicht verborgen, d. h. der Ordner DF.DPE der eGK darf als Wert des Attributs lifeCycleStatus nicht den Wert „deactivated“ haben. |
|||
Aufrufparameter |
||||
Name |
Beschreibung |
|||
Context |
Angaben zum Aufrufkontext gemäß [gemSpec_Kon#4.1.1.4.1] |
|||
EhcHandle |
Verweis auf die eGK, von der der DPE gelöscht werden soll |
|||
HpcHandle |
Verweis auf die LE-Karte (HBA/SMC-B), die zum Zugriff auf die eGK verwendet werden soll |
|||
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 |
Der Wert des Informationselements Länge DPE der Datei EF.DPE der eGK ist ´00 00´. |
|||
N2 |
Der DPE im Informationselement DPE der Datei EF.DPE der eGK ist gelöscht, d.h. alle ursprünglich vom DPE belegten Oktette sind mit ´00´ (NULL) überschrieben worden. |
|||
N3 |
Der Wert des Informationselements Timestamp der Datei EF.StatusDPE der eGK ist aktualisiert. |
|||
N4 |
Der Wert des Informationselements Version_Speicherstruktur der Datei EF.StatusDPE der eGK ist aktualisiert mit einer gemäß [gemSpec_eGK_Fach_NFDM#3.2] gültigen Versionsnummer. |
|||
N5 |
Der Wert des Informationselements Status der Datei EF.StatusDPE 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 EraseDPE, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FM_NFDM_008 – Ablauf EraseDPE“ modelliert. Die Umsetzung des Ablaufs mittels Aufrufen von TUCs des Konnektors und interner Operationen des Fachmoduls spezifiziert Tabelle „Tab_FM_NFDM_030 – Umsetzung Ablaufaktivitäten EraseDPE“. 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). |
|||
108 |
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. |
|||
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. |
|||
5019 |
PIN-Verifikation gescheitert. |
|||
5112 |
Löschen des DPE (technisch) gescheitert. |
|||
5120 |
E1 ist nicht erfüllt. |
|||
5500 |
Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird. |
Abbildung 10: Abb_FM_NFDM_008 – Ablauf EraseDPE
[<=]
NFDM-A_2128 - Berechtigungsregeln EraseDPE
Die Operation EraseDPE des Fachmoduls NFDM MUSS die in der Tabelle „Tab_FM_NFDM_022 – Berechtigungsregeln EraseDPE“ spezifizierten Berechtigungsregeln durchsetzen.
Tabelle 34: Tab_FM_NFDM_022 – Berechtigungsregeln EraseDPE
Berechtigungsregeln EraseDPE |
|
|
|
---|---|---|---|
Bedingungen |
|||
|
MRPIN.DPE aktiviert |
j |
n |
Berechtigungen |
|||
Arzt |
MRPIN.DPE(x) |
x |
|
Mitarbeit Arzt |
MRPIN.DPE(x) |
x |
|
Mitarbeiter Krankenhaus |
MRPIN.DPE(x) |
x |
|
Zahnarzt |
--- |
--- |
|
Mitarbeiter Zahnarzt |
--- |
--- |
|
Apotheker |
--- |
--- |
|
Mitarbeiter Apotheke |
--- |
--- |
|
Psychotherapeut |
--- |
--- |
|
Anderer Heilberuf |
--- |
--- |
|
Versicherter |
--- |
--- |
[<=]
6.2.1.2 Umsetzung
Die folgenden Unterkapitel beschreiben die Umsetzung der Operationsabläufe des DPEService mittels der aufzurufenden TUCs, die der Konnektor Fachmodulen zur Verfügung stellt, oder internen Operationen des Fachmoduls. Tabellarisch wird jeder Aktion der Aktivitätsdiagramme entweder ein bzw. mehrere TUC des Konnektors zugeordnet oder – falls keine aktionsrelevante Dienstfunktionalität vom Konnektor bereitgestellt wird – eine interne Funktion benannt und deren Aufgabe beschrieben. Werden nicht explizit im Fehlerfalle zurückzugebende Fehlermeldungen genannt, werden die Fehlermeldungen der aufgerufenen TUCs zurückgegeben.
6.2.1.2.1 ReadDPE
Tabelle 35: Tab_FM_NFDM_028 – Umsetzung Ablaufaktivitäten ReadDPE
1
|
Identisch zu 1 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
---|---|---|---|
2
|
Zugriffsberechtigung auf eGK prüfen |
||
TUC_KON_000 „Prüfe Zugriffsberechtigung“ |
|||
Eingangsdaten |
|||
mandantId |
Context.MandantId |
||
clientSystemId |
Context.ClientSystemId |
||
workplaceId |
Context.WorkplaceId |
||
userId |
- |
||
ctId |
- |
||
cardHandle |
EhcHandle |
||
needCardSession |
true |
||
allWorkplaces |
false |
||
serviceName |
Bei Aufruf durch Primärsystem über SOAP: DPEService |
||
Beschreibung |
|||
Mittels des TUC-Aufrufs wird überprüft, ob der aufrufende Client (identifiziert über clientSystemId) berechtigt (autorisiert) ist, innerhalb des Mandanten (identifiziert durch mandantId) über den Arbeitsplatz (identifiziert durch workplaceId) auf die lokal gesteckte eGK (identifiziert durch cardHandle) zuzugreifen. Dabei wird gleichzeitig sichergestellt, dass die benötigte Kartensitzung der eGK vom Arbeitsplatz workplaceId gestartet wurde. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5014 ab. |
|||
3
|
Zugriffsberechtigung auf HBA/SMC-B prüfen |
||
TUC_KON_000 „Prüfe Zugriffsberechtigung |
|||
Eingangsdaten |
|||
mandantId |
Context.MandantId |
||
clientSystemId |
Context.ClientSystemId |
||
workplaceId |
Context.WorkplaceId |
||
userId |
für HBA: Context.UserId für SMC-B: - |
||
ctId |
- |
||
cardHandle |
HpcHandle |
||
needCardSession |
true |
||
allWorkplaces |
false |
||
serviceName |
· Bei Aufruf durch Primärsystem über SOAP: DPEService |
||
Beschreibung |
|||
Mittels des TUC-Aufrufs wird überprüft, ob der aufrufende Client (identifiziert über clientSystemId) berechtigt (autorisiert) ist, innerhalb des Mandanten (identifiziert durch mandantId) über den Arbeitsplatz (identifiziert durch workplaceId) auf den/die durch cardHandle identifizierten HBA/SMC-B zuzugreifen. Dabei wird der Zugriff auf den HBA verhindert, wenn es eine Kartensitzung zum selben Primärsystem, aber einer anderen userId gibt, deren Sicherheitszustand erhöht ist. Für eine SMC-B wird sichergestellt, dass es sich um eine im Mandanten verwaltete SMC-B handelt. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5015 ab. |
|||
4
-
5 |
Identisch zu 4-5 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
6 |
Berechtigungsregel ermitteln |
||
6.1 |
TUC_KON_022 „Liefere PIN-Status“ |
||
Eingangsdaten |
|||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||
pinRef |
MRPIN.DPE |
||
Beschreibung |
|||
Über die Abfrage des PIN-Status wird ermittelt, ob die MRPIN.DPE aktiviert (Der Rückgabewert von TUC_KON_022 für pinStatus ist nicht DISABLED) ist. Für alle anderen Rückgabewerte des TUC_KON_022 für pinStatus wird von einer aktivierten MRPIN.NFD ausgegangen. Dieser Teilschritt ist nur notwendig, wenn zur Bestimmung der Berechtigungsregel zusätzlich die Bedingung bezüglich aktivierter Multireferenz-PIN relevant ist. |
|||
6.2 |
identisch zu 6.2 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
Tritt in diesem Schritt ein Fehler auf, bricht die Operation mit Fehler 5011 ab. |
|||
7 - 9 |
Identisch zu 7-9 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
|
|||
10
|
Zugriffsprotokolleintrag auf eGK G 2.0 schreiben |
||
|
Identisch zu 10 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||
11
|
Autorisierung des Versicherten mittels PIN-Verifikation einholen |
||
Falls Berechtigungsregel für die fachliche Rolle eine PIN-Verifikation fordert |
|||
|
TUC_KON_012 „PIN verifizieren“ |
||
Eingangsdaten |
|||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||
workplaceID |
Context.WorkplaceID |
||
pinRef |
für fachliche Rolle Versicherter: MRPIN.DPE_READ für alle anderen fachlichen Rollen: MRPIN.DPE |
||
actionName |
Wert von actionName für diese Operation gemäß Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe |
||
verificationType |
Sitzung |
||
Beschreibung |
|||
Es wird die PIN für lesenden Zugriff auf den DPE auf der eGK verifiziert. Dabei wird der fachliche Akteur am Display des Kartenterminals aufgefordert, die entsprechende PIN einzugeben (Terminalanzeigen s. Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe“), falls er dies nicht bereits im Rahmen der Kartensitzung getan hat. Die PIN-Eingabe erfolgt über das PIN Pad des Kartenterminals. Tritt hier ein Fehler auf, bricht die Operation mit Fehler 5019 ab. |
|||
12 |
Zugriffsprotokolleintrag auf eGK schreiben |
||
Identisch zu 12 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
|||
13
|
DPE-Anwendung der eGK auf Sichtbarkeit prüfen |
||
|
Die Prüfung, ob die DPE-Anwendung der eGK verborgen ist, erfolgt implizit in 14. TUC_KON_202 „LeseDatei“ gibt beim Versuch, den deaktivierten Ordner DF.DPE der eGK zu selektieren, um die darin befindliche Datei EF.StatusDPE zu lesen, den Fehlercode 4086 zurück, woraufhin die Operation mit Fehler 5120 abbricht. |
||
14 |
Technische Konsistenz des DPE auf eGK prüfen |
||
14.1 |
TUC_KON_202 „LeseDatei“ |
||
Eingangsdaten |
|||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 18´ |
||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
||
folder |
´D276 0001 4408´ |
||
offset |
- |
||
length |
- |
||
Beschreibung |
|||
Es werden alle Informationselemente der Datei EF.StatusDPE der eGK gelesen. Gibt der TUC_KON_202 „LeseDatei“ den Fehlercode 4086 zurück, bricht die Operation mit Fehler 5120 ab. Tritt dabei ein anderer Lesefehler auf, bricht die Operation mit Fehler 111 ab. |
|||
14.2 |
NFDM:checkConsistency |
||
Eingangsdaten |
|||
In 14.1 aus der Datei EF.StatusDPE gelesene Daten (= alle Informationselemente) |
|||
Beschreibung |
|||
Es wird überprüft, ob der Wert des Informationselements Status der Eingangsdaten „0“ ist. Ist der Status „0“, ist der DPE technisch konsistent und die Verarbeitung läuft weiter. Ist der Status „1“, ist der Fehler 5103 mit dem Wert des Informationselements Timestamp der Eingangsdaten im Detailtext zurückzugeben. Ist der Wert weder „0“ noch „1“ gemäß [gemSpec_eGK_Fach_NFDM#2.2], so wurde noch kein DPE angelegt. Die Operation bricht daher mit dem Fehler 5121 ab. |
|||
15
|
Version der DPE-Speicherstruktur der eGK prüfen |
||
|
NFDM:checkContainerVersion |
||
Eingangsdaten |
|||
In 14.1 aus dem DPE-Statuscontainer der eGK gelesene Daten (= alle Informationselemente) |
|||
Beschreibung |
|||
Es wird überprüft, ob dem Fachmodul die im Informationselement Version_Speicherstruktur der Eingangsdaten gespeicherte Versionsnummer der DPE-Speicherstruktur der eGK bekannt ist. Ist dies nicht der Fall, bricht die Operation mit Fehler 5104 ab. |
|||
16 |
Existenz DPE auf eGK prüfen |
||
|
Die Prüfung, ob ein DPE auf der eGK existiert, erfolgt implizit in 17. In 17 werden alle Daten aus der Datei EF.DPE der eGK gelesen. Das Informationselement Länge DPE enthält die Größe (Anzahl Oktette) des im Informationselement DPE gespeicherten DPE. Nur wenn ein Wert für dieses Informationselement gesetzt ist und dieser ungleich ´00 00´ ist, existiert ein DPE auf der eGK. |
||
17 |
DPE von eGK lesen |
||
17.1 |
TUC_KON_202 „LeseDatei“ |
||
Eingangsdaten |
|||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 1B´ |
||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
||
folder |
´D276 0001 4408´ |
||
offset |
- |
||
length |
- |
||
Beschreibung |
|||
Es werden die Daten aus beiden Informationselementen (Länge DPE und DPE) der Datei EF.DPE der eGK gelesen. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 111 ab. |
|||
17.2 |
NFDM:checkSize |
||
Eingangsdaten |
|||
In 17.1 aus der Datei EF.DPE der eGK gelesene Daten (die beiden Informationselemente Länge DPE und DPE) |
|||
Beschreibung |
|||
Es wird das Informationselement Länge DPE der Eingangsdaten als Größe des DPE (Anzahl Oktette) ausgewertet. Ist die Größe ´00 00´, bedeutet dies, es existiert kein DPE auf der eGK. In diesem Fall bricht die Operation mit Fehler 5121 ab. |
|||
17.3
|
NFDM:extractDpe |
||
Eingangsdaten |
|||
In 17.1 aus der Datei EF.DPE der eGK gelesene Daten (die beiden Informationselemente Länge DPE und DPE) |
|||
Beschreibung |
|||
Die dem Informationselement Länge DPE folgende und der in 17.2 ausgewerteten Größe entsprechende Anzahl Oktette wird als DPE zur Weiterverarbeitung extrahiert. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 111 ab. |
|||
18 |
DPE dekomprimieren |
||
|
NFDM:decompress |
||
Eingangsdaten |
|||
Der in 17.3 extrahierte DPE |
|||
Beschreibung |
|||
Der DPE wird dekomprimiert. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 5106 ab. |
|||
19
|
DPE gegen [DPE_Document.xsd] validieren |
||
|
NFDM:validateDocument |
||
Eingangsdaten |
|||
Der in 18 dekomprimierte DPE |
|||
Beschreibung |
|||
Der DPE wird gegen das XML-Schema [DPE_Document.xsd] validiert. Ergibt die Validierung, dass der NFD entweder nicht wohlgeformt oder nicht valide zum Schema ist, so bricht die Operation mit Fehler 5114 ab. |
|||
20
|
DPE kodieren |
||
NFDM:encode |
|||
Eingangsdaten |
|||
Der in 19 validierte DPE |
|||
Beschreibung |
|||
Der DPE wird base64-kodiert. Tritt dabei ein Fehler auf, bricht die Operation mit Fehler 5109 ab. |
|||
21
|
Response mit gültigen Antwortparametern zusammenstellen |
||
|
NFDM:prepareResponse |
||
Eingangsdaten |
|||
In 20 base64-kodierter DPE und ggf. von den Basisdiensten des Konnektors erhaltene Warnings |
|||
Beschreibung |
|||
Zusammenstellung einer gültigen Response (Rückgabe und Statusrückmeldung) gemäß Tabelle „Tab_FM_NFDM_015 – Operation ReadDPE“ |
6.2.1.2.2 WriteDPE
Tabelle 36: Tab_FM_NFDM_029 – Umsetzung Ablaufaktivitäten WriteDPE
1 - 3 |
Identisch zu 1-3 von ReadDPE (s. TabelleTab_FM_NFDM_028 – Umsetzung Ablaufaktivitäten ReadDPE) |
|||||
---|---|---|---|---|---|---|
4 |
Sperrung Gesundheitsanwendung auf eGK prüfen |
|||||
4.1 |
TUC_KON_026 „Liefere CardSession“ |
|||||
Eingangsdaten |
||||||
mandantId |
Context.MandantId |
|||||
clientSystemId |
Context.ClientSystemId |
|||||
cardHandle |
EhcHandle |
|||||
userId |
- |
|||||
Beschreibung |
||||||
Für die eGK ist die Sitzung zu ermitteln. Diese wird für den Aufruf des TUCs im nächsten Teilschritt benötigt. |
||||||
4.2
|
TUC_KON_018 „eGK-Sperrung prüfen“ |
|||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
checkHcaOnly |
false |
|||||
Beschreibung |
||||||
Über den TUC wird geprüft, ob die Gesundheitsanwendung der eGK, also der Ordner DF.HCA deaktiviert (= gesperrt) ist und ob das Zertifikat C.CH.AUT der eGK zeitlich gültig und nicht gesperrt ist. Der Aufruf des TUC schließt die Gültigkeitsprüfung der eGK aus Schritt 10 mit ein. Ist die Gesundheitsanwendung gesperrt, bricht die Operation mit Fehler 114 ab. Ist das Zertifikat nicht gültig (Ergebnis der Offline-Prüfung „ungültig), bricht die Operation mit Fehler 107 ab. Ist das Zertifikat gesperrt (Sperrstatus = „gesperrt“), bricht die Operation mit Fehler 106 ab. |
||||||
5
|
Version der eGK prüfen |
|||||
|
Identisch zu 5 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
|||||
6
|
Berechtigungsregel ermitteln |
|||||
6.1 |
Identisch zu 6.1 von ReadDPE (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD) |
|||||
6.2 |
NFDM:getAccessRule |
|||||
Eingangsdaten |
||||||
Ggf. in 6.1 ermittelter PIN-Status |
||||||
Beschreibung |
||||||
Es wird die Berechtigungsregel gemäß Berechtigungstabelle ermittelt. |
||||||
Tritt in diesem Schritt ein Fehler auf, bricht die Operation mit Fehler 5011 ab. |
||||||
7 - 9 |
Identisch zu 7-9 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
|||||
10
|
Gültigkeit der eGK prüfen |
|||||
|
Erfolgt implizit bereits durch Aufruf von TUC_KON_018 in Schritt 4.2 |
|||||
11
|
DPE dekodieren |
|||||
|
NFDM:decode |
|||||
Eingangsdaten |
||||||
Der Wert des Aufrufparameters DPEDocument |
||||||
Beschreibung |
||||||
Der base64-kodierte DPE wird dekodiert. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5107 ab. |
||||||
12 |
DPE gegen [DPE_Document.xsd] validieren |
|||||
NFDM:validateDocument |
||||||
Eingangsdaten |
||||||
Der in 11 dekodierte DPE |
||||||
Beschreibung |
||||||
Der DPE wird gegen das XML-Schema [DPE_Document.xsd] validiert. Ergibt die Validierung, dass der NFD entweder nicht wohlgeformt oder nicht valide zum Schema ist, so bricht die Operation mit Fehler 5114 ab. |
||||||
13 |
Versicherten-ID des DPE prüfen |
|||||
13.1
|
NFDM:extractDpeInsurantId |
|
||||
Eingangsdaten |
||||||
Der in 12 validierte DPE |
||||||
Beschreibung |
||||||
Die Versicherten-ID (Wert des Elements /DPEDocument/Persönliche_Erklärungen/DPE_Versicherter/Versicherter/Versicherten_ID) wird aus dem DPE extrahiert. |
||||||
13.2
|
TUC_KON_034 „Zertifikatsinformationen extrahieren“ |
|||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
qes |
false |
|||||
Beschreibung |
||||||
Durch den TUC-Aufruf wird das Zertifikat C.CH.AUT von der eGK gelesen und sowohl das Zertifikat als auch der Wert des im folgenden Schritt benötigten SubjectDN an das Fachmodul zurückgeliefert. Die Struktur des SubjectDN ist in [gemSpec_PKI#5.1.2] und [gemSpec_PKI#5.1.3.1] definiert. |
||||||
13.3 |
NFDM:extractCertInsurantId |
|||||
Eingangsdaten |
||||||
Der in 13.2 gelesene SubjectDN des in 13.2 gelesenen Zertifikats |
||||||
Beschreibung |
||||||
Aus SubjectDN wird die Versicherten-ID im Feld mit dem Namen organizationalUnitName extrahiert. Anmerkung: Es gibt zwei organizationalUnitName-Felder. 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]). |
||||||
13.4
|
NFDM:checkInsurantIdsForEquality |
|||||
Eingangsdaten |
||||||
In 13.1 aus dem DPE extrahierte Versicherten ID und die in 13.3 aus dem in 13.2 gelesenen Zertifikat extrahierte Versicherten-ID |
||||||
Beschreibung |
||||||
Die beiden extrahierten Versicherten-IDs werden auf Gleichheit getestet. Sind die beiden IDs nicht gleich, bricht die Operation mit Fehler 5108 ab. |
||||||
14 |
DPE komprimieren |
|||||
|
NFDM:compress |
|||||
Eingangsdaten |
||||||
Der in 12 validierte DPE |
||||||
Beschreibung |
||||||
Der in 12 validierte DPE wird komprimiert. Tritt in diesem Schritt ein Fehler auf, bricht die Operation mit Fehler 5110 ab. |
||||||
15 |
Zugriffsprotokolleintrag auf eGK G 2.0 schreiben |
|||||
|
Identisch zu 10 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
|||||
16
|
Autorisierung des Versicherten mittels PIN-Verifikation einholen |
|||||
Falls Berechtigungsregel für die fachliche Rolle eine PIN-Verifikation fordert |
||||||
|
TUC_KON_012 „PIN verifizieren“ |
|||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
workplaceID |
Context.WorkplaceID |
|||||
pinRef |
MRPIN.DPE |
|||||
actionName |
Wert von actionName für diese Operation gemäß Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe |
|||||
verificationType |
Sitzung |
|||||
Beschreibung |
||||||
Es wird die PIN für den schreibenden Zugriff auf den DPE auf der eGK verifiziert. Dabei wird der fachliche Akteur am Display des Kartenterminals aufgefordert, die entsprechende PIN einzugeben (Terminalanzeigen s. Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe), falls er dies nicht bereits im Rahmen der Kartensitzung getan hat. Die PIN-Eingabe erfolgt über das PIN Pad des Kartenterminals. Tritt hier ein Fehler auf, bricht die Operation mit Fehler 5019 ab. |
||||||
17
|
Zugriffsprotokolleintrag auf eGK schreiben |
|||||
Identisch zu 12 von ReadNFD (s. Tabelle „Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD“) |
||||||
18 |
DPE-Anwendung der eGK auf Sichtbarkeit prüfen |
|||||
Die Prüfung, ob die DPE-Anwendung auf der eGK verborgen ist, erfolgt implizit in 19. TUC_KON_203 „SchreibeDatei“ gibt beim Versuch, den deaktivierten Ordner DF.DPE der eGK zu selektieren, um in die darin befindliche Datei EF.StatusDPE zu schreiben, den Fehlercode 4086 zurück, woraufhin die Operation mit Fehler 5120 abbricht. |
||||||
19
|
DPE-Status-Flag auf eGK setzen |
|||||
TUC_KON_203 „SchreibeDatei“ |
||||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 18´ |
|||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||||
folder |
´D276 0001 4408´ |
|||||
offset |
0 |
|||||
length |
1 |
|||||
dataToBeWritten |
„1“ |
|||||
Beschreibung |
||||||
Zur „Transaktionssicherung“ wird der Wert des Informationselements Status der Datei EF.StatusDPE der eGK vor Beginn des Schreibvorgangs des DPE auf „1“ gesetzt. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 4086 zurück, bricht die Operation mit Fehler 5120 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
||||||
20
|
Größe des DPE auf eGK schreiben |
|||||
20.1
|
NFDM:determineSize |
|||||
Eingangsdaten |
||||||
Der in 14 komprimierte DPE |
||||||
Beschreibung |
||||||
Die Größe (Anzahl Oktette) des DPE wird bestimmt. |
||||||
20.2 |
Das Schreiben der in 20.1 ermittelten Größe des DPE auf die eGK erfolgt zusammen mit dem Schreiben des DPE in 21. |
|||||
21 |
DPE auf eGK schreiben |
|||||
21.1
|
NFDM:concatenate |
|||||
Eingangsdaten |
||||||
DPE und die in 20.1 ermittelte Größe (Anzahl Oktette) des DPE |
||||||
Beschreibung |
||||||
Die in 20.1 ermittelte Größenangabe wird konkateniert mit dem an 21.1 übergebenen DPE. Die Struktur entspricht [gemSpec_eGK_Fach_NFDM#3.1]. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
||||||
21.2
|
TUC_KON_203 „SchreibeDatei“ |
|||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 1B´ |
|||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||||
folder |
´D276 0001 4408´ |
|||||
offset |
- |
|||||
length |
- |
|||||
dataToBeWritten |
In 21.1 konkatenierte Oktettkette |
|||||
Beschreibung |
||||||
Die in 21.1 konkatenierte Oktettkette (Größenangabe und DPE) wird auf die eGK in die Datei EF.DPE geschrieben. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. Hierbei wird die Größe (Anzahl Oktette) des DPE geprüft. Ist die Größe des DPE größer als der in der Datei EF.DPE entsprechend des Objektsystems der eGK zur Verfügung stehende Speicherplatz, liefert der TUC den Fehler 4247. In diesem Fall wird Schritt 22 ausgeführt und die Operation mit dem Fehler 5113 abgebrochen. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
||||||
22 |
DPE-Status-Flag auf eGK zurücksetzen |
|||||
Falls die Größenprüfung beim Aufruf von TUC_KON_203 "SchreibeDatei" in 21.2 mit Fehler 4247 endete. |
||||||
22.1
|
TUC_KON_203 „SchreibeDatei“ |
|||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 18´ |
|||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
||||||
folder |
´D276 0001 4408´ |
|||||
offset |
0 |
|||||
length |
1 |
|||||
dataToBeWritten |
„0“ |
|||||
Beschreibung |
||||||
Mit Beendigung des Schreibvorgangs des DPE auf die eGK wird das DPE-Status-Flag (Wert des Informationselements Status der Datei EF.StatusDPE der eGK) wieder zurück auf „0“ gesetzt. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
||||||
22.2 |
Die Operation bricht mit dem Fehler 5113 ab. |
|||||
23
|
DPE-Zeitstempel auf eGK aktualisieren |
|||||
23.1 |
TUC_KON_351 „Liefere Systemzeit“ |
|||||
Eingangsdaten |
||||||
Keine |
||||||
Beschreibung |
||||||
Der TUC liefert die aktuelle Systemzeit des Konnektors. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
||||||
23.2 |
NFDM:formatSystemTime |
|||||
Eingangsdaten |
||||||
Im vorherigen Teilschritt ermittelte Systemzeit |
||||||
Beschreibung |
||||||
Die Systemzeit wird für das Schreiben in das Informationselement Timestamp der Datei EF.StatusDPE der eGK gemäß [gemSpec_eGK_Fach_NFDM#3.2] formatiert (14 Oktette; YYYYMMDDhhmmss). Das eigentliche Schreiben des DPE-Zeitstempels in das Informationselement Timestamp der Datei EF.StatusDPE der eGK erfolgt aus Performancegründen in 25.2. Dort wird die Oktettkette zur Befüllung der Datei EF.StatusDPE als Ganzes in die Datei EF.StatusDPE der eGK geschrieben. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
||||||
24 |
Versionsnummer DPE-Speicherstruktur der eGK auf eGK aktualisieren |
|||||
|
Das Aktualisieren der Versionsnummer erfolgt implizit im nächsten Schritt. Dort wird die Oktettkette zur Befüllung der Datei EF.StatusDPE als Ganzes in die Datei EF.StatusDPE auf der eGK geschrieben. |
|||||
25 |
DPE-Status-Flag auf eGK zurücksetzen |
|||||
25.1
|
NFDM:concatenate |
|||||
Eingangsdaten |
||||||
In 23.2 formatierter DPE-Zeitstempel, Versionsnummer der DPE-Speicherstruktur der eGK, gemäß derer der DPE auf die eGK geschrieben wird. |
||||||
Beschreibung |
||||||
Die Oktettkette für den DPE-Status-Container wird gemäß [gemSpec_eGK_Fach_NFDM#3.2] konkateniert, wobei das Informationselement Version_XML mit 5 Oktetten des Wertes ´00´ zu befüllen ist und das Informationselement Status den Wert „0“ erhält. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 112 ab. |
||||||
25.2 |
TUC_KON_203 „SchreibeDatei“ |
|||||
Eingangsdaten |
||||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 18´ |
|||||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||||
folder |
´D276 0001 4408´ |
|||||
offset |
||||||
length |
||||||
dataToBeWritten |
In 25.1 konkatenierte Oktettkette |
|||||
Beschreibung |
||||||
Mit Beendigung des Schreibvorgangs des DPE auf die eGK wird das DPE-Status-Flag (Wert des Informationselements Status der Datei EF.StatusDPE der eGK) wieder zurück auf „0“ gesetzt und der DPE-Zeitstempel sowie die Versionsnummer der DPE-Speicherstruktur der eGK gemäß [gemSpec_eGK_Fach_NFDM#3.2] aktualisiert. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 112 ab. |
||||||
26
|
Response mit gültigen Antwortparametern zusammenstellen |
|||||
|
NFDM:prepareResponse |
|||||
Eingangsdaten |
||||||
Ggf. von den Basisdiensten des Konnektors erhaltene Warnings |
||||||
Beschreibung |
||||||
Zusammenstellung einer gültigen Response (Rückgabe und Statusrückmeldung) gemäß Tabelle „Tab_FM_NFDM_017 – Operation WriteDPE“ |
6.2.1.2.3 EraseDPE
Tabelle 37: Tab_FM_NFDM_030 – Umsetzung Ablaufaktivitäten EraseDPE
1-9 |
Übergreifende Erfolgsbedingungen prüfen |
|||
---|---|---|---|---|
|
Identisch zu 1-9 von WriteDPE (s. Tabelle „Tab_FM_NFDM_029 – Umsetzung Ablaufaktivitäten WriteDPE“) |
|||
10 |
Zugriffsprotokolleintrag auf eGK G 2.0 schreiben |
|||
Identisch zu 10 von ReadDPE (s. Tabelle „Tab_FM_NFDM_028 – Umsetzung Ablaufaktivitäten ReadDPE“) |
||||
11
|
Autorisierung des Versicherten mittels PIN-Verifikation einholen |
|||
Falls Berechtigungsregel für die fachliche Rolle eine PIN-Verifikation fordert |
||||
TUC_KON_012 „PIN verifizieren“ |
||||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
workplaceID |
Context.WorkplaceID |
|||
pinRef |
MRPIN.DPE |
|||
actionName |
Wert von actionName für diese Operation gemäß Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe |
|||
verificationType |
Sitzung |
|||
Beschreibung |
||||
Es wird die PIN für den löschenden Zugriff auf den DPE auf der eGK verifiziert. Dabei wird der fachliche Akteur am Display des Kartenterminals aufgefordert, die entsprechende PIN einzugeben (Terminalanzeigen s. Tabelle „Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe“), falls er dies nicht bereits im Rahmen der Kartensitzung getan hat. Die PIN-Eingabe erfolgt über das PIN Pad des Kartenterminals. Tritt hier ein Fehler auf, bricht die Operation mit Fehler 5019 ab. |
||||
12
|
Zugriffsprotokolleintrag auf eGK schreiben |
|||
Identisch zu 12 von ReadDPE (s. Tabelle „Tab_FM_NFDM_028 – Umsetzung Ablaufaktivitäten ReadDPE“) |
||||
13 |
DPE-Anwendung der eGK auf Sichtbarkeit prüfen |
|||
|
Die Prüfung, ob die DPE-Anwendung verborgen ist, erfolgt implizit im nächsten Schritt. TUC_KON_202 „LeseDatei“ gibt beim Versuch, die verborgene (deaktivierte) Anwendung DF.DPE der eGK zu selektieren, um die Versionsnummer der DPE-Speicherstruktur der eGK aus dem Informationselement Status der Datei EF.StatusDPE der eGK zu lesen, den Fehlercode 4086 zurück, woraufhin die Operation mit Fehler 5120 abbricht. |
|||
14
|
DPE-Status-Flag auf eGK setzen |
|||
|
TUC_KON_203 „SchreibeDatei“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 18´ |
|||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||
folder |
´D276 0001 4408´ |
|||
offset |
0 |
|||
length |
1 |
|||
dataToBeWritten |
1 |
|||
Beschreibung |
||||
Zur „Transaktionssicherung“ wird das Status-Flag des DPE-Status-Containers (Wert des Informationselements Status der Datei EF.StatusDPE der eGK) vor Beginn des Löschvorgangs des DPE auf „1“ gesetzt. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 5112 ab. |
||||
15 |
Größenangabe DPE auf eGK auf 0 setzen |
|||
|
Das Setzen der Größenangabe für den DPE auf der eGK auf 0 erfolgt implizit in 16. |
|||
16 |
DPE von eGK löschen |
|||
|
TUC_KON_204 „LöscheDateiInhalt“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 1B´ |
|||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||
folder |
´D276 0001 4408´ |
|||
offset |
- |
|||
Beschreibung |
||||
Der Inhalt der Datei EF.DPE auf der eGK wird durch Oktette mit dem Wert ´00´ (NULL) überschrieben. Dadurch wird einerseits der Inhalt des Informationselements Länge DPE mit ´00 00´ überschrieben und zudem die Daten des im Informationselement DPE gespeicherten DPE „gelöscht“, d. h. mit ´00´ (NULL) überschrieben. Gibt der TUC_KON_204 „LöscheDateiInhalt“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 5112 ab. |
||||
17
|
DPE_Zeitstempel auf eGK aktualisieren |
|||
17.1
|
TUC_KON_351 „Liefere Systemzeit“ |
|||
Eingangsdaten |
||||
Keine |
||||
Beschreibung |
||||
Der TUC liefert die aktuelle Systemzeit des Konnektors Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5112 ab. |
||||
17.2 |
NFDM:formatSystemTime |
|||
Eingangsdaten |
||||
Im vorherigen Teilschritt ermittelte Systemzeit. |
||||
Beschreibung |
||||
Die Systemzeit wird für das Schreiben in das Informationselement Timestamp der Datei EF.StatusDPE der eGK gemäß [gemSpec_eGK_Fach_NFDM#3.2] formatiert (14 Oktette; YYYYMMDDhhmmss). Das eigentliche Schreiben des DPE-Zeitstempels in die Datei EF.StatusDPE der eGK erfolgt aus Performancegründen in 19.2. Dort wird die Oktettkette aus DPE-Status-Flag und DPE-Zeitstempel als Ganzes in die Datei EF.StatusDPE der eGK geschrieben. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5112 ab. |
||||
18 |
Versionsnummer DPE-Speicherstruktur der eGK auf eGK aktualisieren |
|||
|
Das Aktualisieren der Versionsnummer der DPE-Speicherstruktur der eGK erfolgt implizit im nächsten Schritt. Dort wird die Oktettkette zur Befüllung des DPE-Status-Containers als Ganzes in die Datei EF.StatusDPE der eGK geschrieben. |
|||
19 |
DPE-Status-Flag auf eGK zurücksetzen |
|||
19.1
|
NFDM:concatenate |
|||
Eingangsdaten |
||||
In 17.2 formatierter Zeitstempel, Versionsnummer der DPE-Speicherstruktur der eGK, gemäß derer auf die eGK geschrieben wird. |
||||
Beschreibung |
||||
Die Oktettkette für den DPE-Status-Container der eGK wird gemäß [gemSpec_eGK_Fach_NFDM#3.2] konkateniert, wobei das Informationselement Version_XML mit Oktetten des Wertes ´00´ zu befüllen ist und das Informationselement Status den Wert „0“ erhält. Tritt hierbei ein Fehler auf, bricht die Operation mit Fehler 5112 ab. |
||||
19.2
|
TUC_KON_203 „SchreibeDatei“ |
|||
Eingangsdaten |
||||
cardSession |
In 4.1 ermittelte Kartensitzung der eGK |
|||
fileIdentifier (optional/verpflichtend, wenn kein sfid angegeben ist) |
´D0 18´ |
|||
sfid (optional/verpflichtend, wenn kein fileIdentifier angegeben ist) |
- |
|||
folder |
´D276 0001 4408´ |
|||
offset |
||||
length |
||||
dataToBeWritten |
In 20.1 konkatenierte Oktettkette |
|||
Beschreibung |
||||
Mit Beendigung des Löschvorgangs des DPE auf der eGK wird das DPE-Status-Flag (Wert des Informationselements Status der Datei EF.StatusDPE der eGK) wieder zurück auf „0“ gesetzt und der DPE-Zeitstempel sowie die Versionsnummer der DPE-Speicherstruktur geschrieben. Gibt der TUC_KON_203 „SchreibeDatei“ den Fehlercode 6581 der eGK zurück, bricht die Operation mit Fehler 5000 ab. In allen anderen Fehlerfällen bricht die Operation mit Fehler 5112 ab. |
||||
20
|
Response mit gültigen Antwortparametern zusammenstellen |
|||
|
NFDM:prepareResponse |
|||
Eingangsdaten |
||||
Ggf. von den Basisdiensten des Konnektors erhaltene Warnings |
||||
Beschreibung |
||||
Zusammenstellung einer gültigen Response (Rückgabe und Statusrückmeldung) gemäß Tabelle „Tab_FM_NFDM_020 – Operation EraseDPE“ |
6.2.2 Artefakte
6.2.2.1 Schnittstellenbeschreibung
Mit dieser Spezifikation wird die in Tabelle 38 mit Versionsnummer angegebene Schnittstellenbeschreibung ausgeliefert. Die referenzierten XML-Schemata definieren die Nachrichtenstruktur (Eingangs- und Ausgabeparameter der Operationen).
Tabelle 38: Tab_FM_NFDM_034 – WSDL-Schnittstellenbeschreibung DPEService
Name der WSDL-Datei |
DPEService.wsdl |
---|---|
Version |
1.0.0 |
Zielnamensraum |
http://ws.gematik.de/conn/nfds/DPEService/WSDL/v1.0 |
verwendete XML-Schemata |
DPEService.xsd (s. Tabelle 39) TelematikError.xsd (s. [gemSpec_OM#A5.3]) |
Die folgende Tabelle gibt die Versionsnummer und den Namensraumbezeichner des mit dieser Spezifikation ausgelieferten XML-Schema an, welches in der WSDL-Schnittstellenbeschreibung für den DPEService referenziert wird.
Tabelle 39: Tab_FM_NFDM_035 – XML-Schema des DPEService inkl. Version
Name der XML-Schema-Datei |
DPEService.xsd |
---|---|
Schemaversion |
1.0.0 |
Zielnamensraum |
http://ws.gematik.de/conn/nfds/DPEService/v1.0 |
6.2.2.2 DPE-Speicherstruktur der eGK
Die DPE-Speicherstruktur der eGK wird in [gemSpec_eGK_Fach_NFDM] definiert. Die Version der DPE-Speicherstruktur wird im Informationselement Version_Speicherstruktur der Datei EF.StatusDPE der eGK gespeichert.
6.2.2.3 Der DPE auf der eGK
Der DPE ist auf der Karte in der Datei EF.DPE gemäß [RFC1952] gzip-komprimiert gespeichert. Die XML-Struktur des DPE ist in [gemSpec_InfoNFDM#5] definiert.
6.2.3 Testunterstützung
Zur Unterstützung von Tests im Zusammenhang mit dem Funktionsmerkmal werden keine gesonderten Festlegungen getroffen.
6.2.4 Hardware-Merkmale
Das Funktionsmerkmal setzt keine besonderen Hardware-Merkmale voraus.
7 Informationsmodell
Das (technische) Informationsmodell NFDM ist in [gemSpec_InfoNFDM] spezifiziert.
Schnittstellenbeschreibungen und Speicherstruktur der eGK sind im jeweiligen Unterkapitel „Artefakte“ der Funktionsmerkmale aufgeführt.
8 Verteilungssicht
Das Fachmodul NFDM ist integraler Bestandteil der dezentralen Komponente „Konnektor“. Die Hardware-Merkmale des Konnektors sind in [gemSpec_Kon#4.4] spezifiziert. Eine weitergehende Darstellung der hardwareseitigen Verteilung des Fachmoduls NFDM bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird daher nicht benötigt.
9 Anhang A – Verzeichnisse
9.1 Abkürzungen
Kürzel |
Erläuterung |
---|---|
AID |
Application Identifier |
C2C |
Card-to-Card |
DF |
Dedicated File |
DPE |
Datensatz „Persönliche Erklärungen“ |
EF |
Elementary File |
eGK |
elektronische Gesundheitskarte |
FID |
File Identifier |
ID |
Identifier |
KVNR |
Krankenversichertennummer |
LE |
Leistungserbringer |
HBA |
Heilberufsausweis |
HSM |
Hardware Security Module |
HTTP |
Hypertext Transfer Protocol |
HTTPS |
Hypertext Transfer Protocol Secure |
NFD |
Notfalldatensatz |
NFDM |
Notfalldaten-Management |
PID |
Password Identifier |
PIN |
Personal Identification Number |
QES |
Qualifizierte Elektronische Signatur |
RFC |
Request for Comments |
SMC |
Security Module Card |
SOAP |
Simple Object Access Protocol |
SubjectDN |
Subject Distinguished Name |
TI |
Telematikinfrastruktur |
TLS |
Transport Layer Security |
TUC |
Technischer Use Case |
URL |
Uniform Resource Locator |
UTF |
Unicode Transformation Format |
WSDL |
Web Service Description Language |
XML |
Extensible Markup Language |
9.2 Glossar
Das Glossar wird als eigenständiges Dokument [gemGlossar] zur Verfügung gestellt.
9.3 Abbildungsverzeichnis
- Abbildung 1: Vom Fachmodul genutzte Basisdienste des Konnektors
- Abbildung 2: Services Fachmodul NFDM
- Abbildung 3: Logische Zerlegung Fachmodul NFDM
- Abbildung 4: Abb_FM_NFDM_001 – Ablauf „Übergreifende Erfolgsbedingungen prüfen“
- Abbildung 5: Abb_FM_NFDM_003 – Ablauf ReadNFD
- Abbildung 6: Abb_FM_NFDM_004 – Ablauf WriteNFD
- Abbildung 7: Abb_FM_NFDM_005 – Ablauf EraseNFD
- Abbildung 8: Abb_FM_NFDM_006 – Ablauf ReadDPE
- Abbildung 9: Abb_FM_NFDM_007 – Ablauf WriteDPE
- Abbildung 10: Abb_FM_NFDM_008 – Ablauf EraseDPE
9.4 Tabellenverzeichnis
- Tabelle 1: Verwendete Bezeichner für Objekte der eGK
- Tabelle 2: Abbildung NFDM-Anwendungsfälle auf Operationen des Fachmoduls NFDM
- Tabelle 3: Tab_FM_NFDM_050 Einteilung der Protokolleinträge in Abhängigkeit der Schwere
- Tabelle 4: Tab_FM_NFDM_051 – Parameter des Ablaufprotokolls
- Tabelle 5: Tab_FM_NFDM_052 – Parameter des Fehlerprotokolls
- Tabelle 6: Tab_FM_NFDM_053 – Parameter des Debug-Protokolls
- Tabelle 7: Tab_FM_NFDM_054 – Parameter des Sicherheitsprotokolls
- Tabelle 8: Tab_FM_NFDM_055 – Parameter des Performanceprotokolls
- Tabelle 9: Tab_FM_NFDM_007 – Werte der Zugriffsprotokolleinträge auf der eGK
- Tabelle 10: Tab_FM_NFDM_001 – Übergreifende Konfigurationsparameter
- Tabelle 11: Tab_FM_NFDM_003 – Service-Informationen NFDM-Services
- Tabelle 12: Tab_FM_NFDM_036 – Anwendungs-Parameter für PIN-Eingabe
- Tabelle 13: Tab_FM_NFDM_037 – Terminal-Anzeigen für PIN-Eingabe
- Tabelle 14: Tab_FM_NFDM_032 – Übergreifende Erfolgsbedingungen
- Tabelle 15: Tab_FM_NFDM_033 – Übergreifende Nachbedingungen
- Tabelle 16: Tab_FM_NFDM_004 – NFDService
- Tabelle 17: Tab_FM_NFDM_005 – Operation ReadNFD
- Tabelle 18: Tab_FM_NFDM_023 – Berechtigungsregeln ReadNFD
- Tabelle 19: Tab_FM_NFDM_008 – Operation WriteNFD
- Tabelle 20: Tab_FM_NFDM_010 – Berechtigungsregeln WriteNFD
- Tabelle 21: Tab_FM_NFDM_011 – Operation EraseNFD
- Tabelle 22: Tab_FM_NFDM_013 – Berechtigungsregeln EraseNFD
- Tabelle 23: Tab_FM_NFDM_025 – Umsetzung Ablaufaktivitäten ReadNFD
- Tabelle 24: Tab_FM_NFDM_026 – Umsetzung Ablaufaktivitäten WriteNFD
- Tabelle 25: Tab_FM_NFDM_027 – Umsetzung zu Ablaufaktivitäten EraseNFD
- Tabelle 26: Tab_FM_NFDM_049 – WSDL-Schnittstellenbeschreibung NFDService
- Tabelle 27: Tab_FM_NFDM_039 – XML-Schema des NFDService
- Tabelle 28: Tab_FM_NFDM_014 – DPEService
- Tabelle 29: Tab_FM_NFDM_015 – Operation ReadDPE
- Tabelle 30: Tab_FM_NFDM_024 – Berechtigungsregeln ReadDPE
- Tabelle 31: Tab_FM_NFDM_017 – Operation WriteDPE
- Tabelle 32: Tab_FM_NFDM_019 – Berechtigungsregeln WriteDPE
- Tabelle 33: Tab_FM_NFDM_020 – Operation EraseDPE
- Tabelle 34: Tab_FM_NFDM_022 – Berechtigungsregeln EraseDPE
- Tabelle 35: Tab_FM_NFDM_028 – Umsetzung Ablaufaktivitäten ReadDPE
- Tabelle 36: Tab_FM_NFDM_029 – Umsetzung Ablaufaktivitäten WriteDPE
- Tabelle 37: Tab_FM_NFDM_030 – Umsetzung Ablaufaktivitäten EraseDPE
- Tabelle 38: Tab_FM_NFDM_034 – WSDL-Schnittstellenbeschreibung DPEService
- Tabelle 39: Tab_FM_NFDM_035 – XML-Schema des DPEService inkl. Version
- Tabelle 40: Tab_FM_NFDM_002 – Fehlermeldungen Fachmodul NFDM
9.5 Referenzierte Dokumente
9.5.1 Dokumente der gematik
Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert; Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument jeweils gültige Versionsnummern sind in der aktuellen, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.
[Quelle] |
Herausgeber: Titel |
---|---|
[DPE_Document.xsd] |
gematik: XML-Schema-Dokument für den DPE |
[DPEService.wsdl] |
gematik: WSDL-Dokument für den DPEService des Fachmoduls NFDM |
[DPEService.xsd] |
gematik: XML-Schema-Dokument für die Nachrichtenstrukturen und Datentypen des DPEService des Fachmoduls NFDM |
[gemGlossar] |
gematik: Glossar der Telematikinfrastruktur |
[gemLH_NFDM] |
Projektteam NFDM: Lastenheft Notfalldaten-Management |
[gemRL_QES_NFDM] |
gematik: Signaturrichtlinie QES für Notfalldaten der eGK |
[gemSysL_NFDM] |
gematik: Systemspezifisches Konzept Notfalldaten-Management (NFDM) |
[gemSpec_Karten_Fach_TIP] |
gematik: Befüllvorschriften für die Plattformanteile der Karten der TI |
[gemSpec_eGK_Fach_NFDM] |
gematik: Speicherstrukturen der eGK für die Fachanwendung NFDM |
[gemSpec_eGK_ObjSys] |
gematik: Spezifikation der elektronischen Gesundheitskarte eGK-Objektsystem |
[gemSpec_InfoNFDM] |
gematik: Informationsmodell Notfalldaten-Management (NFDM) |
[gemSpec_Kon] |
gematik: Spezifikation Konnektor |
[gemSpec_OM] |
gematik: Übergreifende Spezifikation Operations und Maintenance (Fehlermanagement, Versionierung, Monitoring) |
[gemSpec_Perf] |
gematik: Performance und Mengengerüst TI-Plattform |
[gemSpec_PKI] |
gematik: Spezifikation PKI |
[NFD_Document.xsd] |
gematik: XML-Schema-Dokument für den NFD |
[NFDService.wsdl] |
gematik: WSDL-Dokument für den NFDService des Fachmoduls NFDM |
[NFDService.xsd] |
gematik: XML-Schema-Dokument für die Nachrichtenstrukturen und Datentypen des NFDService des Fachmoduls NFDM |
[ServiceInformation.xsd] |
gematik: XML-Schema-Dokument für Serviceinformationen der Konnektordienste |
9.5.2 Weitere Dokumente
[Quelle] |
Herausgeber (Erscheinungsdatum): Titel |
---|---|
[BasicProfile1.2] |
WS-I (11.09.2010): Basic Profile, Version 1.2, http://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html (zuletzt geprüft am 06.06.2012) |
[OASIS-VR] |
OASIS (12. November 2010): Profile for comprehensive multi-signature verification reports for OASIS Digital Signature Services Version 1.0, Committee Specification 01, http://docs.oasis-open.org/dss-x/profiles/verificationreport/oasis-dssx-1.0-profiles-vr-cs01.pdf (zuletzt geprüft am 22.11.2012) |
[RFC1952] |
RFC 1952 (Mai 1996): GZIP file format specification version 4.3, http://tools.ietf.org/html/rfc1952 (zuletzt geprüft am 31.01.2014) |
[RFC2119] |
RFC 2119 (März 1997): Key words for use in RFCs to Indicate Requirement Levels S. Bradner, http://tools.ietf.org/html/rfc2109 (zuletzt geprüft am 06.06.2012) |
10 Anhang B
10.1 Fehlermeldungen
Die Tabelle richtet sich nach den Vorgaben von [gemSpec_OM#3.2.1].
Tabelle 40: Tab_FM_NFDM_002 – Fehlermeldungen Fachmodul NFDM
Component Type |
Code |
ErrorType |
Severity |
ErrorText |
Befüllung Details |
---|---|---|---|---|---|
FM_NFDM |
5000 |
Technical |
FATAL |
Die eGK ist defekt. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5001 |
Technical |
ERROR |
HBA/SMC-B nicht freigeschaltet |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5002 |
Security |
ERROR |
Fachliche Rolle nicht berechtigt zur Ausführung |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5003 |
Technical |
ERROR |
Notfalldatensatz nicht konsistent |
Der Detailtext MUSS den Zeitstempel des NFD aus dem Informationselement Timestamp der Datei EF.StatusNFD der eGK enthalten. |
FM_NFDM |
5004 |
Technical |
FATAL |
Unbekannte Version der Speicherstruktur für den Notfalldatensatz auf der eGK |
Der Detailtext MUSS die Versionsnummer der NFD-Speicherstruktur auf der eGK (s. Kapitel 6.1.2.2) enthalten. |
FM_NFDM |
5006 |
Technical |
ERROR |
Dekomprimierung des Notfalldatensatzes gescheitert |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5007 |
Technical |
ERROR |
Decodierung des Notfalldatensatzes gescheitert |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5008 |
Security |
ERROR |
Die Versicherten-ID des Notfalldatensatzes stimmt nicht mit der Versicherten-ID der eGK überein. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5009 |
Technical |
ERROR |
Die Kodierung (base64) des Notfalldatensatzes ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5010 |
Technical |
ERROR |
Die Komprimierung des Notfalldatensatzes ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5011 |
Security |
ERROR |
Es konnte keine Berechtigungsregel ermittelt werden. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5012 |
Technical |
ERROR |
Das Löschen des Notfalldatensatzes ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5013 |
Business |
ERROR |
Der Notfalldatensatz überschreitet die maximal zulässige Größe. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5014 |
Security |
ERROR |
Das Primärsystem hat keine Zugriffsberechtigung auf die eGK. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5015 |
Security |
ERROR |
Das Primärsystem hat keine Zugriffsberechtigung auf den HBA/die SMC-B. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5016 |
Security |
ERROR |
Die gegenseitige Authentisierung von eGK und HBA/SMC-B (Card-to-Card-Authentisierung) ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5017 |
Security |
ERROR |
Der Notfalldatensatz ist nicht valide. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5018 |
Security |
ERROR |
Die Signaturprüfung konnte nicht durchgeführt werden. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5019 |
Security |
ERROR |
PIN-Verifikation gescheitert |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5020 |
Business |
ERROR |
Der Notfalldatensatz ist verborgen. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5021 |
Business |
ERROR |
Es ist kein Notfalldatensatz auf der eGK gespeichert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5103 |
Technical |
ERROR |
Datensatz „Persönliche Erklärungen“ nicht konsistent |
Der Detailtext MUSS den Zeitstempel des DPE aus dem Informationselement Timestamp der Datei EF.StatusDPE der eGK enthalten. |
FM_NFDM |
5104 |
Technical |
FATAL |
Unbekannte Version der Speicherstruktur für den Datensatz „Persönliche Erklärungen“ auf der eGK |
Der Detailtext MUSS die Versionsnummer der DPE-Speicherstruktur auf der eGK (s. Kapitel 6.2.2.2) enthalten. |
FM_NFDM |
5106 |
Technical |
ERROR |
Dekomprimierung des Datensatz „Persönliche Erklärungen“ gescheitert |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5107 |
Technical |
ERROR |
Decodierung des Datensatz „Persönliche Erklärungen“ gescheitert |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5108 |
Security |
ERROR |
Die Versicherten-ID des Datensatz „Persönliche Erklärungen“ stimmt nicht mit der Versicherten-ID der eGK überein. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5109 |
Technical |
ERROR |
Die Kodierung (base64) des Datensatz „Persönliche Erklärungen“ ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5110 |
Technical |
ERROR |
Die Komprimierung des Datensatz „Persönliche Erklärungen“ ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5112 |
Technical |
ERROR |
Das Löschen des Datensatz „Persönliche Erklärungen“ ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5113 |
Business |
ERROR |
Der Datensatz „Persönliche Erklärungen“ überschreitet die maximal zulässige Größe. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5114 |
Security |
ERROR |
Der Datensatz „Persönliche Erklärungen“ ist nicht valide. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5120 |
Business |
ERROR |
Der Datensatz „Persönliche Erklärungen“ ist verborgen. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5121 |
Business |
ERROR |
Es ist kein Datensatz „Persönliche Erklärungen“ auf der eGK gespeichert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5501 |
Security |
WARNING |
Prüfung der qualifizierten elektronischen Signatur unvollständig oder nicht durchführbar bzw. Signatur ungültig. |
Der Detailtext MUSS auf das Prüfprotokoll (Element VerificationResult) der SAK hinweisen, das in der Response an das Primärsystem zurückgegeben wurde. |
FM_NFDM |
5504 |
Security |
ERROR |
Signatur des Notfalldatensatzes ungültig. Prüfung der Hashwertkette bzw. kryptographische Prüfung der Signatur fehlgeschlagen. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5505 |
Security |
ERROR |
Die Prüfung des Signaturzertifikats des Notfalldatensatzes auf Konformität zu einer qualifizierten elektronischen Signatur ist gescheitert. |
Der Detailtext KANN den Fehler näher beschreiben. |
FM_NFDM |
5500 |
Technical |
FATAL |
Interner Fehler |
Der Detailtext KANN den Fehler näher beschreiben. |