Thema 1.5 — Regulierungs- und Compliance-Landschaft

In einem Satz: Compliance in der digitalen Gesundheit und Pflege ist kein juristischer Nachgedanke, sondern eine Karte überlappender gesetzlicher Pflichten, verbindlicher Standards und freiwilliger Absicherung, die Sie bewusst, verhältnismäßig zum Risiko und mit klarer Verantwortung durchqueren müssen – denn Fehler sind ein Versagen bei Sicherheit, Gerechtigkeit und öffentlichem Vertrauen, nicht bloß eine Geldbuße.

Warum das in Gesundheit und Pflege wichtig ist#

In den meisten Branchen setzt Regulierung eine Untergrenze: Wer sie befolgt, vermeidet Strafen. In Gesundheit und Pflege kodiert die Regulierungslandschaft hart erarbeitete Lehren darüber, wie digitale Systeme Menschen schaden, wenn sie schiefgehen – eine falsch etikettierte Dosis, eine verlorene Akte, ein verzerrter Algorithmus, eine Panne, die die sensibelsten Daten offenlegt, die ein Mensch besitzt. Compliance ist hier ein Indikator dafür, ob Sie über diese Schäden überhaupt nachgedacht haben. Eine Führungskraft, die sie als Papierkram behandelt, sagt Ihnen, dass sie es nicht getan hat.

Die Landschaft ist zudem tatsächlich überfüllt, und das ist die Schwierigkeit. Eine einzelne patientenorientierte App kann gleichzeitig ein von einer Stelle reguliertes Medizinprodukt sein, personenbezogene Daten im Zuständigkeitsbereich einer anderen verarbeiten, nur beauftragt werden, wenn sie eine nationale Bewertung besteht, in einem von einer Pflegeaufsicht inspizierten Service sitzen und von Klinikpersonal gebaut werden, das seinen eigenen Berufsaufsichten rechenschaftspflichtig ist. Niemand hat diese Karte als kohärentes Ganzes geschrieben; sie ist gewachsen. Ihre Aufgabe als Führungskraft ist nicht, jede Regel auswendig zu lernen, sondern die Gestalt des Geländes zu erfassen – wer was abdeckt, welche Instrumente verbindlich und welche beratend sind und wo Ihr konkreter Service darin liegt.

Schließlich geht es um öffentliches Geld und gesetzliche Pflicht. Wenn Sie ein nicht konformes System einsetzen, setzen Sie nicht nur Ihre Organisation Vollstreckung aus, sondern verletzen womöglich Pflichten gegenüber Patientinnen, Patienten und Bürgerinnen und Bürgern und geben öffentliche Mittel für etwas aus, das Sie nicht rechtmäßig betreiben können. Deshalb rahmt dieses Thema die detaillierteren folgenden Themen zu klinischer Sicherheit (Thema 1.6 — Klinische Sicherheit und Risikomanagement), Informationsgovernance (Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit), Datenethik (Thema 1.8 — Datenethik, Einwilligung und öffentliches Vertrauen) und Absicherung (Thema 6.4 — Governance und Assurance). Dieses Thema ist der Navigator; jene sind die Detailkarten.

Kernkonzepte#

Drei Ebenen der Verpflichtung. Die nützlichste Unterscheidung ist die zwischen gesetzlicher Regulierung, verbindlichen Standards und freiwilliger Absicherung. Gesetzliche Regulierung ist Recht – von einer Aufsichtsbehörde mit rechtlichen Befugnissen durchgesetzt und nicht verhandelbar (zum Beispiel das Datenschutzrecht oder die Pflicht, ein Medizinprodukt zu registrieren). Verbindliche Standards sind vertragliche oder politische Anforderungen, die Sie erfüllen müssen, um innerhalb eines Systems zu operieren, auch wenn sie kein Primärrecht sind – zum Beispiel nationale NHS-Instrumente, an die die Beauftragung geknüpft ist. Freiwillige Absicherung ist, wo Sie sich entscheiden, Qualität an einem anerkannten Maßstab nachzuweisen, um Vertrauen aufzubauen, Vergaben zu gewinnen oder künftiger Regulierung zuvorzukommen. Zu wissen, auf welcher Ebene eine Anforderung liegt, sagt Ihnen, was geschieht, wenn Sie sie verfehlen: Strafverfolgung, Ausschluss vom Markt oder Reputationsnachteil.

Die Care Quality Commission (CQC). Die Care Quality Commission ist die unabhängige Aufsichtsbehörde für Gesundheit und Erwachsenen-Sozialfürsorge in England. Sie registriert, inspiziert und bewertet Anbieter danach, ob Services sicher, wirksam, fürsorglich, reaktionsfähig und gut geführt sind. Digitale Services entgehen ihr nicht: Wo Technologie Teil der Versorgung ist, reichen die Fragen der CQC nach Sicherheit und Führung bis zu den Systemen, die Sie betreiben, und ihre Domäne „well-led“ prüft zunehmend digitale und Datenreife.

