Die Konformität einer Anwendung im Gesundheitswesen zur Technischen Richtlinie 03161 wird durch das BSI mit einem Zertifikat bestätigt. Im Zuge dieses Verfahrens wird von einer neutralen Prüfstelle eine Konformitätsprüfung auf Grundlage der in der Technischen Richtlinie definierten Prüfspezifikationen durchgeführt. Die Prüfung wird von der zuständigen Zertifizierungsstelle innerhalb des BSI überwacht und nach erfolgreichem Abschluss mit einem Konformitätsbescheid und einem Zertifikat bestätigt. Die Dauer einer solchen Konformitätsprüfung hängt von vielen Faktoren ab und kann nicht pauschal beziffert werden. Im Regelfall kann mit einer Dauer von durchschnittlich drei Wochen für die Bestätigung des Prüfberichtes durch das BSI gerechnet werden.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bietet das Verfahren zur Bestätigung der Einhaltung der Anforderungen an die Datensicherheit durch den Hersteller in Form einer Zertifizierung nach Technischer Richtlinie an. Die Entscheidung über die Aufnahme oder den Verbleib im Verzeichnis für digitale Gesundheitsanwendungen bzw. digitale Pflegeanwendungen werden durch das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) getroffen. Für Fragen zu Übergangsfristen wird daher auf das BfArM verwiesen.

Die Grundlage für das Prüfurteil ist ein dokumentiertes Risikomanagementverfahren. In die Risikobewertung fließen die im Produkt realisierten Schutzmaßnahmen und deren Effektivität mit ein. Ebenfalls werden Vorgaben für die sichere Nutzung berücksichtigt, sofern diese dem Nutzer ausreichend dargelegt sind. Ob ein Sicherheitsproblem durch die getroffenen Schutzmaßnahmen angemessen behandelt wird, schätzen die Prüfstellen anhand der Schwierigkeit der ermittelten Angriffspfade für den konkreten Einzelfall ein. Bei dieser Einschätzung fließen teilweise oder nicht erfüllte Prüfaspekte durch eine daraus resultierende Steigerung des ermittelten Restrisikos mit ein. Der Prüfer trifft basierend auf dem ermittelten Restrisiko der Gesamtanwendung sein Urteil. Die Entscheidung des Prüfers wird unter Berücksichtigung der Abwägungen des Herstellers vom Bundesamt für Sicherheit in der Informationstechnik geprüft und resultiert im Idealfall in einer erfolgreichen Zertifizierung. Ob die Nichterfüllung eines Prüfaspektes zum Ausschluss einer erfolgreichen Zertifizierung führt, hängt somit von der damit verbundenen Steigerung des Restrisikos für die Gesamtanwendung ab.

Eine Zertifizierung nach Technischer Richtlinie unterteilt sich im mehrere Phasen

1. Vorbereitungsphase

Die Vorbereitungsphase umfasst sämtliche Planungs-, Abstimmungs- und Auswahltätigkeiten, um die erforderlichen Voraussetzungen für die anschließende Durchführung der Konformitätsprüfung eines Produktes nach der Beantragung und Eröffnung eines Zertifizierungsverfahrens zu schaffen.

2. Prüfphase

Die Prüfphase umfasst die Konformitätsprüfung des zu zertifizierenden Produktes durch das beauftragte Prüflaboratorium gemäß dem abgestimmten Evaluierungsplan. Die im Rahmen der Konformitätsprüfung ermittelten Ergebnisse werden vom Prüflaboratorium in einem Prüfbericht dokumentiert, und von der Zertifizierungsstelle bewertet. Ist in dieser Phase eine Nachbesserung oder Überarbeitung des Prüfberichts erforderlich oder ist dieser unvollständig, erstellt die Zertifizierungsstelle eine entsprechende Kommentierung und fordert das Prüflaboratorium auf, eine korrigierte Fassung des Prüfberichts vorzulegen.

3. Zertifizierungsphase

In der Zertifizierungsphase wird die Zertifizierungsentscheidung gefällt. Sofern die Zertifizierungskriterien erfüllt sind, wird eine positive Entscheidung über die Zertifizierung getroffen und die Konformität des Produktes zu den festgelegten Anforderungen mit der Erteilung des beantragten Zertifikats wird bestätigt.

