gemILF_PS_NFDM_V1.5.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Implementierungsleitfaden Primärsysteme – Notfalldaten-Management (NFDM)

    

     

      
Version
      
1.5.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
26.08.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemILF_PS_NFDM
     
    

Dokumentinformationen

Änderungen zur Vorversion

Dokumentenhistorie

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. 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.

Das NFDM besteht aus zwei getrennten Datencontainern bzw. Datensätzen:

1. Notfalldatensatz (notfallrelevante medizinische Daten), kurz NFD
2. 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 ID und der Textmarke 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.

Abbildung 1: Schnittstellen zu der TI

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.

Abbildung 2: Schnittstellen zum Fachmodul NFDM

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.

Tabelle 1: Verweise auf die Zugriffsmatrizen des Fachmoduls NFDM

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.

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 einer 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.

Tabelle 2: Tab_ILF_NFDM_000 – PIN-Eingabe durch Versicherte

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

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

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.

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.

Abbildung 3: Anwendungsfalldiagramm - Verwaltung des NFD im Primärsystem

Wegen der besseren Lesbarkeit sind im Anwendungsfalldiagramm der Abbildung 3 keine Akteure dargestellt. Die berechtigten Akteure sind in den Spezifikationen der Anwendungsfälle und in den Berechtigungsmatrizen der jeweiligen für den Anwendungsfall relevanten Operationen des Fachmoduls NFDM angegeben.

Im Folgenden werden die in der Abbildung 3 dargestellten Anwendungsfälle ausführlicher vorgestellt.

5.1.1 NFD im Notfall von eGK anzeigen

Tabelle 3: Tab_ILF_NFDM_001 – NFD im Notfall von eGK anzeigen

Tabelle 4: Tab_ILF_NFDM_002 Ablaufaktivitäten – NFD im Notfall von eGK anzeigen

Abbildung 4: Abb_ILF_NFDM_001 Standardablauf – NFD im Notfall von eGK anzeigen

5.1.2 NFD außerhalb des Notfalls von eGK anzeigen

Tabelle 5: Tab_ILF_NFDM_003 – NFD außerhalb des Notfalls von eGK anzeigen

Tabelle 6: Tab_ILF_NFDM_004 Ablaufaktivitäten – NFD außerhalb des Notfalls von eGK anzeigen

Abbildung 5: Abb_ILF_NFDM_002 Standardablauf – NFD außerhalb des Notfalls von eGK anzeigen

5.1.3 NFD auf eGK erstellen

Tabelle 7: Tab_ILF_NFDM_005 – NFD auf eGK erstellen

Tabelle 8: Tab_ILF_NFDM_006 Ablaufaktivitäten – NFD auf eGK erstellen

Abbildung 6: Abb_ILF_NFDM_003 Standardablauf – NFD auf eGK erstellen

5.1.4 NFD auf eGK aktualisieren

Tabelle 9: Tab_ILF_NFDM_007 – NFD auf eGK aktualisieren

Tabelle 10: Tab_ILF_NFDM_008 Ablaufaktivitäten – NFD auf eGK aktualisieren

Abbildung 7: Abb_ILF_NFDM_004 Standardablauf – NFD auf eGK aktualisieren

5.1.5 NFD signieren

