Was ist medizinische Software?

Medizinische Software ist eine digitale Anwendung, die zu diagnostischen, therapeutischen, präventiven oder überwachenden Zwecken im Gesundheitswesen eingesetzt wird. Sie unterstützt medizinisches Personal bei Entscheidungen, automatisiert Prozesse und trägt zur Patientenüberwachung bei. Entscheidend ist dabei nicht die technische Ausgestaltung, sondern der medizinische Zweck der Anwendung.

Software gilt als medizinisch, wenn sie direkt oder indirekt Einfluss auf die Gesundheit eines Menschen nimmt – etwa durch die Analyse von Vitaldaten, die Unterstützung bei Diagnosen oder die Steuerung medizinischer Geräte. Nur Software mit einer klaren medizinischen Zweckbestimmung fällt unter die europäische Medizinprodukteverordnung (MDR) und unterliegt somit strengen regulatorischen Anforderungen.

Medizinische Software kann entweder eigenständig als App oder webbasiertes Programm auftreten oder als integrierter Bestandteil eines physischen Medizinprodukts fungieren, beispielsweise in bildgebenden Medizingeräten oder Infusionsgeräten. Ihre Funktionen reichen von der Erfassung und Auswertung klinischer Daten bis hin zur Unterstützung komplexer Therapieentscheidungen.

Kurz gesagt: Medizinische Software ist jede Software, die zur Diagnose, Behandlung, Überwachung oder Verbesserung der Gesundheit entwickelt wurde und damit aktiv zur Digitalisierung des Gesundheitswesens beiträgt.

Welche Arten von medizinischer Software gibt es?

• Diagnostische Software: Dient der Erkennung und Analyse von Krankheitsbildern.
  • Beispiele: Programme zur Auswertung bildgebender Verfahren; Algorithmen zur Analyse von Laborwerten.
• Therapeutische Software: Unterstützt oder steuert Behandlungen.
  • Beispiele: Dosiskalkulationen; Therapieplanungssoftware; Systeme zur Medikamentenabgabe.