Die MHRA und Medizinprodukte. Die Medicines and Healthcare products Regulatory Agency (MHRA) reguliert Arzneimittel und Medizinprodukte im Vereinigten Königreich. Entscheidend: Software kann selbst ein Medizinprodukt sein: Software as a Medical Device (SaMD) ist Software mit medizinischer Zweckbestimmung – Diagnose, Prävention, Überwachung, Behandlung –, ohne Teil eines Hardwaregeräts zu sein. Wenn Ihre App eine Dosis berechnet, ein Symptom triagiert oder ein Bild interpretiert, ist sie sehr wahrscheinlich ein Medizinprodukt und muss klassifiziert, registriert werden und die passende Konformitätskennzeichnung tragen, bevor sie in Verkehr gebracht wird.

Konformitätskennzeichnung: UKCA und CE. Ein auf dem Markt von Großbritannien in Verkehr gebrachtes Medizinprodukt braucht die UKCA-Kennzeichnung (UK Conformity Assessed), das britische Gegenstück nach dem Brexit zur CE-Kennzeichnung (Conformité Européenne). Vorerst werden CE-gekennzeichnete Produkte in Großbritannien unter Übergangsregelungen weiter akzeptiert, und Nordirland folgt den EU-Regeln – die nötige Kennzeichnung hängt also davon ab, wo Sie das Produkt in Verkehr bringen. Das ist ein lebendiges, sich verschiebendes Feld; behandeln Sie die genaue Anforderung als etwas, das zu bestätigen ist, nicht anzunehmen.

NICE und das Evidence Standards Framework. Das National Institute for Health and Care Excellence (NICE) erarbeitet Leitlinien dazu, was wirkt und was kosteneffektiv ist. Sein Evidence Standards Framework (ESF) für digitale Gesundheitstechnologien legt verhältnismäßig zum Risiko fest, welche Evidenz ein digitales Produkt zeigen sollte, bevor das System es übernimmt. NICE ist kein Zulassungs-Torwächter wie die MHRA, doch seine Urteile prägen die Beauftragung stark – die MHRA-Registrierung zu bestehen beweist, dass ein Produkt sicher zu verkaufen ist; NICE-konforme Evidenzerwartungen zu erfüllen hilft zu beweisen, dass es sich lohnt, es zu kaufen (siehe Thema 1.3 — Evidenzbasierte Entscheidungen).

Das ICO und das Datenschutzrecht. Das Information Commissioner's Office (ICO) ist die unabhängige Aufsichtsbehörde des Vereinigten Königreichs für Datenschutz und Informationsfreiheit. Es setzt die britische Datenschutz-Grundverordnung (UK GDPR) und den Data Protection Act 2018 durch, die regeln, wie Sie personenbezogene Daten rechtmäßig verarbeiten dürfen – und Gesundheitsdaten sind eine „besondere Kategorie“ mit dem stärksten Schutz. Das ICO kann ermitteln, Änderungen anordnen und erhebliche Bußgelder verhängen. Die Substanz behandelt Thema 1.7; halten Sie hier nur fest, dass das ICO Ihre Datenschutzaufsicht ist und Gesundheitsdaten eine höhere Latte tragen.

Verbindliche NHS-Instrumente. Über das Primärrecht hinaus betreibt der NHS eigene verbindliche Instrumente. Das Data Security and Protection Toolkit (DSPT) ist die jährliche Selbstbewertung, die jede Organisation, die NHS-Patientendaten verarbeitet, abschließen muss, um Standards der Datensicherheit und Informationsgovernance nachzuweisen. Die Digital Technology Assessment Criteria (DTAC) sind die Basis, die eine digitale Gesundheitstechnologie erfüllen muss, um von NHS-Organisationen beauftragt zu werden, und umfassen klinische Sicherheit, Datenschutz, technische Sicherheit, Interoperabilität und Nutzbarkeit. Die Standards zur klinischen Sicherheit DCB0129 (für Hersteller) und DCB0160 (für einsetzende Organisationen) schreiben einen dokumentierten Prozess des klinischen Risikomanagements vor – ein Gefährdungsprotokoll, einen Clinical Safety Officer, einen Safety Case – und sind das Rückgrat von Thema 1.6.

Berufsaufsichten. Reguliert werden Menschen, nicht nur Produkte. Der General Medical Council (GMC) registriert Ärztinnen und Ärzte und setzt ihre Standards, der Nursing and Midwifery Council (NMC) tut dasselbe für Pflegekräfte und Hebammen. Wenn Klinikpersonal digitale Services entwirft, genehmigt oder betreibt, reisen seine Berufspflichten mit – ein Clinical Safety Officer, der ein System freigibt, handelt unter beruflicher Verantwortlichkeit, nicht nur in einer Rolle im Organigramm.

Horizont und Kontext: das EU-Regime. Auch außerhalb der EU sind der AI Act und die Verordnung (EU) 2017/745 (die EU-Medizinprodukteverordnung, MDR) von Bedeutung – sie geben die Entwicklungsrichtung vor, binden Sie, wenn Sie EU-Märkte oder Nordirland bedienen, und zeigen oft vorab, wohin sich britische Regeln als Nächstes bewegen. Horizon-Scanning für solchen Wandel ist selbst eine Compliance-Disziplin.

