CDASH Mapping: Get LBLOINC Right for SDTM Lab Submissions

CDASH collects trial data at the point of entry, and SDTM organizes that same data into the tabulated, submission-ready format reviewers expect; the bridge between them is a documented mapping specification paired with ETL rules. For laboratory results, the single highest-stakes requirement is populating LBLOINC whenever a valid LOINC code exists. Getting there also depends on solid metadata, consistent linking identifiers, and a validation pass before submission.

TL;DR:

• Request the testing laboratory’s confirmed LOINC crosswalk before mapping begins; FDA guidance warns sponsors not to derive or guess codes without laboratory confirmation.
• Store results in SI units in LB, and add LC with conventional units when reviewers or the submission require both systems.
• Generate stable linking identifiers during database export, then use them consistently across repeating laboratory records and related adverse event, medication, exposure, and demographic domains.
• Run Pinnacle 21 on early drafts and after mapping changes prompted by amendments; waiting until database lock can expose errors across dozens of records.
• Use CDASH compliant forms from study design to reduce later mapping work; retrofitting nonstandard legacy forms requires a longer mapping and validation cycle.

What CDASH and SDTM are, and why both matter

CDASH and SDTM solve different problems, and confusing them is where many mapping projects go wrong. CDASH is a collection standard: it shapes the electronic case report form (eCRF) that a site coordinator fills out during a patient visit. SDTM is a tabulation standard: it defines how that same information must look once it reaches a regulatory reviewer’s desk. The two were never meant to be identical, but they were built to talk to each other.

That conversation happens through CDASH-to-SDTM mapping annotations, which CDISC publishes alongside the CDASH implementation guide. These annotations tell a programmer, field by field, which SDTM variable a given CRF entry should become, and they remove a surprising amount of guesswork from what would otherwise be an ad hoc translation exercise.

Using CDASH-compliant eCRFs from the start brings three concrete advantages:

• Traceability: every SDTM value can be traced back to the exact CRF field that produced it.
• Reuse: standardized field libraries mean less time spent designing forms from scratch for each new study.
• Lower programming burden: less custom mapping logic is needed when the collection structure already anticipates the tabulation structure.

Studies that build CDASH-compliant forms at the design stage, rather than retrofitting them later, consistently report a smoother path to SDTM and fewer late-stage corrections, a pattern documented in implementation research on CDASH harmonization. The upfront discipline pays off downstream, particularly once lab data enters the picture.

Step-by-step: mapping CDASH fields into SDTM domains

Converting CDASH-collected data into SDTM datasets follows a repeatable sequence, whether the study is a Phase 1 pharmacokinetic trial or a multi-site observational program. Skipping steps tends to surface as validation errors much later, when fixes are more expensive.

1. Inventory your source metadata. Pull together annotated CRFs (aCRFs), the CDASH implementation guide version used, and any sponsor-specific collection variants before writing a single line of transformation code.
2. Author the mapping specification. Document every target SDTM variable, the derivation logic behind it, and the linking identifiers (such as LNKID or FALNKID) that will tie repeating records together.
3. Build and run the ETL. Implement transform rules that handle repeating CRF sections, populate context variables like STUDYID, USUBJID, and PRDTC, and apply consistent date and casing conventions.
4. Capture non-standard data. Route anything that does not fit a standard SDTM variable into SUPPQUAL datasets, and begin drafting define.xml in parallel rather than after the fact.
5. Test iteratively and log provenance. Run partial datasets through validation early, and keep a mapping log that records why each derivation decision was made, which becomes invaluable when a reviewer asks a question months later.

Repeating CRF sections deserve particular attention. A single visit with multiple lab draws, for instance, often needs to become several linked SDTM records rather than one flat row, and that only works cleanly when linking IDs are built into the ETL logic rather than patched in afterward.

Pro Tip: Generate a stable CRFSECTION_ID-derived link value during database export, not during SDTM programming, so every downstream transformation inherits a reliable linking key.

Lab-data specifics: LB, LC, and getting LOINC right

Laboratory data carries its own set of SDTM rules that trip up even experienced mapping teams, largely because lab results combine clinical meaning with unit conventions that vary by country and by analyzer. The LB domain holds standardized, typically SI-unit, lab results. When a review division expects conventional units alongside SI units, current sdTCG and CDISC guidance recommends submitting an LC domain to carry those conventional-unit values rather than forcing a single unit system on every reviewer.