• Überwachungssoftware: Erfasst und bewertet kontinuierlich Patientendaten, etwa Herzfrequenz oder Sauerstoffsättigung, und erkennt Abweichungen automatisch.
• Präventive Software: Ermöglicht die Früherkennung von Erkrankungen oder bewertet Risikofaktoren zur Gesundheitsförderung.
• Administrative und dokumentationsbezogene Software: Organisiert Abläufe, unterstützt das Personal und verbessert die Datenverwaltung im Gesundheitswesen.
  • Praxisverwaltungssysteme (PVS): Automatisieren administrative Prozesse wie Terminplanung, Abrechnung, Patientendatenverwaltung und Rezeptausstellung; in der Regel keine Medizinprodukte, können aber bei Schnittstellen zu medizinischen Funktionen regulatorische Relevanz erlangen.
  • Krankenhausinformationssysteme (KIS): Integrieren klinische, administrative und logistische Prozesse im Krankenhaus; verwalten Patientendaten zentral und ermöglichen effiziente Kommunikation; gelten als Medizinprodukt, wenn sie medizinische Entscheidungen beeinflussen.
  • Radiologie- und Bildgebungssoftware (PACS/RIS): Dienen der Verwaltung, Archivierung und Auswertung medizinischer Bilddaten; unterstützen Radiologen bei Diagnose und Befundung; meist als Medizinprodukte klassifiziert.
  • Software für elektronische Gesundheitsakten (EGA/EPA): Speichern und stellen medizinische Informationen strukturiert bereit; ermöglichen sicheren Datenaustausch zwischen Ärzten, Krankenhäusern und Patienten; meist keine Medizinprodukte, können aber Schnittstellen zu solchen haben.
  • Medizinische Apps und mobile Anwendungen: Eigenständige Softwareprodukte auf mobilen Endgeräten; reichen von Tagebuch-Apps bis zu komplexen Diagnose- oder Therapieunterstützungssystemen; gelten als Medizinprodukte, wenn sie einen medizinischen Nutzen im Sinne der MDR haben.
  • Künstliche Intelligenz in Diagnostik und Therapie: Analysiert große Datenmengen, erkennt Muster und unterstützt medizinische Entscheidungen; Beispiele: Tumorerkennung in radiologischen Bildern, Prognosemodelle für Krankheitsverläufe; unterliegt strengen regulatorischen Anforderungen.
  • Software zur Medizingerätesteuerung: Steuert oder überwacht die Funktion physischer Medizinprodukte wie Beatmungsgeräte, Insulinpumpen oder bildgebende Systeme; integraler Bestandteil des Geräts und gemeinsam mit diesem zuzulassen.
  • Software zur medizinischen Dokumentation: Erfasst, verwaltet und archiviert medizinische Daten strukturiert; gewährleistet Nachvollziehbarkeit und rechtssichere Aufzeichnung; kann als Medizinprodukt gelten, wenn sie Diagnosen oder Therapien unterstützt.
  • Dosismanagementsysteme (DMS): Überwachen und dokumentieren patienten- und untersuchungsspezifische Strahlendosen (z. B. DICOM-RDSR), generieren Berichte und Warnungen, unterstützen Optimierung und Compliance; häufig als Medizinprodukt eingestuft.
  • Digitale Anamnese-Software: Ermöglicht die strukturierte Erfassung medizinisch relevanter Patientendaten vor dem Arztkontakt; verbessert Vorbereitung, Effizienz und Dokumentationsqualität; kann regulatorisch relevant sein, wenn Daten diagnostisch oder therapeutisch genutzt werden.
  • Videosprechstunden-Software: Unterstützt die telemedizinische Kommunikation zwischen Arzt und Patient; dient der Fernbehandlung und Dokumentation; kann als Medizinprodukt gelten, wenn diagnostische oder therapeutische Funktionen integriert sind.

Wie funktioniert medizinische Software in der Praxis?

Medizinische Software erfasst, verarbeitet und stellt Gesundheitsdaten strukturiert bereit. Sie fungiert als Bindeglied zwischen Patient, Fachpersonal und technischer Infrastruktur. Ziel ist die Unterstützung medizinischer Entscheidungen, die Automatisierung von Prozessen und die Verbesserung der Versorgungsqualität.

Die Software sammelt Daten aus Patientenakten, Laboren, Bildgebung oder Sensoren – manuell oder automatisiert. Sie verarbeitet strukturierte (z. B. Messwerte) und unstrukturierte Daten (z. B. Texte, Bilder) mithilfe von Algorithmen oder KI, um Muster zu erkennen und Entscheidungshilfen zu generieren. Hohe Datenqualität wird durch Validierung und Plausibilitätsprüfungen gewährleistet. Datenschutz und IT-Sicherheit erfolgen nach DSGVO und ISO 27799.

Über Standards wie HL7, DICOM, FHIR oder sonoGDT kommuniziert die Software mit Geräten und Systemen, um Daten auszutauschen oder Geräte zu steuern. Offene Schnittstellen ermöglichen Interoperabilität und vermeiden Medienbrüche. Bei direkter Gerätesteuerung gelten strenge regulatorische Vorgaben zum Schutz der Patientensicherheit.

Für den klinischen Einsatz muss sich die Software nahtlos in KIS, PVS oder EPA einfügen. Erforderlich sind abgestimmte Schnittstellen, Sicherheitskonzepte und Benutzerrechte. Netzwerksicherheit wird durch Firewalls, Zugriffskontrollen und Verschlüsselung gewährleistet. Intuitive Oberflächen und angepasste Workflows fördern Akzeptanz und reduzieren Fehlbedienungen.

Wie wird medizinische Software reguliert?

