Mapping lab test names to LOINC means pairing each test name printed on a report with the LOINC code whose six parts match what the lab measured: analyte, property, timing, specimen, scale and, where it matters, method. The name is only a starting point. The unit, specimen and method printed with it decide the code.
Why does the same lab test have different names on different reports?
The same lab test has different names on different reports because each lab names tests in its own system, for its own readers, within its own column widths. One lab prints "Glucose", another "GLU", a third "Glucose, Serum". Nothing requires a printed name to match any standard, so the names drift with each lab's software and habits.
The federal CLIA rules require a test report to show "the test performed", according to 42 CFR 493.1291 on the test report, but they do not set the wording. That leaves a lot of room. On fictional sample reports, the variation comes from a few places:
- Abbreviations. Narrow columns push labs toward short forms such as "GLU", "BUN" or "ALT".
- Specimen in the name. Some labs add "Serum", "Plasma" or "Urine" to the name; others print the specimen in a separate field or only in the panel heading.
- Condition in the name. "Fasting", "2 hr" or "random" may be part of the name, a separate field, or a comment.
- Method in the name. Point-of-care results often carry the device or method, as in "POC Glucose".
- Panel context. A result inside a panel heading may print only a short name, relying on the heading for the rest.
This is why the same lab test has different names on different reports, and why lab data from several sources cannot be joined on names. Two identical names can be different tests, and two different names can be the same test. A code that describes the measurement itself solves both problems, which is what LOINC is for. The NLM LOINC page describes LOINC as "a clinical terminology important for laboratory test orders and results", produced by the Regenstrief Institute.
How LOINC codes for lab tests are built: the six parts
LOINC codes for lab tests are built from six parts, also called axes, that together describe one kind of measurement. The FHIR R4 page on using LOINC lists them as component or analyte, property, timing, system or specimen, scale and method. Two tests share a LOINC code only when their parts match.
The six parts, in the order that page gives them:
- Component. The first axis: the analyte name, a sub-class and any challenge, such as a fasting condition.
- Property. The second axis: the kind of property observed, also called the kind of quantity. Mass per volume and moles per volume are different properties.
- Time aspect. The third axis: a point or moment in time versus a time interval, such as a 24-hour collection.
- System. The fourth axis: the type of specimen, such as serum or plasma, blood or urine.
- Scale. The fifth axis: the type of scale used to report the result.
- Method. The sixth axis: the type of method, used when it distinguishes one measurement from another.
The printed report rarely shows all six. The test name usually gives the component. The unit usually reveals the property; mg/dL points to mass per volume and mmol/L to moles per volume. The specimen field or panel heading gives the system. The result itself shows the scale: a number is quantitative, while "Positive" or "Negative" is not. The method is the part most often missing from the page.
How the unit is recorded affects this step directly. The guide to normalizing lab result units covers turning printed units into UCUM codes, which makes the property easier to read off.
Mapping lab test names to LOINC in four steps
Mapping lab test names to LOINC works best as a repeatable process: collect each distinct name with its context, read the six parts from the report, search for candidate codes, and have a person approve the final choice. The output is a reusable map keyed on the lab, the printed name, the unit and the specimen together.
Step 1: collect each name with its context
Build a list of distinct test names per lab, not across labs. For each one, record the unit, the specimen, any panel heading, any method text and an example page. A name with no context cannot be mapped reliably.
Step 2: read the six parts from the page
For each entry, write down what the page tells you for component, property, timing, system, scale and method, and leave a part blank if the page does not say. A blank part is a reason to ask the lab, not to guess.
Step 3: search for candidates
Search a LOINC tool for the component and narrow by the other parts. The NLM Clinical Table Search Service for LOINC returns codes with their component, property, long common name, short name and example units, which is enough to compare candidates side by side.
Step 4: approve and record
A person picks the code, and the map stores the lab, printed name, unit, specimen, chosen code, who approved it and when. New names from that lab then go to the same person before anything is coded automatically.
Record the LOINC version you mapped against as well. LOINC is released in versions; the USCDI laboratory data class page notes that an earlier USCDI version named LOINC 2.80 specifically. Terms can also be retired: a glucose search in the NLM service returns at least one term whose long common name begins with "Deprecated". Re-check your map against each new release, and send any row whose code has been deprecated back to a person for a fresh choice.
Worked map: five printed names for glucose
The table below maps five printed glucose names from fictional reports. The printed names and context are examples; the codes, long common names and short names come from the NLM search service.
| Printed name (example) | Context on the page (example) | Chosen LOINC code | LOINC long common name | What decided it |
|---|---|---|---|---|
| GLUCOSE | Metabolic panel, serum, mg/dL | 2345-7 | Glucose [Mass/volume] in Serum or Plasma | Property: mg/dL is mass per volume |
| GLU | Serum, mmol/L | 14749-6 | Glucose [Moles/volume] in Serum or Plasma | Property: mmol/L is moles per volume |
| Glucose, Fasting | Serum, mg/dL | 1558-6 | Fasting glucose [Mass/volume] in Serum or Plasma | Component: the fasting condition |
| POC Glucose | Fingerstick meter, mg/dL | 41653-7 | Glucose [Mass/volume] in Capillary blood by Glucometer | System and method |
| Glucose, 24 hr Urine | Urine, 24-hour collection, mg/24 h | 2351-5 | Glucose [Mass/time] in 24 hour Urine | Timing and property |
Three candidates were rejected along the way. Glucose [Mass/volume] in Blood (2339-0) has the right property for the first row but the wrong system. Glucose [Mass/volume] in Urine (2350-7) has no 24-hour timing, so it does not fit the last row. Glucose [Mass/volume] in 24 hour Urine (21305-8) has the right timing but measures mass per volume, while the printed unit is mass per time.
One detail in the third row surprises people. The NLM service shows the component of 1558-6 as "Glucose^post CFst". The fasting condition lives in the component, as a challenge, not in the time axis.
LOINC mapping mistakes: matching the name but not the specimen or method
The most common LOINC mapping mistake is matching the test name and stopping there. A name match finds the right analyte but can land on the wrong specimen, property or method, and the code then describes a different measurement from the one on the page. Each axis the name does not mention still has to be checked.
A name-only match on glucose names would have made each of these mistakes:
- Wrong system. "Glucose" mapped to a blood code when the report says serum, or to a serum code for a urine result printed in a urinalysis section.
- Wrong property. A mass concentration code chosen for a result printed in mmol/L because the name matched first.
- Lost timing. A 24-hour urine result mapped to a point-in-time urine code because "24 hr" sat in a comment line.
- Lost method. A meter result mapped to a laboratory serum code, dropping the fact that it came from a fingerstick device.
- Wrong scale. A qualitative urine dipstick result such as "Negative" mapped to a quantitative code.
The fix is structural. Key the map on the printed name plus its unit and specimen, not the name alone, so "Glucose" in mg/dL from serum and "Glucose" in mg/dL from urine become two rows. When a lab changes a unit or a specimen, the key no longer matches, and the row goes back to a person instead of reusing an old code.
Source format makes these mistakes more or less likely. A scanned report can lose the small print that names the specimen or method; the guide to scanned vs digital lab reports covers what survives each format. Results that arrive as HL7 messages may already carry a code from the lab, a difference explained in HL7 ORU messages vs PDF lab reports.
Why do quality measures need LOINC-coded lab data?
Quality measures need LOINC-coded lab data because measure logic looks for codes, not names. Electronic clinical quality measures define their lab criteria as value sets, which are lists of codes. A result stored only under a printed name such as "GLU" cannot match a value set, however clearly a person can read it.
The eCQI Resource Center definition of a value set calls it "a list of specific values, terms, and their codes, used to describe clinical and administrative concepts", and names Logical Observation Identifiers Names and Codes among the standard vocabularies. The NLM's Value Set Authority Center support page describes VSAC as a repository for public value sets and links to the CMS eCQM value sets. US interoperability rules point the same way: the USCDI laboratory data class names LOINC as the standard for the lab test.
That makes lab data abstraction for quality measures a mapping job as much as a reading job. Abstracting a result means finding the right row on the right report, copying the value and date as printed, and attaching the LOINC code that matches the six parts. A wrong code is worse than none, because it puts the result in the wrong value set without anyone noticing.
Collecting the records in the first place, through records requests and chart retrieval, is a separate process covered in the records retrieval and review category.
Schema Care reads lab report test names, results and units as fields, each with a confidence score and a link to its spot on the page, so the person who approves a mapping can check the printed name and its context in one place; the fictional EOB demo shows how that confidence threshold works on another document type. It does not assign LOINC codes. For loading coded results into other systems, see the developer integration category.