Eine negative Zertifizierungsentscheidung wird getroffen, wenn die Zertifizierungskriterien nicht erfüllt werden. Für eine erneute Überprüfung des Produktes muss dann ein neuer Antrag gestellt werden.

Für weiterführende Informationen zum Thema siehe PZS-TR Kapitel 3.5.

Die formale Gültigkeit eines Zertifikates für ein Produkt ist grundsätzlich auf fünf Jahre zeitlich befristet. Ein vom BSI erteiltes Zertifikat nach Technischen Richtlinien ist darüber hinaus ausschließlich für die im Rahmen der Konformitätsprüfung untersuchte Version eines Produkts gültig. Werden an einem zertifizierten IT-Produkt Änderungen vorgenommen, entstehen neue Versionen/Konfigurationen, für die das erteilte Zertifikat keine Gültigkeit besitzt. Insbesondere bei IT-Produkten, die über kurze Release-Zyklen verfügen oder häufig aktualisiert werden (Update/Patch/Hotfix/...), stellt eine hohe Anzahl an Versionsänderungen im Rahmen der Zertifizierung ein großes Problem dar (vgl. PZS-TR Kapitel 3.6.1).

Soll auch für die Änderung oder Weiterentwicklung eines zertifizierten Produktes die Konformität bestätigt werden, so kann beim BSI ein Antrag auf Rezertifizierung oder Maintenance gestellt werden.

• Bei Änderungen am Produkt, bei denen eine Auswirkung auf die TR-Konformität nicht ausgeschlossen werden kann, ist eine Re-Zertifizierung erforderlich (vgl. PZS-TR Kapitel 3.6.2).
• Bei Änderungen am Produkt, die eine Auswirkung auf die TR-Konformität eindeutig ausschließen, kann ein bestehendes Zertifikat auf die neue Produktversion erweitert werden (Maintenance). Über die Anwendbarkeit eines Maintenanceverfahrens entscheidet die Zertifizierungsstelle anhand der von der antragstellenden Organisation bereitzustellenden Änderungsdokumentation und Auswirkungsanalyse (vgl. PZS-TR Kapitel 3.6.3).

Die Kosten für eine Zertifizierung nach Technischer Richtlinie setzen sich aus zwei Komponenten zusammen.

• Die Kosten der neutralen Prüfstelle: Die Kosten der neutralen Prüfstelle werden von der Prüfstelle selber festgelegt und können je nach Prüfstelle, Abrechnungsmodell und Prüfgegenstand variieren. Für konkrete Angaben empfehlen wir Ihnen Kontakt mit der anerkannten Prüfstelle Ihrer Wahl aufzunehmen.
• Die Kosten des Bundesamt für Sicherheit in der Informationstechnik (BSI): Die Kosten des BSI für eine Zertifizierung nach Technischer Richtlinie werden über die jeweils gültige Fassung der "Besondere[n] Gebührenverordnung BMI – BMIBGebV" in Abschnitt 7 Nummer 1.3 geregelt.

Das BSI hat Verständnis für die besonderen Anforderungen an die Barrierefreiheit bei bestimmten Patientengruppen. Um diesen Anforderungen gerecht zu werden und gleichzeitig die Datensicherheit der Patienten, insbesondere bei der Verarbeitung von Gesundheitsdaten, angemessen zu schützen, wurde eine Möglichkeit zur Einwilligung in niederschwellige Verfahren geschaffen. Gemäß § 139e Abs. 10 SGB V haben Versicherte die Möglichkeit nach umfassender Information über die Besonderheiten des Verfahrens in die Nutzung eines Authentifizierungsverfahrens einzuwilligen, das einem niedrigeren Sicherheitsniveau entspricht. Diese Möglichkeit wird in der Technischen Richtlinie 03161-1 und 03161-2 durch die Anforderung O.Auth_4 im Rahmen der Zertifizierung eröffnet und einheitlich für das Gesundheitswesen in der „Spezifikation Sektoraler Identity Provider“ von der gematik in Zusammenarbeit mit der/dem Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) und dem Bundesamt für Sicherheit in der Informationstechnik (BSI) spezifiziert. Durch die Anbindung an die GesundheitsID werden z.B. Verfahren angeboten, die sich aus einer Gerätebindung und einem biometrischen Faktor zusammensetzen. So ist beispielsweise zur Nutzung der Anwendung aus Sicht des Patienten ausschließlich das Verwenden eines biometrischen Faktors erforderlich.

