Use case ideation (What problems are we solving)

[chowsanthony]

What problems exist today that we should solve in addition to using new standards?

[chowsanthony]

Category	Problem area	Current gaps or problems	Opportunities	Why DDS?
Double programming	Manual re-entry of metadata	Variables, labels, formats, and rules are retyped across specs, define.xml, and code	Eliminate redundant manual entry or copied of same metadata	Drive downstream artifacts automatically
Double programming	Validation burden	Teams must validate multiple implementations of the same logic	Reduce validation effort by reducing duplication	Fewer independent implementations means fewer things to reconcile and validate
Double programming	Slow iteration	Double programming slows development cycles and increases lead time	Speed up development without sacrificing control	Automated pipelines reduce manual rework and re-implementation
Audit readiness	External (FDA) audits	High burden to explain processes, data lineage, and controls	Make it easy to demonstrate compliance, traceability, and process integrity	Structured standards create consistent, explainable artifacts
Audit readiness	Data fidelity	Risk of discrepancies between source data, analysis datasets, and outputs	Ensure consistency across systems and transformations	Single source of truth + automated derivations reduce human error
Audit readiness	Traceability	End-to-end traceability (source > transform > analysis > output) is fragmented	Make lineage explicit and queryable	DDS/define.json can encode dataset relationships and derivations
Audit readiness	Reproducibility	Analyses may not be easily reproducible months later	Ensure results can be regenerated on demand	Automated, versioned pipelines improve reproducibility

[sherry-chou]

For the first 'Manual re-entry of metadata'. I think we might start to get problems with variable labels given that starting from SDTMIG v3.3, the conformance rule CG0303 'Variable Label = IG Label' was dropped.
If we want to automate this part, then we need to bring this rule back in and fix what is currently described in the IG (in upcoming SDTMIG v4.0 it's at Section 4.2.1).

(Side note, I've personally never really gotten the reason why we even want to remove this rule in the first place then later worry about users changing underlying meaning of the variable through label.
I recall discussions started about wanting to make labels for variables such as --CAT, --SCAT more meaningful...but at least for me, mapping a certain piece of information to a specific domain itself is given enough context already so having the need to customize their label never persuaded me and this added a layer of complexity if we ever wishes to standardize/automate things.)

[chowsanthony]

Category	Problem area	Current gaps or problems	Opportunities	Why DDS?
Define-XML pain point	Typically treated as an output, not an input	Define is typically authored after datasets and programs exist, so it reflects decisions rather than guiding them	Enable Define to act as a planning and design artifact that drives downstream work	Use DDS/define.json as the canonical, prospective spec that generates study define and informs pipeline configuration
Define-XML pain point	Poor fit for iterative study design	Protocol design changes can be frequent, but study's Define updates lag behind	Make metadata updates cheap, versioned, and easy to diff	Demonstrate how to treat Define as code: version control, diffs, automated regeneration of Define
Define-XML pain point	Hard to keep Define in sync during development	As datasets evolve, Define drifts; teams reconcile Define late, creating rework and risk	Make synchronization automatic and continuous	Regenerate Define from the same source metadata used to drive dataset creation
Define-XML pain point	Teams are not used to “designing with Define first”	Define is seen as regulatory overhead	Shift mindset: Define as a design contract, not just a compliance deliverable	Lower the friction of using Define prospectively by making it useful for developers, not just submitters

[chowsanthony]

Another category could be “Non-standard, non-tabular data handling,” which includes:

1. Binary data, such as imaging and radiology files
2. Omics and assay data
3. Streamable data, such as those generated by DHT devices
4. API-friendly data sources used for data exchange, such as FHIR

[lexjansen]

Also, the possibility of richer text content by allowing HTML in narrative content (method descriptions, comments, ...), instead of just text.

[swhume]

Another Define-XML pain point: organizations lean on their own standards and metadata definitions to generate a define.xml. This results in manual metadata entry/editing, which limits automation and increases variability in standards. In addition to starting from USDM, we seek to increase the use of CDISC standards metadata via BCs + DSSs + CDISC Library API to minimize organizationally defined metadata and maximize automation.

This is similar to "Manual re-entry of metadata" in the Double Programming category.

[sherry-chou]

Adding to what Sam's point - some validation vendors, such as P21 also seemed to build on already available standard metadata from CDISC Library but added their own customization to it to generate, e.g., Value Level information...but values in it although seemingly correct, might be a bit of black box since there is no obvious information given on which version of CT they've used for them. For organizations who uses such products in their downstream pipeline, there would be resistance for them to switch pulling from elsewhere for automation.

[TeMeta]

I'd like to add as a pain point "I want to point to Define-XML as a Data Contract as part of a Data Transfer Specification, but people get confused and tell me it's an output not an input"

[chowsanthony]

Re: Double programming & unit test

Building on the comments about date and time granularity between collection and analysis needs, such as identifying the last observation before exposure, could DDS eventually support pipeline simulations? In cases like this, could it help flag imprecise data, for example missing time information, before enrollment even begins?

[swhume]

We agreed that this content would work well in repo wiki. Let's plan to have this in the wiki prior to our EU Interchange milestone.

[chowsanthony]

We agreed that this content would work well in repo wiki. Let's plan to have this in the wiki prior to our EU Interchange milestone.

See the wiki page: https://github.com/cdisc-org/data-definition-engine/wiki/Vision