Elektronische Gesundheitskarte und Telematikinfrastruktur

Systemspezifisches Konzept Notfalldaten-Management (NFDM)

    

     

      
Version
      
1.3.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
14.05.2018
     
     

      
Status
      
Freigegeben für interne QS
     
     

      
Klassifizierung
      
nicht öffentlich
     
     

      
Referenzierung
      
gemSysL_NFDM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Einarbeitung P15.4

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Das Konzept „Systemspezifisches Konzept NFDM“ entwirft eine erste architektonische Lösungsskizze der Systemlösung für die Fachanwendung NFDM auf Basis der Anforderungen des Lastenheftes NFDM für die Leistungsmerkmale „Basisfunktionalität NFDM (Notfalldatensatz)“ (NFDM-L_1), „Persönliche Erklärungen NFDM“ (NFDM-L_2) und den Leistungsmerkmalen zur Unterstützung der TI-Plattform (Scope des Projektes NFDM für den Online-Produktivbetrieb.

Das vorliegende Konzept beinhaltet die Beschreibung der essentiellen funktionalen Abläufe (Anwendungsfälle) sowie die Identifikation der logischen Komponenten und deren logische Schnittstellen. Die Systemlösung ermöglicht somit die normative Systemzerlegung der Fachanwendung NFDM und die Zuweisung der Anforderungen des Lastenheftes zu den sich aus der Systemzerlegung ergebenden Produkttypen der Fachanwendung (Anhang B2). Damit dient die Systemlösung als Grundlage für die Einheiten der Spezifikationen in der Designphase.

Die in den Anwendungsfällen genutzten Schnittstellen und referenzierten Rollen der TI-Plattform sowie deren Architektur sind in [gemKPT_Arch_TIP] beschrieben.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter der Produkttypen der Fachanwendung NFDM.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens für den Online-Produktivbetrieb. 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 Abgrenzung des Dokuments

In diesem Dokument wird ausschließlich die Systemzerlegung in Komponenten und deren Verteilung auf Produkttypen der TI normativ in Form von Anforderungen festgelegt.

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zum Themenbereich der Prozesse in Arztpraxen, Krankenhäusern oder Apotheken. Informationen zum fachlichen Gesamtkontext finden sich im Lastenheft NFDM [gemLH_NFDM].

Das systemspezifische Konzept NFDM enthält keine Vorgaben zu Test und Betrieb dieses Systems. Fachanwendungsspezifische Vorgaben hierzu finden sich in den entsprechenden Konzepten für den Online-Produktivbetrieb ([gemKPT_Test], [gemKPT_Betr].

Spezifische Vorgaben zu Datenschutz und Sicherheit finden sich in einem fachanwendungsspezifischen Sicherheitskonzept ([gemKPT_Sich_NFDM]) bzw. Datenschutzkonzept ([gemKPT_DS_NFDM]).

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.

2 Systemzerlegung

2.1 Übersicht

Die Komponente und der Produkttyp, an welchen durch die Fachanwendung NFDM Anforderungen gestellt werden, sind in dieser Abbildung blau hervorgehoben.

2.2 Produkttyp „Fachmodul NFDM“

Das Fachmodul NFDM stellt dem Primärsystem die externen Schnittstellen aus Kapitel 5.2 zur Verfügung und kapselt auf diese Weise die Ablauflogik der Anwendungsfälle der Leistungsmerkmale „Basisfunktionalität NFDM (Notfalldatensatz)“ (NFDM-L_1) und „Persönliche Erklärungen NFDM“ (NFDM-L_2), die in Kapitel 4 beschrieben werden.

Die Zuordnung der Lastenheftanforderungen zu dieser Komponente findet sich im Anhang B - 7.1.

3 Informationsmodell

Das fachliche Informationsmodell für die Fachanwendung NFDM wurde bereits im Lastenheft NFDM definiert. Es unterteilt sich in das Modell für die notfallrelevanten medizinischen Informationen und die persönlichen Erklärungen. Die technische Umsetzung der fachlichen Informationsmodelle wird in diesem Konzept für den Fall der notfallrelevanten medizinischen Informationen als „Notfalldatensatz“ (NFD) und für den Fall der persönlichen Erklärungen als „Datensatz ‚Persönliche Erklärungen’“ (DPE) bezeichnet. Die folgende Abbildung verdeutlicht diesen Zusammenhang.

Abbildung 2: Zusammenhang der Begrifflichkeiten zum Informationsmodell NFDM

Das technische Informationsmodell als normative Vorgabe ist in einem eigenständigen Dokument auf Ebene der Spezifikationen spezifiziert [gemSpec_InfoNFDM]. Dabei wurden auch notwendige Anpassungen des fachlichen Informationsmodells dokumentiert und eingearbeitet.

4 Anwendungsfälle

In diesem Kapitel werden die Anwendungsfälle der Fachanwendung NFDM essentiell beschrieben.

Für jedes Leistungsmerkmal werden die Anwendungsfälle und deren Zusammenhang untereinander anhand eines Use-Case-Diagramms dargestellt.

Die Berechtigungen der jeweiligen fachlichen Akteure für die einzelnen Anwendungsfälle sind in einer Berechtigungsmatrix aufgeführt. Die Rollenbezeichnungen denen die Berechtigungen zugewiesen werden entsprechen den in [gemKPT_Arch_TIP#Tabelle 4] definierten. Der Fokus von NFDM bezüglich der Rolle „Anderer Heilberuf“ liegt auf dem Rettungsassistent und dem Notfallsanitäter, andere Heilberufe mit staatlicher Ausbildung (wie z. B. Hebammen) werden dadurch nicht ausgeschlossen.

Für jeden Anwendungsfall erfolgt eine Detaillierung mittels einer tabellarischen Anwendungsfallbeschreibung und eines Sequenzdiagramms.

Die Anwendungsfallbeschreibung beinhaltet neben identifizierenden Eigenschaften (ID, Name) eine Kurzbeschreibung und die essentiellen Aktivitäten, die den Anwendungsfall definieren. Darüber hinaus werden der initiierende Akteur, Vor- und Nachbedingungen, Ein- und Ausgangsdaten sowie der fachliche Auslöser angegeben. Betrachtet wird lediglich der Gutfall. Eine vollständige Spezifikation der Fehlerfälle inkl. Fehlermeldungen erfolgt auf Spezifikationsebene in den jeweiligen Produkttypspezifikationen.

Das Sequenzdiagramm lenkt den Blick auf die zur Auslösung des Anwendungsfalls und Ausführung der essentiellen Aktivitäten an der Systemgrenze der Fachanwendung angebotenen externen und von der TI-Plattform intern benötigten Schnittstellen. Die angebotenen externen Schnittstellen der NFDM-Fachmodule sind im Kapitel 5.2, die verwendeten logischen Schnittstellen der TI-Plattform in [gemKPT_Arch_TIP] detaillierter beschrieben. Die Diagramme dienen somit in erster Linie der Validierung der von der TI-Plattform angebotenen externen Schnittstelle aus NFDM-Sicht.

4.1 Übergreifende Vorbedingungen

Folgende organisatorische Vorbedingungen gelten für alle Anwendungsfälle der Leistungsmerkmale:

• Der Versicherte hat seine Einwilligung zur Nutzung der freiwilligen Fachanwendung NFDM gemäß § 291a Abs. 3 Satz 4 erklärt. Die Einwilligung ist sowohl im NFD als auch im DPE dokumentiert (s. NFDM-A_112). Ist kein NFD bzw. kein DPE auf der eGK vorhanden, muss der Berechtigte vor der Ausführung des Anwendungsfalls eine Einwilligung vom Patienten einholen. Dies gilt nur für den Berechtigten in der Leistungserbringerumgebung.
• Der Versicherte hat sein Einverständnis zur Ausführung des Anwendungsfalls gemäß § 291a, Abs. 5 Satz 1 gegeben.
• Die für alle Anwendungsfälle benötigten dezentralen Komponenten sind betriebsbereit. Dies sind:
• die eGK des Versicherten,
• der HBA des Leistungserbringers bzw. die SMC-B der Leistungserbringerorganisation bzw. der Kostenträger,
• ein eHealth-Kartenterminal, ein Konnektor (mit dem Fachmodul NFDM).
• Die in den Anwendungsfällen benötigten Identifier und der Aufrufkontext gemäß [gemKPT_Arch_TIP#4.2] für HBA bzw. SMC-B und eGK liegen vor.
• Die Gesundheitsanwendung der eGK (DF.HCA) ist nicht gesperrt.
• Die beteiligte LE-Karte (HBA bzw. SMC-B) ist freigeschaltet.
• Die beteiligte eGK hat keine kleinere Versionsnummer als die der Generation 2.
• Die Berechtigungsregeln gemäß relevanter Berechtigungsmatrix für den Anwendungsfall sind erfüllt.
• Die beteiligten Smartcards sind echt.
• Die Version der fachlichen Speicherstrukturen der beteiligten eGK wird vom Fachmodul unterstützt.

4.2 Leistungsmerkmal „Basisfunktionalität NFDM (Notfalldatensatz)“ (NFDM-L_1)

4.2.1 Übersicht

Abbildung 3: Use-Case-Diagramm Leistungsmerkmal „Basisfunktionalität NFDM (Notfalldatensatz)“

Das Signieren des NFD erfolgt direkt durch Nutzung der Operation „sign_Document_QES“ der logischen Schnittstelle „I_SAK_Operations“ (s. [gemKPT_Arch_TIP#5.5.1.3.1]) der TI-Plattform.

4.2.2 Berechtigungen

Die Berechtigungsregeln für den Anwendungsfall „NFD von eGK lesen“ sind in Tabelle 1 definiert.

Tabelle 1: Berechtigungsregeln NFDM-UC_101 „NFD von eGK lesen“

R1, R2, R3,... = Regel 1, 2, 3,..., j bzw. n = Bedingung für die Berechtigungsregel erfüllt bzw. nicht erfüllt, - = Bedingung irrelevant für die Berechtigungsregel, x = berechtigt, xA = berechtigt mit zusätzlicher Autorisierung (PIN-Eingabe) durch den Versicherten, leere Zelle = keine Berechtigung

Die Berechtigungsregeln für den Anwendungsfall  „NFD auf eGK schreiben“  sind in der folgenden Tabelle definiert.

Tabelle 2: Berechtigungsregeln NFDM-UC_100 „NFD auf eGK schreiben“

R1, R2, R3,... = Regel 1, 2, 3,..., j bzw. n = Bedingung für die Berechtigungsregel erfüllt bzw. nicht erfüllt, - = Bedingung irrelevant für die Berechtigungsregel, x = berechtigt, xA = berechtigt mit zusätzlicher Autorisierung (PIN-Eingabe) durch den Versicherten, leere Zelle = keine Berechtigung

Die Berechtigungsregeln für den Anwendungsfall  „NFD von eGK löschen“ sind in der folgenden Tabelle definiert.

Tabelle 3: Berechtigungsregeln NFDM-UC_102 „NFD von eGK löschen“

R1, R2, R3,... = Regel 1, 2, 3,..., j bzw. n = Bedingung für die Berechtigungsregel erfüllt bzw. nicht erfüllt, - = Bedingung irrelevant für die Berechtigungsregel, x = berechtigt, xA = berechtigt mit zusätzlicher Autorisierung (PIN-Eingabe) durch den Versicherten, leere Zelle = keine Berechtigung

Für die Mitarbeiter Arzt/Zahnarzt/Krankenhaus und Apotheke sowie die anderen Heilberufe gilt über die in den Berechtigungsmatrizen spezifizierten Zugriffsrechte hinaus die Rahmenbedingung, dass ein Zugriff nur unter Aufsicht bzw. auf Anweisung des Leistungserbringers erfolgen darf, bei dem der Mitarbeiter tätig ist.

4.2.3 Anwendungsfall „NFD auf eGK schreiben “ (NFDM-UC_100)

Tabelle 4: Anwendungsfallbeschreibung „NFD auf eGK schreiben

Abbildung 4: Sequenzdiagramm „NFD auf eGK schreiben“

4.2.4 Anwendungsfall: „NFD von eGK lesen“ (NFDM-UC_101)

Tabelle 5: Anwendungsfallbeschreibung „NFD von eGK lesen“

Abbildung 5: Sequenzdiagramm „NFD von eGK lesen“

4.2.5 Anwendungsfall: „NFD von eGK löschen“ (NFDM-UC_102)

Tabelle 6: Anwendungsfall „NFD von eGK löschen“

Abbildung 6: Sequenzdiagramm „NFD von eGK löschen“

4.3 Leistungsmerkmal „Persönliche Erklärungen NFDM“ (NFDM-L_2)

4.3.1 Übersicht

Abbildung 7: Use-Case-Diagramm Leistungsmerkmal „Persönliche Erklärungen NFDM“

4.3.2 Berechtigungen

Die Berechtigungsregeln für den Anwendungsfall „DPE von eGK lesen“ sind in Tabelle 7 definiert.

Tabelle 7: Berechtigungsregeln NFDM-UC_201 „DPE von eGK lesen“

R1, R2, R3,... = Regel 1, 2, 3,..., j bzw. n = Bedingung für die Berechtigungsregel erfüllt bzw. nicht erfüllt, - = Bedingung irrelevant für die Berechtigungsregel, x = berechtigt, xA = berechtigt mit zusätzlicher Autorisierung (PIN-Eingabe) durch den Versicherten, leere Zelle = keine Berechtigung

Die Berechtigungsregeln für die Anwendungsfälle „DPE auf eGK schreiben“ und „DPE von eGK löschen “ sind in der folgenden Tabelle definiert.

Tabelle 8: Berechtigungsregeln NFDM-UC_200 „DPE auf eGK schreiben“ und NFDM-UC_202 „DPE von eGK löschen“

R1, R2, R3,... = Regel 1, 2, 3,..., j bzw. n = Bedingung für die Berechtigungsregel erfüllt bzw. nicht erfüllt, - = Bedingung irrelevant für die Berechtigungsregel, x = berechtigt, xA = berechtigt mit zusätzlicher Autorisierung (PIN-Eingabe) durch den Versicherten, leere Zelle = keine Berechtigung

Für die Mitarbeiter Arzt/Zahnarzt/Krankenhaus und Apotheke sowie die anderen Heilberufe gilt über die in den Berechtigungsmatrizen spezifizierten Zugriffsrechte hinaus die Rahmenbedingung, dass ein Zugriff nur unter Aufsicht bzw. auf Anweisung des Leistungserbringers erfolgen darf, bei dem der Mitarbeiter tätig ist.

4.3.3 Anwendungsfall „DPE auf eGK schreiben“ (NFDM-UC_200)

Tabelle 9: Anwendungsfall „DPE auf eGK schreiben“

Abbildung 8: Sequenzdiagramm „DPE auf eGK schreiben“

4.3.4 Anwendungsfall „DPE von eGK lesen“ (NFDM-UC_201)

Tabelle 10: Anwendungsfall „DPE von eGK lesen“

Abbildung 9: Sequenzdiagramm „DPE von eGK lesen“

4.3.5 Anwendungsfall „DPE von eGK löschen“ (NFDM-UC_202)

Tabelle 11: Anwendungsfall „DPE von eGK löschen“

Abbildung 10: Sequenzdiagramm „DPE von eGK löschen“

5 Schnittstellen

5.1 Überblick

Die folgende Abbildung zeigt überblicksartig die von den Komponenten der Fachanwendung angebotenen Schnittstellen sowie die von den Komponenten der Fachanwendung zur Realisierung der Anwendungsfälle genutzten Schnittstellen der TI-Plattform.

Abbildung 11: Schnittstellenüberblick NFDM

In den folgenden Unterkapiteln werden die Schnittstellen zwischen dem Primärsystem und dem Fachmodul NFDM beschrieben.

5.2 Schnittstellen des Fachmoduls zum Primärsystem

5.2.1 Überblick

Das Fachmodul NFDM stellt für die Anwendungsfälle der Leistungsmerkmale NFDM-L_1 „Basisfunktionalität NFDM (Notfalldatensatz)“ und NFDM-L_2 „Persönliche Erklärungen NFDM“ dem Primärsystem jeweils eine Schnittstelle zur Verwaltung von NFD und DPE zur Verfügung.

Abbildung 13 zeigt die beiden Primärsystemschnittstellen des Fachmoduls und deren Operationen im Überblick.

Abbildung 12: Externe Primärsystemschnittstellen des Fachmoduls NFDM

Die einzelnen Operationen der Schnittstellen werden im Folgenden detaillierter beschrieben.

5.3 Schnittstelle „I_NFD_Management“

Das Interface „I_NFD_Management“ stellt dem Primärsystem eine Schnittstelle zur Verwaltung des NFD zur Verfügung. Über den Aufruf der Operationen dieser Schnittstelle kann das Primärsystem die Ausführung der Anwendungsfälle des Leistungsmerkmals NFDM-L_1 „Basisfunktionalität NFDM (Notfalldatensatz)“ anstoßen.

5.3.1 Operation „WriteNFD“

Die Operation „WriteNFD“ dient der Initiierung des Anwendungsfalls „NFD auf eGK schreiben“.

Tabelle 12: Parameter der Operation „WriteNFD“

5.3.2 Operation „ReadNFD“

Die Operation „ReadNFD“ dient der Initiierung des Anwendungsfalls „NFD von eGK lesen“.

Tabelle 13: Parameter der Operation „ReadNFD“

5.3.3 Operation „EraseNFD“

Die Operation „EraseNFD“ dient der Initiierung des Anwendungsfalls „NFD von eGK löschen“.

Tabelle 14: Parameter der Operation „EraseNFD“

5.4 Schnittstelle „I_DPE_Management“

Das Interface „I_DPE_Management“ stellt dem Primärsystem eine Schnittstelle zur Verwaltung des DPE zur Verfügung. Über den Aufruf der Operationen dieser Schnittstelle kann das Primärsystem die Ausführung der Anwendungsfälle des Leistungsmerkmals NFDM-L_2 „Persönliche Erklärungen NFDM“ anstoßen.

5.4.1 Operation „WriteDPE”

Die Operation „WriteDPE“ dient der Initiierung des Anwendungsfalls „DPE auf eGK schreiben“.

Tabelle 15: Parameter der Operation „WriteDPE“

5.4.2 Operation „ReadDPE”

Die Operation „ReadDPE“ dient der Initiierung des Anwendungsfalls „DPE von eGK lesen“.

Tabelle 16: Parameter der Operation „ReadDPE“

5.4.3 Operation „EraseDPE”

Die Operation „EraseDPE“ dient der Initiierung des Anwendungsfalls „DPE von eGK löschen“.

Tabelle 17: Parameter der Operation „EraseDPE“

6 Anhang A – Verzeichnisse

6.1 Abkürzungen

6.2 Glossar

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

6.3 Abbildungsverzeichnis

6.4 Tabellenverzeichnis

6.5 Referenzierte Dokumente

6.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 ist in der aktuellen von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

6.5.2 Weitere Dokumente

7 Anhang B

7.1 Abweichungen vom Lastenheft NFDM

Dieser Anhang gibt einen Überblick über die Änderungen von Anforderungen des Lastenhefts NFDM.

Änderung 1

Die Forderung nach maximal einmaliger PIN-Eingabe pro Steckzyklus der eGK wird aufgehoben, die betroffene Anforderung storniert.

Betroffene Anforderung: NFDM-A_125

Begründung: Mit Nutzung je einer eigenen Multireferenz-PIN für die Verwaltung des NFD und des DPE auf eGKs der Generation 2 ist die Anforderung NFDM-A_125, die maximal eine PIN-Eingabe pro Kartensteckzyklus fordert, nicht mehr erfüllbar. Die aus technischen Gründen erneut notwendige PIN-Eingabe beim Wechsel des Kontextes (NFD zu DPE und umgekehrt) – selbst wenn die PIN im Steckzyklus bereits einmal eingegeben wurde – ist darüber hinaus fachlich gewünscht.

Änderung 2

Die Forderung neben erfolgreichen Zugriffen auch jeden abgebrochenen Zugriffsversuch zu protokollieren wird aufgehoben, die betroffene Anforderung entsprechend geändert.

Betroffene Anforderung: NFDM-A_122, NFDM-A_172

Begründung: Gesetzlich ist nur die Protokollierung erfolgter Zugriffe auf die Daten der eGK gefordert. Zudem ist aus technischer Sicht die Forderung nicht vollständig erfüllbar, da ein Protokollschreiben erst nach erfolgreicher C2C-Authentisierung möglich ist. Darüber hinaus würde ein erfolgreicher Zugriff jeweils zwei Protokolleinträge benötigen, da man, um jeden Zugriffsversuch vor potentiellem Abbruch auch tatsächlich erfassen zu können, gleich nach erfolgreicher C2C-Authentisierung einen Zugriffsprotokolleintrag schreiben müsste. Ob tatsächlich ein Zugriff erfolgte, müsste dann vor dem regulären Beenden des Anwendungsfalls erneut protokolliert werden, da ein Überschreiben von Protokolleinträgen technisch nicht möglich ist. Protokolliert man nur Zugriffsversuche, wären tatsächlich erfolgte Zugriffe nicht unterscheidbar von (gescheiterten) Zugriffsversuchen. Damit folgt das Projekt zudem einer Empfehlung des BSI.

Änderung 3

Die Forderung der Sicherstellung von quantitativen Auswertungen im Rahmen der Testmaßnahmen bezüglich erfolgter PIN-Initialisierungen wird aufgehoben, die betroffene Anforderung storniert.

Betroffene Anforderung: NFDM-A_267

Begründung: PIN-Initialisierungen sind nur noch für eGKs der Generation G1 relevant, eGKs der Generation 2 werden nur noch mit Echt-PIN ausgeliefert.

Änderung 4

Die Berechtigungsmatrizen wurden für die Systemlösung geändert.

Betroffene Anforderungen: NFDM-A_158, NFDM-A_177, NFDM-A_197

Begründung: Notwendige Änderungen nach Einführung der Multireferenz-PIN für eGK G2, der letzten Gesetzesänderungen des § 291a SGB V im Rahmen von [TPGEntlÄndG] in Bezug auf Persönliche Erklärungen des Versicherten sowie die Aufnahme des Notfallsanitäters als fachlichen Akteur mit den gleichen Berechtigungen wie der Rettungsassistent. Die Berufsgruppe des Notfallsanitäters wurde durch [NotSanG] eingeführt, das am 01.01.2014 in Kraft tritt. Sie fällt unter die gemäß § 291a Abs. 4 zum Zugriff auf die Notfalldaten berechtigten „Angehörigen eines anderen Heilberufs, der für die Berufsausübung oder die Führung der Berufsbezeichnung eine staatlich geregelte Ausbildung erfordert“, ist aber nicht gleichzusetzen mit der Ausbildung des Rettungsassistenten. Der Fokus von NFDM bezüglich der angeführten Heilberufsgruppe liegt insbesondere auf den Rettungsassistenten und den Notfallsanitätern, andere Heilberufe (wie z. B. Hebammen) werden jedoch nicht ausgeschlossen und deshalb nun als „Andere Heilberufe“ in den Berechtigungsmatrizen berücksichtigt.

Änderung 5

Eine Signaturprüfung zur Sicherstellung der Authentizität, Integrität und Verbindlichkeit erfolgt nur noch beim Lesen, nicht mehr beim Schreiben bzw. Ändern des NFD. Die betroffenen Anforderungen werden geändert.

Betroffene Anforderungen: NFDM-A_117, NFDM-A_118, NFDM-A_119

Begründung: Da eine Signaturprüfung immer beim Lesen erfolgt, also bei der Nutzung der Daten, ist eine Prüfung beim Schreiben nicht zusätzlich nötig und erhöht auch nicht die Sicherheit. Zudem würde der Benutzer im Gesamtprozess des Aktualisierungsvorgangs mit vorherigem Lesen dann zweimal eine Prüfung durchlaufen müssen.

Änderung 6

Die Forderung nach einer Änderung des Informationsmodells von NFDM ohne Neuevaluation (in einem Zyklus von 2 Jahren) wird aufgehoben und die betroffene Anforderung storniert.

Betroffene Anforderung: NFDM-A_106

Begründung: Diese Anforderung ist im Rahmen der monolithischen Lösung für den Konnektor nicht erfüllbar. Die Entwicklung des Informationsmodells im Rahmen der Fachanwendung ist zudem Gegenstand des Releasemanagements für die Fachanwendung.

Änderung 7

Die Unterstützung für Attributzertifikate durch die Fachanwendung NFDM wurde gestrichen. Die betroffene Anforderung wird storniert.

Betroffene Anforderung: NFDM-A_157

Begründung: Es werden keine HBA-Vorläuferkarten für NFDM unterstützt. Der Fokus der Unterstützung von HBA-Vorläuferkarten liegt auf der Unterstützung bereits bestehender HBA-Anwendungen.

Änderung 8

Die maximal zulässige Bearbeitungszeit für das Lesen der NFD (exklusive Bearbeitungszeit für die Signaturprüfung) wurde von 3 auf 5 Sekunden (im Mittel) erhöht.

Betroffene Anforderung: NFDM-A_126

Begründung: Gemäß Performancemodell der Basis-TI lässt sich die ursprüngliche Anforderungen in Bezug auf den detaillierten Anwendungsfall nicht erfüllen.

7.2 Zuordnung der Lastenheftanforderungen zu Produkttypen

7.2.1 Fachmodul NFDM