A compliant structured diagnostic data regulatory submission needs analysis-ready datasets built on CDISC standards, diagnostic findings mapped through HL7 FHIR's DiagnosticReport resource, and delivery as an eCTD v4.0 package through the FDA Electronic Submissions Gateway. Get those three pieces aligned before you touch a submission calendar.
Here's the checklist to work from:
- Analysis-ready SDTM and ADaM datasets, adapted for diagnostic or IVD study data
- A clinical Study Data Reviewer's Guide (cSDRG) describing conformance choices
- A complete define.xml metadata file mapping every variable
- Controlled vocabulary mappings using LOINC for tests and SNOMED CT for findings
- An eCTD v4.0 sequence with study data placed in the correct module
- A passed ESG test submission before requesting production access
- A Study Data Standardization Plan (SDSP) flagging any nonstandard mappings
Pro Tip: Run technical validation (does the file parse?) and content validation (does the data make sense against the study report?) as two separate exercises. Teams that combine them almost always miss the content-level errors that trigger review holds.
Key Takeaways
A compliant structured diagnostic data regulatory submission depends on dual-standard datasets, disciplined eCTD packaging, and validation run as two separate tracks, not one.
| Point | Details |
|---|---|
| Use dual-path standards | Build CDISC SDTM/ADaM for study reviewers and HL7 FHIR/USCDI for interoperability reviewers in parallel. |
| Map vocabularies early | Assign LOINC codes to tests and SNOMED CT codes to findings before dataset construction begins. |
| Test ESG before production | Complete the mandatory ESG test submission and a sample sequence check well ahead of the filing deadline. |
| Separate validation tracks | Run technical schema validation and content validation as independent activities, not one combined check. |
| Consolidate diagnostic sourcing | Kohealth Labs integrates lab and radiology capture with mapping and define.xml generation built into one workflow. |
Which Standards Apply to Structured Diagnostic Data Submissions
Three standards families do different jobs, and confusing them is the single most common planning mistake in a regulatory submission process. CDISC's SDTM and ADaM models organize tabulation and analysis datasets for study reviewers. HL7 FHIR's DiagnosticReport resource represents findings and interpretations for interoperability and downstream clinical systems. USCDI defines the core data elements nationwide health information exchange expects, including diagnostic report date and time, indication, and the "Result/Report interpreted" element, with USCDI v7 adding further diagnostic elements.
The vocabulary layer matters just as much as the structural one. Use LOINC to identify the test itself, SNOMED CT for the finding or interpretation, and a controlled code list for device or assay specifics that neither vocabulary covers.
Consider a single lab result: a serum glucose value gets a LOINC code, lands in the SDTM LB domain with its result and unit, and simultaneously populates a FHIR DiagnosticReport with a SNOMED CT interpretation code. Two representations, two audiences, one source value.
| Standard | Primary use | Reviewer audience |
|---|---|---|
| CDISC SDTM/ADaM | Study tabulation and analysis | FDA statistical/clinical reviewers |
| HL7 FHIR DiagnosticReport | Findings and interpretations | Interoperability and downstream systems |
| USCDI elements | Nationwide data exchange metadata | Health IT and exchange partners |
MDIC's work on IVD data standardization recommends adapting CDASH, SDTM, and ADaM specifically for in vitro diagnostic study data, arguing that inconsistent formatting, not missing data, is what slows most IVD reviews.
Pro Tip: Build a dual-path deliverable from day one: SDTM/ADaM for the statistical reviewer, FHIR/USCDI for the interoperability reviewer. Retrofitting one from the other later costs far more than building both in parallel.
How to Package and Transmit Your Submission Through eCTD and ESG
The FDA treats eCTD as the accepted electronic format for major application types, and the Electronic Submissions Gateway as the required transmission point for that package. Getting the sequence and account setup right early saves weeks later.
- Register for ESG access and complete the mandatory test submission phase before requesting production credentials.
- Submit a sample dataset or trial sequence for early feedback; FDA guidance specifically recommends this as a check before full production submission.
- Place study-data documents in their designated eCTD locations. Datasets and the cSDRG have defined homes within Module 4 and Module 5, and the SDRG itself needs a specific document type designation.
- Format tabulation datasets as XPORT (.xpt) files, one dataset per file, following FDA naming conventions, and pair each with a complete define.xml.
- Keep an eye on submission size. FDA guidance notes practical limits, generally under 10 GB per sequence, so plan attachment sizing accordingly.
- Run local, automated eCTD validation against the agency's published validation criteria before you touch the ESG test environment.
Pro Tip: Treat the ESG test phase as a dress rehearsal, not a formality. Submissions that fail production transmission almost always failed the same checks in test, just unnoticed.
Building Analysis-Ready Datasets Reviewers Can Actually Use
A dataset isn't analysis-ready just because it's formatted. It's analysis-ready when a reviewer can trace every value back to its source without asking you a question. That means SDTM domains, ADaM analysis datasets where the review requires them, and supplemental or device-specific domains for IVD-specific parameters that standard SDTM doesn't cover.
Three documents make that traceability possible: the define.xml file mapping every variable and its origin, a data dictionary and mapping table showing source-to-SDTM and source-to-ADaM transformations, and the cSDRG describing conformance decisions and any deviations. Provenance documentation, meaning version history and derivation logic for every transformed variable, is what lets a content reviewer trust a derived value without recreating it.
| File type | Purpose | Typical eCTD location |
|---|---|---|
| .xpt tabulation datasets | Raw and derived study data | Module 5 study data section |
| define.xml | Variable-level metadata and mapping | Adjacent to each dataset |
| cSDRG (PDF) | Conformance narrative and deviations | Module 5, SDRG document type |
| Mapping tables | Source-to-standard transformation logic | Supporting appendix |
Take a single glucose result as a worked example: the source lab value maps to LOINC code 2345-7, lands in the SDTM LB domain as LBORRES with LBTESTCD populated, and if a change-from-baseline analysis is required, the derived value appears in an ADaM BDS dataset with full derivation logic documented in define.xml.
Pro Tip: Write your define.xml derivation notes as if the reviewer has never seen your protocol. Vague notes like "calculated per SAP" generate more information requests than any missing dataset.
What Causes Structured Data Submissions to Get Delayed or Rejected
Run two validation tracks, not one. Technical validation checks whether your eCTD package and datasets parse correctly against schema. Content validation checks whether a reviewer can actually interpret the data and tie it back to the study report. MDIC's analysis treats these as genuinely separate activities that both need independent sign-off, and skipping one is where most delays originate.
The recurring pitfalls, in order of frequency:
- Missing or incorrect LOINC and SNOMED CT codes that break automated ingestion
- Incorrectly named or structured .xpt files that fail transport-level checks
- Incomplete define.xml files or cSDRGs that leave reviewers guessing at conformance choices
- Labeling claims that don't match the submitted clinical data, a classic trigger for refuse-to-file decisions
- ESG test submissions skipped or rushed, surfacing production failures too late to fix
Before you submit, run a local schema validator, check SDTM and ADaM conformance against the current implementation guide, validate FHIR resources independently, and push a sample sequence through ESG test.
Pro Tip: Hand your package to someone outside the data team and time how long it takes them to locate the primary dataset, its define.xml, and the analysis rationale. If it takes longer than five minutes, your reviewer will hit the same wall.
When to Engage Regulators and What to Bring
Request a pre-submission meeting, whether pre-IND, pre-NDA, or an End-of-Phase 2 meeting for CBER-regulated products, whenever your data standards plan includes anything nonstandard. Bring mapping tables, sample datasets, and an SDRG outline so regulators can react to structure before you've built the full package.
Your minimum submission package should include the SDSP (or an SDSP appendix), the cSDRG, define.xml, representative sample datasets, full mapping documentation, and a cover letter scoping exactly what data is included.
A realistic milestone sequence looks like this:
- Finalize the standards decision (CDISC version, FHIR profile, vocabulary set)
- Build datasets and complete internal mapping documentation
- Run local schema and conformance validation
- Complete ESG test submission
- Submit a sample sequence for early agency feedback
- Submit the production package
Pro Tip: Flag nonstandard mappings in the SDSP and raise them directly in the pre-submission meeting. Silence on a nonstandard approach is what turns into a refuse-to-file letter three months later.
How Kohealth Labs Operationalizes Analysis-Ready Diagnostic Delivery
Most of the friction in a regulatory submission process traces back to one root cause: diagnostic data arriving from multiple vendors in multiple formats, requiring reconciliation before mapping can even start. Kohealth Labs addresses that at the source by running lab and radiology diagnostics as integrated services under a single workflow, from specimen handling through standardized capture, semantic mapping to LOINC and SNOMED CT, and SDTM/ADaM extraction with define.xml and cSDRG generation built in.
For sponsors and CROs, that consolidation shows up as concrete operational gains:
- Less rework, because mapping happens once against a single data model instead of once per vendor
- Faster reviewer access, since datasets and metadata are generated together, not reconciled after the fact
- Single-source provenance, which shortens the audit trail a content reviewer has to walk
- Fewer ESG test failures, because file structure and naming conventions are consistent from the first sequence
A single-study workflow that unifies lab and radiology capture under one data model cuts the reconciliation work that normally happens before mapping can even begin, and that's where most submission delays are quietly born.
The same AI-driven data processing that flags deviations for safety monitoring also catches the mapping inconsistencies that would otherwise surface during ESG testing.
Pro Tip: Ask any diagnostics vendor how many separate contracts and data formats you'll be reconciling before your standards team even starts mapping. That number predicts your timeline better than anything else.
Editorial Take: What the Standards Debate Misses
Most regulatory guidance on structured diagnostic data treats standards selection as the hard part. It isn't. Choosing CDISC for tabulation and FHIR for interoperability is well documented and rarely controversial. The actual failure point sits in the gap between having the right standard and having consistent source data to map into it, which is exactly what MDIC's IVD data work keeps finding when it flags data inconsistency as the primary review blocker.
Conventional advice tells teams to "adopt CDISC early" and stops there, as if adoption were the finish line. It isn't. A team can be fully CDISC compliant and still generate a cSDRG a reviewer can't follow, because the provenance documentation was an afterthought bolted on after dataset lock.
Prioritize provenance and mapping documentation before you optimize dataset elegance. A reviewer forgives a slightly unconventional domain structure explained clearly in the SDRG. A reviewer does not forgive a beautifully structured dataset with no explanation for how a derived value was calculated. Fix your source-data consistency problem first. The standards conversation gets much easier after that.
Get Analysis-Ready Diagnostic Data Without the Vendor Reconciliation
Most sponsors piece together lab results and radiology data from separate vendors, then spend weeks reconciling formats before their standards team can even start mapping to SDTM or FHIR. Kohealth Labs runs both under a single contract, delivering analysis-ready diagnostic data already structured for the mapping work your submission requires, with AI-driven checks that catch deviations before they become ESG test failures.
That single-contract model means one onboarding process, one data format, and one point of contact instead of three vendor relationships pulling in different directions. If your team is scoping a diagnostic data delivery plan for an upcoming submission, reach out to Kohealth Labs to talk through how your specific study design maps to an analysis-ready delivery workflow.
Frequently Asked Questions
What is required for a structured diagnostic data regulatory submission? You need CDISC-aligned SDTM/ADaM datasets, HL7 FHIR mapping for diagnostic findings, complete define.xml metadata, a cSDRG, and delivery as an eCTD v4.0 package transmitted through the ESG.
Do I need both CDISC and FHIR for one submission? Often yes. SDTM and ADaM serve statistical reviewers examining study tabulations, while FHIR's DiagnosticReport resource serves interoperability reviewers and downstream systems that need machine-readable findings.
How long does the eCTD and ESG testing process take? Timelines vary by sponsor readiness, but the sequence runs from standards finalization through dataset build, local validation, ESG testing, a sample submission, and production filing. Starting ESG account setup early avoids the most common bottleneck.
What causes most rejections in diagnostic data submissions? Missing or incorrect LOINC and SNOMED CT codes, incomplete define.xml or cSDRG documentation, and labeling claims that don't match submitted data are the most frequent causes of delay or refuse-to-file outcomes.
Sources
- Standardizing Clinical Data for In Vitro Diagnostics - Medical Device Innovation Consortium
- Electronic Regulatory Submission and Review | FDA
- Study Data Technical Conformance Guide (FDA supplemental guide) (PDF)
- United States Core Data for Interoperability (USCDI) | Interoperability Standards Platform (ISP)