SDTM LB Mapping: A Practical Guide for Lab Data

SDTM LB mapping is the work of turning laboratory results, whether they come from a central lab transfer or from site-entered CRF fields, into the CDISC Laboratory Test Results domain in a form regulators can review. It is more than renaming columns. You are deciding what each test is, which specimen and method produced it, what unit it is reported in, and how to explain every exception. This guide walks through the decisions in the order you will face them, with the FDA expectations that shape them.

We wrote it for clinical data managers, programmers, study directors and sponsor teams who want fewer surprises between the first lab transfer and the submission package.

TL;DR

• LB mapping is a governed standardization task: test identity, specimen, method, result, units, reference ranges, timing and visit all need documented decisions.
• For FDA submissions, plan for LOINC codes in LB, and for SI results in LB with conventional units in a custom LC domain.
• Do not derive LBLOINC from a test name. If the lab did not supply a defensible code, document why.
• Agreeing on CDASH-aligned collection and a lab transfer specification early saves far more time than fixing inconsistent data later.
• The XPT file is not the finish line. Define-XML and a Study Data Reviewer's Guide are part of the deliverable.

What the LB domain covers

The LB domain holds results from tests and measurements performed on collected biological specimens. CDISC describes typical content such as hematology, clinical chemistry and urinalysis. Microbiology and pharmacokinetic data belong in their own domains, so one of your first scoping decisions is which incoming tests stay in LB and which route elsewhere.

A good LB mapping addresses, at minimum:

• Test identity: the test code and name (LBTESTCD, LBTEST) and the category.
• Specimen and method: the material tested and how.
• Result: original and standardized, character and numeric.
• Units: the unit as reported and the standardized unit.
• Reference ranges and flags: limits and the abnormality indicator.
• Timing: collection date and time, visit, and any planned timepoint.
• Clinical significance: investigator assessments, where the protocol collects them.

If a test does not fit that list, it probably belongs to another domain, and it is better to find that out in the specification than during validation.

Start from the source: central vs. local labs

The mapping path depends on where the data originates. Central laboratory data usually arrives as a vendor transfer file with its own naming, units and ranges. Local laboratory data often arrives through the eCRF, entered by site staff, with ranges that differ from site to site. CDISC publishes separate CDASH examples for local processing and central processing with investigator assessment, and they are a useful reference for which fields you should expect.

Many studies use both. In that case, write one specification that treats each source explicitly, rather than forcing local data into a central-lab pattern. Local data tends to need more work on reference ranges and units, because each site may report differently.

Build a mapping specification that survives version changes

A spreadsheet alone ages quickly. Your specification should name the SDTM version, the SDTM Implementation Guide version and the controlled terminology package it was built against. CDISC's Controlled Terminology Relationships publication links terminology to SDTM variables and domains. The 2024 edition describes 2,384 rows of relationship metadata, including 762 SDTM and SDTMIG variables. CDISC Library delivers versioned standards metadata through a REST API, which helps if you want your specification checked against machine-readable standards.

For each target variable, a useful specification records:

1. The source field or file column, with its original name.
2. The transformation rule, written so a second programmer could reproduce it.
3. The controlled terminology codelist and the version.
4. How missing, unscheduled and repeated results are handled.
5. Who approved the decision and when.

LOINC and LBLOINC: where most of the effort goes

LOINC identifies the observation, and that is why regulators care about it. According to CDISC's controlled terminology page, FDA requires LOINC codes in the clinical LB domain for NDAs, ANDAs and BLAs for studies starting after March 15, 2020, and for certain INDs for studies starting after March 15, 2021. Check the current FDA submission context for your own study, because applicability depends on the application type and start date.

CDISC also publishes an official LOINC-to-LB mapping file with more than 1,400 LOINC codes across chemistry, hematology, coagulation, toxicology, urinalysis, serology and other classes. It excludes areas that map to other domains, such as microbiology, pathology, genomics and vital signs.

Treat the mapping file as an aid, not an answer

The CDISC file helps you populate test code, specimen, method and unit expectations from a LOINC. It does not replace review. Sponsor-specific and lab-specific tests will not all be covered, and some will need documented extensions. Plan for a manual review step, and for a terminology governance owner who decides how new terms are added.

Do not derive LBLOINC from a test name

This is the mistake we would most like to prevent. Takeda's implementation presentation at a CDISC interchange is a good example of expanding terminology and LOINC mapping in practice. The guidance behind it is that sponsors should not attempt to derive LOINC codes. The laboratory should supply them. If a code is unavailable, or a test is not mapped, say so in the data transfer process and explain the reason in the reviewer documentation.

The practical consequence: put LOINC in your lab transfer specification as a required field, for every test, from the start of the study. Asking for it after database build means asking a lab to reconstruct history.

Units: SI in LB, conventional units in LC

Unit handling is a commonly missed detail. The FDA Study Data Technical Conformance Guide, version 5.7 from March 2024, says clinical studies should submit SI laboratory results in LB and an additional custom LC domain for conventional units. LC is structured like LB. Where values differ, it updates the standard results, units, reference ranges and reference-range indicators.

This is a submission-design requirement, not a display preference. CDISC has a presentation on submitting laboratory data in multiple standard units that walks through the LB and LC approach.

What this means for your plan:

• Put the unit strategy in the vendor agreement and the lab transfer specification, so the lab sends what you need.
• Decide which unit is the original (LBORRESU) and which is standardized, and how conversions are performed and validated.
• Test the conversions on real values before database lock, especially for analytes where SI and conventional units differ by a non-trivial factor.
• Describe both domains in Define-XML.