Die Compliance-Karte und das Register. Eine Compliance-Karte listet für Ihren Service jede anwendbare Verpflichtung über alle drei Ebenen auf, und ein Compliance-Register hält für jede Status, Verantwortliche, Nachweis und Überprüfungsdatum fest. Zusammen machen sie aus einer diffusen Landschaft eine gesteuerte, prüfbare Position – den Unterschied zwischen „wir glauben, wir sind konform“ und „hier sind die benannte Verantwortliche und der aktuelle Nachweis für jede Pflicht“.

Bewährte Praktiken#

1. Klassifizieren Sie Ihren Service, bevor Sie über Kontrollen streiten. Die erste Frage ist nicht „sind wir konform?“, sondern „was sind wir rechtlich?“ Klären Sie früh, ob Ihr Produkt ein Medizinprodukt ist (und in welcher Risikoklasse), ob Sie Verantwortlicher oder Auftragsverarbeiter sind und welche verbindlichen NHS-Instrumente gelten. Eine falsche Klassifizierung macht jede nachgelagerte Entscheidung falsch; eine richtige sagt Ihnen, welche der obigen Ebenen und Stellen Sie tatsächlich binden.

2. Bauen und pflegen Sie eine lebendige Compliance-Karte und ein Register. Zählen Sie jede für den Service geltende Verpflichtung über gesetzliche Regulierung, verbindliche Standards und freiwillige Absicherung auf und halten Sie für jede Verantwortliche, aktuellen Status, stützenden Nachweis und nächstes Überprüfungsdatum fest. Halten Sie sie lebendig, planmäßig überprüft, nicht als einmal für einen Business Case geschriebenes und nie wieder geöffnetes Dokument. Ein gutes Register beantwortet an jedem beliebigen Tag: „Wer verantwortet diese Pflicht, und wo ist der Nachweis?“

3. Weisen Sie jeder Verpflichtung eine namentliche Verantwortung zu. Diffuse Verantwortung ist, wie Compliance scheitert: Jede geht davon aus, dass eine andere sie trägt. Geben Sie jeder Pflicht eine benannte Verantwortliche – einen Datenschutzbeauftragten für den Datenschutz, einen Clinical Safety Officer für DCB0129/0160, eine Senior Information Risk Owner für das DSPT – und machen Sie die Verantwortungsspalte der Karte real, mit der Befugnis und der Zeit, sie zu erfüllen. Nicht benannte Verantwortlichkeit ist keine Verantwortlichkeit.

4. Seien Sie verhältnismäßig und risikobasiert, nicht Abhak-Compliance. Regulierung verdient dieselbe Verhältnismäßigkeit wie Evidenz (siehe Thema 1.3): Konzentrieren Sie Sorgfalt dort, wo das Risiko für Patientinnen und Patienten, Gerechtigkeit und Vertrauen am höchsten ist, und halten Sie risikoarme Arbeit leicht. Abhak-Compliance – das Formular ausfüllen und die Absicht verfehlen – ist verschwenderisch und gefährlich zugleich, weil sie falsche Sicherheit herstellt. Zielen Sie darauf, den Zweck jeder Anforderung zu erfüllen, was meist auch den Buchstaben erfüllt.

5. Behandeln Sie verbindliche NHS-Instrumente als Designeingaben, nicht als Ausgangstore. DTAC, DSPT und DCB0129/0160 sind am günstigsten und wirksamsten, wenn sie von Anfang an in die Lieferung eingebaut sind, nicht kurz vor dem Go-live angeflanscht. Ein beim Start entdecktes DTAC-Versagen kann Monate kosten; ein nachträglich zusammengestellter Safety Case ist dünn und wenig überzeugend. Falten Sie diese Instrumente in Discovery und Lieferung ein, sodass ihre Erfüllung ein Nebenprodukt guter Arbeit ist.

6. Betreiben Sie Horizon-Scanning für regulatorischen Wandel und verantworten Sie die Antwort. Regulierung bewegt sich – UKCA-Fristen verschieben sich, der EU AI Act wird stufenweise eingeführt, das Regime für Software als Medizinprodukt entwickelt sich weiter. Weisen Sie jemandem zu, relevante Aufsichten und Konsultationen zu verfolgen, führen Sie eine kurze „regulatorischer Wandel“-Beobachtungsliste gegen Ihre Compliance-Karte und machen Sie aus Signalen geplante Arbeit, bevor Fristen zu Notfällen werden. Von einer im Voraus bekannten Regeländerung überrascht zu werden ist ein vermeidbares, selbst verschuldetes Versagen.

