01135 Technologiepartnerschaften – Eine Risikoanalyse
Der Begriff „Partnerschaft” klingt rund und nach reibungsloser Kooperation. Doch eine gelungene Zusammenarbeit zwischen Medizintechnikunternehmen und Technologiepartnern will im Detail bedacht und gut vorbereitet sein. Um Risiken zu begrenzen, sollten Aspekte der Regulatorik ebenso in den Blick genommen werden wie Fragen der Datensicherheit, der Unternehmenskultur und weitere mehr. Der vorliegende Beitrag skizziert das Spektrum der Anforderungen und führt sie in einer praktischen Checkliste zusammen. Arbeitshilfen: von: |
1 Beispiele für Risiken
Meine langjährigen Erfahrungen als Medizin-Ingenieur, vereidigter Sachverständiger, Mitglied von verschiedenen Gremien, Ausschüssen und Vorständen von Fachorganisationen für das Gesundheitswesen haben mir immer wieder vor Augen geführt, dass bei der vielgepriesenen Konvergenz von Medizin und Technologie entscheidende Risikofaktoren oft ausgeblendet werden. Die folgenden Ausführungen sind aus zahlreichen kollegialen Kooperationen, Gesprächen mit Branchenvertretern, gelungenen wie gescheiterten Projekten und persönlichen Beobachtungen entstanden, und sollen als praxisnaher Leitfaden dienen.
1.1 Der regulatorische Irrgarten
Fehleinschätzungen bezüglich regulatorischer Anforderungen können fundamental sein. Das wurde in der Zusammenarbeit zwischen einem KI-Start-up und einem traditionellen Medizingerätehersteller jedoch erst zu spät deutlich. Das Start-up, frisch mit einer hohen Summe an Risikokapital finanziert, war überzeugt, seine Produktidee würde binnen sechs Monaten Marktreife erlangen. Die ernüchternde Realität der EU-Anforderungen traf das Team dann unvorbereitet. „Wir haben unsere Technologie bereits in drei anderen Branchen implementiert – so anders kann das im Medizinbereich doch nicht sein”, lautete der Tenor eines frühen Meetings. Ein klassischer und kostspieliger Irrtum, wie sich später herausstellte. Das Projekt scheiterte an den versteckten regulatorischen Fallstricken, die selbst erfahrene Projektmanager übersehen.
1.2 Die Dokumentationsfalle
In der Softwareentwicklung außerhalb des Medizinsektors ist Dokumentation oft nachrangig gegenüber funktionierendem Code. In der Medizintechnik hingegen gilt der Grundsatz: „Was nicht dokumentiert ist, existiert nicht.” Die schiere Menge an erforderlichen Dokumenten überfordert technologieorientierte Partner regelmäßig:
• | Risikomanagementsystem nach ISO 14971, |
• | Klinische Bewertung und Nachweise, |
• | Software-Entwicklungsdokumentation nach IEC 62304, |
• | Usability-Engineering nach IEC 62366-1, |
• | Post-Market-Surveillance-Systeme, |
• | Technische Dokumentation gemäß MDR Anhang II und III. |
Immer wieder realisieren Technologiepartner erst nach Monaten, welchen Dokumentationsaufwand die Entwicklung eines Medizinprodukts tatsächlich mit sich bringt.
1.3 Unterschätzte Zeitrahmen
„Time to Market (TTM)” ist ein Begriff, der in Kooperationsgesprächen oft für Missverständnisse sorgt. Während Technologieunternehmen in Monaten denken, müssen Medizintechnikhersteller in Jahren planen. Bei der Entwicklung eines vernetzten Dosierungssystems bestand der Technologiepartner auf vierteljährlichen Software-Updates, während der regulatorische Prozess für jede substanzielle Änderung mehrere Monate in Anspruch nahm. Nach zwei Jahren und erheblichen Investitionen wurde das Projekt eingestellt – nicht wegen technischer Probleme, sondern aufgrund unvereinbarer Prozessvorstellungen.
1.4 Der Fallstrick der Datenhoheit
Es gilt die provokante These: „In der Medizintechnik ist die DSGVO nur die Eintrittskarte – nicht das ganze Konzert.” Die Komplexität der datenschutzrechtlichen Anforderungen wird durch sektorspezifische Regelungen, ethische Überlegungen und internationale Unterschiede potenziert. Ein mittelständischer Hersteller bildgebender Systeme machte eine besonders lehrreiche Erfahrung: Die Kooperation mit einem Cloud-Anbieter für KI-gestützte Bildanalyse erschien zunächst vorteilhaft. Im Kleingedruckten des Vertrags verbarg sich jedoch eine Klausel, die dem Technologiepartner weitreichende Rechte an den anonymisierten Daten einräumte. Als der Cloud-Anbieter später eine eigene Diagnostiklösung auf den Markt brachte, musste der Medizintechnikhersteller erkennen, dass er indirekt zur Entwicklung eines Konkurrenzprodukts beigetragen hatte.
1.5 Sicherheitskulturen prallen aufeinander
Besondere Herausforderungen entstehen bei der Integration von Drittanbieter-Software. Das ernüchternde Fazit eines Partners: „Die unterschiedlichen Sicherheitskulturen sind oft unvereinbar. Während wir jede Codezeile auf Herz und Nieren prüfen, arbeiten manche Partner noch nach dem Motto ‚Ship now, patch later’.”
Eine besonders kritische Konstellation entsteht, wenn das Medizinprodukt selbst sicher ist, aber die Infrastruktur, in die es eingebettet wird, Schwachstellen aufweist. Bei der Sicherheitsanalyse eines vernetzten Patientenmonitors zeigte sich, dass der Großteil der potenziellen Angriffsvektoren nicht im Gerät selbst, sondern in den angebundenen IT-Systemen lag.
1.6 Wenn Unternehmenskulturen kollidieren
Die „weichen Faktoren” sind bei Partnerschaften oft die härtesten Nüsse. Die kulturellen Unterschiede zwischen etablierten Medizintechnikunternehmen und agilen Technologie-Start-ups lassen sich nicht mit einem Vertragswerk überwinden. Hier spielen menschliche Aspekte („Human Factors”) oft eine existenziell wichtige Rolle. Ingenieure eines Medizintechnikunternehmens präsentierten bei einem Workshop für ein neues Joint Venture einen hundertseitigen Anforderungskatalog. Das Entwicklerteam des Software-Partners konterte mit einem vierseitigen „Minimal Viable Product”-Konzept. Beide Seiten verließen den Raum mit dem Gefühl, nicht gehört und respektiert zu werden.
In den folgenden Wochen entstand ein Phänomen, welches man als „begriffliche Scheineinigkeit” bezeichnen könnte: Beide Partner verwendeten dieselben Wörter – „Qualität”, „Validation”, „Testing” – verstanden darunter aber völlig unterschiedliche Dinge.
1.7 Die Asymmetrie im Wissenstransfer
Ein unterschätztes Risiko liegt in der ungleichen Verteilung des Wissenstransfers, schließlich müssen die beiden Welten Medizin und Technik zusammengebracht werden. Um der Problematik in Kooperationen fortan zu begegnen, hat ein Medizintechnikhersteller eine interessante Lösung entwickelt: Er bildet nun bewusst „Zweierteams” aus je einem eigenen Mitarbeiter und einem des Technologiepartners. Jedes Team ist für einen klar definierten Produktbereich verantwortlich. Eine erfolgreiche Strategie: „Früher haben wir unser medizinisches Know-how weitergegeben und kaum technologisches Wissen zurückerhalten. Mit den Tandems stellen wir sicher, dass der Wissenstransfer in beide Richtungen fließt.”
1.8 Die Anwenderperspektive: Oft vernachlässigt, immer entscheidend
Sachverständige erleben regelmäßig die Diskrepanz zwischen technologischer Begeisterung und klinischer Realität. Viele Produkte, die aus Technologiepartnerschaften hervorgehen, lösen Probleme, die in der Praxis nicht existieren – oder schaffen neue: „Wir haben die Lösung – wo ist jetzt das Problem?”.
Ein plastisches Beispiel zeigte sich bei der Einführung eines „revolutionären” Patientenmonitoring-Systems auf einer kardiologischen Station. Das System bot beeindruckende technische Features und eine elegante Smartphone-App. Was es nicht bot, war eine nahtlose Integration in den klinischen Workflow. Die Pflegekräfte mussten nun zusätzlich zur bestehenden Dokumentation die neue Software bedienen.
Der versprochene Effizienzgewinn verkehrte sich in sein Gegenteil. Nach einigen Monaten wurde das System trotz erheblicher Investitionen mangels Akzeptanz wieder abgeschafft.
1.9 Die Validierungskluft
Ein weiteres kritisches Problem entsteht, wenn die klinische Validierung nicht mit der technologischen Entwicklung Schritt halten kann. Bei einem KI-gestützten Diagnosesystem für Hautkrebs entstand folgende Situation: Das System wurde unter kontrollierten Bedingungen mit hochqualitativen Bildern von hellhäutigen Menschen trainiert und validiert. In der klinischen Praxis – mit unterschiedlichen Beleuchtungsverhältnissen, Kamerawinkeln und Hauttypen – sank die Erkennungsrate dramatisch. Bei dunkelhäutigen Bildern versagte die KI gänzlich.