Durch die in diesem Jahr getroffene Einführung von § 393 SGB V wird die Nutzung von Cloud-Diensten im Gesundheitswesen gesetzlich lediglich nach erfolgreicher C5 Testierung genehmigt. Daher kann das BSI abweichend der gesetzlichen Regelung keinerlei Alternativen zustimmen. Für weitere Fragen bzgl. der rechtlichen Regelung zur Nutzung und Bereitstellung von Cloud-Systemen im Gesundheitswesen, verweist das BSI auf das Bundesministerium für Gesundheit (BMG).

Für eine erfolgreiche Zertifizierung ist es erforderlich eine Überprüfung aller Geltungsbereiche durchzuführen, die einen Einfluss auf die Gesamtsicherheit der Anwendung haben können. Die Technische Richtlinie 03161 (TR) unterteilt sich in drei Teile mit jeweils voneinander abgegrenzten Geltungsbereiche. Der erste Teil beschreibt die Sicherheitsanforderungen für mobile Gesundheitsanwendungen. Im zweiten Teil wird der Fokus auf Web-Anwendungen gelegt und der dritte Teil befasst sich mit Hintergrundsystemen.

Eine mobile Anwendung (App) ist beispielsweise grundsätzlich nach dem ersten Teil der TR zu prüfen. Verfügt die App über eine Anbindung an ein Hintergrundsystem, ist eine Aussage über die Gesamtsicherheit der App ohne Prüfung des Hintergrundsystems nicht möglich. Daher muss zusätzlich eine Prüfung nach dem dritten Teil der TR erfolgen. Verfügt die App darüber hinaus über ein Web-Frontend oder sicherheitsrelevante Funktionen, die über eine Web-Schnittstelle realisiert werden (z.B. einen Zugang für Administratoren oder eine Funktion zum zurücksetzen des Passwortes), ist ebenfalls eine Betrachtung des zweiten Teils der TR für eine Aussage über die Gesamtsicherheit erforderlich.

Der Zertifizierung von Anwendungen im Gesundheitswesen nach der Technischen Richtlinie BSI TR-03161 liegen Annahmen zu Grunde, die für die Zertifizierbarkeit der Produkte unerlässlich sind.

Eine dieser Annahmen ist A.Source, die besagt:

„Der Bezug der Anwendung und Ihrer Updates erfolgt ausschließlich über sichere Quellen, die der Hersteller zur Veröffentlichung seiner Anwendung bestimmt hat (z.B. App-Stores, herstellereigene Website, öffentliche Stellen wie zuständige Behörden und Krankenkassen). Die installierten Anwendungen werden regelmäßig auf Updates geprüft und aktualisiert.“

Im Rahmen der Produktprüfung kann das BSI die Bezugsquelle, die die jeweilige Nutzerin oder der jeweilige Nutzer der Anwendung gewählt hat, nicht prüfen. Aus diesem Grund gelten die Sicherheitsaussagen im Zuge der Produktzertifizierung nur unter der Voraussetzung, dass diese Annahme erfüllt ist.

Teile der Bezugsprozesse von digitalen Gesundheits- und Pflegeanwendungen sind im Kontext einer Produktzertifizierung nicht prüfbar. Sie fallen deshalb ebenfalls unter die Annahme A.Source und werden nicht durch das BSI bewertet. Zu diesen nicht prüfbaren Teilprozessen gehören die Verordnung und Einlösung eines Rezeptes für das Produkt über einen Rezeptcode, die direkte Beantragung einer DiGA bei ihrer Krankenkasse oder sonstige versorgungsbedingte Prozesse zum Erhalt des Produktes. 