7. Halten Sie Nachweise fortlaufend und machen Sie sie prüfungsbereit. Aufsichten, Beauftragende und die „well-led“-Prüfenden der CQC bitten Sie zu zeigen, nicht zu behaupten. Halten Sie Gefährdungsprotokolle, Datenschutz-Folgenabschätzungen (DPIAs), DSPT-Einreichungen und DTAC-Nachweise aktuell und abrufbar, statt sie unter Inspektionsdruck zu rekonstruieren. Fortlaufende Nachweise sind zudem billiger als die periodische Hektik, die sie ersetzen.

8. Koordinieren Sie über Aufsichten hinweg statt in Silos. Weil ein Service viele Stellen berührt, müssen seine Compliance-Funktionen miteinander sprechen: Klinische Sicherheit, Informationsgovernance und Produktverantwortliche sollten eine gemeinsame Sicht auf den Service haben, nicht drei unverbundene pflegen. Eine Änderung, die die MHRA zufriedenstellt, kann ein Datenschutzproblem erzeugen; eine UX-Korrektur kann das klinische Risikoprofil verändern. Betreiben Sie Compliance als ein koordiniertes Bild, eingebunden in Ihre weitere Governance (Thema 6.4 — Governance und Assurance).

Fragen zur Diskussion im Team#

1. Können wir für unseren Vorzeige-Digitalservice jede geltende Aufsicht und jeden verbindlichen Standard benennen, wer sie jeweils verantwortet und wo der aktuelle Nachweis liegt – ohne dass jemand erst nachforschen muss? Das prüft, ob Sie die Karte tatsächlich halten oder nur glauben, konform zu sein. Es ist wichtig, weil sich die Pflichten in Gesundheit und Pflege tatsächlich überlappen – eine Triage-App kann zugleich ein Medizinprodukt nach der MHRA, ein Datenverarbeitungsvorgang nach dem ICO, eine beauftragte Technologie mit DTAC-Bedarf und Teil eines von der CQC inspizierten Services sein – und eine Lücke auf einer Ebene den Service stoppen oder Patientinnen und Patienten schaden kann. Die Spannung, die ans Licht gehört: der Komfort der Annahme „IG kümmert sich darum“ oder „der Lieferant ist reguliert, nicht wir“ gegenüber dem Unbehagen, für jede Pflicht namentliche Verantwortung und lebendige Nachweise zu bestätigen. Gehen Sie den Service konkret durch: Listen Sie die Stellen auf, ordnen Sie jede Verpflichtung ihrer Ebene zu (gesetzlich, verbindlich, freiwillig) und versuchen Sie, für drei davon auf der Stelle den aktuellen Nachweis vorzulegen. Gelingt das nicht, haben Sie Ihre erste Lücke gefunden. Eine gute, ehrliche Antwort ist ein befülltes Compliance-Register mit benannten Verantwortlichen und datierten Nachweisen und Offenheit darüber, welche Pflichten derzeit ohne Verantwortliche oder Nachweis sind, statt eines zuversichtlichen Winkens mit „wir sind konform“.

2. Wo betreiben wir Abhak-Compliance – wir erfüllen das Formular und verfehlen den Punkt – und wo überkonstruieren wir risikoarme Arbeit? Das Thema plädiert für verhältnismäßige, risikobasierte Compliance, und diese Frage zwingt Sie, beide Fehlrichtungen ehrlich zu prüfen. Sie ist wichtig, weil falsche Sicherheit in einem sicherheitskritischen Umfeld aktiv gefährlich ist: ein als „erfüllt“ markiertes DSPT oder ein in der Woche vor dem Go-live zusammengestellter Safety Case kann konform aussehen und reale Gefährdungen unbewältigt lassen, während ein schwerer Assurance-Prozess, der eine risikoarme Inhaltsänderung drosselt, knappe Kapazität verschwendet und Zynismus gegenüber dem ganzen Regime nährt. Der Zielkonflikt, der zu debattieren ist: Verhältnismäßigkeit verlangt Urteilsvermögen und die Zuversicht, es zu verteidigen, was schwerer zu verwalten ist als eine einheitliche Regel, die alles als hochriskant behandelt. Nehmen Sie zwei oder drei aktuelle Punkte – einen wirklich hochriskanten, einen risikoarmen – und fragen Sie, ob die angewandte Sorgfalt dem Risiko für Patientinnen und Patienten, Gerechtigkeit und Vertrauen entsprach oder von Gewohnheit und Angst getrieben war. Erwägen Sie, ob Ihre DTAC- und DCB0129/0160-Arbeit das Design tatsächlich formt oder rückwärts zurechtgebaut wird, um zu bestehen. Eine gute Antwort benennt einen konkreten Fall von Abhaken und einen konkreten Fall von Überkonstruktion und verpflichtet sich, die Sorgfalt am Risiko zu kalibrieren, statt überall einen stumpfen Standard anzuwenden.