The intent is reviewer-centered. Preserving both representations spares reviewers from reconstructing conversions themselves.

A worked example of one lab record

Take a serum glucose result from a central lab, reported at a Week 4 visit. The mapping decisions look like this:

None of these is difficult alone. The risk is inconsistency across hundreds of tests and several labs, which is why the rules belong in a specification rather than in programmers' memory.

Design collection for the conversion you will have to do

The cheapest fix for messy lab data is to prevent it. A CDISC presentation on why CDASH is needed reports an academic research organization's experience: roughly seven months for the first trial converting CRF data that was not CDASH-based, against roughly two months for the second trial using CDASH-based CRFs. Those are reported figures from one organization, not a promise for your study. The underlying point holds, though: standardized collection reduces assumptions during mapping, programming and validation, and it improves traceability.

For a CRO or sponsor, that suggests an order of operations:

1. Agree on CDASH-aligned eCRF fields for any lab data collected at sites.
2. Write the lab transfer specification with required fields, including LOINC and units, before the first transfer.
3. Run a test transfer and map it end to end before first patient in.
4. Revisit the specification whenever a lab adds a test or changes a method.

We go deeper on this in our article on getting LBLOINC right when mapping CDASH to SDTM.

What a submission needs beyond the LB file

Producing the XPT file does not complete the job. The FDA guidance expects complete, current Define-XML metadata and a Study Data Reviewer's Guide covering the submitted datasets. Sponsors should follow the applicable SDTMIG unless a documented, appropriate exception applies.

A practical deliverable set for lab data includes:

• Source-to-target specifications.
• Terminology and LOINC decisions, including unavailable codes.
• Derivation rules for study day, baseline and flags.
• Validation results, with explanations for any warnings you accept.
• Define-XML for LB and LC.
• Reviewer-facing explanations for exceptions.

Our overview of what a structured diagnostic data regulatory submission requires covers the same ground from the laboratory side.

Common validation findings, and what they usually mean

Validation tools tend to flag the same families of problems in LB, and each one points back to a specification gap.

• Invalid test codes: LBTESTCD must follow controlled terminology and the variable's length and character rules. A flag usually means a lab test name was carried through without a mapping decision.
• Unit inconsistencies: the same test reported in different standardized units across records. This often comes from a lab changing its reporting between transfers.
• Missing or inconsistent reference ranges: ranges that vary by site or sex but are not described anywhere in the specification.
• LOINC gaps: records where no code was supplied and no explanation was documented.

Fix these in the specification and the transformation code, not by editing the output. That keeps the next transfer clean.

Our perspective: lab data is easiest when the lab is part of the plan

We see LB mapping as a data-standardization project that starts in the laboratory, not in the programming group. The most reliable results come when the laboratory knows the target model before the first sample is run: which codes are required, which units are expected, how specimens and visits are labeled, and what the reviewer will ask for later. When a lab hears those requirements after the data has been produced, everyone ends up reconstructing intent.

That is why we focus on early agreement. For clinical research partners, we pair specimen collection and testing with structured, regulatory-aligned data delivery, so the decisions about identity, units and terminology are made once and carried through. Mapping will always need expert review, and no tool removes that. What a well-planned transfer can do is make the review a matter of confirming, not rescuing.

If your team is working on this now, take heart: a clear specification, a test transfer and a short list of agreed rules solve most of what looks overwhelming at the start.

— Kohealth Labs

Where KoHealth Labs fits

If you are planning a study and want laboratory results that arrive ready for standards-based mapping, see how our clinical trials laboratory services work. We support specimen collection, testing and analysis-ready data delivery for CROs, sponsors and research sites, and you can see the steps on our how it works page. For a wider view of the process, read our 8 steps to analysis-ready lab data and our guide to lab data harmonization.

FAQ

What is SDTM LB mapping?

It is the process of converting laboratory test data into the SDTM Laboratory Test Results domain. The mapping covers test identity, specimen, method, results, units, reference ranges, timing and visit. It should be documented in a versioned specification so each decision can be traced.

Is LOINC required in the LB domain?

For US submissions, CDISC states that FDA requires LOINC codes in clinical LB for NDAs, ANDAs and BLAs for studies starting after March 15, 2020, and for certain INDs for studies starting after March 15, 2021. Confirm applicability for your application type against current FDA guidance.

Why do I need an LC domain?

The FDA Study Data Technical Conformance Guide, version 5.7, asks clinical studies to submit SI results in LB and conventional-unit results in a custom LC domain. LC follows the structure of LB and updates results, units, ranges and indicators where they differ.

Can I derive LBLOINC from the test name?

No. CDISC implementation material advises against deriving LOINC codes yourself. Ask the laboratory to supply them, and if a code is unavailable, document that status and the reason in the data transfer process and reviewer documentation.

When should LB mapping start?

Before the first lab transfer, ideally at protocol and eCRF design. Early agreement on CDASH-aligned collection and a lab transfer specification reduces the assumptions programmers must make later.

Sources

• CDISC: Laboratory Test Results, Central Processing with Investigator Assessment
• CDISC: Laboratory Test Results, Local Processing
• CDISC Controlled Terminology
• CDISC Controlled Terminology Relationships v1.0 for SDTM v1.7, SDTMIG v3.3
• CDISC Library
• Takeda's implementation to expand Terminology and LOINC mapping
• FDA Study Data Technical Conformance Guide
• Submitting Laboratory Data in Multiple Standard Units
• Why is CDASH needed to map eCRF data to SDTM?

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.