Hieraus ergeben sich folgende Konsequenzen für die Zertifizierung einer digitalen Gesundheits- oder Pflegeanwendung:

• Die Abrechnungsprozesse zum Bezug einer digitalen Gesundheits- oder Pflegeanwendung werden in den Anforderungen des Kapitels 3.1.8 Prüfaspekt (8): Kostenpflichtige Ressourcen nicht berücksichtigt. Lediglich darüber hinausgehende kostenpflichtige Ressourcen, wie z.B. In-App-Käufe werden, sofern vorhanden, im Rahmen der Zertifizierung betrachtet.
• Innerhalb des Bezugsprozesses geleistete Regelungen mit dem Nutzer, wie beispielsweise das Tätigen von Einwilligungserklärungen, werden im Kontext der Produktzertifizierung nicht betrachtet. Sofern hieraus direkte oder indirekte Auswirkungen auf Prüfaspekte der Technischen Richtlinie entstehen, z.B. eine Einwilligung gemäß § 139e Abs.10 SGB V mit direkter Auswirkung auf O.Auth_1 und 4, muss der Hersteller diese im Rahmen einer Herstellererklärung gegenüber dem zuständigen Prüflabor offenlegen. Hierdurch wird das Prüflabor in die Lage versetzt, direkte Folgen aus der Herstellererklärung für das Produkt, z.B. die Möglichkeit zum Entziehen erteilter Einwilligungen gem. O.Purp_5, zu bewerten. Die Herstellererklärung selbst wird durch das Prüflabor ausschließlich auf Plausibilität geprüft.

Die Notwendigkeit der Implementierung von gegenseitiger Authentisierung jeglicher Netzwerkkommunikation, die sich aus BSI TR-03161-1 O.Ntwk_1 bzw. BSI TR-03161-2 O.Ntwk_1 ergibt, wird für den weiteren Verlauf der Zertifizierung aufgehoben. Eine Implementierung von TLS gemäß den Anforderungen aus BSI TR-03161-1 O.Ntwk_2 bzw. BSI TR-03161-2 O.Ntwk_2 ist ausreichend.

Zu TR-03161-3 O.Cryp_8: Ergänzend zu den in Kapitel 3.3 der TR-02102-2 definierten Empfehlungen für die Nutzung von TLS 1.2, wird O.Cryp_8 ebenfalls durch die in Kapitel 3.4 der TR-02102-2 beschriebenen Empfehlungen für die Nutzung von TLS 1.3 erfüllt.

Für die Gültigkeit von Authentisierungsverfahren für Anwendungen im Gesundheitswesen wird gemäß § 139e Abs. 10 SGB V zwischen „geeignet sichere[n]“ Authentisierungsverfahren und Authentisierungsverfahren mit „einem niedrigeren Schutzniveau“ unterschieden. Unter Berücksichtigung des Schutzbedarfs von Gesundheitsdaten (vgl. Frage 13) ergibt sich daraus die folgende Übersichtstabelle. Die Tabelle erhebt keinen Anspruch auf Vollständigkeit sondern bildet lediglich die am häufigsten nachgefragten Verfahren beim BSI ab.

* unter Berücksichtigung der technischen Rahmenbedingungen aus Kapitel 4.3.2 der "Spezifikation Sektoraler Identity Provider" der gematik GmbH

Für eine gültige Zwei-Faktor-Authentisierung müssen die beiden Faktoren unterschiedlichen Kategorien (Wissen, Besitz und Inhärenz) angehören.

Für eine Bewertung des Schutzbedarfs für digitale Gesundheitsanwendungen im Kontext der TR-03161 bedarf es zunächst einer Definition von Gesundheitsdaten. Nach Abstimmung mit der Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI) kommt das BSI hierbei zu folgender Einschätzung. 

Was sind Gesundheitsdaten?

Hierzu orientiert sich das BSI an der Legaldefinition in Art. 4 Abs. 15 DSGVO:

"Gesundheitsdaten" (sind) personenbezogene Daten, die sich auf die körperliche oder geistige Gesundheit einer natürlichen Person, einschließlich der Erbringung von Gesundheitsdienstleistungen, beziehen und aus denen Informationen über deren Gesundheitszustand hervorgehen.