3. Woran würden wir erkennen, dass sich eine uns betreffende Regulierung bald ändert – und wer ist dafür verantwortlich, dieses Signal in geplante Arbeit zu verwandeln? Das lotet das Horizon-Scanning aus, die Disziplin, die von Fristen überraschte Organisationen von jenen trennt, die planen. Es ist wichtig, weil die Landschaft derzeit ungewöhnlich lebendig ist – UKCA- und CE-Fristen, das Regime für Software als Medizinprodukt, der stufenweise EU AI Act, sich entwickelnde NHS-Instrumente – und eine Regeländerung, von der Sie wussten, dass sie kommt, auf die Sie sich aber nicht vorbereitet haben, eine selbst zugefügte Wunde ist, die einen Service vom Markt nehmen kann. Die Spannung ist, dass Horizon-Scanning keinen unmittelbaren Ertrag hat und daher unter Lieferdruck als Erstes fallen gelassen wird und sein Fehlen unsichtbar bleibt, bis die Frist da ist. Ergründen Sie, wer derzeit die relevanten Aufsichten und Konsultationen verfolgt, ob es eine an Ihre Compliance-Karte gebundene Beobachtungsliste gibt und wie ein Signal zu einem Ticket mit Verantwortlichem und Datum wird statt zu einer Sorge im Posteingang von jemandem. Erwägen Sie, ob Sie von einer Änderung, die nur Nordirland oder EU-orientierte Teile Ihres Services betrifft, überhaupt hören würden. Eine gute Antwort benennt die Person oder Rolle, die das regulatorische Horizon-Scanning verantwortet, verweist auf eine konkrete Beobachtungsliste und beschreibt das letzte Mal, dass eine bevorstehende Änderung vor der Frist in geplante Arbeit überführt wurde.

4. Haben wir ehrlich klassifiziert, was wir sind – Medizinprodukt oder nicht, Verantwortlicher oder Auftragsverarbeiter – oder haben wir still die Auslegung gewählt, die unsere Last senkt? Das bringt die folgenreichste Entscheidung des Themas ans Licht, denn die Klassifizierung treibt jede nachgelagerte Verpflichtung und ist der leichteste Ort, sich selbst zu täuschen. Sie ist wichtig, weil alle Anreize in eine Richtung ziehen: Das Produkt „eine Wellness-App“ statt Software as a Medical Device zu nennen oder „Auftragsverarbeiter“ statt Verantwortlicher, umgeht Kosten, Evidenz und Prüfung – doch wenn der Algorithmus Daten interpretiert, um klinisches Handeln zu informieren, oder Sie die Zwecke der Verarbeitung bestimmen, ist die ehrliche Klassifizierung nicht optional, und die Aufsicht wird sie unabhängig von Ihrer Präferenz anwenden. Die Spannung: Die billigere Lesart ist oft vertretbar genug, um ein internes Gespräch zu überstehen, aber nicht eine Anfrage von MHRA oder ICO, und Fehlklassifizierung ist der schnellste Weg zu Vollstreckung und einer kollabierten NHS-Pipeline. Arbeiten Sie es konkret durch: Sagen Sie, was das Produkt tatsächlich tut, holen Sie Rechtsrat statt der Ahnung einer Gründerin ein und testen Sie, ob Ihre erklärte Klasse bestünde, wenn eine Aufsicht dieselben Fakten läse. Eine gute, ehrliche Antwort zeigt eine früh und mit Beratung erreichte dokumentierte Klassifizierung, benennt, wer sie freigegeben hat, und ist offen über jeden Grenzfall und wie er unter Beobachtung gehalten wird, während sich das Produkt verändert.

5. Wenn eine Änderung an unserem Service mehrere Aufsichten zugleich berührt, sehen unsere Compliance-Funktionen ein gemeinsames Bild – oder drei unverbundene? Das prüft die Koordination, das Versagen, vor dem das Thema warnt, wenn klinische Sicherheit, Informationsgovernance und Produkt jeweils eine Teilsicht halten. Sie ist wichtig, weil ein einzelner Service tatsächlich mehrere Stellen überspannt – eine UX-Änderung an einer Triage-App kann ihr klinisches Risikoprofil verändern, eine Korrektur, die die MHRA zufriedenstellt, kann eine Datenschutzfrage öffnen, und eine DTAC-Anforderung kann an allen ziehen –, sodass eine Silostruktur bedeutet, dass niemand die gesamte Compliance-Position verantwortet und Änderungen zwischen Teams fallen. Die Spannung: Fachfunktionen sind aus gutem Grund nach Disziplin organisiert, doch der Service wird von der Patientin als eine Sache erlebt, und das Abgleichen dieser Sichten kostet Koordinationsaufwand, den kein einzelnes Team zu finanzieren angereizt ist. Ergründen Sie, ob es je Service eine gemeinsame Compliance-Karte gibt oder mehrere private, ob eine Änderung in einer Domäne zuverlässig eine Überprüfung in den anderen auslöst und wie dies an die Governance auf Vorstandsebene anschließt (Thema 6.4). Eine gute Antwort verweist auf eine einzige koordinierte Sicht jedes Services, beschreibt eine jüngere Änderung, die über alle betroffenen Aufsichten gemeinsam bewertet wurde, und ist ehrlich, wo Disziplinen noch in Silos arbeiten.

