Not every clinical measurement has a LOINC code yet. New biomarkers, novel methods, rare tests, and highly-local protocols show up in real workflows and produce local codes without a LOINC equivalent. The disciplined response is to submit a proposal to LOINC and to carry the local code with a documented mapping plan while the proposal winds through the process.

Naming the proposal path is the discipline. For related walkthroughs, more on healthcare terminologies collects the surrounding material.

Confirm the Gap First

Before proposing a new code, confirm the gap. Every plausible existing LOINC code should be checked. Sometimes the gap is a search failure rather than a real absence, and the code exists under an unexpected long common name.

Two search strategies help: the parts-model approach (search by component and property) and the hierarchy walk. For the parts framing, the LOINC parts model: property, system, and method at a glance covers the axes. A pass through the site's LOINC picker can confirm the code is not among the common set.

The LOINC Submission Process

Regenstrief accepts LOINC submissions via an online form. The submission requires:

• The proposed component name.
• The proposed property, time aspect, system, scale, and method.
• The intended clinical context.
• A reference or contact for follow-up questions.

Submissions typically receive a decision within one to two release cycles (six months to a year). The eventual code arrives in a LOINC release along with hundreds of others.

The Interim Local Code

While the proposal is pending, deployments need to represent the measurement. The pattern is a local code namespace that the source system controls, with a documented mapping plan for the eventual LOINC code.

The local code should carry:

• A stable identifier in the source system's namespace.
• A description matching the proposed LOINC component.
• A cross-reference to the pending LOINC proposal (if a tracking ID exists).

Deployments that skip the cross-reference lose the traceability that lets them adopt the LOINC code cleanly once it arrives.

The Migration Plan

When the proposed LOINC code arrives, the deployment migrates from the local code to the LOINC code. The migration is not usually a hard cut; it is a period of dual coding where both codes are recorded and downstream systems consume the LOINC code.

Dual coding for six months is a common pattern. It gives downstream systems time to adopt the new code. Every LOINC integration eventually runs this migration.

SNOMED as an Alternative

Some measurements without LOINC codes have SNOMED CT equivalents. Findings and clinical assessments often fit SNOMED better than LOINC. For the specific decision, LOINC vs SNOMED for a specific observation — how to decide covers the split.

Adopting a SNOMED code where LOINC does not fit is not a workaround; it is the right vocabulary choice for that category. For the panel-vs-observation framing, distinguishing lab tests, panels, and observations in LOINC covers the category question.

The Documentation Habit

Every local-code decision should be documented: what was searched, why the gap was confirmed, what SNOMED alternative was considered, why the local code was chosen. The documentation survives team rotations; institutional memory does not.

Every LOINC integration that lands well maintains a public record of its local codes and their pending proposals. That is the audit trail future readers use.

Sources

• LOINC canonical Regenstrief page for submitting new term - LOINC canonical Regenstrief page for submitting new term proposals when no code exists