Datenschutzerklärung

Letzte Anpassung am 17.01.2024

Der Datenschutz spielt beim Einsatz von NIDA eine besondere Rolle, da Daten des Rettungsdienstes an unterschiedliche Empfänger, beispielsweise Kliniken und Abrechnungsstellen,  versendet werden, welche bislang nur telefonisch oder überhaupt nicht kommuniziert wurden. Daher ist sicherzustellen, dass die Daten korrekt und vollständig übermittelt (Datensicherheit) und die Daten nur von autorisierten Personen eingesehen und nur für den angedachten Bestimmungszweck (Datenschutz) eingesetzt werden. Es wird empfohlen mit jedem Datenempfänger einen Vertrag über die Nutzung der Daten abzuschließen.

Um ein einheitliches Verständnis zu den Begrifflichkeiten zu NIDAklinik aufzubauen, werden diese im Folgenden erläutert.

Gesundheitseinrichtung: Versorgungseinrichtung, welche das NIDAklinik-System für die Betreuung ihrer Patienten einsetzt. In der Regel sind dies Krankenhäuser mit einer Zentralen Notaufnahme und allen peripheren Akutstationen wie eine Stroke Unit, Chest Pain Unit, eine Intensivstation oder eine Kinderklinik.

Benutzer: Ein Benutzer ist eine Person, die das NIDAklinik-System als Hilfs- oder Arbeitsmittel für seine Arbeit in der Gesundheitseinrichtung verwendet. Den Benutzern können verschiedene Rollen zugewiesen werden. Die Zuordnung der Rollen entscheidet darüber, welche Rechte und Ansichten der jeweilige Benutzer in NIDAklinik besitzt. Im NIDAklinik-System werden folgende Rollen unterschieden:

• Admin: Natürliche Person, der mit Administratoren-Rechten ausgestattet ist. Darunter fällt die Benutzerverwaltung. Im NIDAtracker steht die Benutzerverwaltung zur Verfügung. Über die Benutzerverwaltung können Benutzer verschiedenen Gruppen zugeordnet werden (Admin, Archiv, KIS, Statistik). Der Admin kann, die beim Einrichten eines neuen Systems bzw. Mandanten die initialen Benutzerkonten anlegen, verwalten und diese auch wieder löschen.
• Archiv: Natürliche Person, die Zugriff auf die Archivfunktion hat und alle archivierten Patientendaten einsehen kann. In dem Archiv können archivierte Voranmeldungen und Protokollübergaben in die aktuelle Patientenliste verschoben werden.
• KIS: Natürliche Person, die in der aktuellen Patientenliste die Möglichkeit zum Matching und zur Übertragung der Voranmeldungen und Protokolle an das Krankenhausinformationssystem (KIS) hat.
• Standard: Natürliche Person, die Zugriff auf das NIDAklinik-System über den NIDAtracker hat und/oder Voranmeldungen über das NIDAarrivalboard einsehen kann. Die natürliche Person hat Zugriff eine definierte Teilmenge der Daten des NIDAklinik-Systems. Die natürliche Person hat Zugriff auf die noch nicht archivierten Voranmeldungen und Protokolle im NIDAtracker.
• Statistik: Natürliche Person, die Zugriff auf das NIDAklinik-System hat und aggregierte bzw. statistische Kennzahlen im NIDAtracker angezeigt bekommt. Diese Rolle ist im NIDAklinik-System in der Client-Variante verfügbar.

NIDAklinik-System: Oberbegriff für alle technischen Komponenten von NIDAklinik als Gesamteinheit. Das NIDAklinik-System besteht aus den folgenden technischen Komponenten:

• NIDAtracker: Webanwendung zur Dateneinsicht und -übermittlung an Drittsysteme. Der NIDAtracker visualisiert die relevanten Daten (Voranmeldung und Protokolle), die auf dem NIDAserver in der Klinik gespeichert werden.
• NIDAarrivalboard: Webanwendung zur Dateneinsicht für die Benutzung durch den Benutzer mithilfe eines Internetbrowsers. Das NIDAarrivalboard visualisiert die relevanten Daten, die auf dem NIDAgateway gespeichert werden.
• NIDAserver: Serveranwendung für den sicheren Datenempfang, -speicherung, -archivierung und -verarbeitung. Auf dem NIDAklinik-Server sind NIDAklinik-Module für die zentrale Speicherung, Verwaltung und Weiterverarbeitung der Daten installiert. Der Zugriff auf externe Systeme (z.B. KIS oder DAKS) erfolgt ausschließlich über vorab definierte Protokolle und Schnittstellen (u.a. webrequest, HL7 V2, ESPA-X). Ein direkter Zugriff auf die Datenbank durch eine Notaufnahmesoftware auf den NIDAserver ist nur über vorab definierte Views mit entsprechender Zugriffsbeschränkung und Authentifizierung möglich. Der NIDAserver wird in der Klinik-IT-Struktur gehostet und durch die Gesundheitseinrichtung betrieben.
• NIDAgateway: Serveranwendung für den sicheren Datenempfang, -speicherung, -archivierung, -verarbeitung zwischen Rettungsdienstdokumentationssystemen, Versorgungsnachweissystemen und dem NIDAserver in der Gesundheitseinrichtung. Das NIDAgateway ist bundeslandspezifisch oder deutschlandweit gehostet. Der deutschlandweit erreichbare NIDAklinikgateway übernimmt die Weiterleitung an die entsprechende Klinik. Weiter stellt er den Verbindungsendpunkt für das NIDAarrivalboard dar, welches in der Klinik aufgerufen wird.
• NIDAklinik Postfach: Organisationseinheit für die kleinste abbildbare Untermenge für Voranmeldungen und Protokollen auf dem NIDAserver. Ein Postfach steuert somit gezielt Stationen oder Zufahrtswege für den Rettungsdienst an (z.B. Kreißsaal, Intensivstation und Kinderaufnahme). Der NIDAserver ist über ein Benutzer-/ Rollenkonzept in der Lage weitere Postfächer anzusteuern.

Externe Systeme: Anwendungen von Fremdherstellern, die in das NIDAklinik-System per Fremdaufruf und Nachrichten (z. B. APIs für Integration von Softwareanbietern von Rettungsdienstdokumentationssystemen, ESPA-X für Digitale Alarm- und Kommunikationsserver (DAKS), HL7 zu Krankenhausinformationssystemen und Webrequest für Notaufnahmesoftware,) eingebunden sind.

• KIS: Krankenhausinformationssysteme sind externe Systeme, an denen sich NIDAklinik anbinden lässt. NIDAklinik überträgt die Daten über eine standardisierte HL7 Nachricht zur medienbruchfreien Informationsverarbeitung und Archivierung. Diese werden von einer Gesundheitseinrichtung selbstständig verantwortet.
• DAKS: Digitale Alarm- und Kommunikationsserver sind externe Systeme, an denen sich NIDAklinik anbinden lässt. Über ein ESPA-X Protokoll können Voranmeldungen über den NIDAserver direkt an das DAKS weitergeleitet werden, um das klinische Personal zu alarmieren. Diese werden von einer Gesundheitseinrichtung selbstständig verantwortet.
• Notaufnahmesoftware: Notaufnahmesoftware sind externe Systeme, an denen sich NIDAklinik anbinden lässt. NIDAklinik erlaubt einen beschränkten Datenbankzugriff, um die Daten zur medienbruchfreien Informationsverarbeitung und Archivierung in der Notaufnahmesoftware anzuzeigen. Diese werden von einer Gesundheitseinrichtung selbstständig verantwortet.
• Rettungsdienstdokumentationssysteme: sind externe Systeme, an denen sich NIDAklinik anbinden lässt. NIDAklinik bietet über das NIDAgateway eine REST-API zum Datenempfang aller Rettungsdienstdokumentationssysteme im Einzugsgebiet der Gesundheitseinrichtung an. Es werden Daten von Notarzt- und Rettungsdiensten empfangen, die sich auch gegenüber dem NIDAgateway authentifizieren.
• Rettungsdienstkommunikationssyteme: sind externe Systeme an denen sich NIDAklinik anbinden lässt. NIDAklinik bietet z.B. über das NIDAgateway eine Schnittstelle zum rescuetrack-System der Fa. rescuetrack GmbH.
• Versorgungsnachweissysteme: sind externe Systeme an denen sich NIDAklinik anbinden lässt. NIDAklinik bietet z.B. über das NIDAgateway eine Schnittstelle zu einem Versorgungsnachweissystem, um digitale Zuweisungen zu empfangen.

Feedbacksysteme: sind externe Systeme an denen sich NIDAklinik anbinden lässt. NIDAklinik bietet eine Schnittstelle vom NIDAserver an Curafida (ZTM), um aus der telemedizinischen Voranmeldung und digitale Protokollübergabe eine elektronische Patientenakte anlegt, um dem Notarzt- und Rettungsdienst eine Rückmeldung zum unmittelbaren Behandlungsverlauf zum Patienten ermöglicht. Eine Zuordnung zum Patienten ist durch Übermittlung der Besatzung auf dem Rettungsdienstprotokoll gewährleistet.