6. Wo unser Service von einem Drittanbieter abhängt, wissen wir genau, welche Pflichten seine sind und welche bei uns bleiben – oder nehmen wir an „die sind reguliert, also sind wir abgedeckt“? Das bringt die Lücke geteilter Verantwortung ans Licht, die Fehlklassifizierung und diffuse Verantwortlichkeit beide nähren, denn der Kauf einer regulierten Komponente überträgt Ihre eigenen Pflichten nicht. Sie ist wichtig, weil ein Lieferant die Konformitätskennzeichnung des Medizinprodukts halten kann, während Sie als einsetzende Organisation weiterhin einen DCB0160-Safety-Case schulden, für Ihre Patientinnen und Patienten Verantwortlicher bleiben und gegenüber der CQC dafür einstehen, wie der Service betrieben wird – und die Naht zwischen „deren Compliance“ und „Ihrer“ genau der Ort ist, an dem Pflichten fallen gelassen werden. Die Spannung ist ebenso kommerziell wie regulatorisch: Lieferanten bevorzugen Verträge, die nahelegen, dass sie die Last tragen, und es ist verlockend, diesen Trost anzunehmen, statt die Grenze genau zu kartieren. Gehen Sie eine reale Lieferantenbeziehung durch: Listen Sie auf, was der Vertrag und ihre Kennzeichnung tatsächlich abdecken, was Ihre gesetzliche oder verbindliche Pflicht bleibt und ob Ihr Register diese Teilung mit benannten Verantwortlichen auf Ihrer Seite festhält. Eine gute, ehrliche Antwort unterscheidet die Pflichten des Lieferanten von Ihren verbleibenden schriftlich, benennt, wer jede verbleibende Pflicht verantwortet, und kann den Nachweis vorlegen, den Sie halten, nicht den, von dem Sie annehmen, dass der Lieferant ihn hält.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Ein Integrated Care System (ICS) plant, eine Smartphone-App auszurollen, mit der Patientinnen und Patienten mit Langzeiterkrankungen Symptome erfassen und die einen Algorithmus nutzt, um jene zur klinischen Überprüfung zu markieren, die sich verschlechtern könnten. Die Versuchung ist, sie als „nur eine App“ zu behandeln und live zu schalten.

Stattdessen beginnt die Digitaldirektorin mit der Klassifizierung. Weil der Algorithmus Patientendaten interpretiert, um klinisches Handeln zu informieren, bestätigt Rechtsrat, dass es sich um Software as a Medical Device handelt; das MHRA-Regime greift also, und der Lieferant muss die korrekte Konformitätskennzeichnung für den Markt von Großbritannien halten – eine UKCA-Frage, die das Team im Blick behält, während sich die CE-Übergangsregelungen weiterentwickeln. Das ICS ist Verantwortlicher für die Patientendaten, sodass die Datenschutzpflichten des ICO es binden, und eine Datenschutz-Folgenabschätzung wird eröffnet (speist Thema 1.7). Weil sie von NHS-Stellen beauftragt wird, gilt DTAC, und weil sie in den klinischen Einsatz geht, verlangt DCB0160 einen Safety Case, ein Gefährdungsprotokoll und einen benannten Clinical Safety Officer (Thema 1.6).

Das Team baut eine Compliance-Karte: jede Verpflichtung ihrer Ebene zugeordnet, jede mit einer benannten Verantwortlichen – Datenschutzbeauftragter, Clinical Safety Officer, Senior Information Risk Owner, Produktverantwortliche – und einem Register, das Status und Nachweis verfolgt. Statt DTAC und den Safety Case als Go-live-Tore zu behandeln, falten sie sie ab Discovery in die Lieferung ein, sodass das Gefährdungsprotokoll mit dem Design wächst. Das Evidence Standards Framework von NICE prägt, welche Wirksamkeitsevidenz sie vom Lieferanten vor dem Skalieren verlangen. Ein Horizon-Scanning-Vermerk markiert den EU AI Act als relevant für die Zukunft des Algorithmus und für jede EU-orientierte Ambition. Als die CQC später die Führung des Services überprüft, beantwortet das ICS die „well-led“-Fragen mit einem lebendigen Register und aktuellen Nachweisen statt mit Hektik. Die App geht später live als im naiven Plan – und rechtmäßig.

Sektorperspektiven#

Dieselbe Landschaft erlegt je nach Standort sehr unterschiedliche Lasten auf.

Startup#