Die Regulierung medizinischer Software soll sicherstellen, dass Produkte, die in Diagnostik, Therapie oder Überwachung eingesetzt werden, sicher, leistungsfähig und qualitativ hochwertig sind. Da Software unmittelbaren Einfluss auf medizinische Entscheidungen haben kann, unterliegt sie denselben rechtlichen Anforderungen wie physische Medizinprodukte. In der Europäischen Union bildet die Medical Device Regulation (MDR, Verordnung (EU) 2017/745) den maßgeblichen Rechtsrahmen.

Wann gilt Software als Medizinprodukt?

Ob Software als Medizinprodukt (Software as Medical Device, SaMD) gilt, richtet sich nach ihrer medizinischen Zweckbestimmung, die der Hersteller festlegt. Entscheidend ist also nicht die technische Funktion, sondern der beabsichtigte medizinische Nutzen.

Gemäß Erwägungsgrund (19) und Artikel 2 der MDR gilt Software als Medizinprodukt, wenn sie speziell für einen oder mehrere der folgenden medizinischen Zwecke bestimmt ist:

• Diagnose, Überwachung, Vorhersage, Prognose, Behandlung oder Linderung von Krankheiten,
• Untersuchung, Ersatz oder Veränderung der Anatomie oder eines physiologischen Prozesses,
• Bereitstellung von Informationen, die zur Entscheidungsfindung in medizinischen Kontexten verwendet werden.
  

Damit unterliegt Software denselben Anforderungen wie klassische Medizinprodukte, sobald sie aktiv in medizinische Entscheidungsprozesse eingreift oder diese unterstützt.

Hinweis: Die Leitlinie MDCG 2019-11 stellt klar, dass eine Software nur dann als Medical Device Software (MDSW) gilt, wenn sie selbst einen medizinischen Zweck erfüllt. Die nachfolgende Leitlinie MDCG 2021-24 präzisiert, dass Software, die ausschließlich Informationen aufzeichnet, speichert oder anzeigt, in der Regel nicht als Medizinprodukt einzustufen ist – es sei denn, sie analysiert diese Daten oder beeinflusst eine Behandlung, Dosierung oder Verschreibung (Quelle: MDCG 2019-11; MDCG 2021-24; VDE Wenner, 2023).

Medical Device Software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a medical device in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device

(MDCG 2019-11)

Keine Medizinprodukte im Sinne der MDR sind daher:

• Softwarelösungen für allgemeine oder administrative Zwecke (z. B. Online-Terminkalender-Software, Abrechnungssoftware oder Praxisbuchhaltung-Software),
• Anwendungen mit Lifestyle- oder Wellness-Zielsetzung, wie Fitness- oder Aktivitätstracker,
• Softwarelösungen, die Patientendaten nur speichert oder überträgt, ohne sie medizinisch auszuwerten.
  

Die Einstufung ist orts- und technologieunabhängig: Entscheidend ist allein, ob die Software nach ihrer Zweckbestimmung einen medizinischen Zweck erfüllt. Auch cloudbasierte, mobile oder KI-gestützte Anwendungen können unter die MDR fallen, wenn sie diagnostische oder therapeutische Aussagen ermöglichen oder unterstützen.

Risikoklassifizierung: Regel 11 der MDR

Die MDR unterscheidet vier Risikoklassen (I, IIa, IIb, III), abhängig vom potenziellen Risiko für Patienten und Anwender. Für Software gilt dabei Regel 11 des Anhangs VIII, die in der Praxis als besonders anspruchsvoll gilt (Quelle: VDE Wenner, 2023).

• Klasse I: Software, die keine Informationen für diagnostische oder therapeutische Entscheidungen liefert (z. B. reine Verwaltungssoftware).
• Klasse IIa: Software, die Informationen bereitstellt, die zur Entscheidungsfindung für Diagnose oder Therapie genutzt werden.
• Klasse IIb: Software, deren Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder chirurgische Eingriffe verursachen können.
• Klasse III: Software, deren Entscheidungen zum Tod oder zu einer irreversiblen Verschlechterung des Gesundheitszustands führen können.
  