Das Unternehmen ZTM Bad Kissingen GmbH (ZTM) mit Sitz in Bad Kissingen (Deutschland) bietet Lösungen im Bereich der Telemedizin an. Unter anderem bietet das ZTM das Produkt NIDAklinik an.

NIDAklinik ist eine telemedizinische Plattform zur Vernetzung zwischen dem Notarzt- und Rettungsdienst (insb. deren Rettungsdienstdokumentationssysteme) und dem Krankenhaus (insb. der Notaufnahme).

Mit NIDAklinik werden die Persönlichkeitsrechte aller Patienten, deren Daten erfasst oder verarbeitet werden, gemäß der Datenschutzgrundverordnung (DS-GVO), dem Bundesdatenschutzgesetz (BDSG) und weiteren geltenden Bestimmungen geschützt.

Es werden die Persönlichkeitsrechte aller Benutzer, deren Daten erfasst oder verarbeitet werden, gemäß der DS-GVO, dem BDSG und weiteren geltenden Bestimmungen geschützt.

ZTM stellt mit NIDAklinik eine sogenannte „eHealth-Plattform“ bereit, die von einer Gesundheitseinrichtung für definierte Anwendungsfälle zur telemedizinischen Versorgung ihrer Patienten konfiguriert werden kann. Mit NIDAklinik als Dokumentations- und Kommunikationsplattform möchte das ZTM somit die Patientenversorgung unterstützen und die Qualität der Versorgung steigern.

Die Plattform lässt sich mit einer Vielfalt an Funktionen für die Notfallversorgung konfigurieren. Eine Gesundheitseinrichtung kann folgende Anwendungen mit NIDAklinik umsetzen:

• Telemedizinische Voranmeldung: NIDAklinik kann bei Patienten mit akut lebensbedrohlichen Krankheitsbildern bzw. Patienten mit Transportentscheidung des Notarzt- und Rettungsdienstes in das Krankenhaus (insb. Notaufnahme) eingesetzt werden. Dadurch kann der Austausch zwischen Notarzt- und Rettungsdienst und dem Personal in der Notaufnahme und weiteren peripheren Stationen (Stroke Unit, Chest Pain Unit, Kinderklinik, etc.) verbessert werden. Der Notarzt- und Rettungsdienst kann mithilfe einer integrierten Applikation im Rettungsdienstdokumentationssystem eine telemedizinische Voranmeldung durchführen. Sofern im Einsatz Indikationen zur Übertragung von EKG, Fotodokumentationen der Einsatzstelle, medizinische Indizes oder Checklisten sowie der Stammdaten der elektronischen Gesundheitskarte (eGK) zum Einsatz kommen, kann eine telemedizinische Voranmeldung durchgeführt werden. Die Nutzung der telemedizinischen Voranmeldung orientiert sich an den lokalen Vorgaben der Behörden oder der Leitlinienempfehlung der medizinischen Fachgesellschaften. Ziele einer telemedizinischen Voranmeldung sind die zeitlichen sowie organisatorischen Abläufe der Notfallbehandlung in einer Klinik so früh wie möglich zu beeinflussen und damit patientenrelevante Endpunkte (z.B. Door-to-Needle beim akuten Schlaganfall oder Door-to-Balloon beim ST-Hebungsinfarkt) zu verbessern. Durch die telemedizinische Voranmeldung wird am Transportziel wichtige Vorlaufzeit gewonnen, um einen optimalen Behandlungsablauf gewährleisten zu können.
• Digitale Protokollübergabe: Mit NIDAklinik kann eine Gesundheitseinrichtung über das NIDAgateway das digitale Notarzt- und Rettungsdienstprotokoll in Form einer PDF empfangen. So kann ein Arzt oder Pflegefachkraft in der Gesundheitseinrichtung alle Versionen der übermittelten Protokolle des Notarzt- und Rettungsdienstes einsehen und in Notaufnahmesoftware und KIS integrieren.
• Anbindung an das Krankenhausinformationssystem/ Notaufnahme: Mit NIDAklinik kann die Gesundheitseinrichtung über den NIDAserver die telemedizinische Voranmeldung und das digitale Einsatzprotokoll über standardisierte HL7 Schnittstellen oder Direktdatenbankzugriffen in das KIS/ Notaufnahmesoftware integrieren. Das Ziel der Integration ist die Vermeidung von Medienbrüchen sowie die Vermeidung von Kommunikationsfehlern und Informationsverlusten.
• Anbindung an Telefonalarmierungssysteme: Mit NIDAklinik können über eine ESPA-X Schnittstelle Personenrufanlagen sog. Digitale Alarm- und Kommunikationsserver angesteuert werden. Dieses Zusatzmodul beinhaltet Lizenzkosten inkl. Installation und Konfiguration einer ESPA-X Schnittstelle zur automatischen telefonischen Alarmierung vordefinierter Empfänger in der Klinik. Die Alarmierungskette kann vorab eingestellt werden, um bei Empfang der telemedizinischen Voranmeldung direkt auf dem klinikeigenen Telefon oder Piepser alarmiert zu werden, in Abhängigkeit des Inhaltes der Voranmeldung (z.B. Diagnose, Priorität).
• Anbindung an CORPULS Vitaldatentelemetrie: In NIDAklinik kann mithilfe dieser Erweiterung die Vitalzeichen von CORPULS-Defibrillatoren über die Software "corpuls.mission LIVE" in Echtzeit abrufen. Es handelt sich um eine telemedizinische Softwarekomponente, die Vitalparametern und Kurvengrafiken aus Ruhe-EKGs extrahiert und in Echtzeit von jedem ertüchtigten CORPULS-Defibrillator nach NIDAklinik überträgt. NIDAklinik zeigt corpuls.mission LIVE in Form eines Widgets an. Die Integration über das Widget ist ein eigenständiges Medizinprodukt im Sinne der Medizinprodukteverordnung (EU) 2017/745) der Marke CORPULS als eine eingetragene Marke der GS Elektromedizinische Geräte G. Stemple GmbH. Voraussetzung für die Anbindung an die Vitaldatentelemetrie über corpuls.mission LIVE ist ein Mission Matching über die mobilen Einsatzdokumentationssysteme im Rettungsdienst, eine Ausstattung des corpuls3 mit einem Telemetriemodul (z.B. WLAN und/oder 4F), einer corpuls.mission LIVE Lizenz für alle Geräte (Art. Nrn. 97050 + 97050.1), der Option „Widgets Drittsysteme“ lizensiert für alle Geräte (Art. Nr. 97050.14) und der Option „HL7 FHIR“ lizensiert für alle Geräte (Art. Nr. 97050.15).
• Anbindung an das Feedbacksystem: Mit NIDAklinik können Daten der Voranmeldung und der Protokollübergabe an das Medizinprodukt „Curafida“ über eine Schnittstelle übertragen werden. Curafida ist ein zertifiziertes Medizinprodukt der Klasse I nach dem Medizinprodukterecht-Durchführungsgesetz (MPDG) und ermöglicht über Formulare und Notizen, sowie eine Schnittstelle zu den Notaufnahmesoftware oder Krankenhausinformationssystemen eine Feedbackakte zu führen, die dem Rettungsdienst unter zugänglich gemacht werden kann (siehe Datenschutzkonzept und Datenschutzfolgeabschätzung von Curafida).

Die Durchführung des Rettungsdienstes ist eine öffentliche Aufgabe der Gefahrenabwehr und der Gesundheitsvorsorge, welche in den meisten Fällen von den Trägern (Landkreise, kreisfreie Städte) an Leistungserbringer delegiert wird. Die Leistungserbringer sind Hilfsorganisationen, Feuerwehren als auch private Rettungsdienste. Die Durchführung der Notfallversorgung durch Zentrale Notaufnahmen ist eine öffentliche Aufgabe der Gesundheitsvorsorge, welche in den meisten Fällen von den Trägern (Krankenhauseinrichtungen, Landkreise, etc.) durchgeführt wird.

Das Rettungsdienstpersonal und das Notaufnahmepersonal ist zur Dokumentation im Rahmen des jeweiligen Rettungsdienstgesetzes und SGB V verpflichtet. Eine lückenlose Dokumentation, zur weiteren medizinischen Versorgung der Patienten zwischen diesen Leistungserbringern ist in einigen Bundesländern im jeweiligen Rettungsdienstgesetz geregelt: (beispielhafter Auszug)

