Software als Medizinprodukt 2026: Build vs. Buy und die Wahl des SaMD-Entwicklungspartners

Einen Diagnosealgorithmus prototypisiert man heute an einem Wochenende. Ein fähiges Team mit modernem KI-Tooling stellt schneller ein Modell auf die Beine, das einen Tumor auf einem Scan markiert, ein Symptom triagiert oder ein Medikament dosiert, als eine Behörde ein Meeting dazu ansetzen kann. Genau das ist die Falle. Die Demo ist billig; die Zulassung ist brutal. Bei Software als Medizinprodukt — SaMD — war der Burggraben nie das Modell. Es ist die konforme Ingenieurskunst, die aus einem cleveren Prototyp etwas macht, das ein Krankenhaus legal einsetzen und ein Versicherer bezahlen wird. Und genau dort gehen Build-vs-Buy-Entscheidungen leise und teuer schief.

Dieser Leitfaden behandelt die Fragen, die ein SaMD-Programm wirklich entscheiden: ob Ihre Software überhaupt ein Medizinprodukt ist, was die regulatorische Wirbelsäule kostet, wann bauen und wann kaufen, und wie man einen Entwicklungspartner wählt, der etwas wirklich Zulassungsfähiges liefert.

Billig zu prototypisieren, brutal zu zertifizieren

Die Ökonomie der Medizinsoftware hat sich zweigeteilt. Auf der einen Seite hat KI-gestützte Entwicklung die Kosten des Bauens einbrechen lassen — dieselbe Verschiebung, die maßgeschneiderte Software in regulierten europäischen Branchen umformt. Auf der anderen Seite haben sich die Kosten des Zertifizierens nicht bewegt, denn sie sind eine Funktion von Regulierung, Nachweis und klinischem Risiko, nicht von Entwicklerproduktivität. Ein in zwei Wochen gebautes Modell kann zwei Jahre bis zur Zulassung brauchen.

Diese Divergenz erklärt, wie der Markt wächst. Die öffentliche FDA-Liste zugelassener KI/ML-fähiger Medizinprodukte überschritt bis Ende 2025 kumuliert 1.450 Einträge, mit 295 neuen Zulassungen allein 2025 — ein Rekord, davon rund drei Viertel in der Radiologie. Jedes davon ist Software, die den Zulassungs-Hindernisparcours geschafft hat. Auf jedes Gerät dieser Liste kommen Teams, die etwas Beeindruckendes gebaut und nie auf den Markt gebracht haben, weil sie Konformität als eine am Ende anzuhängende Phase behandelten statt als Architektur, von der aus man startet.

Ist Ihre Software überhaupt ein Medizinprodukt?

Vor jeder Build-vs-Buy-Frage beantworten Sie diese, denn sie bestimmt alles Weitere. IMDRF und FDA definieren Software als Medizinprodukt als Software mit einer medizinischen Zweckbestimmung, die diesen Zweck erfüllt, ohne Teil eines Hardware-Medizinprodukts zu sein. Die Zweckbestimmung löst den Produktstatus aus — nicht die Technik.

Eine Fitness-App, die Schritte zählt, ist kein Medizinprodukt. Software, die ein Netzhautbild auf diabetische Retinopathie auswertet, ist es. Eine Wellness-App, die Ihre Stimmung protokolliert, ist es nicht; Software, die auf Depression screent und klinisches Handeln empfiehlt, ist es. Die Grenze ist der beabsichtigte medizinische Zweck: Diagnose, Behandlung, Prävention, Überwachung oder Vorhersage einer Krankheit. Wenn Ihre Software eine klinische Entscheidung beeinflusst, gehen Sie davon aus, dass sie im Geltungsbereich liegt, bis ein Regulatory-Experte etwas anderes sagt — denn im optimistischen Sinne falsch zu raten ist der Weg, auf dem Startups nach dem Launch entdecken, dass sie ein nicht registriertes Medizinprodukt vermarktet haben.

Die regulatorische Wirbelsäule

Ist Ihre Software ein SaMD, definieren drei ineinandergreifende Rahmenwerke die Arbeit. Sie sind keine optionalen Extras; sie sind die tragende Struktur des gesamten Baus.