Hinweis: Die Regel 11 wird kontrovers diskutiert, da sie in der praktischen Anwendung Interpretationsspielraum lässt. So ist es grundsätzlich möglich, eine Software in Klasse I einzuordnen, wenn sie nachweislich keine Informationen für diagnostische oder therapeutische Entscheidungen liefert und keine physiologischen Prozesse kontrolliert.

Allerdings weist der VDE darauf hin, dass eine derart formulierte Zweckbestimmung in der Praxis nur dann wirksam ist, wenn sie objektiv und funktional durch die tatsächlichen Eigenschaften der Software gedeckt ist. Eine bloße textliche Einschränkung in der Zweckbestimmung („Diese Software liefert keine Informationen zur diagnostischen Entscheidungsfindung“) kann als unzulässig gelten, wenn die reale Nutzung diese Aussage widerlegt (Quelle: VDE Wenner, 2023).

Hinweis: Wird eine Software in der praktischen Nutzung dennoch zur Entscheidungsfindung herangezogen – etwa wenn ein Arzt aus ihren Ergebnissen Therapieanpassungen vornimmt –, kann eine ursprünglich als Klasse I eingestufte Anwendung nachträglich als Klasse IIa gelten. Das hätte unmittelbare regulatorische Konsequenzen bis hin zur Marktentfernung oder Anpassung des CE-Zertifikats (Quelle: VDE Wenner, 2023).

Konformitätsbewertung und CE-Kennzeichnung

Vor dem Inverkehrbringen muss der Hersteller eine Konformitätsbewertung durchführen, um nachzuweisen, dass die Software die grundlegenden Sicherheits- und Leistungsanforderungen der MDR erfüllt.

• Klasse I: Selbstzertifizierung durch den Hersteller ist möglich.
• Ab Klasse IIa: Einbindung einer Benannten Stelle (Notified Body) erforderlich, die technische Dokumentation und Qualitätsmanagementsystem prüft.
  

Nach erfolgreicher Bewertung wird die CE-Kennzeichnung vergeben, die die Konformität mit der MDR bestätigt und das Inverkehrbringen in der gesamten EU erlaubt (Quelle: MDR, Art. 51 i. V. m. Anhang VIII).

Hinweis: Die Wahl des Konformitätsbewertungsverfahrens hängt unmittelbar von der korrekten Klassifizierung ab. Eine unzutreffende Klassifizierung – etwa durch eine „willkürlich“ formulierte Zweckbestimmung – kann dazu führen, dass das Produkt zu Unrecht CE-gekennzeichnet ist und vom Markt genommen werden muss (Quelle: VDE Wenner, 2023).

Qualitäts- und Risikomanagement

Die MDR verpflichtet Hersteller zu einem umfassenden Qualitätsmanagementsystem (QMS) und systematischem Risikomanagement über den gesamten Lebenszyklus des Produkts (MDR, Art. 10 und Anhang I).

Dazu gehören:

• Planung, Entwicklung und Dokumentation der Software,
• Identifikation und Bewertung von Risiken,
• Umsetzung von Risikominderungsmaßnahmen,
• fortlaufende Bewertung im Rahmen der Post-Market Surveillance (PMS).
  

In der Praxis erfolgt die Umsetzung meist gemäß den harmonisierten Normen ISO 13485 (Qualitätsmanagement) und ISO 14971 (Risikomanagement). Die ergänzende Norm IEC 81001-5-1 beschreibt, wie Cybersecurity im Software-Lebenszyklus zu berücksichtigen ist – von der Softwareentwicklung über Wartung bis zum Rückzug des Produkts.

Software-spezifische Normen und Leitlinien

Zur Konkretisierung der MDR-Anforderungen werden für Software insbesondere folgende technische Normen herangezogen:

• IEC 62304: Software-Lebenszyklus für Medizinprodukte (Entwicklung, Wartung, Validierung),
• IEC 82304-1: Anforderungen an eigenständige Gesundheitssoftware,
  • Anforderungen an die Produktsicherheit (Safety), die Informationssicherheit (Security), die Benutzerfreundlichkeit (Usability) und die Gebrauchsanweisung (Instruction for use)
• ISO 14971: Risikomanagementverfahren,
• ISO/IEC 27001 und ISO 27799: Informationssicherheit und Datenschutz im Gesundheitswesen.
  

Diese Normen sind nicht Teil der MDR selbst, werden jedoch von Benannten Stellen als Konformitätsnachweis anerkannt (Quelle: MDR, Anhang I; VDE Wenner, 2023).

Die IEC 62304 beschreibt die Entwicklung und Wartung von Medizinprodukte-Software und richtet sich vor allem an eingebettete Systeme (embedded software). Die IEC 82304-1 erweitert diesen Rahmen auf eigenständige Health Software Products, die der Gesundheitsförderung dienen – unabhängig vom MDR-Status (Quelle: IEC 82304-1, 2024).

Sie schließt die Validierungslücke der IEC 62304 und definiert Anforderungen an Produktqualität, Sicherheit, Dokumentation und das Management des gesamten Lebenszyklus. Hersteller müssen Nutzer, Nutzungskontexte und Risiken definieren, die Validierung unabhängig durchführen und vollständige Begleitdokumente bereitstellen. Änderungen nach der Markteinführung sind systematisch zu bewerten.

Die IEC 82304-1 gilt als Stand der Technik auch für nicht MDR-pflichtige Gesundheitssoftware und wird zunehmend von Auditoren herangezogen (Quelle: VDE Wenner, 2023). Zusammen mit der IEC 62304 bildet sie ein komplementäres Regelwerk: Die IEC 62304 legt Prozessanforderungen fest, die IEC 82304-1 ergänzt diese um Produkt- und Validierungsanforderungen zur Sicherstellung von Sicherheit, Qualität und Zweckbestimmung (Quelle: IEC 82304-1, 2024; VDE Wenner, 2023).

Aufsicht und Marktüberwachung

Nach der Markteinführung unterliegt medizinische Software der Marktüberwachung und Vigilanz gemäß den Artikeln 83 bis 100 MDR. Hersteller müssen:

• ein System zur Überwachung nach dem Inverkehrbringen betreiben,
• Vigilanzmeldungen bei schwerwiegenden Vorkommnissen einreichen,
• Korrekturmaßnahmen dokumentieren und bewerten.
  

In Deutschland obliegt die Aufsicht dem Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM), das Sicherheitsberichte prüft, Rückrufmaßnahmen koordiniert und die Risikominimierung überwacht.

Neben den behördlichen Kontrollmechanismen fördern auch Brancheninitiativen wie der Qualitätsring Medizinische Software (QMS e. V.) die Qualitätssicherung medizinischer Software durch praxisnahe Leitfäden, Erfahrungsaustausch und Schulungen zur MDR-konformen Entwicklung.

Datenschutz und nationale Gesetze (DSGVO, BDSG)

Medizinische Software unterliegt aufgrund der Verarbeitung sensibler Gesundheitsdaten besonders strengen Datenschutzanforderungen. Maßgeblich sind hierbei die Datenschutz-Grundverordnung (DSGVO) und das Bundesdatenschutzgesetz (BDSG).

