gemILF_PS_NFDM_V1.2.0
Elektronische Gesundheitskarte und Telematikinfrastruktur
Implementierungsleitfaden Primärsysteme – Notfalldaten-Management (NFDM)
Version | 1.2.0 |
Revision | 548770 |
Stand | 14.05.2018 |
Status | in Bearbeitung |
Klassifizierung | öffentlich |
Referenzierung | gemILF_PS_NFDM |
Dokumentinformationen
Änderungen zur Vorversion
Die Einarbeitung der Änderungslisten P15.2 und P15.4 erfolgt in gelb.
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
---|---|---|---|---|
1.1.0 |
05.10.17 |
Überarbeitung zum Online-Rollout (Stufe 2.1) |
gematik |
|
Einarbeitung P15.2 und P15.4 |
gematik |
|||
1.2.0 |
14.05.18 | freigegeben |
gematik |
Hinweis zur Erstellung des Leitfadens
Der Leitfaden wurde mit beratender Unterstützung des Bundesverbandes Gesundheits-IT, bvitg e. V., erstellt.
Inhaltsverzeichnis
1 Einordnung des Dokuments
1.1 Zielsetzung
Unter dem Begriff Notfalldaten-Management (NFDM) ist das Handling von Informationen zu verstehen, die auf der elektronischen Gesundheitskarte (eGK) des Versicherten abgelegt werden und in der Notfallversorgung des Versicherten zur Anwendung kommen (§ 291a SGB V). Die Nutzung des Notfalldaten-Managements ist für den Versicherten freiwillig und kann von jedem Versicherten mit einer eGK genutzt werden. Voraussetzung für die Nutzung der Fachanwendung NFDM ist eine vom Versicherten gegebene Einwilligung.(Ausnahme:Gemäß § 291a Abs. 5a Satz 4 SGB V können Versicherte eigenständig auf DPE zugreifen. Wenn der Versicherte ohne Unterstützung eines Zugriffsberechtigten mit der Erhebung, Verarbeitung oder Nutzung seiner DPE, z.B. an einer AdV-Umgebung beginnt, ist gemäß § 291a Abs. 3 Satz 6 SGB V keine Einwilligung in DPE bei einem Leistungserbringer erforderlich.)
Das NFDM besteht aus zwei getrennten Datencontainern bzw. Datensätzen:
- Notfalldatensatz (notfallrelevante medizinische Daten), kurz NFD
- Datensatz persönliche Erklärungen, kurz DPE. Enthält Angaben zum Ablageort bzw. Bevollmächtigten der persönlichen Erklärung(pE – persönliche Erklärung) (Gewebe- und Organspendeerklärung, Vorsorgevollmacht, Patientenverfügung). Diese Angaben sagen nichts über den Inhalt der Erklärung aus.
Der vorliegende Leitfaden definiert fachliche Anforderungen und gibt Hilfen zur Implementierung von Abläufen bei der Verwaltung von NFD und DPE im Primärsystem.
Dieses Dokument beschreibt:
- die Anwendungsfälle, die die Operationen an der Außenschnittstelle des Fachmoduls NFDM nutzen
- die Nutzung der Schnittstelle der Signaturanwendungskomponente des Konnektors zur Erstellung einer qualifizierten elektronischen Signatur (QES) für einen NFD.
Um eine möglichst einheitliche Darstellung des NFD in unterschiedlichen Primärsystemen zu erreichen, wird eine Orientierungshilfe vorgegeben, welche eine Gruppierung der Elemente des NFD bei der Anzeige im Primärsystem vorgibt.
1.2 Zielgruppe
Das Dokument richtet sich an Hersteller von Primärsystemen (Praxisverwaltungssysteme und Krankenhausinformationssysteme).
1.3 Geltungsbereich
Dieses Dokument enthält informative Anforderungen für Primärsysteme. 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.
Wichtiger 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
Das Dokument beschreibt die Nutzung der Schnittstellen zum Fachmodul NFDM und die damit verbundenen Anwendungsfälle im Primärsystem. Darüber hinausgehende Anwendungsfälle, die sich nicht dieser Schnittstellen bedienen, sind nicht Bestandteil dieses Dokumentes.
Dieses Dokument verweist auf den Implementierungsleitfaden für Primärsysteme [gemILF_PS], welches die Nutzung von Komponenten und Schnittstellen der Telematikinfrastruktur (z. B. Verbindungsaufbau zum Konnektor) durch Primärsysteme von Leistungserbringern beschreibt. Insbesondere für Entwickler von Primärsystemen sind die Grundlagen aus dem Leitfaden für die Schnittstellenimplementierung zur Telematikinfrastruktur unverzichtbar.
Der Fokus dieses Dokumentes liegt bei der Definition der fachlichen Anforderungen und der Beschreibung von Abläufen zur Verarbeitung der Datensätze der Fachanwendung NFDM im Primärsystem, deren Struktur das Informationsmodell NFDM [gemSpec_InfoNFDM] spezifiziert. Beschreibungen der internen Abläufe der genannten Schnittstellen sind in der Spezifikation des Fachmoduls NFDM [gemSpec_FM_NFDM] und des Konnektors [gemSpec_Kon] zu finden. Anforderungen an andere Produkttypen sind nicht Bestandteil dieses Dokuments.
Folgende Themenbereiche sind ebenfalls nicht Bestandteil des vorliegenden Dokumentes:
- Festlegungen zur Zuordnung von Heilberufsausweisen (HBA) zu Primärsystem und Mandant, d.h. Identitätsmanagement sowie Rollen- und Rechteverwaltung liegen in der Hoheit des Primärsystems,
- Synchronisationsabläufe zwischen den NFD/DPE und dem Datenbestand des Primärsystems,
- Festlegungen der internen Geschäftsprozesse der Leistungserbringer,
- Verfahrenshinweise zur Weiterleitung von Nachrichten oder Fehlermeldungen an andere Systeme,
- Auslesen der Versichertenstammdaten von der eGK des Versicherten,
- Sicherstellung der langfristigen Verbindlichkeit des NFD (Übersignatur) und die Archivierung von NFD und DPE.
1.5 Methodik
1.5.1 Beschreibung von Anwendungsfällen
Im vorliegenden Implementierungsleitfaden werden die einzelnen Anwendungsfälle der Fachanwendung NFDM im Primärsystem beschrieben und daraus Anforderungen abgeleitet. Die Abläufe der Anwendungsfälle verdeutlichen den Umgang mit den Operationen des Fachmoduls NFDM und des Konnektors.
Die Beschreibung der Anwendungsfälle erfolgt nach folgendem Muster:
Beschreibung des Standardablaufs (Tabelle)
Beschreibung der Umsetzung des Standardablaufs (Tabelle)
Sequenzdiagramm (optional).
Die Tabellen zur Anwendungsfallbeschreibung beinhalten neben dem Namen eine Kurzbeschreibung und einen Standardablauf. Darüber hinaus werden Vor- und Nachbedingungen, Auslöser sowie fachliche Akteure angegeben.
Der Standardablauf beschreibt die Durchführung des Anwendungsfalls im Erfolgsfall und besteht aus nummerierten Aktivitäten. Die Umsetzung des Standardablaufs ist in der weiteren Tabelle ausführlicher erläutert. Allgemeine Vorgaben zur Fehlerbehandlung im Primärsystem und Verweise auf die generischen und spezifischen Fehlermeldungen des Fachmoduls NFDM sind im Kapitel 7.1 enthalten.
Sequenzdiagramme der Anwendungsfälle beinhalten neben der Darstellung des Standardablaufs auch Interaktionen des Primärsystems mit anderen Akteuren und Nachbarsystemen. Interne Prozesse der beteiligten Akteure und Nachbarsysteme werden nicht in den Diagrammen dargestellt. Diese Diagramme verdeutlichen den Nachrichtenaustausch zwischen dem Primärsystem und der von der Telematikinfrastruktur angebotenen Außenschnittstellen.
1.5.2 Anforderungen
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-, Parameternamen oder XML-Elemente/-Attribute werden in nicht-proportionaler Schriftart dargestellt.
Beispiele werden hervorgehoben dargestellt. Bei der Auswertung der (informativen) Beispiele ist zu beachten, dass die zugrunde liegenden XML-Schemadateien und WSDLs versioniert sind und einem Releasemanagement unterliegen. Eine Orientierung über die an der Konnektorschnittstelle zu verwendenden Schemaversionen und Namensräume bietet [gemSpec_Kon#AnhD].
2 Systemüberblick und Kontext
2.1 Schnittstellen zur Telematikinfrastruktur
Dieser Implementierungsleitfaden beschreibt die Nutzung der Schnittstellen der dezentralen Umgebung der Telematikinfrastruktur (Fachmodul NFDM(Spezifikation Fachmodul NFDM [gemSpec_FM_NFDM]) und Konnektor(Spezifikation Konnektor [gemSpec_Kon])) durch das Primärsystem von berechtigten Akteuren im Rahmen der Fachanwendung NFDM.
Die Abbildung 1 stellt die Komponenten und Schnittstellen abstrakt dar. Verbindungen zwischen dem Primärsystem und der dezentralen Umgebung der TI sind stark vereinfacht und dienen nur der Übersicht.
Das Primärsystem arbeitet in der Umgebung des Leistungserbringers und kommuniziert mit dezentralen Komponenten der TI. Dem Akteur ermöglicht das Primärsystem die Nutzung der Fachanwendung NFDM, unterstützt ihn bei Zugriffen auf den eigenen Datenbestand und führt im Auftrag des Akteurs entsprechende Operationen aus. Dabei greift das Primärsystem auf Schnittstellen zu, die der Konnektor an seiner Außenschnittstelle zur Verfügung stellt.
Das Primärsystem kann nicht direkt auf die Kartenterminals und die Karten, die in den Kartenterminals stecken, zugreifen, um Informationen über diese abzufragen. Die Verwaltung der Kartenterminals und der Karten übernimmt der „Systeminformationsdienst“ des Konnektors. Dieser Dienst ermöglicht dem Primärsystem mittels der Schnittstelle I_Poll_System_Information (EventService), Informationen über Kartenterminals und Karten abzufragen. Die Kommunikation verläuft dabei über das SOAP-Protokoll an der vom Konnektor bereitgestellten Webservice-Schnittstelle. Die abgefragten Informationen können die Liste der Kartenterminals enthalten, auf die der aufrufende Mandant und das Primärsystem zugreifen dürfen, sowie die Verfügbarkeit dieser Kartenterminals, falls der Konnektor eine Verbindung zum Kartenterminal hält. Über die Schnittstelle können Karten-Handles abgefragt werden, die bei anderen Konnektoraufrufen zur Adressierung von Karten genutzt werden.
Über die Schnittstelle I_Reg_Notification (EventService) mittels des SOAP-Protokolls meldet das Primärsystem beim Systeminformationsdienst sein Interesse an bestimmten Ereignissen (Topics) an.
Die Zustellung der Ereignisse erfolgt unidirektional an das Primärsystem. Zur Übertragung der Daten wird ein konnektoreigenes Protokoll CETP (Connector Event Transport Protocol) verwendet. Die Struktur dieser Nachricht entspricht dem Element Event gemäß dem Schema EventService.xsd(Aufbau der Ereignisnachricht: [gemILF_PS #4.1.4.1]). Durch das Empfangen der Ereignisse erfährt das Primärsystem z.B., ob der Konnektor eine PIN-Eingabe vom Versicherten verlangt oder ob eine Karte in ein Kartenterminal gesteckt wurde. Diese Informationen kann das Primärsystem dem Akteur mitteilen, damit er rechtzeitig auf das empfangene Ereignis reagieren kann.
Die Kommunikation mit dem Fachmodul NFDM erfolgt mittels des SOAP-Protokolls. Die Operationsaufrufe sind XML-Dokumente und die übertragenen NFD/DPE sind base64-kodiert. Mittels der dargestellten Schnittstellen(Die Spezifikation der Schnittstellen zum Fachmodul NFDM [gemSpec_FM_NFDM#6]) in der Abbildung 2 ermöglicht das Fachmodul NFDM dem Primärsystem mittelbar auf die eGK des Versicherten zuzugreifen. Dabei kann das Primärsystem den NFD/DPE von der eGK auslesen, einen neuen NFD/DPE auf die eGK schreiben oder bei Änderungsbedarf einen bereits existierenden NFD/DPE auf der eGK überschreiben. Außerdem ermöglicht das Fachmodul NFDM dem Primärsystem, den auf der eGK vorhandenen NFD/DPE zu löschen. Die Kommunikation mit dem Fachmodul NFDM erfolgt nur auf explizite Anforderung des berechtigten Akteurs.
Das Primärsystem muss sicherstellen, dass der NFD vor dem Schreiben auf die eGK des Versicherten qualifiziert elektronisch signiert ist. Dazu nutzt das Primärsystem die Schnittstelle I_Sign_Operations(Spezifikation der Schnittstelle zur QES-Erstellung [gemSpec_Kon#4.1.8.5]) (SignatureService) der Komponente „Signaturdienst“ des Konnektors. Diese Schnittstelle unterstützt auch die QES-Erstellung für mehrere NFD (Stapelsignatur). Die Übertragung der Nachrichten erfolgt über das SOAP-Protokoll und der NFD ist base64-kodiert.
Der DPE wird nicht signiert.
2.2 Akteure und Rollen
Akteure interagieren mit den in diesem Dokument vorgestellten Anwendungsfällen. Sie greifen mittels des Primärsystems auf NFD/DPE, die sich auf der eGK des Versicherten befinden, und auf den Datenbestand des Primärsystems zu.
Berechtigte Akteure sind diejenigen Personen, die den Anwendungsfall erfolgreich durchführen können, für die Zugriffsrechte entweder im Fachmodul NFDM definiert sind und evtl. von anderen Personen mit elektronischem Heilberufsausweis (HBA) autorisiert sind. Über ihre Rolle, die technisch durch das Zugriffsprofil ihrer Smartcard repräsentiert wird, erhalten die Akteure die benötigte Berechtigung zum Zugriff auf die NFD oder DPE der eGK.
Berechtigte Akteure können folgende sein: Ärzte, Zahnärzte, Apotheker und jeweils ihre Mitarbeiter sowie Psychotherapeuten und andere Heilberufe (insbesondere Rettungsassistenten/Notfallsanitäter).
In der folgenden Tabelle wird auf Kapitel der Spezifikation des Fachmoduls NFDM verwiesen, in denen die Berechtigungsmatrizen regeln, welche Akteure für die Ausführung der jeweiligen Operationen des Fachmoduls NFDM autorisiert sind.
NFD |
DPE |
|
ReadNFD/-DPE |
[gemSpec_FM_NFDM#6.1.1.1.1] |
[gemSpec_FM_NFDM#6.2.1.1.1] |
WriteNFD/-DPE |
[gemSpec_FM_NFDM#6.1.1.1.2] |
[gemSpec_FM_NFDM#6.2.1.1.2] |
EraseNFD/-DPE |
[gemSpec_FM_NFDM#6.1.1.1.3] |
[gemSpec_FM_NFDM#6.2.1.1.3] |
Akteure, die in Besitz eines HBA sind, können Erstellung einer QES für NFD durchführen.
Versicherter wird in diesem Dokument als Inhaber einer eGK und Nutzer der Fachanwendung NFDM dargestellt, falls er in die Nutzung der Fachanwendung NFDM eingewilligt hat. Die Begriffe „Versicherter“ und „Patient“ sind in diesem Dokument gleichgestellt. Wegen der einheitlichen Verwendung von Begriffen in Spezifikationen der gematik wird der Begriff „Versicherter“ gewählt. Der Versicherte kann dem berechtigten Akteur sein Einverständnis über den Zugriff auf die eGK geben.
2.3 Beteiligte Systeme
Direkt vom Primärsystem erreichbare Systeme sind:
Fachmodul NFDM im Konnektor
Konnektor
Das Primärsystem bedient sich als Clientsystem an den Außenschnittstellen des Fachmoduls NFDM und des Konnektors. Das Fachmodul NFDM ist integraler Bestandteil des Konnektors.
Das Primärsystem kann nicht direkt auf das stationäre Kartenterminal zugreifen, in dem die eGK des Versicherten steckt, sondern nur mittels des Fachmoduls NFDM bzw. des Konnektors. Somit stellt das stationäre Kartenterminal ein weiteres beteiligtes System dar, auf welches das Primärsystem nur mittelbar zugreifen kann.
2.4 Informationsmodell NFDM
Das (technische) Informationsmodell NFDM ist in [gemSpec_InfoNFDM] spezifiziert.
Das Dokument enthält weitere Anforderungen an Primärsysteme, die von Primärsystemherstellern zu berücksichtigen sind.
Das Primärsystem MUSS alle durch das XML-Schema des Infomodells NFDM festgelegten Regeln und die darüber hinaus gehenden in [gemSpec_InfoNFDM] definierten Integritätsregeln überprüfen und den Akteur auf zu korrigierende Einträge hinweisen, bevor es einen NFD oder DPE über den Konnektor auf die eGK schreibt.
NFDM-A_2375 - Clientseitige Validierung
Bevor das Primärsystem einen NFD oder DPE an den Konnektor sendet, MUSS es alle durch das XML-Schema des Infomodells NFDM festgelegten Regeln und die darüber hinaus gehenden in [gemSpec_InfoNFDM] definierten Integritätsregeln auf Einhaltung überprüfen und den Akteur solange auf fehlerhafte Einträge hinweisen, bis er alle korrigiert hat.
[<=]3 Voraussetzungen
Es wird vorausgesetzt, dass das Primärsystem betriebsbereit ist. Dieses soll in der Lage sein, dem berechtigten Akteur die vollständige Nutzung der Fachanwendung NFDM zu gewährleisten. Um das zu erreichen, muss das Primärsystem folgende Voraussetzungen erfüllen:
- Verbindung zum Konnektor (HTTP oder HTTPS) aufbauen,
- Informationen über verfügbare Dienste des Konnektors beschaffen,
- Außenschnittstelle des Konnektors mittels des SOAP-Protokolls ansprechen können,
- Ereignisse beim Ereignisdienst des Konnektors abonnieren können,
- Kontext von Karten erfahren oder abfragen können,
- Verfügbarkeit vorhandener Kartenterminals abfragen können,
- Leistungserbringer-Karte (HBA bzw. SMC-B) freischalten,
- die Konfiguration (Parameter des Aufrufkontextes) von Primärsystem und Konnektor aneinander angleichen.
Wie die Betriebsbereitschaft des Primärsystems hergestellt werden kann, wird ausführlich in [gemILF_PS#4.1] beschrieben.
4 Übergreifende Festlegungen
4.1 Nutzung von Indikatoren
Beim lesenden Zugriff auf NFD/DPE der eGK des Versicherten sind Berechtigungsregeln maßgeblich, die sowohl vom jeweiligen fachlichen Akteur als auch vom Zweck des Zugriffs abhängig sind. Während die Berechtigungsregeln für einzelne Akteure über das Fachmodul gesteuert werden, muss für die Bestimmung des Zugriffszwecks eine Interaktion mit dem jeweiligen Akteur stattfinden. In Folge dieser Interaktion teilt das Primärsystem dem Fachmodul NFDM den Zweck des Auslesens mit. Dies erfolgt über zwei Parameter (EmergencyIndicator und UpdateIndicator) der Leseoperationen ReadNFD und ReadDPE, die das Fachmodul NFDM an seiner Außenschnittstelle dem Primärsystem zur Nutzung anbietet.
Das Mitteilen des Zwecks des Auslesens beeinflusst die Auswahl der Berechtigungsregel im Fachmodul NFDM. Die Berechtigungsregeln definieren, welche fachlichen Akteure ein Zugriffsrecht auf NFD/DPE der eGK des Versicherten erhalten und unter welchen Bedingungen.
Die Feststellung, zu welchem Zweck der NFD/DPE von der eGK des Versicherten ausgelesen werden soll, kann durch eine Benutzerabfrage oder Benutzerauswahl im Primärsystem erfolgen. Diese Abfrage oder Auswahl trägt dazu bei, dass der Leistungserbringer aufgrund seiner bewussten Entscheidung das Auslesen des NFD/DPE von der eGK des Versicherten unter angemessenen Umständen initiiert.
Anhand des EmergencyIndicator-Parameters dokumentiert das Primärsystem, ob der aktuelle Ausleseprozess des NFD/DPE innerhalb einer Notfallsituation stattfindet. Die entsprechende Wertzuweisung des UpdateIndicator-Parameters trägt dazu bei festzustellen, ob der Zugriff auf den NFD/DPE durch eine Bearbeitung des Datensatzes motiviert ist.
4.2 PIN-Handling
4.2.1 Einverständniserteilung für den Zugriff auf eGK
Neben dem lesenden Zugriff kann der berechtigte Akteur auch schreibend auf die eGK des Versicherten zugreifen. Bei diesen Zugriffen der Status der PIN eine wichtige Rolle.
Bei der Aufforderung des Versicherten, die entsprechende PIN am Kartenterminal einzugeben, kann der Versicherte selbst entscheiden, ob er dem Akteur den Zugriff auf seine eGK erteilen will. Durch diesen PIN-Schutzmechanismus wird verhindert, dass beliebige Akteure direkt auf den NFD/DPE zugreifen können.
Die MRPIN.NFD und MRPIN.DPE der eGK haben bei der Auslieferung an die Versicherten den Status „deactivated“. Den Status dieser MRPINs kann der Versicherte an einem Leistungserbringer-AdV-Terminal, einem Kostenträger-AdV-Terminal oder in der @home-Umgebung an einem Gerät des Versicherten ändern. Die MRPIN.NFD_READ und MRPIN.DPE_READ werden im Status „activated“ an die Versicherten ausgeliefert und sie lassen sich nicht deaktivieren.
4.2.2 Zustimmung vom Arzt zur QES-Erstellung
Handelt es sich um eine QES-Erstellung, wird der Arzt vom Konnektor aufgefordert, die PIN seines HBA am Kartenterminal einzugeben. Nach der PIN-Eingabe und der erfolgreich durchgeführten PIN-Verifikation wird mit der QES-Erstellung fortgefahren.
4.3 Protokollierung
NFDM-A_2289 - Protokollierung der nachprüfbaren Informationen über die zugriffsberechtigten Personen
Greift die zugriffsberechtigte Person mittels SMC-B auf den NFD oder den DPE des Versicherten zu und ist diese Person auch von einer anderen Person mit elektronischem Heilberufsausweis (HBA) autorisiert, KANN das Primärsystem nachprüfbare Informationen über diese beiden Personen protokollieren (§291a Abs. 5 Satz 4 SGB V).
[<=]Aufgrund der gesetzlichen Anforderung wird der autorisierenden Person überlassen, wie sichergestellt wird, dass nachprüfbar elektronisch protokolliert wird, wer auf die Daten zugegriffen hat und von wem die zugreifende Person autorisiert wurde. Dies kann zum Beispiel im Praxisverwaltungssystem des Arztes erfolgen.
Die SMC-B der zugriffsberechtigten Person, die auf die eGK des Versicherten zugreifen will, kann mittels eines HBA autorisiert werden. Die Feststellung, ob die SMC-B bereits freigeschaltet ist oder wie die Freischaltung der SCM-B mittels eines HBA erfolgen soll, ist in [gemILF_PS#4.1.5.4] beschrieben.
4.4 Übergreifende Vorbedingungen NFD/DPE
Für die in den Kapiteln 5.1 und 5.2 beschriebenen Anwendungsfälle gelten folgende übergreifende Vorbedingungen:
- Das Primärsystem ist betriebsbereit.
- Das Primärsystem kennt die Schnittstellen aus der Abbildung 1: Schnittstellen zu der TI.
- Konfigurationseinheiten (Primärsystem, Mandant, Arbeitsplatz, Kartenterminals) des Primärsystems sind auch in der Konfiguration des Konnektors enthalten.
- Die berechtigte Karte (HBA bzw. SMC-B) ist freigeschaltet und steckt in einem durch das Primärsystem erreichbarem Kartenterminal.
- Der Akteur hat bereits die für den jeweiligen Anwendungsfall entsprechende Leistungserbringer-Karte (HBA bzw. SMC-B) selektiert und verwendet das CardHandle zur eindeutigen Identifizierung der Karte.
- Die durch das Zugriffsprofil der beteiligten Karte (HBA bzw. SMC-B) repräsentierte fachliche Rolle ist zur Ausführung der Operationen des Fachmoduls NFDM bzw. des Konnektors berechtigt.
- Das Primärsystem hat bereits Abonnements auf die relevanten Topics beim Konnektor (Systeminformationsdienst) angemeldet.
5 Anwendungsfälle
Dieses Kapitel beschreibt die Anwendungsfälle der Fachanwendung NFDM aus Sicht des berechtigten Akteurs bezüglich der Verarbeitung des NFD und DPE des Versicherten im Primärsystem. Das Kapitel stellt Anforderungen an die Funktionalität des Primärsystems und gibt Implementierungshilfen.
Für jeden Anwendungsfall erfolgt eine Detaillierung mittels einer tabellarischen Beschreibung. Der Standardablauf einzelner Anwendungsfälle wird durch ein Sequenzdiagramm dargestellt.
5.1 Die Verwaltung des NFD im Primärsystem
NFDM-A_2291 - Unabhängige Verarbeitung des NFD von der DPE
Das Primärsystem MUSS sicherstellen, dass das Lesen, Aktualisieren, Signieren, Schreiben und Löschen des Notfalldatensatzes unabhängig von der Verwaltung des Datensatzes „Persönliche Erklärungen“ stattfindet.
[<=]Um das medizinische Assistenzpersonal optimal in die Prozesse des Notfalldatenmanagements einbinden zu können – z. B. im Rahmen vorbereitender und unterstützender Tätigkeiten – ist eine Unterstützung eines arbeitsteiligen Verwaltungsprozesses des NFD und des DPE unerlässliche Voraussetzung für die Akzeptanz und Praxistauglichkeit des Notfalldatenmanagements. Daher ist es erforderlich, dass die Verwaltung des NFD und DPE in mehreren unabhängigen Schritten erfolgen kann, die zeitlich nicht in direkter Aufeinanderfolge stattfinden müssen.
NFDM-A_2296 - Ermöglichung der Trennung von Arbeitsschritten bei der Verarbeitung des NFD
Das Primärsystem MUSS es dem Akteur ermöglichen, durch Konfiguration oder andere Regelungen sicherzustellen, dass das Zusammenstellen, Signieren und Schreiben des NFD in zeitlich getrennten Arbeitsschritten durch unterschiedliche Akteure erfolgen kann.
[<=]NFDM-A_2374 - Ermöglichung der Trennung von Arbeitsschritten bei der Verarbeitung persönlicher Erklärungen
Das Primärsystem MUSS es dem Akteur ermöglichen, durch Konfiguration oder andere Regelungen sicherzustellen, dass das Zusammenstellen und Schreiben einer persönlichen Erklärung in zeitlich getrennten Arbeitsschritten durch unterschiedliche Akteure erfolgen kann.
[<=]Hinweis: Das Zusammenstellen von NFD und DPE kann in mehreren unabhängigen Schritten erfolgen, die zeitlich nicht in direkter Aufeinanderfolge stattfinden müssen. Hier wird der Situation in Arztpraxen etc. Rechnung getragen, dass Arbeitsabläufe unterbrochen und zu einem späterem Zeitpunkt fortgesetzt werden können. Zusätzlich können mehrere berechtigte Akteure in die Zusammenstellung eingebunden sein.