Ein Case Report Form (CRF) ist das Studienformular, in dem die für eine klinische Prüfung definierten Daten pro Studienteilnehmer strukturiert dokumentiert werden. Das CRF bildet damit die Brücke zwischen dem Prüfplan (welche Daten werden benötigt?) und der späteren Auswertung bzw. dem klinischen Studienbericht. In modernen Studien wird das CRF meist elektronisch als eCRF innerhalb eines Electronic-Data-Capture-Systems umgesetzt; der Begriff CRF wird jedoch weiterhin als übergeordnete Bezeichnung genutzt.
Ziel: Relevante, auswertbare und prüfbare Studiendaten
Das CRF stellt sicher, dass Daten standardisiert erhoben werden und für statistische Analysen geeignet sind. Es umfasst typischerweise demografische Angaben, Krankheits- und Baseline-Informationen, Visiten- und Untersuchungsdaten, Laborparameter, Studienmedikation, Abweichungen, unerwünschte Ereignisse und Endpunktvariablen. Für Sponsor und CRO ist entscheidend, dass jedes Datenfeld eine klare medizinische oder regulatorische Begründung hat und in definierten Formaten erhoben wird (z.B. Einheiten, Datumslogik, codierte Werte).
Entwicklung eines CRF: Von Protokoll zu Datenspezifikation
Die CRF-Entwicklung beginnt mit dem Prüfplan und dem statistischen Analyseplan. Daraus werden „Critical-to-Quality“-Daten identifiziert, die besonders wichtig für Endpunkte, Sicherheit und regulatorische Entscheidungen sind. Data-Management erstellt darauf aufbauend eine Datenspezifikation und häufig ein annotiertes CRF, das Variablen z.B. zu CDISC SDTM/ADaM zuordnet. Ein iteratives Review mit Medical, Biostatistik, Monitoring, Pharmakovigilanz und ggf. Zulassungsteam reduziert spätere Änderungen. In EU-Projekten ist es praxisrelevant, die Anforderungen aus CTR 536/2014 sowie nationale Vorgaben zu Dokumentation und Datenschutz früh zu berücksichtigen.
Für Sponsor und CRO ist es hilfreich, die CRF-Struktur früh an operativen Abläufen auszurichten: Visiten sollten so abgebildet werden, wie sie in der Klinik real stattfinden, und Dokumentationspflichten (z.B. Schwangerschaftstests, Concomitant-Medication, Protokollabweichungen) müssen eindeutig verortet sein. Werden Themen „irgendwo“ in Freitextfeldern versteckt, entstehen später Lücken in Listings und Safety-Reviews.
Außerdem sollte bereits in der Spezifikation festgelegt werden, wie Daten aus externen Quellen integriert werden (z.B. Zentrallabor, Bildgebung, Geräte- oder Wearable-Daten). Ohne definierte Schnittstellen- und Reconciliation-Regeln kann das CRF zwar formal vollständig wirken, in der Praxis entsteht jedoch ein hoher manueller Abgleichaufwand – oft genau dann, wenn Timelines für Database-Lock und CSR-Erstellung eng werden.
CRF und Datenqualität: Edit-Checks, Queries und Monitoring
Die Datenqualität wird durch definierte Prüfregeln und Prozesse abgesichert. In elektronischen Systemen werden Edit-Checks (Plausibilitätsprüfungen) konfiguriert, die z.B. Wertebereiche und logische Konsistenzen prüfen. Auffälligkeiten erzeugen Queries, die die Site klären muss. Monitoring überprüft im Rahmen der Source-Data-Verification die Übereinstimmung mit Quelldokumenten, wobei risikobasierte Ansätze den Fokus auf kritische Daten legen. Eine klare CRF-Completion-Guideline hilft Sites, Felder korrekt und konsistent auszufüllen.
Aus Sponsor- und CRO-Sicht ist außerdem der „Query-Lifecycle“ ein kritischer Zeitfaktor: Wer triagiert Queries, wer darf sie schließen, und welche Fristen gelten? Ohne klare Regeln entstehen offene Punkte, die sich bis kurz vor Database-Lock aufstauen. Gute CRF-Designs vermeiden unnötige Freitextfelder, nutzen standardisierte Codelists und definieren eindeutige Datenquellen, um Rückfragen zu reduzieren.
Ein weiterer häufiger Stolperstein ist die Abgrenzung zwischen dokumentierter Korrektur und Protokollabweichung: Wenn Daten nachträglich geändert werden, muss erkennbar sein, ob es sich um eine reine Dokumentationskorrektur oder um eine tatsächlich abweichende klinische Situation handelt. Diese Unterscheidung ist bei Audits und Inspektionen relevant und sollte in SOPs sowie im Training der Sites adressiert werden.
Regulatorische Anforderungen und Inspektionsfähigkeit
CRF-Daten müssen vollständig, nachvollziehbar und korrekt sein, da sie Grundlage für Zulassungsentscheidungen und Inspektionen sein können. Relevante Anforderungen betreffen u.a. Datenintegrität (ALCOA+), Audit-Trail bei elektronischen Systemen, dokumentierte Rollen- und Berechtigungskonzepte sowie Validierung der eingesetzten IT-Systeme. Die Grundsätze der ICH-GCP (E6(R2)/E6(R3)) sind international leitend; in der EU ist zusätzlich die Clinical-Trials-Regulation (EU) Nr. 536/2014 zentral, die u.a. Transparenz und Anforderungen an die Studiendokumentation adressiert.
Abgrenzung zu verwandten Begriffen
Das CRF ist das Formular bzw. das Datenerfassungsmodell. Das eCRF ist die elektronische Umsetzung. Das EDC ist das System, das eCRFs hostet und Funktionen wie Query-Management und Datenexport ermöglicht. ePRO-Systeme erfassen patientenberichtete Daten, die je nach Studiendesign separat verwaltet oder mit CRF-Daten zusammengeführt werden. Für Sponsor und CRO ist eine saubere Definition der Verantwortlichkeiten wichtig, z.B. wer welche Datenquelle prüft, wie Abgleiche erfolgen und wie Datenänderungen gesteuert werden.
FAQ: Muss jedes Protokoll-Detail im CRF abgebildet werden?
Nein. Das CRF sollte nur Daten erfassen, die für Endpunkte, Sicherheit, Studienevaluierung oder regulatorische Anforderungen erforderlich sind. Zu viele Felder erhöhen Aufwand und Risiko von Missing-Data, ohne zusätzlichen Erkenntnisgewinn zu liefern.
FAQ: Welche Rolle spielt ein annotiertes CRF?
Ein annotiertes CRF verknüpft CRF-Felder mit standardisierten Datensätzen (z.B. CDISC SDTM). Es erleichtert Datenmapping, Programmierung, Konsistenzprüfungen und die spätere Erstellung von Auswertungsdatensätzen. Für komplexe Programme ist es ein wichtiges Steuerungsinstrument zwischen Data-Management und Statistik.
FAQ: Was passiert, wenn CRF-Änderungen spät im Projekt kommen?
Späte Änderungen erfordern Change-Control, zusätzliche Tests und häufig Trainings. Sie können Datenmigrationen oder Re-Annotation nötig machen und Zeitpläne (z.B. Database-Lock) verzögern. Deshalb ist ein frühes, interdisziplinäres Review zentral.
Regulatorische Referenzen (Auswahl): ICH E6(R3) Good Clinical Practice, EU Clinical-Trials-Regulation (EU) Nr. 536/2014, Datenschutz-Grundverordnung (EU) 2016/679; ergänzend: GAMP 5 (computergestützte Systeme im regulierten Umfeld) als Good Practice.