• Rechtsgrundlage der Verarbeitung: Die Verarbeitung besonderer Kategorien personenbezogener Daten – darunter Gesundheitsdaten – ist grundsätzlich untersagt. Sie ist nur zulässig, wenn die betroffene Person ausdrücklich eingewilligt hat oder eine gesetzliche Grundlage besteht (Art. 9 Abs. 2 a DSGVO, § 48 BDSG). Diese Einwilligung muss freiwillig, eindeutig, informiert und widerrufbar sein (Art. 7 DSGVO).
• Grundsätze der Datenverarbeitung: Nach Art. 5 DSGVO und § 47 BDSG gelten folgende Grundprinzipien:
  • Rechtmäßigkeit und Transparenz: Verarbeitung personenbezogener Daten nur auf rechtmäßige Weise und in nachvollziehbarer Form.
  • Zweckbindung: Erhebung nur für festgelegte und legitime Zwecke; eine zweckfremde Weiterverarbeitung ist unzulässig.
  • Datenminimierung: Es dürfen nur Daten erhoben werden, die für den jeweiligen Zweck erforderlich sind.
  • Richtigkeit: Daten müssen sachlich korrekt und aktuell sein.
  • Speicherbegrenzung: Daten dürfen nur so lange gespeichert werden, wie es für den Zweck erforderlich ist.
  • Integrität und Vertraulichkeit: Schutz vor unbefugtem Zugriff und Datenverlust durch geeignete technische und organisatorische Maßnahmen (TOM).
• Technische und organisatorische Maßnahmen (TOM): Nach Art. 32 DSGVO und § 71 BDSG sind Verantwortliche verpflichtet, ein dem Risiko angemessenes Schutzniveau sicherzustellen. Dazu gehören insbesondere:
  • Zugriffsbeschränkungen: Kontrolle, wer Zugriff auf personenbezogene Daten hat.
  • Verschlüsselung und Pseudonymisierung: Schutz sensibler Informationen vor unbefugtem Zugriff.
  • Datenschutz durch Technikgestaltung: Systeme müssen so entwickelt werden, dass Datenschutzgrundsätze wie Datensparsamkeit bereits in der Softwarearchitektur verankert sind.
  • Regelmäßige Überprüfung: Effektivität der Schutzmaßnahmen ist fortlaufend zu evaluieren (Art. 25 und 32 DSGVO).
• Datenschutz-Folgenabschätzung: Wenn eine Software ein hohes Risiko für die Rechte und Freiheiten Betroffener mit sich bringt, ist eine Datenschutz-Folgenabschätzung erforderlich (Art. 35 DSGVO).
• Pflicht zur Benennung eines Datenschutzbeauftragten: Gemäß Art. 37 DSGVO und § 38 BDSG muss ein Datenschutzbeauftragter bestellt werden, wenn regelmäßig Gesundheitsdaten verarbeitet oder mehr als 20 Personen mit automatisierter Datenverarbeitung beschäftigt sind.

IT-Sicherheit

Die Regulierung medizinischer Software folgt einem zweistufigen Modell aus EU-weiter Cybersicherheitsrichtlinie (NIS-Richtlinie 2016/1148) und deren nationaler Umsetzung im BSI-Gesetz. Dadurch wird sichergestellt, dass medizinische Software sowohl technisch sicher als auch organisatorisch abgesichert betrieben wird – insbesondere, wenn sie in kritischen Infrastrukturen des Gesundheitswesens eingesetzt wird.

Die Richtlinie über Maßnahmen zur Gewährleistung eines hohen gemeinsamen Sicherheitsniveaus von Netz- und Informationssystemen in der Union verpflichtet Betreiber wesentlicher Dienste und Anbieter digitaler Dienste zu umfassenden Sicherheitsmaßnahmen.

• Ziel: Schutz der Netz- und Informationssysteme, die für essenzielle gesellschaftliche und wirtschaftliche Tätigkeiten erforderlich sind.
• Pflichten: Einführung geeigneter technischer und organisatorischer Maßnahmen zur Vermeidung und Bewältigung von Sicherheitsvorfällen sowie Meldepflichten gegenüber den zuständigen Behörden.
• Relevanz für Medizin-Software: Software, die in Krankenhäusern, Laboren oder im Gesundheitswesen eingesetzt wird, gilt oft als Teil kritischer Infrastrukturen und unterliegt damit diesen Sicherheitsanforderungen.
  