Das Primärsystem kann zum Signieren die Operation SignDocument des SignatureService des Konnektors oder dieselbe Operation des Signaturproxy nutzen. Details dazu finden sich in [gemILF_PS#4.4].

Folgende NFDM-spezifische Anforderungen sind dabei zu beachten.

Hinweis:
Die Signatur liegt im Element /NFD:NFD_Document/NFD:SignatureArzt des NFD.

<PTV4>

</PTV4>

5.1.6 NFD auf eGK schreiben

Tabelle 11: Tab_ILF_NFDM_011 – NFD auf eGK schreiben

Tabelle 12: Tab_ILF_NFDM_012 Ablaufaktivitäten – NFD auf eGK schreiben

Abbildung 8: Abb_ILF_NFDM_006 Standardablauf – NFD auf eGK schreiben

5.1.7 NFD von eGK löschen

Tabelle 13: Tab_ILF_NFDM_013 – NFD von eGK löschen

Tabelle 14: Tab_ILF_NFDM_014 Ablaufaktivitäten – NFD von eGK löschen

Abbildung 9: Abb_ILF_NFDM_007 Standardablauf – NFD von eGK löschen

5.2 Die Verwaltung des DPE im Primärsystem

Abbildung 10: Anwendungsfalldiagramm - Verwaltung des DPE im Primärsystem

Die Abbildung 10 stellt eine Übersicht der Anwendungsfälle der Verwaltung des DPE im Primärsystem dar und zeigt deren Abhängigkeiten untereinander. Wegen der besseren Lesbarkeit sind in dem Anwendungsfalldiagramm keine Akteure dargestellt. Die berechtigten Akteure sind in den Spezifikationen der Anwendungsfälle und auch in den Berechtigungsmatrizen der jeweiligen für den Anwendungsfall relevanten Operationen des Fachmoduls NFDM angegeben.

5.2.1 Persönliche Erklärung im Notfall von eGK anzeigen

Tabelle 15: Tab_ILF_NFDM_015 – Persönliche Erklärung im Notfall von eGK anzeigen

Tabelle 16: Tab_ILF_NFDM_016 Ablaufaktivitäten – Persönliche Erklärung im Notfall von eGK anzeigen

Abbildung 11: Abb_ILF_NFDM_008 Standardablauf – Persönliche Erklärung im Notfall von eGK anzeigen

5.2.2 Persönliche Erklärung außerhalb des Notfalls von eGK anzeigen

Tabelle 17: Tab_ILF_NFDM_017 – Persönliche Erklärung außerhalb des Notfalls von eGK anzeigen

Tabelle 18: Tab_ILF_NFDM_018 Ablaufaktivitäten – Persönliche Erklärung außerhalb des Notfalls von eGK anzeigen

Abbildung 12: Abb_ILF_NFDM_009 Standardablauf – Persönliche Erklärung außerhalb des Notfalls von eGK anzeigen

5.2.3 Persönliche Erklärung auf eGK aktualisieren

Tabelle 19: Tab_ILF_NFDM_019 – Persönliche Erklärung auf eGK aktualisieren

Tabelle 20: Tab_ILF_NFDM_020 Ablaufaktivitäten – Persönliche Erklärung auf eGK aktualisieren

Abbildung 13: Abb_ILF_NFDM_010 Standardablauf – Persönliche Erklärung auf eGK aktualisieren

5.2.4 Persönliche Erklärung auf eGK erstellen

Tabelle 21: Tab_ILF_NFDM_021 – Persönliche Erklärung auf eGK erstellen

Tabelle 22: Tab_ILF_NFDM_022 Ablaufaktivitäten – Persönliche Erklärung auf eGK erstellen

Abbildung 14: Abb_ILF_NFDM_011 Standardablauf – Persönliche Erklärung auf eGK erstellen

5.2.5 Persönliche Erklärung von eGK löschen

Tabelle 23: Tab_ILF_NFDM_023 – Persönliche Erklärung von eGK löschen

Tabelle 24: Tab_ILF_NFDM_024 Ablaufaktivitäten – Persönliche Erklärung von eGK löschen

Abbildung 15: Abb_ILF_NFDM_012 Standardablauf – Persönliche Erklärung von eGK löschen

5.2.6 Secondary: DPE auf eGK schreiben

Tabelle 25: Tab_ILF_NFDM_025 – (secondary) DPE auf eGK schreiben

Tabelle 26: Tab_ILF_NFDM_026 Ablaufaktivitäten – (secondary) DPE auf eGK schreiben

Abbildung 16: Abb_ILF_NFDM_013 Standardablauf – (secondary) DPE auf eGK schreiben

5.2.7 DPE von eGK löschen

Tabelle 27: Tab_ILF_NFDM_027 – DPE von eGK löschen

Tabelle 28: Tab_ILF_NFDM_028 Ablaufaktivitäten – DPE von eGK löschen

Abbildung 17: Abb_ILF_NFDM_014 Standardablauf – DPE von eGK löschen

6 Ergänzende Funktionalitäten

6.1 Empfehlung zur Archivierung

Auf der Grundlage gesetzlicher Regelungen besteht eine Archivierungspflicht für die medizinischen Dokumente des Versicherten. Die Archivierung ist korrekt, verständlich, vollständig, nachvollziehbar und zeitnah durchzuführen. Je nach gesetzlicher Regelung sind damit dokumentierte Inhalte mit Aufbewahrungszeiträumen verbunden.

Zur Aufbewahrungsfrist wird auf die jeweils aktuelle Fassung der „Empfehlungen zur ärztlichen Schweigepflicht, Datenschutz und Datenverarbeitung in der Arztpraxis“ der BÄK und KBV, siehe [BÄK_KBV], und auf die einschlägigen gesetzlichen Normen verwiesen.

Folgende Tabelle listet alle in den Anwendungsfällen aufgeführten Archivierungsvorgänge auf.

Tabelle 29: Tab_ILF_NFDM_029 – Übersicht Archivierungsvorgänge

6.2 Drucken

Ein informatives Beispiel für die Gestaltung eines NFD-Ausdrucks findet sich auf der Webseite des NFDM-Sprint-Projektes.^{(https://nfdm.gematik.de/sites/nfdm_gematik/content/e15/e159/e489/NFD-Musterausdruck.pdf)}

7 Nichtfunktionale Aspekte

7.1 Fehlerbehandlung

Bei erwarteten oder unbeabsichtigten Abweichungen antwortet das Fachmodul NFDM oder eine andere Konnektor-Komponente dem Primärsystem mit einer Warnung oder einer Fehlermeldung. Fehlermeldungen werden mittels eines gematik-eigenen SOAP-Faults^{(Struktur der Fehlermeldung: [gemILF_PS#6.3])} an das Primärsystem gemeldet.

Bei der Nutzung der Operationen des Fachmoduls NFDM oder einer anderen Konnektor-Komponente über Webservices sind die Vorgaben für die Struktur und Inhalte von Fehlermeldungen identisch. Empfehlungen zur Fehlerverarbeitung und die Struktur der SOAP-Fault-Nachricht, die das Primärsystem verarbeiten muss, sind in [gemILF_PS#6.2] und [gemILF_PS #6.3] beschrieben.

Das Primärsystem soll eine fehlertolerante Verarbeitung aufweisen. Dazu gehört:

• Eine planmäßige Verarbeitung von Fehlern und Warnungen der Konnektorschnittstellen, ohne abzubrechen oder die Arbeit des Akteurs zu blockieren.
• Verständliche Anzeige von Fehlerzuständen.

Idealerweise lässt sich das Verhalten bei Fehlern oder Warnungen über Konfigurationsparameter einstellen (Timeout für SOAP-Requests, Responses etc.).

Im Folgenden werden allgemeine Vorgaben zur Fehlerbehandlung innerhalb der Fachanwendung NFDM im Primärsystem definiert.

Tabelle 30: Tab_ILF_NFDM_033 – Generische und spezifische Fehlermeldungen

7.2 Verlagerung von Schreibvorgängen in den Hintergrund

7.3 Visuelle Darstellung von Daten im PS

Für die visuelle Darstellung von NFD/DPE ist eine grafische Benutzeroberfläche im Primärsystem erforderlich, auf der die NFD/DPE fachlich, strukturiert und übersichtlich dem Akteur dargestellt werden.

Um die Qualität der Darstellung von Daten im Primärsystem sicherzustellen, wird auf die Verwendung der Norm EN ISO 9241^{(Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten – [DIN EN ISO 9241])} hingewiesen.

7.4 Umgang mit NFD-/DPE-Schemata

Die gematik wird dem Primärsystemhersteller das aktuelle NFD-/DPE-Schema zusammen mit der Information zur Integration und Umsetzung zur Verfügung stellen. Der Primärsystemhersteller wird das aktuelle XML-Schema in bevorstehende Primärsystem-Aktualisierungen integrieren.

Bei künftigen Änderungen am NFD-/DPE-Schema werden neben dem Schema auch die Überleitungshinweise veröffentlicht. Die Überleitungshinweise sollen entstandene Änderungen an dem aktuellen XML-Schema beschreiben, so dass sie für den Primärsystemhersteller nachvollziehbar sind. Ferner wird mitgeteilt, ab wann das veröffentlichte XML-Schema gültig ist.

8 Anhang A – Verzeichnisse

8.1 Abkürzungen

8.2 Glossar

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

8.3 Abbildungsverzeichnis

8.4 Tabellenverzeichnis

8.5 Referenzierte Dokumente

8.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.

8.5.2 Weitere Dokumente

9 Anhang B – Beispiele

Um einen besseren Überblick über die Nachrichten, die zwischen Primärsystem und Fachmodul NFDM ausgetauscht werden, zu geben, wird im Folgenden die Struktur dieser Nachrichten (Request und Response) mit Beispieldaten vorgestellt. Diese haben einen informativen Charakter.

Die folgenden Beispieldaten bieten eine Implementierungshilfe zu den in diesem Dokument vorgestellten Anwendungsfälle an. Die Beispieldaten der Anwendungsfälle aus dem Kapitel 5.2 „Die Verwaltung des DPE im Primärsystem“ sind identisch mit den Folgenden und werden nicht explizit beschrieben. Die Namen der aufgerufenen Operationen sind unterschiedlich, z.B. ReadNFD und ReadDPE.

Der Austausch dieser Nachrichten erfolgt dabei mittels des SOAP-Protokolls. Das in der NFDService.wsdl angegebene SOAP-Encoding document/literal sorgt für die Prüfung des Inhalts des Elementes SOAP-ENV:Body auf die Gültigkeit gegenüber dem Schema NFDService.xsd.

9.1 B1 – ReadNFD

Beispiel #: Beispiel für den SOAP-Aufruf der Operation ReadNFD

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:m1="http://ws.gematik.de/conn/ConnectorCommon/v5.0">

    <SOAP-ENV:Body>

        <m:ReadNFD xmlns:m="http://ws.gematik.de/conn/NFDService/v1.0">

            <m0:Context>

                <m1:MandantId>m0001</m1:MandantId>

                <m1:ClientSystemId>cs0001</m1:ClientSystemId>

                <m1:WorkplaceId>wp007</m1:WorkplaceId>

                <m1:UserId>ui123</m1:UserId>

            </m0:Context>

            <m1:EhcHandle>ehc0123456789</m1:EhcHandle>

            <m1:HpcHandle>hpc112233</m1:HpcHandle>

            <m:EmergencyIndicator>true</m:EmergencyIndicator>

            <m:UpdateIndicator>false</m:UpdateIndicator>

        </m:ReadNFD>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

In obigem SOAP-Aufruf wird die Operation ReadNFD mit folgenden Parametern aufgerufen:

Context^{(Aufrufkontext ist ausführlicher in [gemILF_PS#3.3.1] beschrieben.)}:

• MandantId ist eine alphanumerische ID des Mandanten und ist sowohl im Primärsystem als auch im Konnektor hinterlegt.
• ClientSystemId ist eine alphanumerische ID des Primärsystems. Sie ist sowohl im Primärsystem als auch im Konnektor konfiguriert und dem Mandanten mit der MandantId zugeordnet.
• WorkplaceId ist eine alphanumerische ID und ist sowohl im Primärsystem als auch im Konnektor konfiguriert. Sie ist im Konnektor dem Mandanten mit der MandantId als auch dem Primärsystem mit der ClientSystemId zugeordnet.
• Die Angabe eines Benutzers UserID ist notwendig, wenn HpcHandle zu einem HBA gehört.

Karten-Handle:

• EhcHandle adressiert die eGK des Versicherten, von der der NFD ausgelesen werden soll. Die Adressierung wurde zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCards() ermittelt.
• HpcHandle adressiert den HBA oder die SMC-B, die zur Authentisierung verwendet werden soll.

Zweck des Aufrufes:

• EmergencyIndicator enthält den Wert „true“. Der NFD soll in einer Notfallsituation von der eGK des Versicherten ausgelesen werden.
• UpdateIndicator enthält den Wert „false“. Das Auslesen des NFD von der eGK des Versicherten soll nicht zum Zwecke der Aktualisierung erfolgen.

Auf die obige Anfrage zum Fachmodul NFDM sind verschiedene Antworten möglich. Dabei sind drei Fälle zu unterscheiden:

• OK: Rückgabe des NFD inklusive einer gültigen QES und des Prüfprotokolls.
• WARNING: Rückgabe des NFD mit einer nicht erfolgreichen QES-Prüfung, unabhängig davon, ob der Akteur das Sicherheitsniveau der QES im xTV angenommen oder abgelehnt hat.
• ERROR: Das Fachmodul NFDM meldet einen Fehler. Der NFD wird nicht an das Primärsystem zurückgeliefert. Die Struktur der SOAP-Fault-Nachricht ist in [gemILF_PS#6.3] beschrieben.

Beispiel #: ReadNFDResponse bei Erfolg

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://ws.gematik.de/conn/NFDService/v1.0"

xmlns:urn="urn:oasis:names:tc:dss-x:1.0:profiles:verificationreport:schema#" xmlns:urn1="urn:oasis:names:tc:dss:1.0:core:schema"

   <soapenv:Header/>

   <soapenv:Body>

     <v1:ReadNFDResponse>

       <v1:Status>

            <v1:Result>OK</v1:Result>

      </v1:Status>

      <v1:NFDDocument>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi </v1:NFDDocument>

      <urn:VerificationReport>...</urn:VerificationReport>

     </v1:ReadNFDResponse>

   </soapenv:Body>

</soapenv:Envelope>

Ergebnis:

Im Element Status/Result hat das Fachmodul NFDM die Antwort der aufgerufenen Operation ReadNFD hinterlegt. Die Durchführung war erfolgreich und der NFD konnte von der in der Anfrage adressierten eGK ausgelesen werden.

NFD:

Der von der eGK des Versicherten ausgelesene NFD ist im Element NFDDocument hinterlegt und ist inklusive der QES base64-kodiert.

Prüfbericht

Das ausführliche Ergebnis der QES-Prüfung ist im Element VerificationReport enthalten. Die Struktur entspricht [OASIS-VR]. Details zur Ausgestaltung des Prüfberichts werden in einer zukünftigen Version der Konnektor-Spezifikation ergänzt.

9.2 B2 – WriteNFD

Beispiel #: Beispiel für den SOAP-Aufruf der Operation WriteNFD

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:m1="http://ws.gematik.de/conn/ConnectorCommon/v5.0">

    <SOAP-ENV:Body>

        <m:WriteNFD xmlns:m="http://ws.gematik.de/conn/NFDService/v1.0">

            <m0:Context>

                <m1:MandantId>m0001</m1:MandantId>

                <m1:ClientSystemId>cs0001</m1:ClientSystemId>

                <m1:WorkplaceId>wp007 </m1:WorkplaceId>

                <m1:UserId>ui123</m1:UserId>

            </m0:Context>

            <m1:EhcHandle>ehc0123456789</m1:EhcHandle>

            <m1:HpcHandle>hpc112233</m1:HpcHandle>

    <m:NFDDocument>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</m:NFDDocument>

        </m:WriteNFD>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

In obigem SOAP-Aufruf wird die Operation WriteNFD mit folgenden Parametern aufgerufen:

Context:

• MandantId ist eine alphanumerische ID des Mandanten und ist sowohl im Primärsystem als auch im Konnektor hinterlegt.
• ClientSystemId ist eine alphanumerische ID des Primärsystems. Sie ist sowohl im Primärsystem als auch im Konnektor konfiguriert und dem Mandanten mit der MandantId zugeordnet.
• WorkplaceId ist eine alphanumerische ID und ist sowohl im Primärsystem als auch im Konnektor konfiguriert. Sie ist im Konnektor dem Mandanten mit der MandantId als auch dem Primärsystem mit der ClientSystemId zugeordnet.
• Die Angabe eines Benutzers „UserID“ ist notwendig, wenn HpcHandle zu einem HBA gehört.

Karten-Handle:

• EhcHandle adressiert die eGK des Versicherten, auf die der NFD geschrieben werden soll. Die Adressierung wurde zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCards() ermittelt.
• HpcHandle adressiert den HBA oder die SMC-B, die zur Authentisierung verwendet werden soll.

NFD:

• NFDDocument enthält einen base64-kodierten NFD. Der NFD ist gültig gemäß dem XML-Schema [NFD_Document.xsd] und verfügt über eine gültige QES.

Auf diese Anfrage zum Fachmodul NFDM sind verschiedene Antworten möglich. Dabei sind zwei Fälle zu unterscheiden:

• OK: Bestätigung über die erfolgreiche Durchführung der Operation.
• ERROR: Das Fachmodul NFDM meldet einen Fehler. Der NFD ist nicht auf die eGK des Versicherten geschrieben. Die Struktur der SOAP-Fault-Nachricht ist in [gemILF_PS#6.3] beschrieben.

Beispiel #: WriteNFDResponse bei Erfolg

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://ws.gematik.de/conn/NFDService/v1.0" xmlns:v2="http://ws.gematik.de/tel/error/v2.0">

   <soapenv:Header/>

   <soapenv:Body>

      <v1:WriteNFDResponse>

         <v1:Status>

            <v1:Result>OK</v1:Result>

         </v1:Status>

      </v1:WriteNFDResponse>

   </soapenv:Body>

</soapenv:Envelope>

Ergebnis:

• Im Element Status/Result hat das Fachmodul NFDM die Antwort der aufgerufenen Operation WriteNFD hinterlegt. Die Speicherung war erfolgreich, der an das Fachmodul NFDM übergebene NFD ist auf die eGK des Versicherten geschrieben worden.

9.3 B3 – EraseNFD

Beispiel #: Beispiel für den SOAP-Aufruf der Operation EraseNFD

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:m1="http://ws.gematik.de/conn/ConnectorCommon/v5.0">

    <SOAP-ENV:Body>

        <m:EraseNFD xmlns:m="http://ws.gematik.de/conn/NFDService/v1.0">

            <m0:Context>

                <m1:MandantId>m0001</m1:MandantId>

                <m1:ClientSystemId>cs0001</m1:ClientSystemId>

                <m1:WorkplaceId>wp007</m1:WorkplaceId>

                <m1:UserId>ui123</m1:UserId>

            </m0:Context>

            <m1:EhcHandle>ehc0123456789</m1:EhcHandle>

            <m1:HpcHandle>hpc112233</m1:HpcHandle>

        </m:EraseNFD>

    </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

In obigem SOAP-Aufruf wird die Operation EraseNFD mit folgenden Parametern aufgerufen:

Context:

• MandantId ist eine alphanumerische ID des Mandanten und ist sowohl im Primärsystem als auch im Konnektor hinterlegt.
• ClientSystemId ist eine alphanumerische ID des Primärsystems. Sie ist sowohl im Primärsystem als auch im Konnektor konfiguriert und dem Mandanten mit der MandantId zugeordnet.
• WorkplaceId ist eine alphanumerische ID und ist sowohl im Primärsystem als auch im Konnektor konfiguriert. Sie ist im Konnektor dem Mandanten mit der MandantId als auch dem Primärsystem mit der ClientSystemId zugeordnet.
• Die Angabe eines Benutzers „UserID“ ist notwendig, wenn „HpcHandle“ zu einem HBA gehört.

Karten-Handle:

• EhcHandle adressiert die eGK des Versicherten, von der der NFD gelöscht werden soll. Die Adressierung wurde zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCards() ermittelt.
• HpcHandle adressiert den HBA oder die SMC-B, die zur Authentisierung verwendet werden soll. Die Adressierung wurde zuvor über eine Meldung des Ereignisdienstes des Konnektors oder über EventService.getCards() ermittelt.

Auf diese Anfrage zum Fachmodul NFDM sind verschiedene Antworten möglich. Dabei sind zwei Fälle zu unterscheiden:

• OK: Bestätigung über die erfolgreiche Durchführung der Operation.
• ERROR: Das Fachmodul NFDM meldet einen Fehler. Der NFD ist nicht von der eGK des Versicherten gelöscht. Die Struktur der SOAP-Fault-Nachricht ist in [gemILF_PS#6.3] beschrieben.

Beispiel #: EraseNFDResponse bei Erfolg

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://ws.gematik.de/conn/NFDService/v1.0" xmlns:v2="http://ws.gematik.de/tel/error/v2.0">

   <soapenv:Header/>

   <soapenv:Body>

      <v1:EraseNFDResponse>

         <v1:Status>

            <v1:Result>OK</v1:Result>

         </v1:Status>

      </v1:EraseNFDResponse>

   </soapenv:Body>

</soapenv:Envelope>

Ergebnis:

• Im Element Status/Result hat das Fachmodul NFDM die Antwort der aufgerufenen Operation EraseNFD hinterlegt. Die Löschung war erfolgreich, von der angegebenen eGK des Versicherten ist der dort befindliche NFD gelöscht worden.