CDASH to SDTM: Where Clinical Data Mapping Actually Breaks
Most CDASH to SDTM mapping pain originates in the eCRF, not the mapping specification. Four design faults account for the bulk of it: free text where a code list belonged, one field carrying two concepts, unstructured dates, and forms built to mirror a protocol table rather than a data model. All four are cheap to prevent and expensive to resolve.
By the time a mapping specification is being written, the decisions that make it hard have already been made. The mapper’s job at that point is to absorb ambiguity that was introduced months earlier, without the ability to go back and ask what was meant.
This guide follows the pipeline from collection to submission, names the four places it breaks, and sets out the design choices that decide whether mapping takes days or months. It sits under how clinical trial data moves from site entry to submission, and is aimed at the people designing forms rather than the people writing the mapping spec.
After reading this you will be able to:
- Trace the four stages between an eCRF field and a submission dataset
- Spot the four design faults that generate most mapping rework
- Choose the cheap version of six recurring eCRF decisions
- Run an annotation review before the forms are signed off
From Collection to Submission
Four stages, and the economics of the last two are set almost entirely by the first.
CDASH governs stage one, SDTM governs stage three, and define.xml describes the relationship for a reviewer. Stage two, annotation, is the cheapest and most frequently postponed step in the whole chain, and postponing it is what converts stage three from configuration into interpretation.
Where the Mapping Actually Breaks
What these have in common is that none of them looks like a problem at the time. A free text field is more flexible. A combined field is fewer boxes for the coordinator. A form that mirrors the protocol table is easier to review against the protocol. Every one of those is a reasonable local decision that becomes a mapping cost globally.
The Three Faults You Will Meet Most Often
Free Text Where a Code List Belonged
If a question has a finite answer set, collecting it as free text guarantees that you will later reconcile a long tail of spellings, abbreviations and near-synonyms into controlled terms. Concomitant medications are the classic case: a dictionary lookup at entry costs the coordinator a few seconds and saves a retrospective coding exercise across the whole study.
Where a genuinely open answer is needed, the fix is not to abandon the code list but to specify the "other" path explicitly, so that the open text is the exception rather than the default.
One Field Carrying Two Concepts
A result and its unit. A value and its qualifier. A finding and whether it was clinically significant. Combined into one field, these have no single submission target, so the mapping has to parse them apart, and parsing depends on everyone having typed them the same way, which they did not.
One concept per field is the rule, with the qualifier as its own field and its own code list.
Dates That Are Not Really Dates
Real clinical data contains partial dates, because patients recall months without days. The question is whether your eCRF anticipated that. Structured day, month and year parts with a documented convention for unknown components produces something convertible. A free text date field produces a dozen formats across sites and a case-by-case interpretation during mapping.
Cheap Version, Expensive Version
Six recurring decisions, each made in an afternoon during the build.
The point worth sitting with is that none of the cheap versions is harder to configure than the expensive one. They are only harder to remember to ask for, which is an argument for a checklist rather than for expertise.
Annotating at Design Time
Annotation means marking each eCRF field with its submission target. Done while the forms are being designed, it is a few hours of work and it changes the forms for the better, because fields with no obvious target get noticed while they can still be redesigned.
Done at submission, it is a documentation exercise performed on decisions that can no longer be revised. The step that makes annotation real rather than nominal is confirmation by someone from biostatistics before the forms are signed off, since the annotation is ultimately a statement about what analysis will receive. Where this fits in the build sequence is covered in every step between final protocol and first patient in.
Controlled Terminology and Version Control
Controlled terminology is what keeps values consistent enough for any of the structure to mean anything. It applies across collection and submission, and the version applying to your study depends on your target region and submission date.
Those versions change. Confirm which apply during the build, and confirm again before lock, because a version assumption carried over from a previous study is a quiet source of conformance findings. Treat it as a build artifact with an owner rather than as background knowledge.
A Design Review Before Sign-Off
Eight questions, asked of every form before it is signed off.
- Does every field have an identified submission target?
- Is any free-text field capturing something with a finite answer set?
- Does any field carry more than one concept?
- Are dates collected as structured parts, with a partial-date convention documented?
- Is "not done" distinguishable from "blank"?
- Do results have a separate unit field with a code list?
- Is visit identification structured rather than free text?
- Has biostatistics confirmed the annotation, in this version?
Clinera EDC is the layer where these decisions get configured, and for organizations running this work across many sponsors, CRO and research organization teams face the same review at higher volume. The scope question underneath, what the platform decides versus what stays with you, is in what an EDC system does, and the four jobs it cannot do for you.
References
- CDASH, Clinical Data Acquisition Standards Harmonization. CDISC foundational standards. www.cdisc.org
- SDTM, Study Data Tabulation Model. CDISC foundational standards. www.cdisc.org
- Study Data Technical Conformance Guide. US Food and Drug Administration, study data standards resources. www.fda.gov
- Good Clinical Data Management Practices. Society for Clinical Data Management. scdm.org
This guide describes process and regulatory expectations in general terms and is not legal or regulatory advice. Confirm the current version and applicability of any standard or guidance for your study and region.
Frequently Asked Questions
What is the difference between CDASH and SDTM?
CDASH describes how to collect data, giving conventions for eCRF fields and naming at the point of capture. SDTM describes how to submit it, as standardized tabulation datasets in the structure a regulator reviews. They are two ends of the same pipeline, and the define file describes the relationship between what was submitted and what it means. Designing collection with the submission structure in view is what makes the middle step cheap.
When should the eCRF be annotated to SDTM?
During design, while the forms are still easy to change. Annotation at design time costs a few hours and changes field choices for the better. Annotation at submission time is a documentation exercise performed on decisions that can no longer be revised, so the mapping has to absorb every ambiguity rather than prevent it. Having someone from biostatistics confirm the annotation before sign-off is the step that makes it real.
What is define.xml and who produces it?
It is the metadata file that tells a reviewer what each submitted dataset contains: dataset and variable metadata, value level metadata, code list definitions and links back to the annotated eCRF. It is typically produced by the team building the SDTM datasets, usually biostatistics or a standards group, but its quality depends heavily on whether collection metadata was captured properly during the build.
Why are partial dates such a common problem?
Because real clinical data contains them and free-text fields invite inconsistency. A patient recalls starting a medication in March without the day. If the field is free text, that arrives in a dozen formats across sites and every one becomes an interpretation during mapping. Collecting structured day, month and year parts, with a documented convention for what happens when a part is unknown, removes the ambiguity at source.
Which standard versions apply to our study?
That depends on your target region and your submission date, and the supported versions change over time. Regulators publish what they accept, so the version check belongs in the build and again before lock rather than at submission. Locking a version choice early and then confirming it is still current is more reliable than assuming the version you used last time still applies.
Can Nirmitee Healthtech review an eCRF that is already built?
Yes, and the review is most useful before the first patient is enrolled, though it still has value after. The work is a pass through each form against a target domain, identifying free-text fields that should be code lists, fields carrying two concepts, date handling and any structure with no obvious domain. The output is a list of changes ranked by what they will cost if left alone.
