Alle Artikel
Regulatorik Systeme

ICH M11: das Protokoll als austauschbares Datenformat

ICH M11 (CeSHarP) ist seit dem 19. November 2025 auf Step 4 und besteht aus drei Komponenten: Guideline, human-lesbarem Template und einer Technical Specification für den elektronischen Austausch von Protokollinhalt. Die FDA hat die zugehörige Final Guidance am 22. Mai 2026 veröffentlicht. Der Standard ist nicht verbindlich, er beschreibt aber erstmals das Protokoll als strukturiertes, zwischen Systemen austauschbares Datenobjekt. Das maschinenlesbare Gegenstück liefert CDISC USDM v4.0 (3. Juni 2025) im Rahmen von TransCelerate DDF. Der Artikel ordnet die drei Komponenten, das Verhältnis zu USDM und DDF, den Reifegrad der Referenzimplementierung und den Adoptionsstand für Sponsoren im DACH-Raum ein.

ICH M11, geführt unter der Bezeichnung Clinical Electronic Structured Harmonised Protocol (CeSHarP), ist die internationale Harmonisierungsvorgabe für Aufbau und Inhalt klinischer Prüfprotokolle. Der Standard erreichte am 19. November 2025 Step 4 der ICH-Verfahrensordnung, also die finale Verabschiedung durch die regulatorischen Mitglieder. Die US-amerikanische Arzneimittelbehörde hat die zugehörige Final Guidance am 22. Mai 2026 im Federal Register veröffentlicht (91 FR 30310, Docket FDA-2022-D-3054).

Für Regulatory Affairs, Clinical Data Standards und Medical Writing ist dabei weniger die Vorlage interessant als der dritte Bestandteil des Pakets. M11 beschreibt das Protokoll nicht nur als Dokument mit vorgegebener Gliederung, sondern als Menge definierter Datenelemente, die zwischen Systemen und Organisationen ausgetauscht werden können. Damit verschiebt sich die Frage, die Sponsoren zu beantworten haben: nicht mehr, welche Kapitelstruktur das Protokoll bekommt, sondern welches System künftig den Protokollinhalt führt.

Der Standard in drei Teilen

M11 besteht aus drei koordinierten Komponenten. Die erste ist die Guideline selbst, die Designprinzipien und Begründungen enthält. Die zweite ist ein human-lesbares Template, also die Gliederung, die Autorinnen und Autoren beim Schreiben verwenden. Die dritte ist eine Technical Specification, die zu den Inhalten des Templates Datenelemente samt technischer Attribute definiert: Definition, Conformance und Cardinality, also verbindliche Bedeutung, Verbindlichkeitsgrad und zulässige Häufigkeit je Element.

Die dritte Komponente trägt die eigentliche Neuerung. Ein Template harmonisiert die Reihenfolge der Kapitel; eine Technical Specification harmonisiert, welche Information als adressierbares Objekt vorliegt und wie sie sich übertragen lässt. Die ICH benennt das Ziel als offenen, nicht-proprietären interoperablen Standard für den elektronischen Austausch von Protokollinhalt (eigene Übersetzung). Aus einem Word-Dokument mit einheitlicher Gliederung wird damit eine Struktur, aus der sich Zielsysteme bedienen können.

Ebenso wichtig ist die Reichweite. M11 ist eine Guideline, keine Rechtsnorm. Die Fassung lässt ausdrücklich einen alternativen Ansatz zu, sofern er die regulatorischen Anforderungen erfüllt. Wer M11 als Stichtagsthema behandelt, unterstellt eine Verbindlichkeit, die der Text nicht hergibt. Die praktische Wirkung entsteht anders: über Behördenerwartungen, über Partner in gemeinsamen Studien und über die eigene Systemlandschaft, die strukturierten Inhalt weiterverarbeiten kann oder eben nicht.

Wiederverwendung als Designprinzip

Abschnitt 2.1 der Guideline führt "Design for content re-use" als benanntes Prinzip: Das Protokoll ist eine reichhaltige Informationsquelle, deren Inhalte wiederverwendet werden können (eigene Übersetzung). Dieser Satz ist der Hebel, an dem der gesamte nachgelagerte Nutzen hängt.