• Rettungsdienstgesetz NRW -RettG NRW § 7a
• Rettungsdienstgesetz Bayern – BayRDG Fünfter Teil. Art. 46 (1) und Art 47 (19 Abs. 1
• Rettungsdienstgesetz Hamburg – HmbRDG §7 Abs. 4.
• Rettungsdienstgesetz Schleswig-Holstein - §9 Abs. 2
• Rettungsdienstgesetz Mecklenburg-Vorpommern – RDG M-V § 15 Abs. 3

Die Voranmeldung und Protokollübergabe soll Ärzte und Pflegepersonal über den Verlauf einer Krankheit und die bisherige prähospitale Behandlung informieren (BGH NJW-RR 1993, 2375; OLG Jena GesR2005, 556; OLG Oldenburg NJW-RR 2000, 240; OLG Zweibrücken NJW-RR 2000, 62) mit der Pflicht zur organisatorischen Vorbereitung (OLG Braunschweig, Urt. v. 18.12.1997 –1 U 30/97). Der Zweck der Datenübertragung ist neben den medizinischen Vorteilen eine unterlassene Befunderhebung mit entsprechender beweisrechtlicher Konsequenz bei der Übergabe des Patienten in der Gesundheitseinrichtung zu vermeiden.

Im Netzwerk des digitalen Notfallmanagements werden sensible Patientendaten (u.a. Biosignale wie EKG) oder besonders schützenswerte Daten (wie Krankenkassendaten, Wohnadresse) ausgetauscht und verarbeitet. Damit stellt sich die Frage nach der daten-schutzrechtlichen Zulässigkeit der einzelnen digitalen Verfahren im digitalen Notfallmanagement selbst, bzw. auch in ihrem Zusammenwirken. Grundlegend bedarf die Datenverarbeitung das Einverständnis des Patienten. Datenschutzrechtliche Aspekte sind in der Datenschutz-Grundverordnung (DSGVO) geregelt. Der Zweck der Datenübertragung muss begründbar sein und den Grundsätzen zum Datenschutz gemäß Art. 5 Abs.1 DSGVO entsprechen (Rechtmäßigkeit der Verarbeitung, Verarbeitung nach Treu und Glauben, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit der Datenverarbeitung, Speicherbegrenzung, Integrität und Vertraulichkeit).

Gerade in der Akut- und Notfallmedizin ist ein Einholen des schriftlichen Einverständnisses in der Notfallsituation kaum möglich und praktikabel. Daher wird im Notfalleinsatz davon ausgegangen, dass der Patient die bestmögliche Versorgung erhalten möchte und ein Datenaustausch zwischen den Leistungserbringern dieses Ziel im Sinne des Patienten verfolgt. In bestimmten Fällen ist der Patient nicht mehr in der Lage einzuwilligen. Alternativen wie das Verständigen eines Betreuers oder Angehörigen würde zu einer erheblichen Zeitverzögerung führen. Daher regelt die DSGVO Datenverarbeitungen auch ohne Einwilligung, soweit diese dem Schutz lebenswichtiger Interessen dienen (vgl. Art. 6 Abs. 1 UAbs. 1 Buchst. d, Art. 9 Abs. 2 Buchst. c, DSGVO). Das Interesse an der Übermittlung der Daten überwiegt somit das Interesse des Betroffenen an dem Ausschluss der Übermittlung erheblich. Eine explizite Einwilligung am Notfallort zur Befundübermittlung ist aufgrund des überwiegenden Interessens nicht erforderlich.

Das ZTM stellt das NIDAklinik-System mit allen Modulen der Gesundheitseinrichtung für die Installation und den Betrieb zur Verfügung.

Jede Gesundheitseinrichtung erhält ein eigenes NIDAklinik-System und hat ausschließlich Zugriff auf ihre eigenen Patientendaten. Je nach Klinikinfrastruktur können NIDAklinik Postfächer weitere Anfahrtswege sein, oder weitere Kliniken.

NIDAklinik stellt sicher, dass nur die Personen Zugriff erhalten können, die dafür autorisiert sind. Die Autorisierung kann über die eigene Benutzerverwaltung in NIDAklinik realisiert werden. Alternativ kann die klinikinterne Benutzerverwaltung über eine LDAP-Anbindung realisiert werden. LPAD ist ein produktagnostisches Protokoll. In LDAP wird eine „Bindung“ zum Klinikdienst hergestellt. Die Authentifizierung erfolgt dann über den Benutzer bekannten Benutzername und Passwort. Allerdings kann NIDAklinik selbst nicht überprüfen, ob der Zugriff berechtigt ist. Hierfür ist jede Gesundheitseinrichtung selbst verantwortlich.

NIDAklinik wird in der IT-Infrastruktur der jeweiligen Klinik gehostet und betrieben. Über das Postfachsystem können Kliniken, die innerhalb der gleichen IT-Infrastruktur liegen, Daten vom Rettungsdienst von unterschiedlichen Zielkliniken (Postfächer) empfangen. Externe Einrichtungen, z.B. eine Klinik außerhalb der IT-Infrastruktur kann nicht über das gleiche NIDAklinik-System eingebunden werden.

Nachfolgend werden die Verpflichtungen der einzelnen Verantwortlichen bei der Verarbeitung personenbezogener Daten transparent beschrieben, welche im Kontext mit den NIDAklinik-Modulen bestehen.

Gemäß Artikel 28 DS-GVO liegt eine Auftragsverarbeitung zwischen dem ZTM (Auftragsverarbeiter) und der Gesundheitseinrichtung vor. Zwischen ZTM und der Gesundheitseinrichtung wird eine Vereinbarung zur Auftragsverarbeitung (AVV) geschlossen. Gegenstand dieser Vereinbarung ist die Verarbeitung personenbezogener Daten durch das ZTM für die Gesundheitseinrichtung in deren Auftrag und nach deren Weisung. Die Vereinbarung gilt entsprechend für die (Fern-)Prüfung und Wartung automatisierter Verfahren oder von Datenverarbeitungsanlagen, wenn dabei ein Zugriff auf personenbezogenen Daten nicht ausgeschlossen werden kann. Gemäß Artikel 32 DS-GVO treffen das ZTM und die Gesundheitseinrichtung geeignete technische und organisatorische Maßnahmen (TOMs), um die Datensicherheit zu gewährleisten.

Die Ärzte, Pflegefachkräfte und Admins der Gesundheitseinrichtung stellen dem Patienten die erforderlichen Informationen über die Erhebung personenbezogener Daten gemäß Artikel 13 und Artikel 14 DS-GVO in einfacher und leicht zugänglicher Form zur Verfügung. Hierzu stellen sie dem Patienten eine Einwilligungs- und Teilnahmeerklärung zur Verfügung.

Gegenüber dem ZTM und den Gesundheitseinrichtungen können die Patienten die ihnen zustehenden Rechte aus Artikel 15 bis 22 DS-GVO geltend machen. Bei Anfragen zur Auskunft wird das ZTM die Abstimmung mit der zuständigen Gesundheitseinrichtung suchen, um die Rechtmäßigkeit der Anfrage zu prüfen und den Patienten identifizieren zu lassen.

Für die rechtmäßige Erfassung der Daten mit dem NIDAklinik-System ist der Benutzer der Gesundheitseinrichtung verantwortlich. Er entscheidet, welche Daten des Patienten erfasst werden, und stellt vorab sicher, dass die Einwilligungserklärung dem Patienten vorliegt und holt diese bei Bedarf ein.

Für den Inhalt von Formularen und Checklisten (Formularfelder, Fragen, Antwortmöglichkeiten) im NIDAklinik-System ist das ZTM zuständig und gibt Standardchecklisten vor.

Das ZTM setzt den Inhalt, Umfang und Dauer der im NIDAklinik-System gespeicherten Daten fest. Die Gesundheitseinrichtungen sind zudem für ihre Daten, die sie in ihren externen Systemen (z.B. Notaufnahmesoftware, Krankenhausinformationssystem) speichern, eigenständig verantwortlich. Inhalt, Umfang und Dauer der gespeicherten Daten in den externen Systemen regelt jede Gesundheitseinrichtung eigenständig für sich.

Zudem ist die Gesundheitseinrichtung für den rechtmäßigen Zugriff der Daten durch die Benutzer aus dem NIDAklinik-System verantwortlich.

Das ZTM und die Gesundheitseinrichtung haben eigenständig Sorge zu tragen, dass sie die gesetzlichen Aufbewahrungspflichten der Daten einhalten.

Das ZTM und die Gesundheitseinrichtung informieren sich gegenseitig unverzüglich und vollständig, wenn sie bei der Prüfung der Verarbeitungstätigkeiten Fehler oder Unregelmäßigkeiten hinsichtlich datenschutzrechtlicher Bestimmungen feststellen.

Das ZTM und die Gesundheitseinrichtung führen gemäß Artikel 30 DS-GVO ein Verzeichnis von Verarbeitungstätigkeiten, das deren jeweiligen Zuständigkeiten unterliegt. Die Verarbeitungstätigkeiten des ZTM umfassen die Installation und Supporttätigkeiten des NIDAklinik-Systems. Die Gesundheitseinrichtung nimmt die Verarbeitungstätigkeiten in ihr Verzeichnis auf, da hierbei regelmäßig Gesundheitsdaten und damit auch besondere Daten nach Artikel 9 DS-GVO verarbeitet werden. Das ZTM und die Gesundheitseinrichtung unterliegen gemäß Artikel 33, 34 DS-GVO Melde- und Benachrichtigungspflichten gegenüber der Aufsichtsbehörde. Beide obliegen gegenüber den betroffenen Personen, welche von einer Verletzung des Schutzes personenbezogener Daten betroffen sind, einer Melde- und Benachrichtigungspflicht.

Die jeweiligen Funktionsbausteine basieren auf dem von der Fa. medDV programmierten NIDAklinik-System. Im Rahmen von Forschungsprojekten, wie z.B. PerCoMed (BMBF, Pervasive Computing in of networked medical care – Förderkennzeichen (FKZ): 16I1546), INSPIRE (BMBF, Improving Service Productivity in Healthcare –FKZ. 01 FL10080), Rettungskette5G (BMVD, FKZ: 45FGU106_J). CAEHR (BMBF, FKZ 01ZZ2103) und CONNECT_ED (BMBF, FKZ), wird das System in der Kooperation von ZTM und medDV kontinuierlich weiterentwickelt und evaluiert.

Das ZTM ist für den Betrieb des NIDAklinik-Systems zuständig. Zudem übernimmt das ZTM für das NIDAklinik-System die Planung, die Konzeption, die Schulung, den Vertrieb, die Beratung, die Implementierung, die Installation und den Support.

Zudem werden bei Bedarf und abhängig von den Rahmenbedingungen der beteiligten Gesundheitseinrichtungen weitere Softwaresysteme von Sub-Unternehmer und Fremdherstellern eingesetzt werden. Für diese Systeme liegen separate Datenschutzkonzepte und -unterlagen vor.

Das NIDAklinik-System besteht aus mehreren Modulen, die im Folgenden beschrieben werden.

Der NIDAtracker ist eine Webanwendung zur Dateneinsicht und -übermittlung an Drittsysteme. Der NIDAtracker visualisiert die relevanten Daten (Voranmeldung und Protokolle), die auf dem NIDAserver in der Klinik gespeichert werden. Der NIDAtracker ist die zentrale Patientenakte für alle eintreffenden Notfallpatienten, die von einem Rettungsdienstdokumentationssystem digital angemeldet wurden. Der NIDAtracker kann mehrere Systeme (z.B. Vitaldatentelemetrie) in einer patientengeführten Akte anzeigen. Das Matching der Patientendaten zu einem Fall wird über das NIDAgateway über eine alphanumerische ID gewährleistet, die für alle Fälle einzigartig ist.

Webanwendung zur Dateneinsicht für die Benutzung durch den Benutzer mithilfe eines Internetbrowsers. Das NIDAarrivalboard visualisiert die relevanten Daten, die auf dem NIDAgateway gespeichert werden.

Serveranwendung für den sicheren Datenempfang, -speicherung, -archivierung und -verarbeitung. Auf dem NIDAklinik-Server sind NIDAklinik-Module für die zentrale Speicherung, Verwaltung und Weiterverarbeitung der Daten installiert. Der Zugriff auf externe Systeme (z.B. KIS oder DAKS) erfolgt ausschließlich über vorab definierte Protokolle und Schnittstellen (u.a. webrequest, HL7 V2, ESPA-X). Ein direkter Zugriff auf die Datenbank durch eine Notaufnahmesoftware auf den NIDAserver ist nur über vorab definierte Views mit entsprechender Zugriffsbeschränkung und Authentifizierung möglich. Der NIDAserver wird in der Klinik-IT-Struktur gehostet und durch die Gesundheitseinrichtung betrieben.

Serveranwendung für den sicheren Datenempfang, -speicherung, -archivierung, -verarbeitung zwischen Rettungsdienstdokumentationssystemen und dem NIDAserver in der Gesundheitseinrichtung. Das NIDAgateway ist bundeslandspezifisch oder deutschlandweit gehostet. Der deutschlandweit erreichbare NIDAklinikgateway übernimmt die Weiterleitung an die entsprechende Klinik. Weiter stellt er den Verbindungsendpunkt für das NIDAarrivalboard dar, welches in der Klinik aufgerufen wird. Über eine REST-API können sich Rettungsdienstdokumentationssysteme an das NIDAgateway anbinden. Die Hoheit über die Datenerfassung inkl. Anbindung an die Medizintechnik, Foto- und Videoaufnahme oder Einlesen der Versicherungsdaten obliegt dem Partnerunternehmen des ZTM (z.B. Pulsation IT GmbH, ZOLL Medical Deutschland GmbH).

Organisationseinheit für die kleinste abbildbare Untermenge für Voranmeldungen und Protokollen auf dem NIDAserver. Ein Postfach steuert somit gezielt Stationen oder Zufahrtswege für den Rettungsdienst an (z.B. Kreißsaal, Intensivstation und Kinderaufnahme). Der NIDAserver ist über ein Benutzer-/ Rollenkonzept in der Lage weitere Postfächer anzusteuern.

Für die Nutzung von NIDAklinik werden unterschiedliche Arten von Daten verwendet und gespeichert, die im Folgenden zusammen mit ihren Löschklassen und -fristen beschrieben werden.

Im Sinne der Datensparsamkeit wird auf eine möglichst geringe Speicherung von Daten geachtet. Die Verantwortung zur Sicherung der Daten im Sinne der Dokumentation (z.B. für die Leistungsdokumentation) obliegt der Gesundheitseinrichtung im Rahmen ihrer üblichen Vorgaben.

Die Stammdaten, die Nutzungsdaten, die medizinischen Daten und die Benutzerdaten gelten als personenbezogene Daten. Die Konfigurationsdaten werden getrennt gespeichert und sind keine personenbezogenen Daten.

Das NIDAklinik-System dient ausschließlich dem Zweck der Datenerfassung und -übertragung im Rahmen einer telemedizinischen Patientenversorgung. Daher sind von der Gesundheitseinrichtung alle mit dem NIDAklinik-System erfassten und empfangenen Daten, die einer Bewahrungspflicht genügen müssen, mit ihrem externen System bzw. mit dem dafür vorgesehenen Verfahren zur medizinischen Dokumentation abzuspeichern. Das NIDAklinik-System stellt somit kein Dokumentationssystem für die medizinische Leistungserbringung dar und unterliegt damit nicht den Vorgaben für Notaufnahmesoftwaresysteme, Krankenhausinformationssysteme oder anderen medizinischen Dokumentationssystemen.

Auf dem NIDAarrivalboard und dem NIDAtracker bleiben alle Daten nur solange wie notwendig im Sinne einer hohen Benutzerfreundlichkeit (vor allem für die Sicherstellung der Alarmierbarkeit) angezeigt. Das gilt sowohl für medizinische Daten, Stammdaten als auch für Benutzerdaten.

Alle Daten werden nur für den Zeitraum des Nutzungszwecks gespeichert. Der Zeitraum für den Nutzungszweck orientiert sich an den zeitlichen Vorgaben für die Aufgabenerfüllung. Dabei wird auf eine angemessene Benutzerfreundlichkeit geachtet. Zudem gelten die Vorgaben für die Aufbewahrungspflichten und Backups.

Die Löschfristen für die in den NIDAklinik-Modulen erhobenen medizinischen Daten sind modular festgelegt. Als Standard wird auf

• dem NIDAgateway/NIDAarrivalboard eine Löschfrist von drei Stunden verwendet,
• dem NIDAserver/ NIDAtracker eine Löschfrist nach Ablauf der Aufbewahrungsfrist von 10 Jahren verwendet,

damit die Gesundheitseinrichtung ausreichend Zeit für die Speicherung der medizinischen Daten in ihrem Primärsystem hat oder die Daten zur statistischen Auswertung (Qualitätssicherung) verwenden kann (Zweckbindung). Dies ergibt sich aus den Grundsätzen der Speicherbegrenzung (Art. 5 Abs. 1 lit. e) DSGVO), dem Zweckbindungsgrundsatz (Art. 5 Abs. 1 lit. b) DSGVO) sowie dem Grundsatz der Datenminimierung (Art. 5 Abs. 1 lit. c) DSGVO). Die allgemeine Aufbewahrungsfrist beträgt in der Regel 10 Jahre. Verlangt der Betroffene der Datenverarbeitung (Löschanweisung) z.B. der Patient die Löschung seiner personenbezogenen Daten oder kommt der Verantwortliche seiner Pflicht zur Löschung nach, so muss dies innerhalb einer angemessenen Löschfrist geschehen. Im Falle einer Löschanweisung beträgt die Löschfrist 120 Tage. Der Vorgang zur Löschung der Daten wird in einem Löschprotokoll dokumentiert. Auch für Rückfragen der Patienten und Angehörigen sowie für die Nachbearbeitung (z.B. Ergänzung fehlender Daten) ist ein Zeitraum von 120 Tagen gerechtfertigt. Zur Einhaltung der Bearbeitungszeit ist die Mitarbeit der Rechenzentren und der IT-Abteilungen der Gesundheitseinrichtungen notwendig.