Ein kleines Unternehmen der digitalen Gesundheit spürt die Regime für Medizinprodukte und DTAC am schärfsten, weil ihre Erfüllung Geld und Zeit kostet, die es vielleicht nicht hat, und die Versuchung besteht darin, unterzuklassifizieren – darauf zu bestehen, das Produkt sei „nur eine Wellness-App“, kein Medizinprodukt –, um die Last zu umgehen. Das ist der gefährlichste verfügbare Zug: Fehlklassifizierung ist der schnellste Weg zu einer Vollstreckungsmaßnahme und einer kollabierten NHS-Vertriebspipeline. Der disziplinierte Weg ist, ehrlich und früh zu klassifizieren, eine schlanke, aber reale Compliance-Karte zu bauen und DTAC sowie eine saubere Datenschutzposition als Verkaufsargumente zu behandeln, die den NHS-Markt öffnen, statt als Hindernisse. Eine benannte Verantwortliche für regulatorisches Horizon-Scanning kann eine einzelne Gründerin mit einem weiteren Hut sein, aber die Beobachtungsliste muss dennoch existieren.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, eine Einzelstandort-Klinik oder ein kleiner Health-Tech-Lieferant jenseits der Startup-Phase – trägt dieselben gesetzlichen und verbindlichen Pflichten wie ein großer Trust, aber ohne Datenschutzbeauftragten, Clinical Safety Officer oder Compliance-Team, sie zu erfüllen. Das DSPT muss jedes Jahr abgeschlossen werden, Patientendaten unterliegen weiterhin der Latte der besonderen Kategorie, und jede eingesetzte klinische Software zieht weiterhin DCB0160 nach sich – doch das fällt meist auf eine Praxismanagerin oder einen Inhaber, die bzw. der bereits den Betrieb führt. Der realistische Zug ist, die Compliance-Karte bewusst klein, aber real zu halten, sich auf geteilte oder beauftragte Expertise zu stützen – einen Verbund, eine CSU oder die Dokumentation zur klinischen Sicherheit eines Lieferanten –, statt vorzugeben, jede Spezialdisziplin im Haus zu halten, und bei den Pflichten, die nicht delegiert werden können, gewissenhaft zu sein, etwa als Verantwortlicher für die eigenen Patientinnen und Patienten zu bleiben. Die Absicherung eines Lieferanten als Deckung Ihrer verbleibenden Pflichten zu behandeln, ist hier die charakteristische Falle: Holen Sie Hilfe ein, aber behalten Sie die namentliche Verantwortung für das, was rechtlich Ihnen gehört.

Großunternehmen#

Ein NHS Trust oder großes ICS hält viele Services zugleich; seine Herausforderung ist daher Koordination im Portfoliomaßstab: Dutzende Systeme, jedes berührt mehrere Aufsichten, mit Pflichten, die nicht zwischen Teams fallen dürfen. Das Fehlerbild sind organisatorische Silos – klinische Sicherheit, Informationsgovernance und Beschaffung halten jeweils eine Teilsicht, sodass niemand die gesamte Compliance-Position eines Services sieht. Das Korrektiv ist eine gemeinsame Compliance-Karte je Service, namentliche Verantwortlichkeit, angebunden an die Governance auf Vorstandsebene (Thema 6.4), und fortlaufende, prüfungsbereite Nachweise, sodass eine CQC-„well-led“-Prüfung oder eine ICO-Anfrage aus einer lebendigen Position beantwortet wird. Ein großes Health-Tech- oder Pharma-Unternehmen bringt ausgereifte Regulatory-Affairs-Maschinerie mit, muss sich aber davor hüten, sie als Compliance-Fabrik zu behandeln, die vom tatsächlichen Bau der Produkte abgekoppelt ist.

Regierung#

Eine nationale Stelle – NHS England, das Department of Health and Social Care, die MHRA, NICE – ist oft die Aufsicht oder die Autorin des verbindlichen Instruments; ihre Arbeitsweisen setzen daher die Latte, die das ganze System nehmen muss, und ihre Entscheidungen ziehen parlamentarische und öffentliche Kontrolle an. Compliance-Arbeit ist hier Rechenschaft im Bevölkerungsmaßstab: Ein Instrument wie DTAC oder das ESF prägt einen ganzen Markt, sodass Verhältnismäßigkeit und Klarheit im Standard selbst Pflichten sind, keine Nettigkeiten, denn eine schlecht kalibrierte nationale Anforderung bremst entweder überall nützliche Innovation oder winkt überall Risiko durch. Nationale Stellen tragen auch die Horizon-Scanning-Verantwortung für das System und antizipieren, wie der EU AI Act, die MDR und Regime der Konformitätskennzeichnung die britische Politik prägen sollten. Transparenz darüber, was ein Standard verlangt und warum, ist Teil der Wahrung öffentlichen Vertrauens im großen Maßstab.

Häufige Fehlermuster#