LOINC coding is where regulatory expectations are most explicit. FDA guidance states that sponsors should populate LBLOINC whenever a valid LOINC code exists for a lab test, and explicitly cautions against sponsors deriving or guessing a code without confirmation from the testing laboratory, according to FDA recommendations on LOINC submission. That single requirement shapes much of the operational work in a lab-data mapping project.

A few practical moves make compliance easier:

• Request the lab vendor’s internal-code-to-LOINC crosswalk early, before mapping specification work begins.
• Preserve LBNAM so reviewers can identify which laboratory generated each result.
• Choose the most specific LOINC code available rather than a generic panel-level code when a specimen-level code exists.
• Map values to SI units for LB, and populate LC with conventional units when the submission calls for both.

Submitting both LB and LC up front, rather than waiting for a reviewer to request the missing unit system, has become the more defensible approach in current practice, per the same CDISC lab data guidance. Teams that treat lab-to-LOINC mapping as a late-stage cleanup task tend to lose the most time, since confirming codes with a lab’s informatics contact can take longer than the mapping itself. Our LOINC mapping guide for high-volume lab tests walks through prioritizing the tests that carry the most submission weight first.

Validation and tools: define.xml, Pinnacle 21, and test strategy

A mapping project is not finished when the ETL runs cleanly; it is finished when the datasets pass structured validation and the accompanying metadata tells a reviewer exactly what was done and why. A complete submission package includes several distinct artifacts, not just the SDTM datasets themselves.

• SDTM datasets covering every domain the protocol requires, including LB and, where applicable, LC.
• define.xml, built to version 2.1 or later, documenting every variable, derivation, and controlled terminology reference.
• ADRG/SDRG notes explaining study-specific decisions a reviewer would otherwise have to guess at.
• Controlled terminology mappings, confirmed against the current CDISC CT package in use for the study.

Pinnacle 21 remains the standard validator most teams run before submission, and its output tends to cluster around a few recurring issue types: controlled terminology mismatches, missing required variables, and unit inconsistencies between LB and LC records. Catching these early, rather than at the final submission pass, is largely a matter of cadence.

Running validation against early SDTM drafts, well before the database locks, surfaces structural problems while they are still cheap to fix. Teams that wait until data is final to run their first Pinnacle 21 pass often discover systemic mapping errors that require reworking dozens of records at once, a pattern consistent with the operational benefits of early, iterative conversion described in CDASH implementation research. Automating recurring checks, rather than running validation manually at each milestone, keeps that cadence sustainable across a long study.

Checklist, timeline, and who needs to be involved

Planning a CDASH-to-SDTM lab mapping project works best when the deliverables and the people responsible for them are defined before work starts, not discovered along the way.

1. Annotated CRFs confirming which CDASH fields map to which SDTM variables.
2. A written mapping specification covering derivations, linking logic, and edge cases.
3. A lab-to-LOINC crosswalk file confirmed directly by the testing laboratory.
4. ETL scripts implementing the mapping specification, version-controlled and documented.
5. define.xml and accompanying reviewer notes.
6. Validation reports from each testing pass, including the final pre-submission run.

Timeline expectations vary with how early CDASH was adopted. Studies that collected data on CDASH-compliant CRFs from the outset tend to move through SDTM conversion faster, since much of the mapping logic was anticipated during form design, a benefit documented in peer-reviewed CDASH adoption research. Studies retrofitting SDTM onto non-standard legacy CRFs should plan for a longer mapping and validation cycle, particularly where lab data involves multiple vendors or unit systems.

Four roles typically carry the bulk of this work: the data manager who owns the mapping specification, the central lab or labs supplying LOINC crosswalks, the programmer implementing and testing the ETL, and the sponsor reviewer signing off on define.xml and validation results before submission.

Pro Tip: Loop in the central lab’s informatics contact during protocol finalization, not after database lock, so LOINC crosswalk delays never sit on the mapping project’s critical path.

Our lab data harmonization primer outlines the first steps research teams and labs should take together before a mapping project formally kicks off.

How a lab partner reduces CDASH to SDTM mapping friction

