Written by:
Last Published:
29. Oktober 2026
•
Software für klinische Studien ist jede Anwendung, die zur Planung, Durchführung oder Analyse einer klinischen Studie verwendet wird. Um sie erfolgreich zu entwickeln oder zu bewerten, muss man mit ihrem Inhalt beginnen: Datensätze, die Studiendaten oder behördliche Einreichungen stützen, oder personenbezogene Daten. Diese Antwort bestimmt, wie die Software validiert, gesichert, gehostet und geprüft werden muss und welche Kosten bei Fehlern entstehen.
Dieser Leitfaden richtet sich an CTOs, Produktleiter und Technologiemanager bei Auftragsforschungsinstituten (CROs), Sponsoren und HealthTech-Anbietern. Wenn Sie Software für klinische Studien für CROs entwickeln, kaufen oder bewerten, hilft Ihnen dieser Leitfaden bei der Einschätzung von drei Aspekten: den regulatorischen Anforderungen, den Kosten bei Fehlentscheidungen und der Entscheidung zwischen Eigenentwicklung oder Zukauf.
Unsere Perspektive basiert auf einem realen Projekt. Aurora Analytica hat gemeinsam mit uns die Geo Matrix Decision Engine entwickelt, ein Tool zur Szenarioplanung für klinische Studien, das CROs dabei unterstützt, Szenarien zu simulieren, bevor sie sich für reale Abläufe entscheiden. Wir beleuchten die geltenden Regeln, welche technischen Entscheidungen eine genauere Prüfung erfordern und was eine Fehlentscheidung kostet.
Ein Hinweis zum Umfang: Wir behaupten nicht, dass die Geo Matrix über eine Zertifizierung verfügt. Wir beschreiben nicht, welche Daten die Nutzer in das System laden, und wir veröffentlichen keine Ergebnisdaten des Projekts. Wir nutzen es als Beispiel, um aufzuzeigen, wo die Fragen beginnen. Dies stellt keine Rechtsberatung dar; die letzte Entscheidung liegt bei Ihrer Rechtsabteilung für regulatorische Fragen.
Die Regulierung beginnt dort, wo Software für klinische Studien Datensätze erstellt, ändert oder speichert, die Studiendaten oder behördliche Einreichungen stützen, oder wo sie personenbezogene Daten verarbeitet. Dieser Geltungsbereich umfasst alles von der elektronischen Datenerfassung bis zur Szenarioplanung. Planungstools liegen oft knapp außerhalb dieser Grenze, aber nicht immer.
Stellen Sie sich einen Zollgrenzübergang vor. Ein Tool kann den ganzen Tag direkt daneben arbeiten, ohne jemals die Grenze zu überschreiten. Laden Sie es jedoch mit der falschen Fracht (etwa Datensätzen, die in eine Einreichung einfließen, oder Daten auf Teilnehmerebene) und schon landet es in der Inspektionsschlange. Der Code hat sich nicht geändert. Die Fracht schon.
Wir nutzen eine zentrale Frage, um den Rest dieses Artikels zu strukturieren: den sogenannten Fracht-Test. Welche Fracht befördert das Tool? Wie gelangt diese Fracht hinein und wieder hinaus? Und welche Unterlagen belegen, dass sie ordnungsgemäß gehandhabt wurde?
Fracht steht für Daten und Datensätze. Die Übergänge sind Logins, Integrationen, Importe und Exporte. Die Unterlagen umfassen Validierung, Audit-Trails und Dokumentation.
Aurora Analytica asked us to build the Geo Matrix Decision Engine, the first decision engine in its Aurora Suite. It lets CROs run scenarios with custom data and see the results on a world map, so they can predict outcomes virtually before real-world implementation, for example when answering requests for information and requests for proposals (RFIs and RFPs).
The wider Aurora Suite is a web application that covers areas such as trial design, country and site selection and clinical operations. Aurora Analytica developed 11 Decision Engines that perform more than 14 assessments for planning, designing and running clinical trials. The Geo Matrix was the first.
Day to day, the engine offers:
Under the hood, the front end uses Next.js, React and Redux (plus Papa Parse for CSV handling), with authentication through Auth0 by Okta. The back end runs on Nest.js and Prisma, with PostgreSQL as the database and AWS for hosting.
We worked through a minimum viable product (MVP) approach, where product owners, developers and UX/UI designers agree the core features first. Under our Managed Project Working Model, we supplied the whole team: front-end and back-end developers, designers and project managers. You can read the full story in the Aurora Analytica case study.
What does a tool like this do? It moves a costly decision earlier, to a point where changing your mind is cheap. A simulation does not replace a trial. It helps you decide which trials are worth running.
Verzögerungen sind der teure Teil. Das Tufts Center for the Study of Drug Development (Tufts CSDD) beziffert die direkten Kosten eines Verzögerungstages auf etwa 23.700 USD für eine Phase-II-Studie und 55.700 USD für eine Phase-III-Studie, zuzüglich etwa 800.000 USD pro Tag an potenziell entgangenen Umsätzen durch verschreibungspflichtige Medikamente. Software ist nur ein Faktor von vielen, aber einer, den Sie kontrollieren können.
Diese Zahlen basieren auf US-Dollar-Werten von 2023 und stützen sich auf Verkaufsdaten für 645 Medikamente und Budgetdaten für 447 Studienprotokolle. Betrachten Sie diese als Richtwerte, nicht als Prognosen.
Planungsentscheidungen haben ein ähnliches Gewicht. Eine Studie des Tufts CSDD aus dem Jahr 2012, beschrieben in Applied Clinical Trials, untersuchte fast 16.000 Prüfzentren in 151 globalen Phase-II- und III-Studien, die zwischen 2008 und 2010 durchgeführt wurden. Sie ergab, dass 11 % der Zentren, die bereit für die Rekrutierung waren, keine Patienten aufnahmen und dass 41 % dieser aktivierten Zentren ihre Rekrutierungsziele verfehlten. Deshalb erhalten die Durchführbarkeit klinischer Studien und die Auswahl der Prüfzentren so viel Aufmerksamkeit und deshalb gibt es Tools für die Simulation und Analyse klinischer Studien.
Für einen CEO, COO oder CFO ist unsere Sicht auf den Mehrwert einfach. Gute Tools machen sich auf drei Arten bezahlt:
Vier Entscheidungen sind am wichtigsten: wie Benutzer authentifiziert werden und was die jeweilige Rolle tun darf, wo Daten gehostet werden und wer dafür verantwortlich ist, wie Daten in das System gelangen und es wieder verlassen, und was das System über Änderungen protokolliert. Jede dieser Entscheidungen ist früh kostengünstig zu gestalten, aber teuer nachträglich zu implementieren. Aufsichtsbehörden und Kunden fragen nach allen vier Punkten.
Die Geo Matrix wickelt die Authentifizierung über Auth0 ab, einen verwalteten Identitätsanbieter. Identitätsmanagement ist eine Spezialaufgabe, die nur wenige Produktteams von Grund auf selbst entwickeln sollten.
Die Leitlinie zu computergestützten Systemen und elektronischen Daten in klinischen Studien der Europäischen Arzneimittel-Agentur (EMA) erfordert Kontrollen, die sicherstellen, dass nur autorisierte Personen Zugriff auf ein System haben, mit eindeutigen Benutzernamen, individuellen Konten und Zugriffsbeschränkungen nach dem Prinzip der geringsten Rechte. In den USA legt 21 CFR Part 11 entsprechende Anforderungen fest. Dies ist die Vorschrift der Food and Drug Administration (FDA) zu elektronischen Aufzeichnungen und Signaturen, die in Titel 21 des Code of Federal Regulations (CFR) zu finden ist. Sie fordert die Beschränkung des Systemzugriffs auf autorisierte Personen sowie elektronische Signaturen, die einer einzigen Person eindeutig zugeordnet sind.
Die Nutzung eines verwalteten Anbieters verlagert zwar die Arbeit, aber nicht die Verantwortung. Die EMA-Leitlinie ist in diesem Punkt unmissverständlich: Die Beauftragung eines Dienstleisters entbindet nicht von der Verantwortung für Datenintegrität, Sicherheit und Vertraulichkeit.
Das Hosting auf AWS ist Routine, und die EMA-Leitlinie behandelt Cloud- und On-Premises-Systeme gleich. Es gelten dieselben Erwartungen, und die verantwortliche Partei muss sicherstellen, dass der Anbieter qualifiziert ist. Ein nützliches Gedankenmodell ist das AWS-Modell der geteilten Verantwortung: Der Anbieter sichert die Cloud selbst ab, und Sie bleiben für das verantwortlich, was Sie darin ablegen und wie Sie es konfigurieren.
Für einen relationalen Datenspeicher wie PostgreSQL sollten Sie frühzeitig eine weitere Frage stellen: Welche Aufbewahrungsregeln gelten für die jeweilige Datenart, und bleibt beim Löschen an einer Stelle irgendwo anders eine Kopie zurück?
Jeder CSV-Pfad ist ein eigener Grenzübertritt. Für ein Tool mit Import- und Exportfunktion würden wir im Rahmen einer Designprüfung folgende Fragen stellen:
(Dies sind Fragen für jeden CSV-Workflow. Sie stellen kein Urteil über die Geo Matrix dar.)
Ein Audit-Trail ist die Aufzeichnung des Systems darüber, wer Daten erstellt, geändert oder gelöscht hat und wann dies geschah. Hier ist die regulierte Arbeit am wenigsten nachsichtig.
ICH E6(R3), die Leitlinie des International Council for Harmonisation zur guten klinischen Praxis (dritte Überarbeitung), erwartet, dass Änderungen an Quelldaten nachvollziehbar sind, ohne den ursprünglichen Eintrag zu verdecken. Die EMA-Leitlinie ist spezifischer: Ein Audit-Trail sollte für die Erstellung und Änderung aller elektronischen Daten aktiviert sein, und normale Benutzer sollten ihn nicht deaktivieren können. Part 11 fordert sichere, computergenerierte und zeitgestempelte Audit-Trails, wobei die FDA in ihrer Leitlinie von 2003 angibt, bei dieser Anforderung sowie bei der Validierung Ermessensspielraum bei der Durchsetzung auszuüben, und eine begründete, dokumentierte Risikobewertung empfiehlt.
Für eine Szenario-Engine ist unsere Ansicht, dass Reproduzierbarkeit die praktische Umsetzung dieses Konzepts darstellt. Wenn ein Ergebnis dazu beiträgt, eine Entscheidung in einer Ausschreibung zu rechtfertigen, wird irgendwann jemand fragen, welche Eingaben dazu geführt haben. Einem Tool, das diese Frage beantworten kann, vertraut man leichter, und es lässt sich leichter verkaufen.
Vier Quellen leisten den Großteil der Arbeit: ICH E6(R3) für gute klinische Praxis, die EMA-Leitlinie zu computergestützten Systemen für EU-Studien, 21 CFR Part 11 der FDA für elektronische Aufzeichnungen und Signaturen sowie die Datenschutz-Grundverordnung (DSGVO) für personenbezogene Daten. Welche davon für Ihre Software relevant sind, hängt davon ab, wo sie betrieben wird, welche Aufzeichnungen sie erstellt und wer sie nutzt.
| Quelle | Was sie abdeckt | Bedeutung für Software |
|---|---|---|
| ICH E6(R3) | Gute klinische Praxis, einschließlich Daten-Governance und computergestützter Systeme. In der EU seit dem 23. Juli 2025 wirksam (Grundsätze und Anhang 1). | Systeme sollten zweckmäßig sein, mit einer am Risiko ausgerichteten Validierung. Änderungen an Quelldaten sollten nachvollziehbar sein, und der Zugriff sollte sicher und zuordenbar sein. |
| EMA-Leitlinie zu computergestützten Systemen | Computergestützte Systeme, einschließlich Software as a Service, die zur Erstellung oder Erfassung elektronischer klinischer Daten oder zur Steuerung anderer Studienprozesse verwendet werden. Seit dem 9. September 2023 anwendbar. | Gilt für Sponsoren, Prüfer und ihre Dienstleister. Umfasst Validierung, Audit-Trails, Benutzerverwaltung und Cloud-Anbieter. |
| 21 CFR Part 11 | Elektronische Aufzeichnungen und elektronische Signaturen gemäß den Aufzeichnungsanforderungen der FDA sowie bei der FDA eingereichte elektronische Aufzeichnungen. Die FDA legt den Anwendungsbereich eng aus. | Validierung, sichere Audit-Trails, Zugriffsbeschränkungen und eindeutige elektronische Signaturen. |
| DSGVO | Personenbezogene Daten, wobei Gesundheitsdaten nach Artikel 9 als besondere Kategorie gelten. | Gilt, wenn Sie oder Ihre Kunden personenbezogene Daten im räumlichen Anwendungsbereich verarbeiten, einschließlich der Daten von Studienteilnehmern und, ja, der Konten Ihrer eigenen Nutzer. |
In der EU ist die Verordnung über klinische Prüfungen seit dem 31. Januar 2022 anwendbar, und Studien, die unter der alten Richtlinie genehmigt wurden, mussten bis zum 31. Januar 2025 umgestellt werden.
Gilt das alles also auch für ein Planungs- oder Entscheidungsunterstützungstool? Unserer Ansicht nach in der Regel nicht direkt. Unterlagen, die rein der internen Planung dienen, sind oft nicht die Dokumente, nach denen ein Inspektor fragt, auch wenn Entscheidungen zur Machbarkeit und Standortwahl im Trial Master File landen können.
Da Ihre Kunden jedoch die Verantwortung für die von ihnen genutzten Systeme tragen, werden sie Sie bitten, ihnen den Nachweis zu erleichtern. Anbieterfragebögen übernehmen die Sprache dieser Regeln, unabhängig davon, ob die Regeln Sie formell direkt betreffen oder nicht.
Die DSGVO verdient eine gesonderte Erwähnung. Selbst ein Tool, das niemals die Unterlagen eines Teilnehmers zu Gesicht bekommt, verarbeitet personenbezogene Daten: Benutzernamen, geschäftliche E-Mail-Adressen und Anmeldeaktivitäten zählen dazu.
Kaufen Sie ein, wenn ein ausgereiftes Produkt die Aufgabe bereits erfüllt und Ihr Wettbewerbsvorteil woanders liegt. Entwickeln Sie selbst, wenn der Arbeitsablauf spezifisch für Sie ist (etwa bei der Szenarioplanung auf Basis eigener Daten) oder wenn Sie mehrere Systeme miteinander verknüpfen müssen. Prüfen Sie in jedem Fall, wie sich das Tool in Ihre bestehenden Studien-Systeme einfügt, und behalten Sie die Validierung sowie die Anbieterqualifizierung im Blick.
Die meisten Technologie-Stacks für klinische Studien umfassen vier Systemarten, die man kennen sollte:
CRO-Software für Szenarioplanung oder Analysen ergänzt diese Systeme in der Regel, anstatt sie zu ersetzen. Daher ist die Integration die entscheidende Frage für die Eignung. Wenn das System Daten aus Ihrem EDC oder CTMS lesen oder dorthin schreiben kann, wird die Integration zu einem weiteren Kontrollpunkt.
Wenn Sie Optionen vergleichen (egal ob kommerzielle Produkte oder die kundenspezifische Entwicklung von Software für klinische Studien), empfehlen wir die Bewertung anhand von sechs Kriterien:
Anbieter berechnen ihre Preise unterschiedlich, zum Beispiel pro Studie, Standort, Nutzer oder Abonnement. Fragen Sie daher jeden Anbieter nach einer vollständigen Aufschlüsselung. Eine kundenspezifische Entwicklung wird nach Umfang berechnet. Unabhängig davon, wofür Sie sich entscheiden, sollten Sie Validierung und Änderungskontrolle als Teil der Kosten betrachten und nicht als Zusatzleistung.
Wenn Sie sich für eine Eigenentwicklung entscheiden, fangen Sie klein an. Wählen Sie einen Arbeitsablauf, stimmen Sie die Kernfunktionen mit den zukünftigen Nutzern ab und veröffentlichen Sie eine erste Version, so wie es das Aurora-Projekt mit seinem MVP getan hat.
Bevor Sie mit dem Programmieren beginnen, legen Sie fest, welche Daten die Software enthalten soll und welche Datensätze sie erstellt. Gehen Sie dann die Punkte Zugriff, Hosting, Datentransfer, Audit und Validierung in dieser Reihenfolge durch. Die folgende Liste wandelt den „Cargo-Test“ in Fragen um, die in einer Design-Überprüfung innerhalb einer Stunde beantwortet werden können.
Es handelt sich um jede Anwendung, die zur Planung, Durchführung oder Analyse einer klinischen Studie verwendet wird. Die Haupttypen sind EDC, CTMS, eTMF, IRT, Tools für patientenberichtete Ergebnisse sowie Analyse- oder Entscheidungsunterstützungstools wie die Aurora Analytica Geo Matrix. Wie streng die jeweilige Software reguliert wird, hängt von den erstellten Datensätzen und den gespeicherten Daten ab.
Es gibt nicht das eine beste Produkt. Die richtige Wahl hängt von Ihren Studienphasen, Ihrer Region, den bereits genutzten Systemen und dem benötigten Validierungssupport ab. Vergleichen Sie die Optionen anhand der sechs oben genannten Kriterien (regulatorische Eignung, Integration, Validierungssupport, Hosting, Revisionssicherheit und Gesamtkosten) und verlangen Sie von jedem Anbieter Belege statt Versprechungen.
Ein EDC dient der Erfassung klinischer Daten. Ein CTMS dient der Verwaltung der Studie: Prüfzentren, Meilensteine, Monitoring-Besuche und Budgets. Viele Sponsoren und CROs nutzen beides, oft in Kombination mit einem eTMF für essenzielle Dokumente.
Das hängt vom Umfang ab, daher gibt es keine seriöse Pauschale. Fünf Faktoren treiben die Kosten maßgeblich: die Anzahl der Benutzerrollen, die Anzahl der Integrationen, die Tiefe der Validierung, das Hosting-Modell und die Entscheidung zwischen Lizenzkauf oder Eigenentwicklung. Kalkulieren Sie Validierung, Änderungsmanagement und Support von Anfang an mit ein.
Beginnen Sie mit der Definition der Dateninhalte, da dies den regulatorischen Rahmen festlegt. Planen Sie Zugriffskontrollen, Audit-Trails und Integrationen von Anfang an ein, integrieren Sie die Validierung in die Entwicklung und fügen Sie Module erst hinzu, wenn das Fundament stabil ist. Der Abschnitt „Eigenentwicklung oder Kauf“ oben zeigt, wie man klein anfängt.
Wenn es sich um ein computergestütztes System handelt, das in einem regulierten Studienprozess eingesetzt wird, ja. Die verantwortliche Partei bleibt auch dann in der Pflicht, wenn sie sich auf die Dokumentation des Anbieters stützt. ICH E6(R3) fordert eine zweckmäßige und risikobasierte Validierung; der Umfang richtet sich also nach dem Risiko. Ein Tool zur Szenarioplanung benötigt eine dokumentierte Begründung für den Validierungsumfang. Ein System zur Erfassung von Studiendaten erfordert deutlich mehr.
Nicht automatisch. Part 11 gilt für elektronische Aufzeichnungen, die gemäß FDA-Anforderungen erstellt, geändert oder gespeichert werden, sowie für elektronische Einreichungen bei der FDA. Die eigene Leitlinie zu Anwendungsbereich und Anwendung der FDA besagt, dass Part 11 eng auszulegen ist und elektronische Aufzeichnungen, die nicht durch die zugrunde liegenden FDA-Regeln gefordert sind, keine Part-11-Aufzeichnungen darstellen. Ein Tool, dessen Ergebnisse niemals zu solchen Aufzeichnungen werden, fällt möglicherweise nicht darunter. Für klinische Prüfungen ist die Leitlinie mit Fragen und Antworten zu elektronischen Systemen und Aufzeichnungen vom Oktober 2024 die aktuelle Referenz.
Wenn die Ergebnisse in eine Einreichung einfließen oder das Tool innerhalb eines regulierten Prozesses verwendet wird, ändert sich die Bewertung. Klären Sie dies mit Ihrem Regulatory-Team.
Ja. Es gelten dieselben Erwartungen wie für On-Premise-Systeme. Entscheidend ist der Nachweis: ein qualifizierter Anbieter und eine schriftliche Aufgabenteilung. Die Verantwortung für Datenintegrität, Sicherheit und Vertraulichkeit verbleibt bei Ihnen.
Ja, überall dort, wo personenbezogene Daten verarbeitet werden. Teilnehmerdaten stellen den Hochrisikofall dar, da sie größtenteils Gesundheitsdaten betreffen und somit eine besondere Kategorie gemäß Artikel 9 bilden. Auch die Namen, E-Mails und Anmeldedaten Ihrer eigenen Nutzer zählen dazu, weshalb die meisten Tools in den Anwendungsbereich fallen.
Software für klinische Studien definiert sich über ihren Inhalt, nicht über ihren Namen. Führen Sie zuerst den „Fracht-Test“ durch: Was transportiert das Tool, wie gelangen Daten hinein und hinaus und welche Dokumentation belegt die ordnungsgemäße Handhabung? Die Aurora Analytica Geo Matrix zeigt, wie nah ein Planungstool an regulierten Prozessen angesiedelt ist und warum Prüfer als Erstes Identitätsmanagement, Hosting, Datentransfer und Audit-Trails kontrollieren. Verzögerungen sind teuer. Entscheiden Sie sich daher bei Entwicklung oder Kauf für Passgenauigkeit, Integration und Validierung und dokumentieren Sie Ihre Überlegungen, insbesondere wenn die Antwort „nicht im Anwendungsbereich“ lautet. Wenn Sie das tun, verkürzt sich die Wartezeit bei der „Zollabfertigung“ erheblich.
If you are planning HealthTech software, or reviewing a product that sits close to a regulated process, we are happy to talk it through. Imaginary Cloud has been building healthcare technology since 2010, and our healthcare page lists more than 300 healthcare solutions delivered.
See how we work with healthcare teams on our healthcare technology solutions page. If your product also handles US patient data, our guide to HIPAA compliant software development covers the architecture checklist.
Ready to talk? Contact us and tell us what you are building. We will help you work out where the regulatory questions start and what a sensible first version looks like.
Alexandra Mendes ist Senior Growth Specialist bei Imaginary Cloud und verfügt über mehr als 3 Jahre Erfahrung in der Erstellung von Texten über Softwareentwicklung, KI und digitale Transformation. Nach Abschluss eines Frontend-Entwicklungskurses erwarb Alexandra einige praktische Programmierkenntnisse und arbeitet nun eng mit technischen Teams zusammen. Alexandra ist begeistert davon, wie neue Technologien Wirtschaft und Gesellschaft prägen. Sie liebt es, komplexe Themen in klare, hilfreiche Inhalte für Entscheidungsträger umzuwandeln.
People who read this post, also found these interesting:
.webp)
.webp)
