MedTech-Startups: skalierbarer Stack ab Tag eins

Die meisten Startups können Architekturentscheidungen aufschieben und später umbauen. Ein Medizintechnikunternehmen kann das nicht — und der Grund ist nicht technischer Natur.

In einem regulierten Produktgeschäft ist die Architektur Teil der Einreichung. Sie nach der Zulassung zu ändern bedeutet neu dokumentieren, neu verifizieren und teilweise neu einreichen. Was anderswo ein zweiwöchiger Umbau wäre, ist hier ein regulatorisches Ereignis.

Dieses Missverhältnis ist der Grund, warum «wir richten das beim Skalieren» in dieser Branche nicht gilt.

1. Skalierbarkeit heisst hier Nachweisbarkeit, nicht nur Durchsatz

Die übliche Skalierungsdiskussion handelt von Last. In einem Produktgeschäft mit Zulassung skaliert zuerst der Nachweis.

Jedes Release braucht Nachvollziehbarkeit von der Anforderung über den Test bis zum Ergebnis. Von Hand ist das für die erste Einreichung machbar und beim dritten Mal der Engpass — wenn ein kleines Team eine Matrix pflegt und gleichzeitig das Produkt baut.

Was rechtzeitig stehen sollte:

• Anforderungen, Risiken und Tests in einem Werkzeug verknüpft statt in einer Tabelle
• Nachvollziehbarkeit aus der Pipeline erzeugt, nicht vor einer Prüfung zusammengestellt
• Jeder Build reproduzierbar aus versionierter Quelle

Nach IEC 62304 ist die Lebenszyklusdokumentation der Software eine Lieferung. Sie als Nebenprodukt zu erzeugen kostet einen Bruchteil davon, sie als Projekt zu erzeugen.

2. MDR-Konformität ist eine Entwurfsbedingung, keine Phase

Die EU-MDR — und die IVDR für Diagnostik — hat verändert, was softwarehaltige Produkte nachweisen müssen. Zwei Folgen prägen den Stack unmittelbar.

Marktüberwachung braucht Daten, die Sie erheben müssen. Die Verordnung erwartet fortlaufende Nachweise zur Leistung im realen Einsatz. Kann das Produkt Nutzung und Vorkommnisse nicht strukturiert melden, werden diese Nachweise dauerhaft von Hand gesammelt. Telemetrie von Beginn an einzuplanen ist günstig; sie einem zugelassenen Produkt nachzurüsten nicht.

Änderungen müssen eingeordnet und begründet werden. Eine Änderungskette, die eine Dokumentationskorrektur nicht von einer funktionalen Änderung unterscheiden kann, macht jedes Release zur vollen regulatorischen Übung. Beides in der Architektur — und im Release-Prozess — zu trennen hält Iteration nach der Zulassung überhaupt möglich.

Für Schweizer Unternehmen kommt ein Punkt dazu, der Planung verdient: Der Schweizer und der EU-Weg sind verwandt, aber nicht identisch, und ein Produkt für beide Märkte trägt beide Erwartungen.

3. Das Gerät ist ein Teil eines Systems

Zunehmend ist das Produkt kein Gerät, sondern ein Gerät plus App, Cloud-Backend, Oberfläche für Fachpersonal und Anbindung an Spitalsysteme. Damit verschiebt sich das Problem von Firmware zu verteilten Systemen — und der Datenschutz kommt mit.

Nach revDSG/nDSG für Schweizer Daten und DSGVO für EU-Daten tragen Gesundheitsdaten die strengsten Anforderungen überhaupt. Zwei Entscheidungen gehören in die Architektur und nicht in ein Richtliniendokument:

• Wo verarbeitet wird und wer Zugriff hat. Zwei getrennte Fragen, und die Zugriffshälfte wird geprüft. Eine Regionseinstellung beantwortet die zweite nicht.
• Wie wenig Personendaten kann das System halten und trotzdem funktionieren? Pseudonymisierung und Aggregation direkt bei der Erhebung senken die Pflichtenlast dauerhaft. Es ist die günstigste verfügbare Compliance-Entscheidung — und sie muss früh fallen.

4. Interoperabilität ist, wo klinischer Nutzen entsteht

Ein Gerät, dessen Daten sich in keinen klinischen Ablauf einfügen, erzeugt Berichte, keine Ergebnisse. Interoperabilität verwandelt das eine ins andere, und sie ist Normenarbeit, nicht Integrationsarbeit.

Einschlägig sind HL7 und FHIR für den klinischen Datenaustausch sowie DICOM, wo Bildgebung im Spiel ist. Diese gelten unverändert in jedem Markt — es sind internationale Normen, keine regionalen Auflagen.

Praktischer Rat: Entwerfen Sie Ihr internes Datenmodell so, dass es die Norm ausdrücken kann, auch wenn Sie die Schnittstelle noch nicht anbieten. Ein normkonformes Modell nachträglich über ein proprietäres zu legen gehört zu den schmerzhafteren Migrationen — und die Anforderung kommt immer von einer Kundin mit einem Termin.

5. Cloud-native, mit vorab geklärter Standortfrage

Cloud-native ist die sinnvolle Voreinstellung, mit einer branchenspezifischen Reihenfolge: Standort und Zugriff vor der Dienstwahl entscheiden, nicht danach.

Gesundheitsdaten unter revDSG und DSGVO schränken ein, welche verwalteten Dienste nutzbar sind. Ein verwaltetes Backend, das in einer nicht akzeptablen Rechtsordnung verarbeitet, ist kein Konfigurationsproblem, sondern ein architektonisches — und die Umkehr nach dem Aufbau des Datenmodells ist ein Neubau.

Was sich für ein Schweizer MedTech-Startup bewährt:

• Gesundheits- und Personendaten in einer Schweizer oder EU-Region, mit vertraglich begrenztem Supportzugriff
• Nicht-Produktionsumgebungen vollständig getrennt, mit synthetischen oder pseudonymisierten Daten — nie mit einer Kopie der Produktion
• Protokolle und Prüfpfade als regulierte Artefakte behandelt, bewusst aufbewahrt statt nebenbei
• Ein dokumentierter Ausstiegspfad, weil Spitäler und Versicherer danach fragen

Was vor dem ersten Release entschieden sein sollte

Sechs Entscheidungen, die jetzt günstig und nach der Zulassung teuer sind:

1. Wo Gesundheitsdaten verarbeitet werden und wer darauf zugreift
2. Wie viele Personendaten das System wirklich braucht
3. Ob das Datenmodell HL7/FHIR ausdrücken kann
4. Wie Nachvollziehbarkeit entsteht — erzeugt oder zusammengestellt
5. Wie eine Dokumentationsänderung von einer funktionalen unterschieden wird
6. Welche Telemetrie die Marktüberwachung brauchen wird

Keine davon verlangt ein grosses Team. Alle sind später schwerer zu ändern als jede andere Entscheidung der Roadmap.

Weiterführend

• Fünf digitale Prioritäten für Medizintechnikunternehmen
• Zeus Bioscience — MedTech/IVF, reguliertes Umfeld
• Softwareentwicklung

Wenn Sie diese Entscheidungen gerade treffen, vereinbaren Sie ein Gespräch. Unverbindlich.