Much of the friction in lab-data mapping traces back to incomplete or delayed information from the testing laboratory itself. Clinical trial teams benefit from electronic results reporting, LIS integration, and specimen logistics designed to reduce exactly that friction. When a lab partner can supply a confirmed lab-to-LOINC crosswalk alongside dual-unit reporting, teams gain a faster path to populating both LB and LC without guessing at codes or re-querying a lab weeks into programming. Research organizations can access laboratory testing and specimen management designed to fit study-specific requirements, which is where analysis-ready feeds make the largest difference to a mapping timeline. Details on testing capabilities can be found on the what we test page.

Handling adverse events and concomitant medication data in the mapping process

Adverse event (AE) and concomitant medication (CM) data follow the same general CDASH-to-SDTM logic as lab data, but with their own wrinkles worth planning for separately. AE data collected on CDASH-standard forms typically maps into the AE domain with relatively direct variable correspondence, though coding against MedDRA happens as a distinct step from the structural mapping itself, and both need to be complete before the dataset is submission-ready.

Concomitant medications map into the CM domain, where dictionary coding against WHO Drug or a similar reference adds another layer beyond the structural transformation. A common source of error in both domains is timing: AE and CM records often need to be cross-checked against visit dates and, where relevant, against lab result dates to confirm temporal relationships a reviewer may ask about, such as whether a lab abnormality preceded or followed a reported adverse event.

Because AE and CM data frequently reference other domains, including LB, keeping linking identifiers consistent across all three is worth building into the mapping specification from the start rather than reconciling after the fact. Treating AE, CM, and LB mapping as fully separate workstreams, without a shared linking convention, is one of the more common sources of late-stage rework.

Integrating lab data with other clinical trial domains

Lab results rarely stand alone in an analysis. A single LB record often needs to connect to exposure data (EX), demographics (DM), and sometimes AE records, since a safety reviewer frequently wants to see a lab abnormality alongside the dose a patient was receiving at the time. That connective tissue depends on consistent use of USUBJID across every domain and, for time-based analysis, consistent and correctly derived date variables like LBDTC.

Analysis datasets built under ADaM standards draw directly from SDTM domains including LB, which means mapping errors in the tabulation layer propagate forward into every downstream analysis. A missing LBLOINC code or an inconsistent unit between LB and LC does not just fail validation; it can limit how effectively a statistician can pool lab results across sites or across studies for a pooled safety analysis.

Teams planning for cross-domain integration from the outset, rather than treating each domain as an isolated deliverable, tend to catch these dependencies before they become last-minute fire drills. Reviewing how LB, EX, AE, and DM will need to join together for analysis, before mapping specifications are finalized, is one of the more effective ways to avoid rework once a statistician starts building ADaM datasets.

Quality control and audit trailing during mapping

Mapping CDASH data into SDTM involves enough manual decision-making, particularly around derivations and non-standard fields, that a documented quality control process is not optional for a submission-bound dataset. Every derivation rule in the mapping specification should have a documented rationale, not just a formula, so a reviewer or auditor years later can understand why a decision was made.

Version-controlling both the mapping specification and the ETL scripts, rather than treating them as living documents that change without a record, creates the audit trail regulators and internal QA teams eventually ask for. Logging mapping provenance, meaning which source field and which transformation rule produced each SDTM value, pays off most when a late-stage query asks why a specific value looks unexpected.

A second, independent review of the mapping specification, separate from the programmer who implemented it, catches a meaningful share of errors before they reach validation. Running Pinnacle 21 at each major milestone rather than only at the end turns validation into a quality control checkpoint rather than a final gate, and it keeps the audit trail showing steady, documented progress rather than a single pass-fail event at submission time.

Common lab mapping challenges and how to troubleshoot them

A handful of problems recur across nearly every lab-data mapping project. Missing or unconfirmed LOINC codes top the list, usually because a lab vendor has not yet supplied a crosswalk file; the fix is requesting that file, with specific test codes and specimen types, as early as protocol finalization rather than after database lock.

Unit mismatches between sites or between a central lab and a local lab create a second common headache, particularly when some results arrive already in SI units and others need conversion. Deciding on the LB and LC structure before data starts flowing in, rather than retrofitting it once results are already loading, avoids a substantial amount of rework.