Das BSIG setzt die europäische NIS-Richtlinie in nationales Recht um und legt konkrete Anforderungen für den IT-Sicherheitsstandard in kritischen Infrastrukturen und digitalen Diensten fest.

• Zuständige Behörde: Das Bundesamt für Sicherheit in der Informationstechnik (BSI) fungiert als zentrale Meldestelle und Aufsichtsbehörde (§§ 4–8b BSIG).
• Sicherheitsanforderungen: Betreiber kritischer Infrastrukturen – darunter auch Gesundheitseinrichtungen – müssen nach § 8a BSIG angemessene organisatorische und technische Schutzmaßnahmen treffen, um Netz- und Informationssysteme vor Angriffen zu schützen.
• Zertifizierung: Das BSI kann nach § 9 BSIG IT-Produkte zertifizieren, die bestimmte Sicherheitsstandards erfüllen. Softwareprodukte, die im medizinischen Bereich eingesetzt werden, können damit ein freiwilliges IT-Sicherheitskennzeichen (§ 9c BSIG) erhalten.
• Meldepflichten: Sicherheitsvorfälle müssen dem BSI unverzüglich gemeldet werden, um die Funktionsfähigkeit kritischer Systeme sicherzustellen (§ 8b Abs. 4 BSIG).
  

Hersteller und Betreiber sind verpflichtet, Sicherheitskonzepte umzusetzen, die den Stand der Technik widerspiegeln. Dazu gehören Maßnahmen wie Zugriffsbeschränkungen, Verschlüsselung, Angriffserkennungssysteme und Notfallmanagement. Verstöße gegen Sicherheitsanforderungen können gemäß § 14 BSIG mit erheblichen Bußgeldern geahndet werden.

Anforderungen der Kassenärztlichen Vereinigungen (KV)

Medizinische Software in vertragsärztlichen Praxen unterliegt den Vorgaben der Kassenärztlichen Vereinigungen (KV) und der Kassenärztlichen Bundesvereinigung (KBV). Diese regeln Zulassung, Interoperabilität und IT-Sicherheit nach § 390 SGB V.

Zulassung und Zertifizierung: Praxisverwaltungssysteme und weitere Anwendungen benötigen eine KBV-Zulassung, um für Abrechnung, Dokumentation und Kommunikation eingesetzt werden zu dürfen.

Schnittstellenanforderungen: Software muss standardisierte Formate wie KIM und FHIR unterstützen und vollständig mit der Telematikinfrastruktur (TI) kompatibel sein. Authentifizierung, Datenübertragung und TI-Komponenten sind nach gematik-Vorgaben abzusichern.

IT-Sicherheitsrichtlinie: Die KBV verpflichtet Praxen zur Umsetzung technischer und organisatorischer Schutzmaßnahmen. Zentrale Punkte sind Passwortschutz, Netztrennung, regelmäßige Datensicherung, Zugriffskontrolle, Patch-Management und sichere E-Mail- sowie Cloud-Nutzung (C5-Testat gemäß § 393 SGB V). Anforderungen gelten abgestuft nach Praxisgröße und umfassen auch Schulungspflichten für Personal.

Aktualisierungspflicht: Systeme müssen fortlaufend gepflegt, sicherheitsrelevante Updates zeitnah installiert und Maßnahmen jährlich evaluiert werden. Neue Anforderungen, etwa zu Cloud- und E-Mail-Sicherheit, treten zum 1. Oktober 2025 in Kraft.

Wie sicher ist medizinische Software gegen Cyberangriffe?

Mit der wachsenden Vernetzung im Gesundheitswesen steigt das Risiko gezielter Cyberangriffe. Gesundheitsdaten gehören nach der EU-Datenschutz-Grundverordnung (DSGVO, Art. 9) zu den sensibelsten Informationen. Ein Ausfall oder eine Manipulation medizinischer Software kann die Patientenversorgung unmittelbar gefährden.