Konkret betrifft das Objekte, die heute in jedem Studienverlauf mehrfach manuell übertragen werden. Der Schedule of Activities wandert aus dem Protokoll in die CRF-Spezifikation, in den Prüfplan für die Prüfzentren und in die Einwilligungserklärung. Ein- und Ausschlusskriterien tauchen im Protokoll, im Screening-Formular, in der Registrierung und in der Publikation auf. Endpunkte erscheinen im Protokoll, im statistischen Analyseplan und im Studienbericht. Jede dieser Übertragungen ist heute eine Kopie, und jede Kopie erzeugt eine eigene Version.

Die Alternative besteht nicht darin, weniger zu kopieren, sondern die Objekte einmal strukturiert vorzuhalten und alle Zielformate daraus abzuleiten. Genau darauf zielt die von ICH beschriebene Logik "Write Once, Read Many": Der Protokollinhalt wird einmal erfasst und speist anschließend Systeme wie EDC, CTMS, dezentrale Studienkomponenten, Randomisierungssysteme und, perspektivisch, elektronische Patientenakten.

USDM und DDF als maschinenlesbares Gegenstück

Die Technical Specification beschreibt, welche Elemente ausgetauscht werden. Ein Datenmodell, das diese Elemente trägt, kommt von anderer Seite. USDM (Unified Study Definitions Model) ist das gemeinsame Referenzmodell von CDISC und TransCelerate, entwickelt in der Initiative DDF (Digital Data Flow). CDISC beschreibt es als Standardmodell für die Entwicklung konformer Study-Definition-Technologien (eigene Übersetzung).

Die Versionslinie ist kurz und für die Planung relevant: v1.0 am 9. August 2022, v2.0, v3.0 am 16. April 2024, v4.0 am 3. Juni 2025. Phase 3 der Initiative (2023 bis 2024) bildete das damalige M11-Template im Modell ab, Phase 4 (2024 bis 2025) setzte die Ausrichtung am finalisierten Template fort. Eine Version 5.0 war Mitte 2026 nicht veröffentlicht; ein entsprechendes Gerücht ließ sich in den Primärquellen nicht bestätigen.

Für Architekturdiskussionen zählt eine Festlegung, die USDM ausdrücklich nicht trifft. Die DDF-Referenzarchitektur hält fest, dass sich das Modell in unterschiedlichen physischen Datenspeichern umsetzen lässt, darunter relationale Datenbanken, Property-Graph-Datenbanken, RDF-Triplestores und Dokumentdatenbanken. USDM ist ein UML- und JSON-basiertes Objektmodell, kein Graph und keine Datenbank. Die Wahl der Speichertechnologie bleibt damit eine freie Entscheidung des Sponsors und lässt sich nicht mit dem Standard begründen.

Die Referenzimplementierung ist kein Produkt

An dieser Stelle entsteht in Marktgesprächen ein wiederkehrendes Missverständnis. Neben dem Modell existiert eine SDR (Study Definitions Repository)-Referenzimplementierung, entstanden bei TransCelerate in Zusammenarbeit mit Accenture und veröffentlicht unter Apache 2.0. Das Projekt selbst hält fest, dass die Referenzimplementierung kein voll funktionsfähiges Produkt werden soll (eigene Übersetzung).

Wer also hört, ein Sponsor "betreibe ein SDR", hört keine Produktentscheidung, sondern die Aussage, dass eine Variante eines offenen Artefakts im Einsatz ist. Für die eigene Bewertung folgt daraus zweierlei: Adoptionsmeldungen aus dem Markt sind kein Reifegrad-Indikator, und die Frage nach Betrieb, Validierung und Support beantwortet die Referenzimplementierung nicht. Sie beantwortet nur die Frage nach dem Datenformat.

Adoptionsstand

Der Abstand zwischen Standard und Praxis ist groß. TransCelerate nannte am 8. Oktober 2025 die Größenordnung, dass rund 90 Prozent der Protokolle weiterhin als unstrukturierte Dokumente vorliegen. Die Angabe stammt aus einer Pressemitteilung der Initiative selbst und wird ohne offengelegte Erhebungsmethodik geführt; sie taugt als Richtungsindikator, nicht als belastbare Marktzahl.

