gemSpec_FLA_NFDM_V1.1.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Fachlogik der Fachanwendung NFDM in KTR-AdV

(FLA-NFDM)

    

     

      
Version
      
1.1.0
     
     

      
Revision
      
829909
     
     

      
Stand
      
Wert nicht konfiguriert
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FLA_NFDM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Einarbeitung von Änderungen lt. P15.2

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die spezifischen Anforderungen für die Fachlogik der Fachanwendung NFDM in KTR-AdV (FLA-NFDM).

FLA-NFDM ist diejenige Komponente der Fachanwendung NFDM, welche die Anwendungsfälle der Fachanwendung NFDM und die Anwendungsfälle des Leistungsmerkmals „Datenübertragung bei Kartentausch“ der Fachanwendung AdV in KTR-AdV auf Seite der AdV-App umsetzt. Der Funktionsumfang wird definiert durch das Leistungsmerkmal NFDM-L_2 („Persönliche Erklärungen NFDM“) der Fachanwendung NFDM. Dieses wurde in [gemSysL_NFDM] definiert und stellt KTR-AdV eine Grundfunktionalität zur Verwaltung von Datensätzen für persönliche Erklärungen (DPE) zur Verfügung.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller der KTR-AdV, die die Fachlogik der Fachanwendung NFDM umsetzen.

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 FLA-NFDM bereitgestellten logischen Schnittstellen. Es werden Plattformbausteine aus KTR-AdV gemäß [gemSpec_KTR-AdV] verwendet, die Zugriff auf produktübergreifende Plattformleistungen definieren.

Die vollständige Anforderungslage für FLA-NFDM ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten. Diese sind in dem Produkttypsteckbrief der KTR-AdV verzeichnet, da FLA-NFDM integraler Bestandteil der KTR-AdV ist.

1.5 Methodik

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

Sie werden im Dokument wie folgt dargestellt:

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

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

Hinweise zur Nomenklatur:

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

Bezeichner für Objekte der eGK:

Der Bezeichner der in [gemSpec_eGK_ObjSys] definierten Objekte der eGK dient dazu, das Objekt innerhalb der Spezifikation zu identifizieren. Adressieren lassen sich die Objekte auf der eGK über deren Attribut pwdIdentifier (für Passwortobjekte), fileIdentifier (für Elementary Files (EFs)) oder applicationIdentifier (für Dedicated Files (DFs)). Ein File Identifier (FID) /Application Identifier (AID)/Password Identifier (PID) muss nur innerhalb eines Ordners eindeutig sein. Aus Gründen der Lesbarkeit und um Unterschiede zwischen eGK G2 und eKG G2.1 darzustellen, werden in dieser Spezifikation Bezeichner eingeführt, für die in der folgenden Tabelle sowohl der Bezeichner als auch der FID/AID/PID mit dem übergeordneten Ordner (überg. DF) angegeben sind.

Tabelle 1: Tab_FLA_NFDM_001 Verwendete Bezeichner für Objekte der eGK

2 Systemüberblick

FLA-NFDM ist Bestandteil des Produkttyps KTR-AdV der Fachanwendung AdV.