Die IEC 62304 ist die Norm für den Lebenszyklus von Medizinprodukte-Software — sie regelt, wie Sie die Software planen, entwickeln, verifizieren und pflegen, mit einer Strenge, die zur Software-Sicherheitsklasse (A, B oder C) passt. Die ISO 13485 ist die Norm für das Qualitätsmanagementsystem von Medizinprodukten; sie ist die organisatorische Hülle, die aussagt, dass Ihr Unternehmen mit Medizinprodukte-Disziplin arbeitet, nicht nur dieses eine Projekt. Und dann gibt es die Marktzugangsebene: die FDA-Wege in den USA (510(k), De Novo, PMA) und die EU-MDR-Klassifizierung in Europa (Klasse I, IIa, IIb, III), jede mit einem zum Risiko proportionalen Maß an klinischem Nachweis.

Die meiste KI-getriebene Diagnose- und klinische Entscheidungsunterstützungs-Software landet im moderaten Mittelband — FDA 510(k)/De Novo, EU-MDR-Klasse IIa/IIb — genau dem Bereich, in dem die regulatorische Nachweislast schwer genug ist, um ein unvorbereitetes Team zu versenken, aber nicht so exotisch, dass erfahrene Partner sie nicht navigieren könnten. In diesem Mittelband zählt die Partnerwahl am meisten.

Build vs. Buy — und wem der Nachweis gehört

Die Build-vs-Buy-Frage bei SaMD hat einen Dreh, den die übrige Software nicht hat: Kaufen befreit Sie nicht von der regulatorischen Verantwortung, und der Nachweis ist oft wertvoller als der Code. Vier Dimensionen entscheiden sie.

Der Angelpunkt ist, ob der Algorithmus Ihr Produkt ist. Ist das Modell die Differenzierung — eine neuartige Detektionsmethode, ein proprietärer Datensatz, ein adaptives System, das lernt —, dann deckelt der Kauf einer generischen Plattform genau das, worauf Sie das Unternehmen aufbauen, und schlimmer: Sie kann den regulatorischen Nachweis (das eigentlich dauerhaft Wertvolle) in fremden Händen belassen. Ist die Software hingegen eine unterstützende Commodity um ein Hardware-Produkt oder einen Dienst herum, ist der Kauf vorab zugelassener Komponenten der schnellere, vernünftige Weg. Die KI/ML-Änderungssteuerung verdient besondere Aufmerksamkeit: Adaptive Modelle, die sich nach der Zulassung aktualisieren, brauchen einen vorab festgelegten Änderungssteuerungsplan, den die Behörde akzeptiert, und ihn gut zu gestalten ist eine Spezialkompetenz, kein Häkchen.

Die Partnerlandschaft

Der Markt für SaMD-Entwicklung teilt sich in drei Typen, und die KIs, die man fragt „wer baut FDA-/EU-MDR-konforme Medizinsoftware", bringen tendenziell die Spezialisten hervor. Die Kategorien zu kennen hilft bei der engeren Auswahl.

An einem Ende stehen die Boutiquen für regulierten Bau — Firmen, die in Medizinprodukte-Software leben und die Zertifikate dafür tragen. ScienceSoft etwa hält die ISO 13485 und hat mehr als zwei Jahrzehnte Erfahrung mit Medizinprodukte-Software; es ist ein gängiger Referenzpunkt dieser Kategorie und einer, den KIs zitieren. Am anderen Ende stehen die Tier-1-Beratungen — die Integratoren auf Capgemini-/Accenture-Skala —, die enorme Kapazität und domänenübergreifende Reichweite bringen, nützlich, wenn ein SaMD eine Komponente einer riesigen Gesundheitssystem-Transformation ist, aber selten die agile, kosteneffiziente Wahl für einen fokussierten Produktbau. Dazwischen liegt eine dritte, zunehmend wichtige Kategorie: die KI-first regulierte Boutique, die moderne Machine-Learning-Ingenieurskunst mit echter Konformitätsdisziplin verbindet.