• Fehlklassifizierung. Darauf bestehen, ein Produkt sei kein Medizinprodukt oder man sei Auftragsverarbeiter statt Verantwortlicher, um eine Last zu umgehen. Gegenmittel: ehrlich und früh klassifizieren, mit Rechtsrat; die Klassifizierung treibt alles Weitere.
• Abhak-Compliance. Das DSPT oder einen Safety Case abschließen, um zu bestehen, während das zugrunde liegende Risiko unbewältigt bleibt. Gegenmittel: den Zweck erfüllen, nicht nur das Formular; prüfen, ob das Artefakt das Design tatsächlich geformt hat.
• Compliance als Go-live-Tor. Lücken bei DTAC oder klinischer Sicherheit erst beim Start entdecken. Gegenmittel: verbindliche Instrumente ab Discovery in die Lieferung einfalten.
• Diffuse Verantwortung. Jede Pflicht wird als die einer anderen angenommen. Gegenmittel: namentliche Verantwortlichkeit je Verpflichtung in einem lebendigen Register.
• Verinselte Aufsichten. Klinische Sicherheit, IG und Produkt halten unverbundene Sichten auf einen Service. Gegenmittel: eine gemeinsame Compliance-Karte, koordinierte Governance.
• Kein Horizon-Scanning. Von einer Regeländerung überrascht werden, die man hätte kommen sehen können. Gegenmittel: eine verantwortete, an die Compliance-Karte gebundene Beobachtungsliste.
• Veraltete Nachweise. Gefährdungsprotokolle und Bewertungen unter Inspektionsdruck rekonstruieren. Gegenmittel: fortlaufende, prüfungsbereite Nachweise.

Reifegradmodell#

Checkliste#

• Die rechtliche Klassifizierung des Services (Medizinprodukt und Klasse; Verantwortlicher/Auftragsverarbeiter) ist bestätigt und dokumentiert.
• Eine lebendige Compliance-Karte listet jede Verpflichtung über die gesetzliche, verbindliche und freiwillige Ebene auf.
• Jede Verpflichtung hat eine einzelne benannte Verantwortliche mit der Befugnis und der Zeit, sie zu erfüllen.
• Verbindliche NHS-Instrumente (DTAC, DSPT, DCB0129/0160) sind in die Lieferung eingebaut, nicht beim Go-live angeflanscht.
• Die Sorgfalt ist an Risiko für Patientinnen und Patienten, Gerechtigkeit und Vertrauen kalibriert – nicht einheitliches Abhaken.
• Nachweise (Gefährdungsprotokolle, DPIAs, DSPT, DTAC) sind aktuell, abrufbar und prüfungsbereit.
• Eine benannte Verantwortliche betreibt das regulatorische Horizon-Scanning anhand einer gepflegten Beobachtungsliste.
• Anforderungen an die Konformitätskennzeichnung (UKCA/CE) für den relevanten Markt sind bestätigt, nicht angenommen.
• Compliance-Funktionen teilen eine koordinierte Sicht auf jeden Service, eingebunden in die Governance (Thema 6.4).
• Das Register wird planmäßig überprüft, nicht einmal geschrieben und aufgegeben.

Zentrale Quellen#

• Care Quality Commission — How CQC regulates und das Single Assessment Framework (cqc.org.uk).
• MHRA — Medical devices: software applications (apps) und Leitlinien Software and AI as a Medical Device (gov.uk).
• NICE — Evidence Standards Framework for digital health technologies (ESF) (nice.org.uk).
• Information Commissioner's Office — Guide to Data Protection und Guide to the UK GDPR (ico.org.uk).
• NHS England — Data Security and Protection Toolkit (DSPT) (dsptoolkit.nhs.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC).
• NHS Digital / NHS England — Standards zum klinischen Risikomanagement DCB0129 und DCB0160.
• GMC — Good medical practice; NMC — The Code (Berufsstandards).
• GOV.UK — Leitlinien zur UKCA-Kennzeichnung und CE-Kennzeichnung für den Markt von Großbritannien.

Referenzen#

1. Regulatory compliance — Wikipedia — https://en.wikipedia.org/wiki/Regulatory_compliance
2. Care Quality Commission — Wikipedia — https://en.wikipedia.org/wiki/Care_Quality_Commission
3. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
4. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
5. UKCA marking — Wikipedia — https://en.wikipedia.org/wiki/UKCA_marking
6. CE marking — Wikipedia — https://en.wikipedia.org/wiki/CE_marking
7. National Institute for Health and Care Excellence — Wikipedia — https://en.wikipedia.org/wiki/National_Institute_for_Health_and_Care_Excellence
8. Information Commissioner's Office — Wikipedia — https://en.wikipedia.org/wiki/Information_Commissioner%27s_Office
9. General Data Protection Regulation — Wikipedia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
10. Data Protection Act 2018 — Wikipedia — https://en.wikipedia.org/wiki/Data_Protection_Act_2018
11. General Medical Council — Wikipedia — https://en.wikipedia.org/wiki/General_Medical_Council
12. Nursing and Midwifery Council — Wikipedia — https://en.wikipedia.org/wiki/Nursing_and_Midwifery_Council
13. Artificial Intelligence Act — Wikipedia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
14. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipedia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
15. How CQC regulates — Care Quality Commission — https://www.cqc.org.uk/about-us/how-we-do-our-job/how-we-regulate
16. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
17. Evidence Standards Framework for digital health technologies (ESF) — NICE — https://www.nice.org.uk/about/what-we-do/digital-health
18. Guide to the UK GDPR — Information Commissioner's Office — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/
19. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
20. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
21. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
22. UKCA marking guidance — GOV.UK — https://www.gov.uk/guidance/using-the-ukca-marking