Im Erwägungsgrund 35 der DSGVO heißt es hierzu:

Zu den personenbezogenen Gesundheitsdaten sollten alle Daten zählen, die sich auf den Gesundheitszustand einer betroffenen Person beziehen und aus denen Informationen über den früheren, gegenwärtigen und künftigen körperlichen oder geistigen Gesundheitszustand der betroffenen Person hervorgehen. Dazu gehören auch Informationen über die natürliche Person, die im Zuge der Anmeldung für sowie der Erbringung von Gesundheitsdienstleistungen im Sinne der Richtlinie 2011/24/EU des Europäischen Parlaments und des Rates für die natürliche Person erhoben werden, Nummern, Symbole oder Kennzeichen, die einer natürlichen Person zugeteilt wurden, um diese natürliche Person für gesundheitliche Zwecke eindeutig zu identifizieren, Informationen, die von der Prüfung oder Untersuchung eines Körperteils oder einer körpereigenen Substanz, auch aus genetischen Daten und biologischen Proben, abgeleitet wurden, und Informationen etwa über Krankheiten, Behinderungen, Krankheitsrisiken, Vorerkrankungen, klinische Behandlungen oder den physiologischen oder biomedizinischen Zustand der betroffenen Person unabhängig von der Herkunft der Daten, ob sie nun von einem Arzt oder sonstigem Angehörigen eines Gesundheitsberufes, einem Krankenhaus, einem Medizinprodukt oder einem In-Vitro-Diagnostikum stammen.

Vor dem Hintergrund des weiten Wortlauts von Art. 4 Abs. 15 DSGVO und den Ausführungen in Erwägungsgrund 35 kommt die Literatur zu einem grundsätzlich weiten Begriffsverständnis und versteht den Begriff "Gesundheitsdaten" so, dass letztlich alle Informationen erfasst werden, welche die körperliche wie psychische Gesundheit einer Person betreffen.

Wie hoch ist der Schutzbedarf von Gesundheitsdaten?

Für Gesundheitsdaten nach Art. 4 Abs. 15 DSGVO gibt es keine ausdrückliche Regelung zum Schutzbedarf. 

Die DSGVO qualifiziert Gesundheitsdaten als sehr sensible Daten, die einen besonderen Schutzbedarf haben. So sieht Art. 9 Abs. 1 DSGVO ein grundsätzliches Verarbeitungsverbot vor. Eine Datenverarbeitung ist datenschutzrechtlich somit nur zulässig, wenn die Voraussetzungen von Art. 9 Abs. 2 bzw. Abs. 3 DSGVO erfüllt sind. Darüber hinaus sind die allgemeinen Anforderungen an die Rechtmäßigkeit der Datenverarbeitung nach Art. 6 DSGVO zu beachten. Hieraus lässt sich ableiten, dass der Schutzbedarf grundsätzlich als hoch bis sehr hoch anzusehen ist. Die konkrete Klassifizierung des Schutzbedarfes (hoch oder sehr hoch) ist dann eine Frage des Einzelfalls.

Das Logging von sensiblen Daten widerspricht der Anforderung O.Source_3. Vor diesem Hintergrund ist entscheidend, welche Informationen die zu loggenden Daten, z.B. die UserID, bereitstellen. Sollten diese direkten Aufschluss auf die natürliche Person des Users bieten, bspw. sofern MaxMustermann19700101 als UserID verwendet wird, ist sie als sensibler Datenwert zu betrachten und entsprechend nicht zu loggen. In diesem Fall ist ein Logging pseudonymisierter UserIDs als konform zu der Technischen Richtlinie zu betrachten. Bestenfalls ist die UserID durch einen randomisierten alphanumerischen Code umgesetzt, welcher nicht alleinig für den Zugriff auf sensible Daten verwendet werden kann.

Sofern die Informationen in einem Token nicht alleinig zur Identifizierung des Users durch Dritte genutzt werden können und ein Autorisierungsversuch mit diesen Informationen fehlschlagen würde, kann ein solches Token geloggt werden. Andernfalls sind die sensitiven Informationen im Token vor dem Loggen zu entfernen.