Der Produkttyp KTR-AdV wird gebildet aus einem AdV-Server mit zugehöriger AdV-App. Die AdV-App beinhaltet Plattformbausteine, Serverproxy und Fachlogik, zu welcher FLA-NFDM gehört. Die Zerlegung des Produkttyps KTR-AdV wird in [gemSpec_KTR-AdV#4] definiert.

FLA-NFDM nutzt die dezentrale TI-Plattform in KTR-AdV durch Aufruf der Plattformbausteine gemäß [gemSpec_KTR-AdV#Anhang B]. FLA-NFDM ist integraler Bestandteil der KTR-AdV Umgebung (App und AdV-Server), d.h. die Spezifikationen KTR-AdV (als Plattformkomponente) und FLA-NFDM sind zwar getrennt, werden aber von einem Hersteller als eine Funktionalität aus einem AdV-Server mit zugehöriger AdV-App umgesetzt. Die inneren (rein logischen) Schnittstellen zwischen FLA-NFDM und KTR-AdV sind von außen nicht erkennbar.

FLA-NFDM stellt seine Anwendungsfälle über folgende Schnittstellen der KTR-AdV zur Verfügung:

• I_DPE_Management für das Leistungsmerkmal NFDM-L_2 der Fachanwendung NFDM
• I_COPY_DATA für das Leistungsmerkmal „Datenübertragung bei Kartentausch“ der Fachanwendung AdV

Die Operationen der Schnittstelle I_DPE_Management bilden die Anwendungsfälle des Leistungsmerkmals NFDM-L_2 gemäß folgender Tabelle ab.

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

3 Systemkontext

3.1 Akteure und Rollen

FLA-NFDM ist Bestandteil des Produkttyps KTR-AdV und unterliegt damit der Definition für Akteure und Rollen von KTR-AdV gemäß [gemSpec_KTR-AdV#3.1].

Der Nutzer, als natürliche Person, welche die Anwendungsfälle NFDM und AdV in der KTR-AdV startet, agiert in der Rolle „Versicherter“.

3.2 Nachbarsysteme

FLA-NFDM ist integraler Bestandteil von KTR-AdV. Auf der logischen Ebene in KTR-AdV ist FLA-NFDM Teil der Fachlogik der AdV-App. Die Nachbarsysteme der KTR-AdV sind in [gemSpec_KTR-AdV#3.2] dargestellt.

4 Zerlegung des Produkttyps

Eine weitere Untergliederung der Aufbaustruktur von FLA-NFDM ist nicht erforderlich.

5 Übergreifende Festlegungen

5.1 Fehlerbehandlung

Tritt bei der Ausführung einer Operation von FLA-NFDM ein Fehler auf, der zum Abbruch der Operation führt, so wird dieser an die aufrufende AdV-App der KTR-AdV gemeldet.

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

5.2 Berechtigungen

5.2.1 Fachliche Rollen

Der fachliche Akteur (hier Versicherter) ruft fachliche Anwendungsfälle von NFDM zur Anzeige und Bearbeitung der auf seiner eGK gespeicherten Daten auf. Der Versicherte erhält mittels der fachlichen Rolle, die technisch durch das Zugriffsprofil seiner eGK repräsentiert wird, die Autorisierung zur Ausführung des jeweiligen Anwendungsfalls.

5.2.2 Berechtigung

FLA-NFDM spezifiziert die Fachlogik NFDM. Die Berechtigungen zum Zugriff auf die eGK, die für die Anwendungsfälle NFDM erforderlich sind werden durch KTR-AdV gesteuert und sind nicht Bestandteil von FLA-NFDM.

5.3 Unterstützte Generationen der eGK

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

5.4 Versionierung

FLA-NFDM ist integraler Bestandteil des Produkttyps KTR-AdV und unterliegt der Versionierung von KTR-AdV. Deshalb ist für FLA-NFDM keine separate Versionierung vorgesehen.

5.5 Protokollierung

Für die Protokollierung von FLA-NFDM in KTR-AdV gelten die Anforderungen zum Logging aus [gemSpec_KTR-AdV#5.2]. Darüberhinaus gelten in FLA-NFDM die folgenden Anforderungen.

5.5.1 Zugriffsprotokolleinträge auf der eGK

5.6 Datenspeicherung

5.7 Meldungen am Kartenterminal

Wenn es sich um ein Kartenterminal ohne Anzeige handelt, dann kann die Anforderung NFDM-A_2399 nicht umgesetzt werden. Die Anzeige wird dann ausschließlich durch die AdV-App in KTR-AdV gemäß „Tabelle 4: Tab_FLA_NFDM_003 – Terminal-Anzeigen für PIN-Eingabe“ realisiert.

Tabelle 4: Tab_FLA_NFDM_003 – Terminal-Anzeigen für PIN-Eingabe

5.8 Übergreifende Vorbedingungen

Vorbedingungen sind Bedingungen, die erfüllt sein müssen, bevor eine Operation von FLA-NFDM aufgerufen werden kann. Die Bedingungen müssen von der aufrufenden Komponente in KTR-AdV durchgesetzt werden.

Die folgenden „Übergreifenden Vorbedingungen“ gelten für für alle Operationen der in Kapitel 6 definierten Services und werden von der aufrufenden Komponente vor dem Aufruf der Operationen der Schnittstelle I_DPE_Management und I_COPY_DATA in KTR-AdV geprüft:

Tabelle 5: Tab_FLA_NFDM_004 – Übergreifende Vorbedingungen für FLA-NFDM

Darüberhinaus können in den Operationen weitere Vorbedingungen definiert werden.

5.9 Übergreifende Nachbedingungen

Erfolgsbedingungen sind Bedingungen, die erfüllt sein müssen, damit eine Operation von FLA-NFDM erfolgreich durchlaufen werden kann. Jede der Bedingungen wird von den Operationen im Rahmen der Verarbeitung überprüft.

Folgende „Übergreifende Erfolgsbedingungen“ gelten für alle Operationen der in Kapitel 6 definierten Services. Sie werden in allen Operationsspezifikationen des Kapitel 6 referenziert.

Tabelle 6: Tab_FLA_NFDM_005 – Übergreifende Erfolgsbedingungen

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

Tabelle 7: Tab_FLA_NFDM_006 – Übergreifende Nachbedingungen

6 Funktionsmerkmale

In diesem Kapitel werden die Schnittstellen von FLA-NFDM definiert. Für jede Operation wird das an der jeweiligen Schnittstelle sichtbare und damit testbare Verhalten normativ in tabellarischer Form spezifiziert.

Die Unterkapitel „Umsetzung“ beschreiben die Umsetzung der Operationsabläufe der jeweiligen Schnittstelle in der KTR-AdV Umgebung mittels der aufzurufenden Plattformbausteine, die KTR-AdV zur Verfügung stellt, oder internen Operationen von FLA-NFDM. Tabellarisch wird jeder Aktion der Aktivitätsdiagramme entweder ein bzw. mehrere Plattformbausteine des KTR-AdV zugeordnet oder – falls keine aktionsrelevante Dienstfunktionalität bereitgestellt wird – eine interne Funktion benannt und deren Aufgabe beschrieben. Werden nicht explizit im Fehlerfalle zurückzugebende Fehlermeldungen genannt, werden die Fehlermeldungen der aufgerufenen Plattformbausteine zurückgegeben. Der in KTR-AdV realisierte Card Proxy gemäß [gemSpec_KTR-AdV] hat das Wissen über die fachspezifischen Anteile der jeweiligen Smartcard und setzt die erforderliche Funktionalität um. Deshalb muss FLA-NFDM in KTR-AdV folgende Aspekte nicht spezifizieren:

• wo die Artefakte auf einer Karte liegen,
• welche Zugriffsrechte zum Ausführen von Aktionen erforderlich (bspw. Verifikation einer PIN, externe Authentisierung eines CV-Zertifikates mittels Card-2-Card) sind,
• wie erforderliche Zugriffsrechte erworben werden können, und
• wie auf Daten zugegriffen oder gewisse Aktionen ausgeführt werden

6.1 Schnittstelle I_DPE_Management

FLA-NFDM stellt mit der Schnittstelle I_DPE_Management Operationen in KTR-AdV zur Verfügung, die die fachlichen Anwendungsfälle von NFDM zum Lesen, Schreiben und Löschen des Datensatzes „Persönliche Erklärungen“ auf der eGK unterstützen.
Es handelt sich hierbei um eine interne Schnittstelle, deren Signatur und Verhalten definiert wird, jedoch keine Festlegungen hinsichtlich Implementierung getroffen werden.

Die Schnittstelle I_DPE_Management umfasst die 3 Operationen:

• ReadDPE: DPE von eGK lesen
• WriteDPE: DPE auf eGK schreiben
• EraseDPE: DPE von eGK löschen

6.1.1 Schnittstellendefinition

6.1.1.1 ReadDPE

NFDM-A_2400 - ReadDPE

FLA-NFDM MUSS für KTR-AdV die Operation ReadDPE gemäß Tabelle 8: Tab_FLA_NFDM_007 – Operation ReadDPE anbieten.

Tabelle 8: Tab_FLA_NFDM_007 – Operation ReadDPE

Name	ReadDPE
Beschreibung	Die Operation liest den DPE im Informationselement DPE der Datei EF.DPE von der eGK und gibt ihn über den Parameter DPEDocument an den Aufrufer zurück.
Vorbedingungen	In KTR-AdV werden vor Aufruf dieser Operation die übergreifenden Vorbedingungen aus Tabelle „Tab_FLA_NFDM_004 – Übergreifende Vorbedingungen für FLA-NFDM“ geprüft.
Erfolgsbedingungen	Die Operation MUSS die folgenden Erfolgsbedingungen überprüfen.
	ID	Bedingung
	E1	Der auf der eGK gespeicherte DPE ist technisch konsistent, d. h. der Wert des Informationselement Status der Datei EF.StatusDPE der eGK ist „0“.
	E2	Die Version der internen Speicherstruktur (s. 6.3.1) der Dateien der Anwendung „Datensatz Persönliche Erklärungen“ der eGK (DPE-Speicherstruktur) wird von FLA-NFDM unterstützt.
	E3	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´.
	E4	Der auf der eGK gespeicherte DPE ist valide gegen das XML-Schema für den DPE (s. [gemSpec_InfoNFDM#5]).
Aufrufparameter	keine
Rückgabe	DPEDocument				Von der eGK des Versicherten gelesener, dekomprimierter und validierter DPE gemäß gemSpec_KTR-AdV
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die übergreifenden Nachbedingungen gemäß Tabelle „Tab_FLA_NFDM_006 – Übergreifende Nachbedingungen“ und die folgenden erfüllen.
	ID		Bedingung
	N1		Der DPE (Ausgabeparameter DPEDocument) ist dekomprimiert.
Ablauf	Der Ablauf der Operation ReadDPE, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung 1: Abb_FLA_NFDM_001 – Ablauf ReadDPE modelliert. Die Umsetzung des Ablaufs mittels Plattformbausteinen von KTR-AdV und interner Operationen von FLA-NFDM spezifiziert Tabelle 11: Tab_FLA_NFDM_010 – 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.
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_FLA_NFDM_018 – Fehlermeldungen “ definiert. Generische Fehlermeldungen
	Code			Befüllung Details
	108			Der Detailtext KANN den Fehler näher beschreiben.
	111			Der Detailtext KANN den Fehler näher beschreiben.
	Spezifische Fehlermeldungen
	Code			Auslösende Bedingung
	5103			E1 ist nicht erfüllt.
	5104			E2 ist nicht erfüllt.
	5106			Die Dekomprimierung des DPE ist gescheitert.
	5114			E4 ist nicht erfüllt.
	5121			E3 ist nicht erfüllt.
	5500			Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.

Abbildung 1: Abb_FLA_NFDM_001 – Ablauf ReadDPE

[<=]

6.1.1.2 WriteDPE

NFDM-A_2401 - WriteDPE

FLA-NFDM MUSS für KTR-AdV die Operation WriteDPE gemäß Tabelle 9: Tab_FLA_NFDM_008 – Operation WriteDPE anbieten.

Tabelle 9: Tab_FLA_NFDM_008 – Operation WriteDPE

Name	WriteDPE
Beschreibung	Die Operation schreibt den ihr im Parameter DPEDocument übergebenen DPE auf die eGK in das Informationselement DPE der Datei EF.DPE
Vorbedingungen	In KTR-AdV werden vor Aufruf dieser Operation die übergreifenden Vorbedingungen aus Tabelle „Tab_FLA_NFDM_004 – Übergreifende Vorbedingungen für FLA-NFDM“ und folgende Vorbedingung geprüft.
	ID			Bedingung
	V1			Das Zertifikat C.CH.AUTN der eGK ist zeitlich gültig und nicht gesperrt.
Erfolgsbedingungen	Die Operation MUSS die folgenden Erfolgsbedingungen überprüfen.
	ID	Bedingung
	E1	Der übergebene DPE ist valide gegen das XML-Schema für den DPE (s. [gemSpec_InfoNFDM#5]).
	E2	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.AUTN.R2048) 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]).
	E3	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	DPEDocument					Auf die eGK des Versicherten zu schreibender DPE gemäß gemSpec_KTR-AdV
Rückgabe	keine
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die übergreifenden Nachbedingungen gemäß Tabelle „Tab_FLA_NFDM_006 – Übergreifende Nachbedingungen“ und die folgenden erfüllen.
	ID		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“.
Ablauf	Der Ablauf der Operation WriteDPE, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung „Abb_FLA_NFDM_002 – Ablauf WriteDPE“ modelliert. Die Umsetzung des Ablaufs mittels Plattformbausteinen von KTR-AdV und interner Operationen FLA-NFDM spezifiziert Tabelle 12: Tab_FLA_NFDM_011 – 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.
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_FLA_NFDM_018 – Fehlermeldungen “ definiert. Generische Fehlermeldungen
	Code				Befüllung Details
	108				Der Detailtext KANN den Fehler näher beschreiben.
	112				Der Detailtext KANN den Fehler näher beschreiben.
	Spezifische Fehlermeldungen
	Code				Auslösende Bedingung
	5000				Die eGK ist defekt.
	5108				E2 ist nicht erfüllt.
	5110				Die Komprimierung des DPE ist gescheitert.
	5113				E3 ist nicht erfüllt
	5114				E1 nicht erfüllt.
	5500				Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.

Abbildung 2: Abb_FLA_NFDM_002 – Ablauf WriteDPE

[<=]

6.1.1.3 EraseDPE

NFDM-A_2402 - EraseDPE

FLA-NFDM MUSS für KTR-AdV die Operation EraseDPE gemäß Tabelle 10: Tab_FLA_NFDM_009 – Operation EraseDPE anbieten.

Tabelle 10: Tab_FLA_NFDM_009 – Operation EraseDPE

Name	EraseDPE
Beschreibung	Die Operation löscht den DPE im Informationselement DPE der Datei EF.DPE der eGK.
Vorbedingungen	In KTR-AdV werden vor Aufruf dieser Operation die übergreifenden Vorbedingungen aus Tabelle „Tab_FLA_NFDM_004 – Übergreifende Vorbedingungen für FLA-NFDM“ geprüft.
Erfolgsbedingungen	Die Operation MUSS die folgenden Erfolgsbedingungen überprüfen.
	ID	Bedingung
	E1	Die Version der internen Speicherstruktur (s. 6.3.1) der Dateien der Anwendung „Datensatz Persönliche Erklärungen“ der eGK (DPE-Speicherstruktur) wird FLA-NFDM unterstützt.
Aufrufparameter	keine
Rückgabe	keine
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die übergreifenden Nachbedingungen gemäß Tabelle „Tab_FLA_NFDM_006 – Übergreifende Nachbedingungen“ und die folgenden erfüllen.
	ID		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“.
Ablauf	Der Ablauf der Operation EraseDPE, der das definierte Außenverhalten abbildet, ist im Aktivitätsdiagramm der Abbildung 3: Abb_FLA_NFDM_003 – Ablauf EraseDPE modelliert. Die Umsetzung des Ablaufs mittels Plattformbausteinen von KTR-AdV und interner Operationen von FLA-NFDM spezifiziert Tabelle 13: Tab_FLA_NFDM_012 – 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.
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_FLA_NFDM_018 – Fehlermeldungen “ definiert. Generische Fehlermeldungen
	Code			Befüllung Details
	108			Der Detailtext KANN den Fehler näher beschreiben.
	112			Der Detailtext KANN den Fehler näher beschreiben.
	Spezifische Fehlermeldungen
	Code			Auslösende Bedingung
	5000			Die eGK ist defekt.
	5104			E1 ist nicht erfüllt.
	5112			Löschen des DPE (technisch) gescheitert.
	5500			Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.

Abbildung 3: Abb_FLA_NFDM_003 – Ablauf EraseDPE

[<=]

6.1.2 Umsetzung

Die folgenden Unterkapitel beschreiben die Umsetzung der Operationsabläufe von I_DPE_Management in der KTR-AdV Umgebung.

6.1.2.1 ReadDPE

Tabelle 11: Tab_FLA_NFDM_010 – Umsetzung Ablaufaktivitäten ReadDPE

6.1.2.2 WriteDPE

Tabelle 12: Tab_FLA_NFDM_011 – Umsetzung Ablaufaktivitäten WriteDPE

6.1.2.3 EraseDPE

Tabelle 13: Tab_FLA_NFDM_012 – Umsetzung Ablaufaktivitäten EraseDPE

6.2 Schnittstelle I_COPY_DATA

FLA-NFDM stellt mit der Schnittstelle I_COPY_DATA Operationen in KTR-AdV zur Verfügung, die in NFDM das Funktionsmerkmal „Datenübertragung bei Kartentausch“ unterstützen. Der Datensatz „Persönliche Erklärungen“ soll hierüber im Rahmen der Bereitstellung einer neuen eGK des Versicherten von der alten Karte auf die neue Karte übertragen werden. Es handelt sich hierbei um eine interne Schnittstelle, deren Signatur und Verhalten definiert wird, jedoch keine Festlegungen hinsichtlich Implementierung getroffen werden.

Die Schnittstelle I_COPY_DATA umfasst die 2 Operationen:

• GetData
• PutData

6.2.1 Schnittstellendefinition

6.2.1.1 GetData

NFDM-A_2403 - Operation GetData

FLA-NFDM MUSS für KTR-AdV die Operation GetData des Funktionsmerkmals „Datenübertragung bei Kartentausch“ gemäß Tabelle „Tab_FLA_NFDM_014 – Operation GetData“ anbieten.

Tabelle 14: Tab_FLA_NFDM_014 – Operation GetData

Name	GetData
Beschreibung	Die Operation liest den im Aufrufparameter application benannten Datensatz DPE von der eGK und gibt ihn über den Parameter Document an den Aufrufer zurück.
Vorbedingung	In KTR-AdV werden vor Aufruf dieser Operation die übergreifenden Vorbedingungen aus Tabelle „Tab_FLA_NFDM_004 – Übergreifende Vorbedingungen für FLA-NFDM“ geprüft.
Erfolgsbedingungen	Die Operation MUSS die folgenden Erfolgsbedingungen überprüfen.
	ID	Bedingung
	E1	Der auf der eGK gespeicherte Datensatz ist technisch konsistent, d. h. der Wert des Informationselements Status des Datensatzes in der Datei EF.StatusDPE der eGK ist „0“.
	E2	Die Version der internen Speicherstruktur (s. 6.3.1) der auf der eGK wird von FLA-NFDM unterstützt.
	E3	Es ist ein gemäß [RFC1952] gzip-komprimierter DPE auf der eGK gemäß [gemSpec_eGK_Fach_NFDM#2.1] gespeichert, d. h. das Informationselement Länge DPE der Datei EF.DPE der eGK hat einen Wert ungleich ´00 00´.
	E4	Der auf der eGK gespeicherte Datensatz DPE ist valide gegen das entsprechende XML-Schema für den Datensatz DPE (s. [gemSpec_InfoNFDM#5]).
Aufrufparameter	Name				Beschreibung
	objsysVersion				Version des Objektsystems der eGK, von der der Datensatz DPE gelesen werden soll
	application				Identifier der eGK für den Datensatz, dessen Daten gelesen werden sollen. Folgende Werte sind zulässig: DF.DPE
Rückgabe	Name				Beschreibung
	document				Von der eGK des Versicherten gelesener, dekomprimierter Datensatz DPE, der durch Aufrufparameter application benannt wurde. Folgende XML-Dokumente sind zulässig: DPE_Document gemäß gemSpec_KTR-AdV
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die folgenden Nachbedingungen erfüllen.
	ID		Bedingung
	N1		Der Datensatz DPE (Ausgabeparameter document) ist dekomprimiert.
Ablauf	Der Ablauf der Operation GetData, ist im Aktivitätsdiagramm der Abbildung „Abbildung 4: Abb_FLA_NFDM_004 – Ablauf GetData“ modelliert. Die Umsetzung des Ablaufs spezifiziert Tabelle „Tabelle 16: Tab_FLA_NFDM_016 – Umsetzung Ablaufaktivitäten GetData“. 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.
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_FLA_NFDM_018 – Fehlermeldungen “ definiert. Generische Fehlermeldungen
	Code			Befüllung Details
	108			Der Detailtext KANN den Fehler näher beschreiben.
	111			Der Detailtext KANN den Fehler näher beschreiben.
	Code			Befüllung Details
	5103			E1 ist nicht erfüllt.
	5104			E2 ist nicht erfüllt.
	5106			Die Dekomprimierung des DPE ist gescheitert.
	5114			E4 ist nicht erfüllt.
	5121			E3 ist nicht erfüllt.
	5500			Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.

Abbildung 4: Abb_FLA_NFDM_004 – Ablauf GetData

[<=]

6.2.1.2 PutData

NFDM-A_2404 - Operation PutData

FLA-NFDM MUSS für KTR-AdV die Operation PutData des Funktionsmerkmals „Datenübertragung bei Kartentausch“ gemäß Tabelle „Tab_FLA_NFDM_015 – Operation PutData“ anbieten.

Tabelle 15: Tab_FLA_NFDM_015 – Operation PutData

Name	PutData
Beschreibung	Die Operation schreibt im Aufrufparameter application benannten Datensatz DPE_Document gemäß gemSpec_KTR-AdV in das Informationselement DPE der Datei EF.DPE.
Vorbedingung	In KTR-AdV werden vor Aufruf dieser Operation die übergreifenden Vorbedingungen aus Tabelle „Tab_FLA_NFDM_004 – Übergreifende Vorbedingungen für FLA-NFDM“ und folgende Vorbedingung geprüft:
	ID		Bedingung
	V1		Das Zertifikat C.CH.AUTN der eGK ist zeitlich gültig und nicht gesperrt.
	V2		Die KVNR der eGK, von der der DPE Datensatz stammt (Document) ist gleich der KVNR der eGK für welche die Operation PutData aufgerufen wird (Die ersten zehn unveränderbaren Stellen der Krankenversichertennummer (KVNR) werden für den Vergleich herangezogen.).
Erfolgsbedingungen	Die Operation MUSS die folgenden Erfolgsbedingungen überprüfen.
	ID	Bedingung
	E1	Der übergebene DPE ist valide gegen das XML-Schema für den DPE (s. [gemSpec_InfoNFDM#5]).
	E2	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.AUTN.R2048) 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]).
	E3	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.
	E4	Es ist auf der eGK kein DPE bereits vorhanden, d. h. das Informationselement Länge DPE der Datei EF.DPE der eGK hat einen Wert gleich ´00 00´.
Aufrufparameter	Name				Beschreibung
	objsysVersionSrc				Version des Objektsystems der eGK, von der der Datensatz DPE ursprünglich gelesen werden soll
	objsysVersionDest				Version des Objektsystems der eGK, auf die der Datensatz DPE geschrieben werden soll
	application				Identifier der eGK für den Datensatz, dessen Daten geschrieben werden sollen. Folgende Werte sind zulässig: DF.DPE
	document				Der durch Aufrufparameter application benannte und auf die eGK zu schreibende Datensatz DPE. Folgende XML-Dokumente sind zulässig: DPE_Document gemäß gemSpec_KTR-AdV
Rückgabe	Name				Beschreibung
Nachbedingungen	Falls alle Erfolgsbedingungen erfüllt sind, MUSS die Operation die folgenden Nachbedingungen erfüllen.
	ID		Bedingung
	N1		Der im Aufufpameter Document übergebene Datensatz DPE ist gemäß [RFC1952] gzip-komprimiert auf der eGK im Informationselement DPE der Datei EF.DPE gemäß [gemSpec_eGK_Fach_NFDM#3.1] gespeichert.
	N2		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.
	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“.
Ablauf	Der Ablauf der Operation PutData, ist im Aktivitätsdiagramm der Abbildung „Abb_FLA_NFDM_005 – Ablauf PutData“ modelliert. Die Umsetzung des Ablaufs spezifiziert Tabelle „Tabelle 17: Tab_FLA_NFDM_017 – Umsetzung Ablaufaktivitäten PutData“. 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.
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_FLA_NFDM_018 – Fehlermeldungen “ definiert. Generische Fehlermeldungen
	Code			Befüllung Details
	108			Der Detailtext KANN den Fehler näher beschreiben.
	112			Der Detailtext KANN den Fehler näher beschreiben.
	Spezifische Fehlermeldungen
	Code			Auslösende Bedingung
	5000			Die eGK ist defekt.
	5104			Die Version der internen DPE-Speicherstruktur wird von FLA-NFDM nicht unterstützt. Eine Prüfung der Existenz eines DPE kann nicht erfolgen.
	5108			E2 ist nicht erfüllt.
	5110			Die Komprimierung des DPE ist gescheitert.
	5113			E3 ist nicht erfüllt
	5114			E1 nicht erfüllt.
	5122			E4 ist nicht erfüllt.
	5500			Jegliches fehlerhafte Verhalten, das nicht durch die anderen Fehlermeldungen erfasst wird.

Abbildung 5: Abb_FLA_NFDM_005 – Ablauf PutData

[<=]

6.2.2 Umsetzung

Die folgenden Unterkapitel beschreiben die Umsetzung der Operationsabläufe von I_ COPY_DATA in der KTR-AdV Umgebung.

6.2.2.1 GetData

Tabelle 16: Tab_FLA_NFDM_016 – Umsetzung Ablaufaktivitäten GetData

6.2.2.2 PutData

Tabelle 17: Tab_FLA_NFDM_017 – Umsetzung Ablaufaktivitäten PutData

6.3 Artefakte

6.3.1 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.3.2 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.4 Testunterstützung

Zur Unterstützung von Tests im Zusammenhang mit den Funktionsmerkmalen werden keine gesonderten Festlegungen getroffen.

6.5 Hardwaremerkmale

Die Funktionsmerkmale setzen keine besonderen Hardwaremerkmale 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

FLA-NFDM ist integraler Bestandteil von KTR-AdV. Die Hardware-Merkmale von KTR-AdV sind in [gemSpec_KTR-AdV] spezifiziert.

Eine weitergehende Darstellung der hardwareseitigen Verteilung von FLA-NFDM bzw. seiner Teilsysteme und der Einbettung in die physikalische Umgebung wird daher nicht benötigt.

9 Anhang A – Verzeichnisse

9.1 Abkürzungen

9.2 Glossar

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

9.3 Abbildungsverzeichnis

9.4 – Tabellenverzeichnis

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

9.5.2 Weitere Dokumente

10 Anhang B

10.1 Fehlermeldungen

Die Tabelle richtet sich nach den Vorgaben von [gemSpec_OM#5.3.1.2].

Tabelle 18: Tab_FLA_NFDM_018 – Fehlermeldungen FLA-NFDM