Soweit durch ein Update des Software-Programms Regelungen dieser Vereinbarung betroffen sind, ist der Kunde (z. B. für Information des Datenschutzbeauftragten und Mitarbeitervertretung) zu informieren und eine Anpassung der entsprechenden Regelungen zu vereinbaren.

Mit dem NIDAarrivalboard/ NIDAtracker werden keine Patientendaten lokal auf dem dafür eingesetzten Computer gespeichert. Über den Internetbrowser können Benutzeranmeldedaten über die browsereigene Funktion gespeichert werden. Über den Internetbrowser werden Cookies gespeichert. Diese Cookies zu speichern ist notwendig, damit

• die Funktionen des NIDAarrivalboards für ein 24/7-Betrieb im „stand-alone“-Modus geeignet ist, und
• die Funktionen des NIDAtrackers zur Alarmierung und akustisches Signal sowie bei Aktualisierung der Webseite ein erneutes Einwählen nicht notwendig ist (Verhinderung automatisches Ausloggen), gewährleistet wird.

Über den Internetbrowser auf diesem Computer erfolgt der Abruf, die Anzeige und die Erfassung von Daten direkt auf dem NIDAgateway oder NIDAklinik-Server.

Der NIDAklinik HL7 Connector speichert keine Daten, sondern übermittelt die Daten nachrichtenbasiert ohne Zwischenspeicherung. Hierfür sind daher keine Löschregeln notwendig. Zur Problem-Analyse im Rahmen einer Wartung können LOG-Dateien gespeichert werden, die Patientendaten enthalten. Diese werden nach erfolgter Analyse und Wartung manuell gelöscht. Die Standardeinstellung hat zur Folge, dass LOG-Dateien ohne Patientendaten sind.

