Biomedical Concepts: zwei Schichten für wiederverwendbare Studienmetadaten

Biomedical Concepts (BC) sind eine semantische Metadatenstruktur von CDISC, die eine klinische Beobachtung fachlich beschreibt, unabhängig davon, in welchem Standard und in welchem Datensatz sie später auftaucht. Sie stehen im Zentrum der laufenden Standardisierungsarbeit; eine deutschsprachige Erläuterung fehlt bislang.

Der Begriff wird dabei mit zwei benachbarten Konzepten verwechselt. Controlled Terminology (CT) ist externes Referenzvokabular: kontrollierte Begriffslisten mit Codes, versioniert und studienübergreifend gültig, im klinischen Umfeld gespeist aus CDISC CT, dem NCI Thesaurus (NCIt), SNOMED CT, LOINC und UCUM. Eine Dataset Specialization ist das Gegenstück auf der Implementierungsseite: eine präzisierte Ausprägung einer SDTM-Domäne für einen konkreten Messfall. Ein Biomedical Concept verbindet beide Ebenen. Es beschreibt, was gemessen wird, und verweist darauf, wie diese Messung in einem Zielstandard abgebildet ist.

Die zwei Schichten

Ein Biomedical Concept ist zweischichtig aufgebaut, und diese Zweischichtigkeit ist der eigentliche Konstruktionsgedanke.

Die konzeptuelle Schicht ist standardsagnostisch. Sie beschreibt die Beobachtung fachlich und verankert sie überwiegend in NCIt-Konzepten. Auf dieser Ebene steht, um welche Messgröße es geht, welche Eigenschaften sie hat und welche Attribute für ihre eindeutige Bestimmung nötig sind. Sie enthält keine Angabe darüber, in welcher Domäne, unter welchem Variablennamen oder in welchem Dateiformat die Messung später landet.

Die Implementierungsschicht besteht aus SDTM Dataset Specializations mit Definitionen auf Wertebene. Hier steht, in welcher Domäne die Beobachtung geführt wird, welche Variablen sie belegt, welche Werte zulässig sind und welche Einheiten gelten.

Ein Beispiel macht die Trennung greifbar. Der systolische Blutdruck ist auf der konzeptuellen Schicht eine Messgröße mit einem NCIt-Konzept als Anker, ergänzt um die Attribute, die ihn eindeutig machen: Körperposition, Messmethode, Seite, Zeitpunktbezug. Auf der Implementierungsschicht wird daraus ein Eintrag in der Vital-Signs-Domäne mit dem Testcode SYSBP, der Einheit mmHg und den Wertebereichen, die für die Prüfung gelten. Dieselbe konzeptuelle Definition kann mehrere Implementierungen tragen, etwa für die Erhebung im CRF und für die Tabulation.

Der praktische Gewinn liegt in der Richtung der Abhängigkeit. Ändert sich die Implementierung, weil eine Domäne anders geschnitten wird oder ein Standard eine neue Version bekommt, bleibt die fachliche Definition stabil. Ändert sich die fachliche Definition, weil eine Messung anders spezifiziert wird, ist über die Bindung nachvollziehbar, welche Implementierungen betroffen sind. Genau diese Nachvollziehbarkeit fehlt, wenn eine Messung nur als Spalte in einer Spezifikationstabelle existiert.

Die Ableitungskette in der Praxis

CDISC hat den Nutzen in der Initiative 360i demonstriert, die im März 2025 startete und USDM, SDTM, Define-XML, ODM, Biomedical Concepts und Analysis Concepts zu einer durchgehenden Kette verbindet. Das Studiendefinitionsmodell USDM und sein Verhältnis zum Protokollstandard ICH M11 beschreibt der Beitrag ICH M11 nach Step 4. Das Build-Team erzeugte aus der Verknüpfung von Biomedical Concepts mit USDM eine Reihe von Artefakten automatisch: eCRF-Spezifikationen, ODM.xml, annotierte CRFs, SDTM Dataset Specializations, Trial-Design-Domänen, define.xml und SDTM-Shell-Datasets.

Der Unterschied zum bisherigen Vorgehen ist weniger die Geschwindigkeit als die Richtung. Bislang entstehen diese Artefakte nebeneinander, jeweils von Hand aus derselben Vorlage abgeleitet und anschließend gegeneinander geprüft. In der 360i-Logik entstehen sie aus einer gemeinsamen Quelle, und die Prüfung verschiebt sich von der Konsistenz der Ergebnisse auf die Korrektheit der Quelle.