Repeating lab panels, where a single visit produces dozens of individual analyte results, often expose weak linking logic. If LNKID or FALNKID values are not built consistently from a stable source field, the resulting SDTM records can become difficult to reassemble into a coherent panel view for review. Building that linking rule into the database export itself, rather than leaving it to ad hoc programmer judgment during SDTM creation, fixes this at the source rather than patching it downstream.

Finally, inconsistent LBNAM values, where the same lab is labeled differently across forms or sites, obscure which laboratory actually produced a result. Standardizing lab identifiers at the point of data entry prevents this from becoming a cleanup project later.

How protocol amendments affect CDASH to SDTM mapping

Protocol amendments are a near-certainty in any trial of meaningful length, and they rarely arrive without consequences for a mapping specification already in progress. Adding a new lab panel, changing a visit schedule, or adjusting an inclusion criterion can all require new CDASH fields, which in turn require new SDTM mapping rules and, for lab tests specifically, new LOINC confirmations from the testing lab.

The mapping specification should be treated as a versioned document that tracks which protocol version each rule corresponds to, rather than a single static file that gets edited in place. Without that version history, it becomes difficult to explain to a reviewer why certain records follow one derivation logic and others follow a slightly different one.

Amendments that change lab panels are worth flagging for an updated LOINC crosswalk request immediately, since lab vendors need lead time to confirm codes for any newly added tests. Re-running validation after each amendment-driven mapping update, rather than waiting until the next scheduled milestone, catches structural issues introduced by the change while they are still isolated to a small set of records.

CDASH-first or post-hoc conversion: which approach fits your program?

For high-volume or repeated studies, especially where lab data carries significant analytical weight, building CDASH-compliant CRFs from the start is worth the upfront investment. When timelines are tight, prioritize LOINC mapping for your most common lab tests and run validation early rather than waiting until the end.

— Kohealth Labs

Get lab-ready for your next CDASH to SDTM submission

A mapping project moves faster when the lab data arriving at your door is already clean, well-coded, and consistently structured. Clinical research organizations and sponsors may benefit from electronic results reporting, LIS integration, specimen logistics, and lab-to-LOINC mapping support designed to reduce the friction described throughout this guide.

Whether you are seeking a primary lab partner for an upcoming study or additional resources for specialized panels and faster turnaround, clinical trials laboratory services offer analysis-ready reporting that CDASH-to-SDTM mapping depends on. Reach out to talk through your study’s lab requirements and get a crosswalk process started before your next database lock.

FAQ

What are the key differences between SDTM and CDASH?

CDASH is a data collection standard that shapes how an eCRF is built, while SDTM is a tabulation standard that defines how cleaned trial data must be structured for regulatory submission. CDASH includes mapping annotations that show how a given collected field becomes a specific SDTM variable, which is what makes the conversion between the two more predictable than building SDTM from scratch.

What is the role of CDASH in clinical trials?

CDASH standardizes how data is collected at the point of entry, giving sites a consistent eCRF structure across studies and sponsors. Because CDASH anticipates SDTM’s tabulation structure, using CDASH-compliant forms at study design reduces the mapping and programming work needed later to produce submission-ready SDTM datasets.

What does CDASH mean?

CDASH stands for Clinical Data Acquisition Standards Harmonization, a CDISC standard that defines consistent field names, structures, and collection conventions for case report forms. It exists to make data collection repeatable across studies and to simplify the eventual conversion of that data into SDTM.

What is the PR domain in SDTM?

The PR domain in SDTM captures procedures performed on a trial subject, such as surgical or diagnostic procedures, distinct from the LB domain that holds laboratory test results. Like other SDTM domains, PR records rely on consistent USUBJID and date variables to link correctly with related domains during analysis.

Sources

• The Magic that Happens between CDASH and SDTM | CDISC
• Recommendations for the Submission of LOINC Codes in Regulatory Applications to the U.S. Food and Drug Administration
• Clinical Data Acquisition Standards Harmonization importance and benefits in clinical data management (PMC)

For more information about our diagnostic testing, clinical research laboratory services, or partnership opportunities, visit https://kohealthlabs.com or contact KoHealth Labs at (469) 792-8439 and ask for Amy Patterson.