HL7 Table HL70061: Check Digit Scheme

HL70061 lists the check digit algorithms that an HL7 v2 sender may declare when transmitting an extended identifier. The code goes in CX.3 Check Digit Scheme (and the equivalent components on XCN and XON), and tells the receiver which algorithm to run against the identifier's check digit in CX.2 to detect transcription errors. The table is small — four codes — but it underpins decades of legacy identifier hygiene in paper-driven workflows.

Purpose

Check digits exist because humans transcribe identifiers wrong. A misread 5 for an S, a swapped pair of digits, or a missing leading zero will all yield a different check digit, so a receiver that runs the same algorithm can flag the problem before the identifier is used clinically. HL70061 simply names the algorithm so sender and receiver agree on which math to perform.

In modern FHIR-first deployments the check digit is usually folded into Identifier.value and never separately validated, but in v2 the field remains widely populated for legacy MRNs, account numbers, and NPI identifiers.

Where it's used

• CX.3 Check Digit Scheme — extended composite ID with check digit (PID-3, PID-4, NK1-33, GT1-2, IN1-49, and dozens more).
• XCN.12 Check Digit Scheme — extended composite ID number and name for persons (ORC-12, PRT-5, etc.).
• XON.5 Identifier Check Digit Scheme — extended composite name and ID number for organizations.
• HD.2 / EI in some profiles where a check-digited universal ID is required.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.20
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0061

Vorro emits this OID in CX.3 when a profile demands OID-bound coded values; most v2 channels keep CX.3 as a simple ID-typed code.

HL7-defined vs user-defined

HL70061 is HL7-defined. The four codes cover the algorithms HL7 has accepted into the normative table. Local sites that compute check digits with proprietary algorithms are expected to leave CX.3 empty rather than invent a new code; the identifier is then treated as opaque by downstream receivers.

Version differences

• v2.2 — Table introduced with M10 and M11.
• v2.3 — ISO added.
• v2.5 — NPI added in anticipation of the US National Provider Identifier rollout.
• v2.6 – v2.8.1 — Set frozen at four codes.

Common mistakes

• Populating CX.2 (Check Digit) without populating CX.3 (Check Digit Scheme). A check digit with no algorithm is unverifiable; receivers will treat the value as opaque and the integrity guarantee is lost.
• Using M10 for NPI check digits. The NPI algorithm prepends 80840 before applying Mod 10 — a plain M10 validator will mark every NPI as invalid.
• Putting the check digit on the end of CX.1 (the ID itself) and also in CX.2. The check digit must be in exactly one place; duplicating it causes off-by-one validation failures.
• Sending MOD10 or Mod10 instead of M10. HL70061 codes are case-sensitive and use the short forms exactly as listed.

Examples

A patient MRN with a Luhn check digit:

PID|1||10456^7^M10^HOSPITAL^MR||DOE^JANE^A||19850412|F

CX.1 is 10456, CX.2 is 7 (the Luhn check digit), CX.3 is M10.

An NPI on XCN with the NPI-specific algorithm:

ORC|RE|||||||||||1234567893^SMITH^JOHN^^^^^^NPI^L^^^NPI

XCN.1 is the 10-digit NPI (including the trailing check digit), XCN.9 is the assigning authority, XCN.12 is NPI.

An organization identifier with ISO 7064:

PD1|||GENERAL HOSPITAL^X^123456^7^ISO^^^^XX

XON.3 is the organization ID, XON.4 is the check digit, XON.5 is ISO.

A FHIR Identifier round-trip — the check digit becomes part of value, and the scheme is preserved in an extension:

{
  "identifier": [{
    "system": "urn:oid:2.16.840.1.113883.4.6",
    "value": "1234567893",
    "extension": [{
      "url": "http://example.org/StructureDefinition/check-digit-scheme",
      "valueCode": "NPI"
    }]
  }]
}

FHIR mapping

FHIR Identifier carries the identifier value as a single string in Identifier.value, with no dedicated slot for the check-digit algorithm. The check digit, if any, is part of the value. Implementations that need to preserve HL70061 across a FHIR round-trip carry it in an Identifier.extension; otherwise the algorithm metadata is lost.

Engine considerations

• Validation on ingest — When CX.3 is populated, run the named algorithm against CX.1 and compare against CX.2. Mismatches should route to a curation queue, not silently pass.
• Generation on outbound — If a downstream channel needs check-digited identifiers and the source did not provide one, the engine should compute it using the algorithm declared by the destination profile.
• NPI special case — Always use the NPI algorithm (with the 80840 prefix) for NPIs. Treating an NPI as plain Luhn yields false negatives.
• Empty vs absent — An empty CX.3 means "no check digit declared"; a populated CX.3 with empty CX.2 is malformed. Engines should reject the latter on schema validation.

How Vorro handles HL70061

Vorro recognizes all four HL70061 codes and runs the corresponding validator on ingest whenever CX.3 is populated. Mismatches surface as soft warnings on the channel monitor and do not block message flow by default, since legacy senders are known to populate CX.3 without keeping CX.2 in sync. Operators can flip the validator to hard-fail mode per channel.

On outbound, Vorro computes check digits only when the destination profile explicitly requires them; the algorithm choice is configured per channel and emitted into CX.3 verbatim. The NPI algorithm is hard-wired for any identifier whose assigning authority OID matches the US NPI namespace.

Related pages

• CX data type — Extended Composite ID with Check Digit
• XCN data type — Extended Composite ID Number and Name for Persons
• XON data type — Extended Composite Name and ID Number for Organizations

Sources

• HL7 Terminology — CodeSystem v2-0061 Check Digit Scheme
• HL7 v2 product brief