The short version
- Conformance rules check that data follow a standard's structure and conventions. They are necessary and useful.
- They cannot check that a derivation matches the analysis plan, that the data reflect what was collected, or that a value is clinically sensible.
- Treat a clean validation report as the start of review, and put the effort it saves into the checks only people can do.
The rule sets
FDA's validator rules and business rules. FDA publishes validator rules, which describe checks of standardized study data against the standards and FDA's expectations, and business rules, which state the expectations themselves in plain terms [1]. The Technical Conformance Guide explains how conformance issues should be handled and asks that issues which remain are explained in the reviewer's guide [2].
CDISC CORE. The CDISC Open Rules Engine is an open-source implementation of the conformance rules that CDISC publishes alongside its standards, executable so that sponsors, vendors and regulators can run the same rules the same way [3]. Rules that are published, versioned and executable reduce the arguments about what a standard means.
Commercial and in-house tools implement these rules and add their own. Whichever tool you use, the same principle applies: it checks rules.
What rules are good at
Rules are excellent at checks that can be stated precisely and evaluated on the data alone:
- Required and expected variables present, with the right names, types and lengths.
- Values drawn from the declared controlled terminology.
- Keys unique, and records consistent across datasets, for example every subject in an events domain also in demographics.
- Dates in ISO 8601 format, and end dates not before start dates.
- Dataset and variable conventions in the implementation guide followed [4].
These are the errors that would otherwise make a reviewer's tools fail or mislead, and running rules early and often removes them cheaply.
What rules cannot see
| Problem | Why a rule passes it | Who catches it |
|---|---|---|
| A derivation implements the specification incorrectly | The value has a valid format and range | Independent programming or code review |
| The specification misreads the SAP | Data match the specification exactly | Statistician review of specifications and outputs |
| A mapping puts collected data in the wrong variable | The wrong variable accepts the value | Review against the annotated CRF |
| A value is valid but clinically implausible | Within format and terminology | Data review by clinical and data management |
| Records are missing, for example a lost vendor transfer | Nothing is there to check | Reconciliation of counts with the source |
Every row is a correctness question, and correctness depends on information that is not in the data: the protocol, the SAP, the CRF and the source systems.
How to use a clean report well
A clean validation report should change where review effort goes, not reduce it. Once the structural noise is gone, spend the time on reconciliations of record counts with sources, on reading key outputs for sense, and on tracing a few values from output to collection. Report the remaining validation findings with reasons in the reviewer's guide, and report the correctness checks you ran in your own quality records.
A synthetic example
The fictional ZEPHYR-101 SDTM transfer passes the rule set with no errors. A count reconciliation against the central laboratory's transfer log finds 312 missing records from one site and one month, lost when a transfer file was overwritten. No conformance rule could have found them, because the data that remained were perfectly conformant.
Do this today
- Run your conformance checks at every transfer, not only before submission, so structural issues never accumulate.
- Add a record-count reconciliation against each external data source to your transfer checklist.
- List the correctness checks your team runs that no rule could replace, and make sure each has an owner.
Check yourself
One question
Show the answer
Answer 2. Rules check structure, presence, terminology and many consistency conditions. A value that has the right format and plausible range but was derived from the wrong reference date can pass them all. Catching it needs a check against the specification and the source.
Apply it
Turn it into a plan
The brief says what to check. The Navigator and the Handbook turn it into dated, owned actions for your milestone, in your browser, with no study data.
Sources
References
- U.S. Food and Drug Administration. Study Data Standards Resources, including the FDA Validator Rules and FDA Business Rules for study data. www.fda.gov ↗
- U.S. Food and Drug Administration. Study Data Technical Conformance Guide: Technical Specifications Document. www.fda.gov ↗
- CDISC. CORE: CDISC Open Rules Engine. www.cdisc.org ↗
- CDISC. Study Data Tabulation Model Implementation Guide (SDTMIG) version 3.4. www.cdisc.org ↗
Standards and guidance change. Confirm the version in force for your study, sponsor and region before relying on any reference. Examples are synthetic and illustrative. This brief is generalized professional guidance, not regulatory advice.
Next brief · Sunday 10:00 ET · Week Ahead