Mit NIDAklinik kann ein Benutzer statische Stammdaten zu allen Benutzern erfassen. Folgende Stammdaten werden verarbeitet:

• verfügbare Gruppen (Postfach ID).

In NIDAklinik werden folgende Benutzerdaten für die Administration der Benutzerkonten gespeichert: Benutzername, Vorname und Nachname.

In NIDAklinik werden Nutzungsdaten gespeichert, um dem Support die Möglichkeit zur Fehlersuche zu vereinfachen. Folgende Daten werden hierfür gespeichert: Benutzername, Ereignisse im Zusammenhang mit der Authentifizierung, Änderungsdatum bei Ereignissen in den Patientenkonto, Zeitpunkt Start der Voranmeldung, Zeitpunkt Start des Versendens, Anzahl der Versuche des Versendens, Dateigröße der versendeten Daten, Zeitpunkt des Datenempfangs, Dateigröße der empfangenen Daten, Zeitpunkt eines Verbindungsabbruchs, Zeitpunkt eines Programmfehlers inkl. Fehlerbeschreibung, Browsertyp / Browserversion, verwendetes Betriebssystem, Referrer URL, Hostname / IP des zugreifenden Rechners und Uhrzeit der Serveranfrage.

Diese Protokolle werden gemäß den Löschfristen und ausschließlich für Support-Zwecke eingesetzt. Der Datenzugriff auf die Protokolle wird protokolliert und kann von der zuständigen Mitarbeitervertretung, sofern eine vorhanden ist, eingesehen werden.

Die Nutzungsdaten werden nicht automatisch gelöscht, um für Support und Wartungs-zwecke eine ausreichende Datenmenge zur Problemanalyse bieten zu können.

Die medizinischen Daten können sich aus den folgenden Datenkategorien zusammensetzen:

• Personalstammdaten
• Messungen
• Scores
• Protokolle
• Fotos
• EKG

Personalstammdaten

• „Nachname“, „Vorname“, „Geburtsdatum“, „Geschlecht“, „Versicherten-Nr.“, „Versicherten-Status“, „Straße“, „Hausnummer“, „PLZ“, „Ort“,

Messungen

Das NIDAklinik-System nimmt selbst keine Messungen vor, sondern empfängt die Messungen entweder über eine Schnittstelle zu den Medizinprodukten oder über Handeingaben in das Rettungsdienstdokumentationssystem über das NIDAgateway. Folgende Messungen können empfangen werden:

„Vitalparameter“ (Blutdruck, Herzfrequenz, Atemfrequenz, Blutzucker, Temperatur, SpO2)“, „Rückrufnummer Angehörige“, „Abfrageschemata (Antokoagulantien“, „Schmerzen“, „Ausstrahlung“, „Ereigniszeitpunkt“, „Katecholamingabe“, „Intubation“, „Reanimation“, „STEMI“, „Bypass“, „Herzkatheter“, „Herzinfarkt“, „Verletzungen“, „Kreislauf“, „Intubation“, „I-Status“, „GCS (Augen, Motorik, Verbal)“, „Voranmeldediagnose“, „geschätzte Ankunftszeit“, „Priorität (Dringlichkeit)“, „Vorzustand prä-mRS“, „Last-Seen-Well“,  „Rettungsmittelkennung“, „Rückrufnummer RTW und Leitstelle“, „Anmeldetext“, „berechnete Ankunftszeit bei GPS-Modul“, „Krankenkasse“, „Krankenkassen-ID“, „Versichertennummer“, „Status“, „privat versichert“, „befreit“, „MIND-Datensatz“, „Anamnesetext“, „First Responder“; „Erstbefund-Zeitpunkt“, Pupillenstatus“, „Erkrankung“, „Messwerte Erstbefund“, „EKG-Befund“, „Atemwege“ (frei, Spastik, Stridor, Rasselgeräusche, nicht beurteilbar, nicht untersucht, Patient kann sicher schlucken, Atemwegsverlegung), „Atmung“ (auffällig, Dyspnoe, Zyanose, Schnappatmung, Beatmung, Apnoe, Hyperventilation, sonstige), „Kreislauf“ (unauffällig, Blutung, nicht untersucht, Puls regelmäßig, Rekap-Zeit), „Haut“ (unauffällig, Oedeme, kaltschweißig, sonstige, nicht beurteilbar, Dekubitus, stehende Hautfalten), „Psyche“ (unauffällig, verwirrt, verlangsamt, suizidal, aggressiv, erregt, euphorisch, sonstige, depressiv, wahnhaft, ängstlich, motorisch unruhig), „Verletzungen“ (keine, Zusammenhang mit, Verletzungsmuster), „Unfallmechanismus“, „Lokalisation und Schweregrad“, „Unfallhergang“, „Medikation“ (Medikament, Applikationsform, Dosis, Flussrate in ml/h, keine Medikation), „Maßnahmen“ (Zugänge), „Atemweg“ (Atemwege freimachen, Absaugen, Laryngoskopie, Entlastungspunktion), „Beatmung“ (Spontanatmung, kontrollierte Beatmung, Maschinell, manuell, Demandventil, Rückatmung), „Defibrillation“ (monophasisch, biphasisch, Pacer, Frequenz, Joule, Kardioversion), „Bemerkungen“, „Übergabeort“, „Unterschrift“, „Wertsachen“, Schmerzen (0-10, NRS nicht beurteilbar, NRS nicht erhoben), „Lagerung“, „Immobilisation“, „Sonstige“.

Medizinische Scoring-Systeme

• PEES (Augen: geöffnet 0-2, Blickwendung 0-1, einseitig gestreckter steifer Arm und/oder Bein 0-1, Zuckungen einseitig (nicht zittern) 0-1, Nesteln, Lippenlecken, Schmatzen mit Verwirrtheit 0-2, Dauer des Anfalls>30s 0-1, Dauer der Bewusstseinsstörung nach dem Anfall>3 min 0-1, Zungenbiss 0-2, Epilepsie/ Anfälle bekannt 0-2, Summe.)
• 4I-SS (Vigilanz [wach:0, bedingt ansprechbar:1, nicht ansprechbar:2]; Kopf- und Blickwendung [keine Blickwendung: 0, nur Blickwendung:1, Kopf- und Blickwendung:2]; Hemiparese [keine:0, leicht:1, schwer:2]; Sprach-Sprechstörung [nein:0, ja:1]; Summe.)
• sNIHSS-EMS (Bewusstseinszustand 0-3, Gesichtslähmung 0-3, Motorik Arme 0-4, Motorik Beine 0-4, Sensibilitätsstörung 0-2, Sprachstörung (Aphasie) 0-3, Verwaschenes Sprachen (Dysarthrie) 0-2, Summe.)

Protokolle

• Notarztprotokoll (analog dem Notarztdienst zur Verfügung gestellten Dokumentationsschema)
• Rettungsdienstprotokoll (analog dem Rettungsdienst zur Verfügung gestellten Dokumentationsschema)
• „Telefonnummer Rettungsmittel“, „Name/Vorname zum Fahrer“, „Beifahrer“, „Praktikanten und Notarzt“, „Einsatzdatum“, „Transport von“, „Transport nach“, „Einsatz-Art“, „Einsatzort-Typ“, „Voranmeldung (ZNA, Stroke Unit, CPU, Trauma-Zentrum, sonstige, nicht vorangemeldet), „FMS-Zeiten (Status 1,2,3,4,7,8 und Alarmierungszeit), „Alarmierung Notarzt“

Fotodokumentation

Fotos können als jpg. oder png. empfangen werden. Die Inhalte der Fotos des Einsatzes werden vom Notarzt- und Rettungsdienstmitarbeiter bestimmt. Fotodokumentationen dienen zur Festhaltung von Auffälligkeiten am Körper (u.a. Gesichtslähmung beim akuten Schlaganfall, Hautrötung bei der Tiefenbeinvenenthrombose oder Unfallkinematik/ Karosserieverformung beim Verkehrsunfall).

Videodokumentation

Videos können als mp4 empfangen werden. Die Inhalte der Videos des Einsatzes werden vom Notarzt- und Rettungsdienstmitarbeiter bestimmt. Videodokumentationen dienen zur Festhaltung von Auffälligkeiten am Körper (u.a. Gesichtslähmung beim akuten Schlaganfall, Hautrötung bei der Tiefenbeinvenenthrombose oder Unfallkinematik/ Karosserieverformung beim Verkehrsunfall).

EKG

• 6-Kanal-EKG (Rohdaten und PDF) Ableitungen I-III und aVR-AVF
• 12-Kanal-EKG (Rohdaten und PDF) ergänzend zu oben V1-V6
• 12-Kanal-EKG (FHIR-Ressource) analog FHIR-Schnittstellenbeschreibung corpuls.live

Zur eindeutigen Identifikation und Zuordnung werden Metadaten zum EKG (NIDA-ID, Zeitpunkt der Aufnahme (Datum und Uhrzeit) und der Nachname, Vorname und Geburtstag gespeichert.

Für alle medizinische Daten werden die nachfolgenden Löschklassen festgelegt.

Löschklasse „Medizinische Daten“ (NIDAklinik Server)

• Löschung der Daten nach 10 Jahren oder nach Antrag auf Löschung durch den Patienten gemäß seines Widerspruchsrechts nach Art. 21 DS-GVO

Die Konfiguration erfolgt entweder auf dem NIDAgateway (NIDAarrivalboard) oder auf in der Gesundheitseinrichtung (NIDAserver). Für die Konfiguration des NIDAklinik-Systems werden folgende Konfigurationsdaten gespeichert:

• Für das NIDAarrivalboard werden alle administrativen Konfigurationen der jeweiligen Lizenzschlüssel (z.B. c2BdX-wlmny-NEiQA-t9vWT) zentral auf dem jeweiligen NIDAgateway gesichert.
  • Konfigurationsdaten sind: Leitstelle, Beschreibung, Verbindung verloren Nachricht, Filter, Rufzeichen, Anmeldetext, Anzahl Voranmeldungen, Ablaufzeit, Sortierung, Soundfilter
• Die Webanwendungen NIDAarrivalboard und NIDAtracker beim Kunden speichern die lokalen Konfigurationen in Cookie-Dateien des Browsers. Beim Starten der Anwendung wird die Konfiguration aus der Cookie-Datei geladen, solange diese noch gültig ist.
  • Konfigurationsdaten (NIDAarrivalboard) sind: Hintergrundfarbe, Tonausgabe, Lizenzkey
  • Konfigurationsdaten (NIDAtracker) sind: Desktopbenachrichtigungen, Benachrichtigungston und -art, Filter für Benachrichtigungston, Sprache
• Für den NIDAserver in der Klinik werden folgende Konfigurationsdateien gespeichert: NIDAserver-Konfiguration, Webserver-Konfiguration, MQTT-Broker-Konfiguration, Datenbank-Konfiguration, ElasticSearch-Konfiguration, Logstash-Konfiguration

Da hierzu keine personenbezogenen Daten gespeichert werden, wird keine Löschfrist angesetzt. Die Konfiguration wird während der Installationsphase vorgenommen. Auf Anfrage des Kunden sind Konfigurationsanpassungen nach der Grundkonfiguration ebenfalls möglich. Im Livebetrieb werden Konfigurationsanpassungen nur nach Abstimmung mit der zuständigen IT-Abteilung der Klinik getätigt. Vor dem Anpassen von Konfigurationsdateien werden von diesen Sicherungen erstellt, welche es ermöglichen den Vorzustand wiederherzustellen.

Die Berechtigungsvergabe und -verwaltung steht nach Bereitstellung des NIDAklinik-Systems der Gesundheitseinrichtung zur eigenständigen Konfiguration zur Verfügung. Als Werkeinstellung wird der Gesundheitseinrichtung ein Benutzerkonto „Admin“ bereitgestellt, mit dem alle weiteren Benutzer erstellt werden können. So kann ein Admin nach durchgeführter Schulung über die NIDAklinik Benutzerverwaltung alle weiteren erforderlichen Benutzerkonten erstellen.

Den Rollen werden Zugriffsrechte in unterschiedlichem Umfang zugeordnet. Einem Benutzer wird eine Rolle zugeordnet. Ein Benutzer kann mehrere Rollen zugeordnet bekommen. Die Rechte wer- den dann additiv erweitert, so dass der Benutzer alle Rechte von allen ihm zugeordneten Rollen erhält.

Das NIDAklinik-System unterscheidet zwei Zugriffsklassen:

• Leserecht: Zugriffrecht zur Anzeige von Inhalten einer Datenklassen.
• Schreibrecht: Zugriffsrecht zum Speichern, Ändern oder Löschen einer Datenklasse.

Benutzer: Ein Benutzer ist eine Person, die das NIDAklinik-System als Hilfs- oder Arbeitsmittel für seine Arbeit in der Gesundheitseinrichtung verwendet. Den Benutzern können verschiedene Rollen zugewiesen werden. Die Zuordnung der Rollen entscheidet darüber, welche Rechte und Ansichten der jeweilige Benutzer in NIDAklinik besitzt. Im NIDAklinik-System werden folgende Rollen unterschieden:

• Admin: Natürliche Person, der mit Administratoren-Rechten ausgestattet ist. Darunter fällt die Benutzerverwaltung. Im NIDAtracker steht die Benutzerverwaltung zur Verfügung. Über die Benutzerverwaltung können Benutzer verschiedenen Gruppen zugeordnet werden (Admin, Archiv, KIS, Statistik). Der Admin kann, die beim Einrichten eines neuen Systems bzw. Mandanten die initialen Benutzerkonten anlegen, verwalten und diese auch wieder löschen.
• Archiv: Natürliche Person, die Zugriff auf die Archivfunktion hat und alle archivierten Patientendaten einsehen kann. In dem Archiv können archivierte Voranmeldungen und Protokollübergaben in die aktuelle Patientenliste verschoben werden.
• KIS: Natürliche Person, die in der aktuellen Patientenliste die Möglichkeit zum Matching und zur Übertragung der Voranmeldungen und Protokolle an das Krankenhausinformationssystem (KIS) hat.
• Standard: Natürliche Person, die Zugriff auf das NIDAklinik-System über den NIDAtracker hat und/oder Voranmeldungen über das NIDAarrivalboard einsehen kann. Die natürliche Person hat Zugriff eine definierte Teilmenge der Daten des NIDAklinik-Systems. Die natürliche Person hat Zugriff auf die noch nicht archivierten Voranmeldungen und Protokolle im NIDAtracker.
• Statistik: Natürliche Person, die Zugriff auf das NIDAklinik-System hat und aggregierte bzw. statistische Kennzahlen im NIDAtracker angezeigt bekommt. Diese Rolle ist im NIDAklinik-System in der Client-Variante verfügbar.

Verwendete Daten

• 7.1. Stammdaten
• 7.2. Benutzerdaten
• 7.3. Nutzungsdaten
• 7.4. Medizinische Daten
• 7.5. Konfigurationsdaten

Das NIDAklinik System kann nicht komplett eigenständig ohne Hinzunahme weiterer Systeme eingesetzt werden. Alle Daten zum Patienten werden zunächst lokal mit dem Rettungsdienstdokumentationssystem in einem sicheren Datencontainer erfasst und gespeichert, damit sie anschließend per Klick auf der Schaltfläche „Versenden“ (oder ähnlich) an das NIDAgateway versendet werden können. Drittanbieter wie ZOLL Ambulance oder Pulsation IT verwenden eine REST API, um Daten vom Rettungsdienstdokumentationssystem an das NIDAgateway zu senden. Die technische Vorgehensweise zur Anbindung der Drittsysteme ist in einem technischen Datenblatt beschrieben. Prinzipiell muss sich das Rettungsdienstdokumentationssystem am NIDAgateway authentifizieren, um einen Bearer-Token (Request for Comments, RFC) zurückzuerhalten, der für 12 Stunden gültig ist. Nach Ablauf der Gültigkeitszeitraum muss sich das Rettungsdienstdokumentationssystem erneut für diesen Einsatz authentifizieren. Das Rettungsdienstdokumentationssystem fragt dann eine Liste an bekannten Postfächern ab und erlaubt dann eine Datenübertragung. So ist eine eindeutige, zeitlich begrenzte Zuordnung von Rettungsdienstdaten zu Klinikpostfächern gewährleistet. Die Regelungen zum Mobile Device Management und Verarbeitung der Daten auf dem Rettungsdienstdokumentationssystem sind durch die jeweiligen Hersteller geregelt.

Nach erfolgreicher Empfangsbestätigung auf dem NIDAgateway werden die Patientendaten lokal auf dem NIDAklinik Server gespeichert. Über NIDAklinik erfolgt nach erfolgreicher Authentifizierung der Zugriff auf die für den Benutzer freigegebenen Patientendaten. Jeder Gesundheitseinrichtung steht hierfür ein eigener Server zur Verfügung, so dass jeder Benutzer ausschließlich Zugriff auf ihre eigenen Daten erhalten kann (Postfach). Der Rettungsdienst administriert die Postfächer und die Zuordnung der Postfächer auf den Rettungsdienstdokumentationssystemen nach Anweisung durch das ZTM selbst. Damit ist sichergestellt, dass kein Rettungsdienstdokumentationssystem an ein Postfach sendet, der nicht vom Administrator zugewiesen wurde. 

Es können mehrere Postfächer auf einem NIDAserver installiert sein, solange diese aber im gleichen IT-Netz der Klinik zugeordnet sind. Die Systemarchitektur des NIDAklinik Systems stellt die nachfolgende Abbildung dar. Sie illustriert die Beziehungen zwischen den einzelnen NIDAklinik Komponenten und Systemen von Fremdherstellern bzw. Drittanbietern. Die Verbindungen zwischen den einzelnen Komponenten stellen die Schnittstellen dar, welche von einer Komponente angeboten und von anderen Komponenten konsumiert werden. Die Datenübertragung in die Klinik erfolgt nach einem „doppelten Umschlag-Prinzip“.

In den Postparametern des Webrequests ist die Zielklinik enthalten. Dieser Teil kann und muss vom NIDAgateway ausgepackt werden, damit das Ziel der Daten bekannt ist. Durch das provider-seitige VPN, können die mobilen Geräte nur Daten an den NIDAserver bzw. NIDAgateway senden. Die Übermittlung der Daten in die Klink erfolgt dann vom NIDAgateway aus. Die eigentlichen Nutzdaten für die Klinik sind für den Gateway nicht entschlüsselbar als Datei im Request enthalten. Diese Datei wird mit dem öffentlichen Schlüssel des Zielkrankenhauses auf dem Pad verschlüsselt. Die öffentlichen Schlüssel aller angebundenen Kliniken sind lokal auf den mobilen Geräten verfügbar.

Das Hosting (Betrieb des NIDAklinik-Servers) übernimmt die Gesundheitseinrichtung für sich selbst in Form eines On-Premise-Dienstes.

Das ZTM erhält Zugriff über Fernwartung im Rahmen einer Auftragsverarbeitung, um Wartung und Pflege der Software durchführen zu können. Die Gesundheitseinrichtung stellt den ordentlichen Betrieb des NIDAklinik-Servers sicher. Hierfür hat die Gesundheitseinrichtung die vom ZTM vorgegebenen Voraussetzungen für Installation und Betriebs des NIDAklinik-Servers in ihrem Rechenzentrum sicherzustellen.

Der NIDAklinik-Server wird in der DMZ installiert und erhält ausschließlich über den NIDAgateway Daten über einen TCP Port. Somit greifen alle Benutzer über einen Web-Client auf den NIDAklinik Server zu, so dass lediglich eine IP-Port-Freigabe bzw. VPN-Routing für das NIDAgateway in die DMZ notwendig ist. Die Ports vom NIDAarrivalboard (443) und NIDAtracker (1443) sind getrennt voneinander. Als Protokoll selbst wird eine SSL Verbindung bzw. https Requests verwendet. In Summe ist die Datenübertragung somit dreifach verschlüsselt

• die Dateien selbst
• die SSL-Verbindung
• das VPN.

Der NIDAgateway erhält den verschlüsselten Datensatz, wertet die Headerdaten aus und leitet das verschlüsselte Paket per https an den NIDAserver (Server in der Zielklinik) weiter. In der Zielklinik werden diese Datenpakete entschlüsselt. Somit liegen alle Voranmeldedaten, auch die demographischen Daten, der Klinik vor. Die Voranmeldedaten werden am NIDAtracker angezeigt, dieser ist im LAN mit dem NIDAserver verbunden. Auf dem NIDAgateway werden Postfächer für jede Klinik zur Verfügung gestellt. Das NIDAarrivalboard erhält KEINE Daten vom NIDAgateway, es zeigt diese anonymisierten Daten lediglich an. Hierfür baut das NIDAarrivalboard eine bidirektionale Socket-Verbindung mit dem zentralen Gateway auf (SSL-Verschlüsselung).

Die Installation und Aktualisierung eines Virenschutz-Programmes sowohl auf dem NIDAarri-valboard als auch auf dem NIDAserver liegt in der Verantwortung der Klinik. 

Für den NIDAklinik Server setzt das ZTM folgende Voraussetzungen an

• 64-Bit fähiges Windows Betriebssystem (Windows Server 2016 oder höher)
• .Net Framework 4.8 oder höher
• 8 GB RAM
• zwei HDD-Partitionen
• Partition 1: Betriebssystem / Software-Partition mit 50 - 60 GB Speichervolumen
• Partition 2: Daten Partition mit 50 GB freien Speicher auf HDD (Dieser Wert richtet sich nach der zu erwartenden Datenmenge 50 GB -> ca. 100.000 Datensätze)
• 2,0 GHz Prozessorleistung oder höher (Multicore Prozessor)
• LAN- und Breitbandanschluss wird vorausgesetzt

Für das NIDAarrivalboard setzt das ZTM folgende Voraussetzungen an

• Windows 10
• 2,0 GHz Prozessorleistung und 4 GB Arbeitsspeicher
• Browser: Google Chrome, Mozilla Firefox, MS Edge (Version bitte relativ aktuell halten)
• JavaScript muss aktiviert sein
• Cookies müssen erlaubt sein

Nach Aufruf des Links wird ein Lizenzschlüssel abgefragt. Diesen Lizenzschlüssel senden wir Ihnen in einer separaten Mail. Die Zuordnung Lizenzschlüssel / Klinikrelevante Daten erfolgt durch den ZTM-IT-Service. Der Lizenzschlüssel kann immer nur für einen Client/Browser aktiv verwendet werden. Wenn Sie die Anwendung ggf. doch an mehreren Clients laufen lassen möchten, können Sie gerne weitere Lizenzschlüssel bei unserem IT-Service-Team beantragen. Auf dem Rechner, an dem das Arrivalboard ausgeführt wird, wird ein Cookie mit einer Laufzeit von 7 Tagen abgelegt. Erfolgt in diesem Zeitraum kein Aufruf des Links, so wird der Cookie ablaufen und der Lizenzschlüssel muss bei der nächsten Nutzung erneut eingetragen werden.

Es wird sichergestellt, dass die Rechenzentrumsinfrastruktur, -betrieb und Serverfertigung des NIDAgateways in Deutschland erfolgt und der Anbieter nach ISO/IEC 27001:2013 zertifiziert ist.

Das System wird im Rahmen des operativen Betriebs als eigene Serverinstanz (Produktivsystem) bereitgestellt. Die Administration des NIDAklinik-Servers ist ausschließlich von einem definierten IP-Bereich (ZTM Bad Kissingen GmbH) möglich. Die Administration erfolgt per RDP (verschlüsselt).

Das ZTM ist für die Schulung der Multiplikatoren zuständig, und bietet für sie auch den Second-Level-Support an.

Für den First-Level-Support sind Leiter, Betreuer und Assistenten der Gesundheitseinrichtung zu-ständig. Der Support über First-Level an Second-Level geschieht per Telefon, per E-Mail, per Vi-deotelefonie oder einem Vor-Ort-Termin.

Neben der allgemeinen Produktinformation zu NIDAklinik vom ZTM liegt den Benutzern ein allge-meines Benutzerhandbuch inkl. des Datenschutzkonzeptes und der Nutzungsvereinbarung vor, welches digital den Verantwortlichen in der Gesundheitseinrichtung bei Einrichtung des NIDAklinik Systems (auch jederzeit zugreifbar online als Internetseite oder über den NIDAtracker) zur Verfügung gestellt wird.

Der Support erfolgt über zwei Stufen:

• Stufe 1: Bei Problemen und Anmerkungen kann sich der Benutzer an den First-Level-Support wenden, der von der Gesundheitseinrichtung selbst gestellt wird.
• Stufe 2: Falls das Problem im First-Level-Support nicht gelöst werden kann, dann steht das ZTM im Second-Level-Support zur Verfügung.

Zugriff auf die Administration des NIDAklinik-Servers hat der Support des ZTM, um auf die Nutzungsprotokolle für Supportfälle zuzugreifen und die Programme auf dem NIDAklinik-Server zu aktualisieren bzw. bei Problemen die Ursachen zu prüfen.

Die Tabelle beschreibt den Prozess der Benutzerbetreuung in der Zusammenarbeit zwischen der Gesundheitseinrichtung und dem ZTM in Form einer Kommunikationsmatrix.

Die Systemarchitektur des NIDAklinik-Systems wird in der nachfolgenden Abbildung dargestellt.

Sie illustriert die Beziehungen zwischen dem NIDAklinik-Server, dem NIDAgateway, den Fremdsystemen und den Anwendungen auf den Bediengeräten. Die Verbindungen zwischen den einzelnen Modulen stellen die Schnittstellen dar, welche von einer Komponente angeboten und von anderen Komponenten konsumiert werden. 

Die Kommunikation zwischen diesen Systemen gestaltet sich somit folgendermaßen:

1. Ein Rettungsdienstdokumentationssystem sendet über den Mobilfunk inkl. VPN und Firewall an das NIDAgateway und leitet diese dann dem entsprechenden Postfach zu.
2. Die Daten werden autorisiert und geprüft. Eine Weiterleitung erfolgt nur auf das zugeordnete Postfach und wird über definierte Ports an das Postfach gesendet und auf dem NIDAserver in der Klinik in einer SQL-Datenbank gespeichert.
3. Das NIDAarrivalboard visualisiert die Daten des NIDAgateway ohne Speicherung in der Klinik. Der NIDAtracker visualisiert die Daten des NIDAservers mit Speicherung in der Klinik.
4. Externe Systeme in der Gesundheitseinrichtung können über Schnittstellen angesteuert werden.
   1. HL7 zu Krankenhausinformationssystemen (via HL7 Connector)
   2. Direktdatenbankimport über HTTPS in Notaufnahmesoftware und Feedbacksystem
   3. ESPA-X zu DAKS

Das NIDAklinik-System kann grundsätzlich komplett eigenständig auch ohne Hinzunahme von Fremdsystemen eingesetzt werden. Welche Fremdsysteme wie angebunden werden, verantwortet und entscheidet die Gesundheitseinrichtung.

Alle Systeme von Fremdherstellern dienen lediglich der Erweiterung der Funktionalität und Steigerung der Effizienz in der Datenverarbeitung. Daher stellt das NIDAklinik-System das Basissystem dar, das mit weiteren Systemen von Fremdherstellern optional erweitert werden kann:

HL7 Schnittstelle (Frontend): Über den NIDAtracker kann der HL7 Connector, der als Proxy auf dem NIDAserver installiert ist, steuert werden. Hierfür kann der Benutzer mit der Rolle „KIS“ in der Detailansicht auf den Button „KIS-Import“ klicken. Es öffnet sich ein Fenster, das die Benutzeroberfläche des HL7 Connectors anzeigt. Hier kann der Benutzer den Patienten einem KIS-Fall zuweisen, so dass die entsprechenden Daten des Notarzt- und Rettungsdienstes an das KIS über eine HL7 Nachricht weitergeleitet werden kann. Das System übernimmt dafür die vom Rettungsdienst übertragenen Informationen zu „Patient“ und „Kostenträger“. Das KIS sendet HL7 ADT Nachrichten an den NIDAserver, um relevante Verknüpfungseigenschaften in der Benutzeroberfläche anzuzeigen. Es erfolgt ein automatischer Matchingvorschlag zu erhaltenen ADT-Nachrichten (Nachname, Vorname, Geburtsdatum, Versicherungsnummer). Im Regelfall ist der Notarzt- und Rettungsdienst angewiesen die Daten aus der elektronischen Gesundheitskarte (eGK) auszulesen, um vollständige und eindeutige Stammdaten zu übertragen. Im Notfall liegen diese Informationen nicht regelhaft vor, so dass händische Eingaben auf dem Rettungsdienstdokumentationssystem möglich sind. Das NIDAklinik System unterscheidet nicht, ob der Rettungsdienst die eGK am Einsatzort eingelesen hat oder die Informationen zu den Stammdaten mündlich erfragt hat. Der Benutzer muss davon ausgehen, dass diese Informationen „Vorabinformationen“ sind und daher ist eine Sichtkontrolle durch den Benutzer über die Benutzeroberfläche bei der Zuordnung zu einem KIS-Fall obsolet. 

Weitere Daten werden nicht übertragen bzw. auf dem NIDAklinik-Server gespeichert. Ist eine Übertragung der Versicherungsnummer erfolgt, dann wird ausschließlich die Versicherungsnummer im automatischen Matching auf der Benutzeroberfläche verwendet, um auszuschließen, dass Abweichungen bei „Nachname“ und „Vorname“ das Matching stören (z.B. bei Namensänderung bei Ehe oder Scheidung). Der Benutzer bekommt nun eine Liste mit möglichen Patientenfällen angezeigt und kann nun per Klick auf den Fall eine KIS-Verknüpfung (Button: „Verknüpfen“) herstellen.

HL7 Connector (Backend): Der HL7 Connector ist ein Proxy und stellt das Bindeglied zwischen dem KIS und dem NIDAklinik Server dar. Er nimmt ADT (Aufnahme Nachrichten) an, weißt diese auf ein definiertes Objekt zu und schickt dieses weiter an den NIDAserver. Unter ADT werden die allgemeinen demographischen und verwaltenden, nicht klinischen Patientendaten verstanden. Weiter bekommt der HL7 Connector Daten vom NIDAserver und leitet diese als HL7 Nachrichten an das KIS System der Klinik weiter. 

Eine ausführliche Beschreibung der technischen Vorgehensweise ist im Dokument „HL7 Connector“ beschrieben.

Direktdatenbankanbindung (Webrequest): Der Datensatz des Notarzt- und Rettungsdienstes kommt in der Klinik am NIDAserver an und kann im NIDAtracker geöffnet werden. Es erfolgt gleichzeitig auf dem NIDAserver ein HTTPs Webrequest (post) inkl. NIDA-ID (Feldname: nida_id) wird vom NIDAserver an eine Zieladresse des Drittanbieters geschickt.

Beispiel für einen HTTPs Webrequest: http://192.168.178.1:5000/nida/?id=8719e081d0270f964618c01f7fe74f32

Die NIDA-ID ist eine alphanummerische einzigartige Identifikationsnummer. Falls Kliniken mehrere Postfächer haben, kann zusätzlich noch die Postfach-ID in den Request aufgenommen werden.

Im nächsten Schritt kann sich das Drittsystem sich mit entsprechenden Login-Daten (Leserecht) an der NIDAserver anmelden und erlaubt dem Drittsystem die Daten aus den zur Verfügung stehenden Datenbank-Views zu kopieren. Das Drittsystem hat die Möglichkeit folgende Daten und Dateien aus den zur Verfügung gestellten Views zu importieren: Demographische Daten, Vitalparameter, Bilder (als .png), EKG (als .pdf), Protokolle (als .pdf). 

Verschlüsselung: Um die Inhalte der Patientenakte zu schützen, werden alle Kommunikationswege via TLS verschlüsselt. Hierzu werden entsprechende Sicherheitszertifikate im Rechenzentrum der Gesundheitseinrichtung installiert. Auf dem Webserver werden keine Daten gespeichert, sondern nur weitergereicht. Nach dem Prinzip „Security by Design“ wird auf Datensparsamkeit und möglichst enge Löschfristen geachtet. Zudem werden Daten von Postfächern in jeweils getrennten Instanzen gespeichert.

Datenspeicherung: Als Datenbank kommt MySQL oder MariaDB zum Einsatz. Die Daten werden von MySQL verschlüsselt auf der Festplatte abgelegt. Um einen Zugang zu den Daten zu erhalten ist die Eingabe eines Benutzernamens und Passwortes notwendig. Zusätzlich werden von der Datenbank nur Verbindungen von definierten Hosts oder IP-Adressen akzeptiert.

Für NIDAklinik werden verschiedene Risiken betrachtet. Dazu werden mögliche Risiken, die im Kontext mit den NIDAklinik Komponenten (Eingesetzte Software) bestehen, beschrieben und Lösungsvorschläge zur Minimierung des Risikos aufgezeigt. Weiterhin werden die potenzielle Schadenshöhe und Eintrittswahrscheinlichkeit vor und nach Einführung der Gegenmaßnahmen dargestellt.

Für NIDAklinik wird eine Vielzahl an technischen und organisatorischen Schutzmaßnahmen getroffen:

• Die Unterscheidung der Rollen stellt sicher, dass Benutzer keine weiteren Benutzer anlegen können. Die Gefahr eines Missbrauchs ist niedrig, da Benutzer nur wenige Anpassungsmöglichkeiten am Software-Client innerhalb der ihnen vorgegebenen Arbeitsplatzsysteme vornehmen können.

• Für jedes Konto wird ein Benutzerkontoantrag bereitgestellt, damit der Benutzer seine Anmeldedaten erhält. Dem Benutzer wird ergänzend zu den Anmeldedaten die Bedienungsanleitung, die Nutzungsvereinbarung und die Datenschutzerklärung bereitgestellt. Der Benutzer akzeptiert durch seine willentliche Anmeldung an seinem Benutzerkonto mit Benutzername und Passwort, dass er die Nutzungsvereinbarung und Datenschutzerklärung verstanden und akzeptiert hat. Ein Missbrauch ist nur durch willentlichen aktiven Beitrag des Benutzers (eingeschränkt) möglich.

• Jeder Arzt ist verpflichtet und selbst verantwortlich, die gewonnenen Daten an seinem Arbeitsplatz gegen den Zugriff unberechtigter Dritter zu sichern. Hierzu hat der Arbeitgeber die dafür notwendigen räumlichen und technischen Möglichkeiten zur Verfügung zu stellen.

Die Mitbestimmungsrechte der Mitarbeitervertretungen bleiben unberührt.