Bedrohungslage: Cyberangriffe auf Arztpraxen und Krankenhäuser nehmen stark zu. Neben Ransomware, Phishing und Angriffen auf unsichere Schnittstellen gefährden vor allem veraltete Systeme, ungetrennte Netzwerke und Social Engineering die IT-Sicherheit. Laut BSI setzen nur rund ein Drittel der befragten Praxen die IT-Sicherheitsrichtlinie nach § 75b SGB V vollständig um; etwa zehn Prozent waren bereits von Sicherheitsvorfällen betroffen (Quelle: BSI, 2024). Häufig fehlen Back-ups, Festplattenverschlüsselungen und ein professionelles Patchmanagement. Besonders problematisch ist der Parallelbetrieb von TI-Konnektoren mit herkömmlichen Routern. Das BSI empfiehlt den Einsatz von Informationssicherheitsbeauftragten und betont, dass viele Mängel mit geringem Aufwand behebbar sind. Cyberangriffe gefährden die Verfügbarkeit, Integrität und Vertraulichkeit medizinischer Daten und damit unmittelbar die Patientensicherheit.

Rechtlicher Rahmen: Die europäische Medizinprodukteverordnung (MDR 2017/745) verpflichtet Hersteller, Cyberrisiken über den gesamten Produktlebenszyklus zu berücksichtigen. Das umfasst Softwareentwicklung, Betrieb, Wartung und Außerbetriebnahme. Ergänzende Leitlinien wie MDCG 2019-16 und die EU-Verordnung 2024/1860 konkretisieren Anforderungen an Authentifizierung, Patch-Management und Schwachstellenüberwachung.

Für Betreiber gelten zusätzlich das IT-Sicherheitsgesetz 2.0 und die NIS-2-Richtlinie (EU 2022/2555), die Meldepflichten und Sicherheitsstandards für kritische Infrastrukturen – etwa Kliniken oder Labore – festlegen.

Relevante Normen: Internationale Standards helfen bei der technischen Umsetzung:

• ISO 14971: Risikomanagement für Medizinprodukte.
• IEC 62304 / 81001-5-1: Software-Lebenszyklus mit Fokus auf Sicherheit.
• IEC 60601-4-5: IT-Sicherheitsanforderungen für vernetzte Geräte.
• IEC 62443: Sichere Produktentwicklung („Secure Development Lifecycle“).
• ISO/IEC 27001 und 27799: Informationssicherheitsmanagement im Gesundheitswesen.
• BSI TR-03161: Nationale technische Richtlinie für Anwendungen im Gesundheitswesen (relevant für DiGA).
  

Wichtige Schutzmaßnahmen: Cybersecurity beginnt bei der Entwicklung („Secure by Design“) und setzt sich im Betrieb fort:

• Zugriffsschutz durch starke Authentifizierung und Rollenmanagement.
• Verschlüsselung sensibler Daten im Speicher und bei Übertragung.
• Regelmäßige Updates und Schwachstellen-Monitoring.
• Protokollierung und Monitoring zur Früherkennung von Angriffen.
• Notfall- und Wiederanlaufpläne zur Sicherung der Verfügbarkeit.
• Schulung des Personals, da Menschen oft das schwächste Glied der Sicherheitskette sind.

Hersteller müssen sicherstellen, dass personenbezogene Daten nur rechtmäßig verarbeitet werden. „Privacy by Design und Default“ bedeutet, dass Datenschutz bereits in der Systemarchitektur und in den Standardeinstellungen integriert ist. So werden Vertraulichkeit, Integrität und Verfügbarkeit der Daten gewährleistet.

FAQ

Weitere Quellen

• https://www.vde.com/topics-de/health/beratung/regel-11
• https://www.johner-institut.de/blog/regulatory-affairs/it-sicherheit-im-gesundheitswesen/
• https://www.johner-institut.de/blog/iec-62304-medizinische-software/iec-82304/