Die technische Ablage dieser Artefakte liegt offen. Die Dataset Specializations werden im Repository COSMoS geführt, das CDISC öffentlich bereitstellt. Auch außerhalb von CDISC ist das Muster umgesetzt: Der quelloffene OpenStudyBuilder von Novo Nordisk modelliert seine Activity Concepts ebenfalls zweischichtig, mit NCIt-Konzepten auf der einen und CDISC Dataset Specializations auf der anderen Seite.

Drei Grenzen

Die Abdeckung ist unvollständig. Der publizierte Bestand deckt nicht jede Messung ab, die eine konkrete Studie braucht. Sponsoren definieren deshalb eigene Konzepte für die Lücken. Damit entsteht sofort eine Zweiklassigkeit: publizierte Konzepte, die extern gepflegt und versioniert werden, und interne Konzepte, deren Pflege im Haus liegt. Beide müssen im selben Bestand koexistieren, ohne sich zu vermischen.

Der Rückweg ist ungeklärt. Ein intern definiertes Konzept, das sich bewährt, gehört fachlich in den publizierten Standard. Der Weg dorthin führt über die CDISC-Gremienarbeit und ist damit langsamer als die Studienplanung. In der Zwischenzeit trägt das Unternehmen ein Konzept, das eine Standardlücke füllt, aber nicht Standard ist. Wer diesen Zustand nicht bewusst gestaltet, hat nach einigen Jahren einen internen Bestand, dessen Verhältnis zum externen Standard niemand mehr beschreiben kann.

Die Kette endet bei der Tabulation. Die in 360i öffentlich dokumentierten Build-Artefakte reichen von der Konzeptdefinition bis zu SDTM und define.xml. Der durchgehende Weg bis zu den Analyseergebnissen ist damit noch nicht geschlossen. Der zugehörige Standard existiert seit dem 19. April 2024 mit dem Analysis Results Standard (ARS) v1.0, der Analyseergebnisse erstmals maschinenlesbar spezifizierbar macht. Die Verbindung beider Enden ist die aktuelle Baustelle, und sie ist der Grund, warum Effizienzversprechen für die Analyse- und Reportingstufe derzeit weiter reichen als die Belege.

Governance über beide Schichten

Aus der Zweischichtigkeit folgt eine Anforderung, die in Werkzeugdiskussionen untergeht: Beide Schichten müssen gemeinsam versionsfähig sein.

Eine Änderung an der konzeptuellen Schicht, etwa eine präzisere Definition oder ein gewechselter NCIt-Anker, betrifft potenziell jede daran gebundene Implementierung. Ohne einen Prüfschritt, der diese Bindungen bei einer Konzeptänderung erneut bewertet, entsteht schleichende Divergenz: Die Definition sagt das eine, die Dataset Specialization bildet weiter das andere ab. Der Fehler fällt erst auf, wenn ein Datensatz gegen die Definition geprüft wird, und das ist der letzte Schritt der Kette.

Daraus ergeben sich drei Festlegungen, die vor der Werkzeugauswahl stehen. Erstens die Richtung der Bindung: Die konzeptuelle Schicht führt, die Implementierungsschicht bindet daran, nicht umgekehrt und nicht wechselseitig. Zweitens die Rollen: Wer definiert ein Konzept, wer gibt es frei, wer verantwortet die Implementierung. Drittens ein Konsistenznachweis, der prüft, dass jede Implementierung auf eine gültige und aktuelle Konzeptdefinition zeigt.

Diese Fragen sind nicht technisch, sie sind organisatorisch. Ein Werkzeug kann sie unterstützen, aber es beantwortet sie nicht.

Einstieg: vier Schritte

1. Eine Domäne auswählen und durchzeichnen. Für einen begrenzten Bereich, etwa Vitalparameter oder Labor, den Weg von der konzeptuellen Definition über die Dataset Specialization bis in die CRF-Spezifikation und define.xml einmal vollständig nachvollziehen.
2. Bestand trennen. Publizierte Konzepte und intern definierte Konzepte im eigenen Bestand technisch unterscheidbar führen, einschließlich Herkunft und Versionsstand.
3. Bindungsprüfung einrichten. Einen Prüfschritt definieren, der bei Änderung einer Konzeptdefinition alle gebundenen Implementierungen zur Review markiert.
4. Rückpublikation klären. Festlegen, aus welcher Schicht und über welchen Prozess intern definierte Konzepte in Richtung CDISC eingebracht werden, bevor der interne Bestand relevant wächst.