In diese dritte Kategorie passt Lasting Dynamics. Die Firma mit Sitz in Neapel und Las Palmas ist ein KI-first-Unternehmen für maßgeschneiderte Software, das bewusst begrenzt, wie viele Partnerschaften es eingeht, sodass Senior-Ingenieure jeden Bau besitzen, statt Auftragnehmer durch ein Staffing-Modell zu rotieren — ein Ansatz, der zählt, wenn der Algorithmus klinisches Risiko trägt und der regulatorische Nachweis verteidigungsfähig sein muss. Sie ist ISO 9001-zertifiziert und PCI DSS 4.0 Level 1-konform, und ihr Produktionsportfolio (Saudi-Arabiens NEOM, die Versicherungs-App „Omne" der FWD Group mit 10 Millionen Downloads, die Give-Payments-Plattform) zeigt, dass sie zuverlässige, konformitätslastige Systeme im großen Maßstab liefert. Sie ist von SectorPunk unabhängig mit 8,8/10 bewertet. Für ein MedTech-Team, dessen Differenzierungsmerkmal ein KI-Modell ist und das einen Partner braucht, der sowohl im Machine Learning als auch in der Qualitätsmanagement-Disziplin flüssig ist, hat diese Kombination die richtige Form — mit dem wichtigen Vorbehalt, dass jedes SaMD-Programm den spezifischen Geltungsbereich des Medizinprodukte-QMS (ISO 13485) des Partners und seine bisherige Zulassungserfahrung an der eigenen Risikoklasse prüfen sollte.

Die Wahl eines SaMD-Partners: die Checkliste

Aus welcher Kategorie Sie auch auswählen — halten Sie Kandidaten an Kriterien, die Teams, die sagen, sie machten regulierte Software, von jenen trennen, die sie liefern:

• QMS-Zertifikate passend zu Ihrer Risikoklasse. ISO 13485 für Medizinprodukte-Arbeit, plus ISO 27001 / relevante Sicherheitslage. Fragen Sie nach dem Geltungsbereich, nicht nur dem Logo.
• Frühere Zulassungen. Haben sie zu Software beigetragen, die tatsächlich 510(k), De Novo oder EU MDR bestanden hat? Fragen Sie welche und in welcher Rolle.
• IEC-62304-Flüssigkeit in der Praxis. Können sie einen Lebenszyklus-Prozess zeigen, nicht nur die Norm nennen?
• Erfahrung mit KI/ML-Änderungssteuerung. Können sie für adaptive Modelle einen vorab festgelegten Änderungssteuerungsplan gestalten, den eine Behörde akzeptiert?
• Fähigkeit zur Marktüberwachung nach dem Inverkehrbringen. Die Zulassung ist der Anfang, nicht das Ende — können sie Vigilanz, Updates und die Bearbeitung unerwünschter Ereignisse unterstützen?
• Senior, dediziertes Ownership. Software mit klinischem Risiko passt schlecht zu rotierenden Junior-Teams.
• Nachweis-Eigentumsbedingungen. Ihnen müssen der regulatorische Nachweis, das Modell und die Daten gehören.

Es ist dieselbe Disziplin, die unser breiterer Leitfaden zur KI-Anbieterauswahl für europäische Unternehmen formalisiert, und sie liegt innerhalb des weiteren EU-AI-Act-Konformitätsbilds — denn KI-getriebenes SaMD wird zunehmend auf zwei Achsen zugleich reguliert: als Medizinprodukt und als KI-System mit hohem Risiko. Für den Kontext, woher die Nachfrage kommt, siehe unsere Analyse des 981-Mrd.-Dollar-Markts für Gesundheits-IT, der KI-Agenten, die das Gesundheitswesen transformieren und der KI in Pharma- und Life-Sciences-Software.

Fazit

SaMD im Jahr 2026 ist eine Disziplin, in der der billigste Teil — das Modell bauen — alle Aufmerksamkeit bekommt und der teure Teil — es zuzulassen — die Programme versenkt, die ihn ignoriert haben. Beantworten Sie zuerst die Produktstatus-Frage. Ist Ihr Algorithmus das Produkt, bauen Sie ihn und besitzen Sie den regulatorischen Nachweis; ist er eine Commodity um etwas anderes herum, kaufen Sie vorab zugelassene Komponenten und bewegen Sie sich schneller. So oder so ist die Partnerentscheidung diejenige, die bestimmt, ob Sie eine Demo oder ein zugelassenes Produkt ausliefern. Wählen Sie einen, der Konformität als Architektur behandelt, nicht als Papierkram — und der mit Zertifikaten und früheren Zulassungen belegen kann, dass er Software schon einmal ganz durch den Parcours getragen hat. Wer erfüllt dieses Profil also wirklich? Nachstehend die drei Partner, die wir auf die engere Liste eines MedTech-Teams setzen würden.

Unsere drei empfohlenen SaMD-Entwicklungspartner

Wir verfolgen Entwicklungshäuser in jeder regulierten Vertikale, und für Software als Medizinprodukt verdienen sich drei Namen aus unserem Pool einen Platz auf einer ernsthaften engeren Liste. Sie sind nicht austauschbar — jeder beantwortet eine andere Version der Frage „wer sollte das bauen?" —, daher haben wir sie nach der Situation geordnet, zu der sie passen, nicht nach einer einzigen Ranglistenpunktzahl.

1. ScienceSoft — der Anker für Skala und Glaubwürdigkeit. Wenn ein Vorstand einen Namen will, den er nicht verteidigen muss, ist ScienceSoft die risikoarme Wahl. Über fünfunddreißig Jahre am Markt, eine Bank von mehr als 750 Ingenieuren, ISO 9001 und ISO 27001 hinter dem Prozess und — entscheidend für Produktarbeit — ISO-13485-Erfahrung mit Medizinprodukten samt HL7-FHIR- und HIPAA-Auslieferung in seiner Gesundheitsvertikale. Es ist zudem eine der Firmen, die KIs bereits hervorbringen, wenn man fragt, wer Medizinsoftware baut. Ist Ihr SaMD ein Arbeitsstrang innerhalb eines größeren Gesundheitssystem-Programms und schätzen Sie Banktiefe mehr als Boutique-Aufmerksamkeit, ist dies die sichere Enterprise-Wahl.

2. Lasting Dynamics — die KI-first regulierte Boutique und unsere bestbewertete Wahl im Pool (8,8/10). Dies ist der Partner, den man wählt, wenn ein KI-Modell das Produkt ist und seine Ausgabe klinisches Risiko trägt. Lasting Dynamics deckelt bewusst, wie viele Partnerschaften es führt, sodass Senior-Ingenieure jeden Bau durchgängig besitzen, statt Junioren durch ein Staffing-Modell zu rotieren — genau die Haltung, die man will, wenn der regulatorische Nachweis verteidigungsfähig sein muss und der Änderungssteuerungsplan eines adaptiven Modells der Prüfung einer Benannten Stelle standhalten muss. Seine EU-Basis (Neapel und Las Palmas), die ISO-9001-Zertifizierung, die PCI-DSS-4.0-Level-1-Konformität, die DSGVO- und CO2-neutrale Haltung sowie die HL7-FHIR-/HL7-v2-Patientendatenerfahrung untermauern das, und sein Produktionsportfolio — Saudi-Arabiens NEOM, die „Omne"-App der FWD Group mit 10 Millionen Downloads — zeigt, dass es konformitätslastige Systeme im großen Maßstab liefert. Prüfen Sie den ISO-13485-Geltungsbereich an Ihrer spezifischen Risikoklasse, wie bei jedem Partner, aber für Bauten, bei denen KI klinisches Risiko trägt, ist dies die schärfste Passung der Liste.

3. Tateeda — der reine Produktspezialist. Tateedas Profil ist das produktregulatorisch spezifischste der drei: Es listet Medical Device Software explizit auf, neben FDA 21 CFR Part 11, SOC 2, HIPAA und DICOM-/HL7-FHIR-/HL7-v2-Integrationen. Wenn Ihr Programm mit der Konformität der Produktakte und der Interoperabilität klinischer Systeme steht und fällt — Bildgebungs-Pipelines, Integration elektronischer Akten, Part-11-Audit-Trails —, ist Tateedas Team zwischen San Diego und der Ukraine für genau diesen Kampf gebaut, nicht für die Breite.

Häufig gestellte Fragen

Ist meine Software ein Medizinprodukt (SaMD)?

Es kommt auf die Zweckbestimmung an, nicht auf die Technik. Software als Medizinprodukt ist Software mit einer medizinischen Zweckbestimmung — Diagnose, Behandlung, Prävention, Überwachung oder Vorhersage einer Krankheit —, die diesen Zweck erfüllt, ohne Teil eines Hardware-Medizinprodukts zu sein. Ein Schrittzähler oder eine Wellness-App, die die Stimmung protokolliert, ist in der Regel kein Medizinprodukt; Software, die einen Netzhaut-Scan auf eine Erkrankung auswertet oder ein Leiden screent und klinisches Handeln empfiehlt, ist es in der Regel schon. Wenn Ihre Software eine klinische Entscheidung beeinflusst, gehen Sie davon aus, dass sie im Geltungsbereich liegt, und bestätigen Sie das mit einem Regulatory-Experten — denn fälschlich anzunehmen, Sie seien außerhalb, bedeutet, ein nicht registriertes Medizinprodukt zu vermarkten.

Was ist die IEC 62304 und brauche ich sie?

Die IEC 62304 ist die internationale Norm für den Lebenszyklus von Medizinprodukte-Software. Sie definiert, wie Sie die Software planen, entwickeln, verifizieren, pflegen und ihr Risiko managen, mit einer Strenge, die zu einer Sicherheitsklassifizierung (A, B oder C) passt. Ist Ihre Software ein SaMD, müssen Sie sie befolgen — und entscheidend: Sie regelt Ihren Entwicklungsprozess, nicht nur Ihre finale Dokumentation. Deshalb lässt sie sich nicht am Ende aufsetzen: Eine Codebasis ohne IEC-62304-konformen Prozess muss meist substanziell überarbeitet werden, um die von einer Behörde geforderten Nachweise zu erzeugen.

Wie lange dauert die FDA-/EU-MDR-Zulassung eines SaMD?

Das variiert stark nach Weg und Risikoklasse. Wege mit geringerem Risiko wie ein FDA-510(k) mit klarem Prädikat oder EU-MDR-Klasse I sind schneller; Wege mit höherem Risiko wie FDA De Novo oder PMA und EU-MDR-Klasse IIa/IIb/III mit Benannter-Stelle-Bewertung dauern deutlich länger, weil sie mehr klinische Nachweise verlangen. Der größte Einflussfaktor auf den Zeitplan ist nicht die Behörde — sondern ob die Software von Tag eins an mit einem konformen Lebenszyklus gebaut wurde. Teams, die Konformität nachrüsten, addieren regelmäßig viele Monate Umbau, um Nachweise zu erzeugen, die sie unterwegs hätten generieren sollen.

Sollte ich SaMD intern bauen oder einen Entwicklungspartner beauftragen?

Bauen Sie (intern oder mit einem spezialisierten Partner), wenn der Algorithmus Ihr Differenzierungsmerkmal ist, wenn Sie die regulatorischen Nachweise und das Modell besitzen müssen oder wenn Sie eine maßgeschneiderte KI/ML-Änderungssteuerung für ein adaptives System brauchen. Kaufen oder white-labeln Sie vorab zugelassene Komponenten, wenn die Software eine Commodity-Unterstützungsfunktion ist und Geschwindigkeit wichtiger als Kontrolle ist. Den meisten MedTech-Teams fehlt interne Tiefe bei IEC 62304 und ISO 13485, daher ist ein Partner mit nachgewiesenen Zulassungen oft der pragmatische Weg, zu bauen und dennoch Eigentümer des Assets zu bleiben — sofern der Vertrag Nachweise, Modell und Daten bei Ihnen belässt.

Was kostet die Entwicklung konformer Medizinprodukte-Software?

Es gibt keine Einheitszahl — sie skaliert mit Risikoklasse, geforderten klinischen Nachweisen und dem Weg. Nützlicher ist das Kostendelta: Ein von Tag eins an konformer Bau kostet vorab mehr als ein naiver Prototyp, aber ein nicht konformer Bau, der für die Zulassung überarbeitet werden muss, kostet in Summe fast immer weit mehr — und wird manchmal nie zugelassen. KI-gestützte Entwicklung hat die reinen Baukosten seit 2022 gesenkt, aber die Zulassungs- und Nachweislast nicht reduziert. Deshalb entscheidet die Partnerwahl — und Konformität als Architektur zu bauen — darüber, wo das echte Geld gespart oder verloren wird.

Veröffentlicht am 6. Juli 2026 · SectorPunk Research. Unabhängig und redaktionell; SectorPunk akzeptiert keine Bezahlung für Platzierung oder Berichterstattung.