Die Richtung deckt sich aber mit dem, was auf der Standards-Seite parallel passiert. CDISC hat im März 2025 die Initiative 360i gestartet, die USDM, SDTM, Define-XML, ODM, Biomedical Concepts und Analysis Concepts zu einer durchgehenden Metadatenkette verbindet. Das Build-Team erzeugte daraus 2025 unter anderem eCRF-Spezifikationen, ODM.xml, annotierte CRFs, SDTM Dataset Specializations, Trial-Design-Domains und define.xml. Die Kette reicht damit bis zur Tabulation, noch nicht durchgängig bis zu den Analyseergebnissen.

Zusammengenommen ergibt das eine ungewöhnliche Lage: Das technische Fundament ist verabschiedet und in Referenzimplementierungen demonstriert, während die überwiegende Zahl der laufenden Studien weiterhin dokumentenbasiert arbeitet. Für Sponsoren ist das kein Argument zu warten, sondern die Beschreibung des Zeitfensters, in dem eine Umstellung ohne Verfahrensdruck vorbereitet werden kann.

Einordnung für Sponsoren im DACH-Raum

Vier Funktionen sind unmittelbar betroffen, und jede hat eine eigene Leitfrage.

Regulatory Affairs verantwortet die Einreichung und damit die Frage, in welcher Form Protokollinhalt gegenüber Behörden erscheint. Solange der elektronische Austausch freiwillig bleibt, ändert sich am Einreichungsweg nichts; die Vorbereitung besteht darin, das eigene Template gegen das M11-Template zu spiegeln und Abweichungen zu dokumentieren.

Clinical Data Standards verantwortet das Modell dahinter. Hier fällt die Entscheidung, ob USDM als internes Zielmodell gesetzt wird und welche Version. Da die Versionslinie beweglich ist, gehört ein definierter Umgang mit Versionswechseln zur Entscheidung, nicht als Nachtrag.

Medical Writing verantwortet die Inhalte und erlebt die spürbarste Veränderung. Strukturiertes Authoring verlagert Arbeit vom Formulieren zum Kuratieren und Freigeben wiederverwendbarer Bausteine. Diese Beschreibung stammt allerdings überwiegend aus Anbieter- und Verbandsveröffentlichungen, nicht aus geprüfter Evidenz; sie ist als Erwartung zu behandeln, nicht als belegter Befund.

IT und Validierung verantworten die Systemseite. Sobald Protokollinhalt als Datenobjekt in mehreren Systemen liegt, stellt sich die Frage nach der führenden Fassung, nach Versionierung über Systemgrenzen und nach dem Audit Trail derselben Änderung an unterschiedlichen Stellen. Das ist dieselbe Systematik, die aus der Arbeit mit elektronischen Produktinformationen bekannt ist und dort im Beitrag zur ePI-Readiness beschrieben ist.

Nicht betroffen ist die Durchführungsebene der Studie. M11 regelt Struktur und Austausch des Protokollinhalts, nicht Rekrutierung, Monitoring oder Studienbetrieb.

Vorbereitung: vier Schritte

  1. Übertragungsstellen inventarisieren. Erfassen, welche Protokollinhalte heute manuell in andere Dokumente und Systeme übertragen werden, mit Angabe von Quelle, Ziel und Häufigkeit. Der Schedule of Activities, die Eignungskriterien und die Endpunkte sind der übliche Ausgangspunkt.
  2. Eigenes Template gegen M11 spiegeln. Abweichungen zwischen firmeneigener Protokollvorlage und M11-Template auflisten und je Abweichung entscheiden, ob sie fachlich begründet ist oder historisch gewachsen.
  3. Führende Fassung festlegen. Für jedes strukturierte Objekt bestimmen, welches System die maßgebliche Version hält, sobald Protokollinhalt in mehr als einem System vorliegt. Ohne diese Festlegung entsteht dieselbe Divergenz wie bei parallelen Dokumentversionen, nur schlechter sichtbar.
  4. Versionsstände beobachten. Den Status der Technical Specification und die USDM-Versionslinie halbjährlich prüfen und die interne Zielversion daran ausrichten.