CDISC Submission Standards Software Problems: The 7 That Cost You Weeks Before a Filing

Why does a standards tooling project turn into a clinical data platform?

The brief that arrives is usually narrow: automate the Define-XML, or stop remapping the same laboratory extract every study. Three months later the scope has grown a metadata repository, controlled terminology governance, an execution engine and a validation loop, because none of the original request survives without them.

The reason is that a Define-XML which cannot disagree with the data has to be rendered from the same source as the data, and that source is the mapping declaration. The moment you accept that, you have committed to holding mappings as metadata rather than as code, which means an execution engine, which means version control over standards, which means governance over your own extensions. Each step follows necessarily from the one before, so the scope does not creep so much as unfold.

The fix is to phase against studies rather than against features. A defensible first release is a metadata repository, a mapping declaration and execution engine, generated Define-XML, controlled terminology versioning and an automated conformance loop, proven end to end on three representative studies. Analysis dataset derivation traceability, double programming comparison, reviewer guide generation and legacy onboarding belong in a second phase with their own budget. The projects that overrun are the ones that tried to model every domain the organisation has ever seen in release one, which is a modelling exercise with no delivery date attached.

What goes wrong when you onboard legacy and acquired studies?

An acquisition brings six studies. A partner delivers data in their own convention. An old study predates your standards entirely. Each one is a discovery exercise before it is a mapping exercise, and the discovery is where the schedule risk actually lives, not the transformation.

The specific failures are consistent. Source column names carry meaning that exists only in an annotated case report form nobody can locate. Coded values were extended locally, so the same concept appears three ways across three studies and no codelist explains any of them. Derived variables arrive in what should be raw data, which means a mapping that looks straightforward is quietly carrying somebody else's clinical decision. And the original specification, where it exists, describes intent rather than what the programs actually did.

The fix is to profile before you map. Catalogue every source dataset, its column names, value distributions and any annotated form, then let a model propose candidate mappings against your existing approved library, ranked by confidence, for a programmer to accept, reject or edit. The value is not accuracy on any single mapping. It is that a programmer starts from a populated draft informed by every mapping your organisation has already approved, rather than a blank specification. Onboard the studies most likely to appear in a filing or an integrated summary first, and accept that some legacy assets are best left where they are with a documented rationale.

Why do the source system and library integrations break after the first study?

Because study one is always the tidy one. Your first integration is built against a single electronic data capture export and a single laboratory vendor layout, and it works. Study four arrives from a different contract research organisation whose convention differs in ways that look cosmetic and are not: a different subject identifier construction, dates carried as partial values, visit structures recorded against a different anchor.

The trap that is specific to this domain is that these differences are invisible in a schema comparison and only appear as conformance findings weeks later, or worse, as a reviewer question after submission. A column that matches by name and type can still carry a different clinical meaning, and the mapping that silently accepts it produces datasets that validate cleanly and describe something slightly untrue.

The fix is to treat each delivery convention as an onboarding pattern rather than a variation, held as a named, reusable profile with its own transformation rules and its own test fixtures. Pull standards metadata from the CDISC Library rather than maintaining your own copies that drift. And run conformance as an automated loop on every build rather than a gate near the filing, so a convention difference surfaces on the day it arrives instead of during the quarter you cannot afford.

What happens when controlled terminology and validation are not governed?

Controlled terminology is published on a regular cycle and your studies are pinned to different versions. On top of that sit your own extensible codelists, and in most organisations those extensions accumulate without an owner, so the same concept appears three ways across three studies. Nobody notices until an integrated summary is attempted and the pooling fails, at which point the cleanup is archaeology conducted under a deadline.

The validation side has a matching gap. Pinnacle 21 is the de facto standard and deserves that position, but validation is diagnosis rather than treatment. It tells you what is non conformant. It does not tell you which of several hundred findings are the same three problems repeated across domains, and it does not do the mapping. Teams that run it only at the end mistake a rejected file for a data problem when it is a governance problem that was visible months earlier.

The fix is to treat terminology as versioned reference data with a promotion process. Published packages load automatically. Every sponsor extension requires a named owner, a definition and an approval, and the system reports where an extension is used and whether a published term has since arrived that should replace it. Then group conformance findings by root cause rather than by count, so the team fixes three declarations instead of triaging four hundred rows. The payoff is not conformance for its own sake, it is that integration across studies stops being an excavation exactly when you need it most.

Should you build custom or configure what you already own?

Licence, genuinely, if you file rarely and your studies are conventional. Pinnacle 21 Enterprise plus experienced contract programmers will get you a compliant package for less than any build, and there is no portfolio effect to capture because you do not have a portfolio. Licence also if your organisation has no standards governance function, because tooling does not create governance and an ungoverned metadata repository decays faster than a folder of programs.

Before commissioning anything, exhaust what you already hold. Pinnacle 21 Enterprise ships a metadata repository and governance you configure to its model, and many organisations buy it and use it as a validator. Certara Formedix is strong on metadata driven study design if that is closer to your problem. The SAS Clinical Standards Toolkit gives a serious framework if you are a deep SAS shop with the internal expertise to maintain it, which is a real condition rather than a formality.

Build when two or more of these hold. You file more than a couple of submissions a year and the same mapping work keeps repeating. You carry acquired assets in unfamiliar structures and legacy onboarding has become a recurring cost line. You receive data from several contract research organisations on different conventions. Your terminology extensions are ungoverned and cross study integration is painful. Or your Define-XML is assembled by hand near the filing date, which is a schedule risk hiding as a task.

How do hidden costs get into the quote?

Through items that read as configuration and behave as separate workstreams. The recurring ones in this category deserve to be named in the estimate rather than absorbed.

• Each source convention. Every contract research organisation delivery pattern is its own onboarding profile with its own rules and fixtures, not a variation on the first one.
• Running both SAS and R. A shop maintaining two execution paths is doing double the validation work, permanently.
• Therapeutic area supplements. Areas with specific supplemental standards add domains and rules that were not in the base scope.
• Computerised system validation. A system producing submission datasets is regulated under 21 CFR Part 11 and needs qualification, with requirements traced to executed test scripts and documented change control.
• Library integration. Pulling standards metadata from the CDISC Library rather than maintaining copies is the right call and is real integration work.

What keeps the number down is implementing three representative studies end to end before widening, and resisting the pull to model every domain in release one. The validation package is not the place to economise, because a system whose output you cannot defend has no value regardless of what it cost.

What separates a standards build that works from one that fails?

Ask how the Define-XML stays synchronised with the datasets. If the answer involves a separate generation step run late in the process, they are rebuilding the problem you are trying to leave. The correct answer is that both are rendered from the same metadata and cannot diverge, and a partner who has done this says it before you finish the question.

Ask what happens when the implementation guide moves a version. A team that has lived through it talks about the target standard as a parameter and about regeneration with a change report. A team that has not talks about updating the programs, which is the same quarter of manual work you are paying to eliminate.

Ask how derivations are tested. Fixtures with expected outputs, run automatically, is the only answer that holds up when a reviewer asks how a particular analysis flag was set for one subject. Bind the derivation text and the executable rule together so the specification and the code cannot drift apart, and make sure a model never derives data, only proposes mappings for a human to confirm.

Then confirm in writing before kickoff that you own the repository, the metadata, the infrastructure accounts and the validation package. Your mapping library will become one of the more valuable assets in the department, and it has to be portable to any partner, including away from whoever built it.