HL7 DLN Data Type: Driver’s License Number

The DLN (Driver's License Number) data type was introduced in HL7 v2.3 to carry a person's driver's license as a structured triple — the license number, the issuing jurisdiction, and the expiration date — rather than as an unstructured string. It is the standard mechanism for representing a driver's license used as an identity-verification artifact in PD1 Patient Additional Demographics fields and in some registration profiles. The expiration date matters: an expired license is no longer a valid identity-verification document for most US registration workflows.

Purpose

A driver's license used for identity verification has three load-bearing facts: which number is on the card, which state or country issued it, and when it expires. Encoding any one of these implicitly (assuming the issuing state from the patient's address, for example) creates registration defects. DLN packages all three components into a single field so that downstream identity-verification, MPI matching, and audit logging can consume them uniformly without inference.

Components

Source: HAPI HL7v2 v2.8.1 javadoc (DLN).

Comp	Name	Sub-type	Length	Required	Description
DLN.1	License Number	st	—	R	The number/identifier as printed on the license. Alphanumeric.
DLN.2	Issuing State, Province, Country	is	—	O	Code from HL7 table 0333 — the state/province/country that issued the license.
DLN.3	Expiration Date	dt	—	O	DT in `YYYYMMDD` format; the date on which the license stops being valid.

Most-used components

DLN.1 License Number — always populated; this is the actual license identifier.
DLN.2 Issuing State, Province, Country — populated whenever the issuing jurisdiction is known; required in practice for any meaningful identity verification.
DLN.3 Expiration Date — populated whenever the source system has it; without it, downstream consumers cannot reject expired-document presentations.

Where it's used

PD1 Patient Additional Demographics — driver's license-related fields in registration messages.
PID-19 SSN Number Patient extensions in some profiles that overlay DLN for identity verification.
Custom Z-segments used by registration kiosks and self-service check-in flows.
Identity-proofing fields in ADT^A28 (add person) and ADT^A31 (update person) messages.
PID-20 Driver's License Number (Deprecated) — older messages used DLN directly at this position before alternative identifiers took over.
Z-fields in motor-vehicle-accident encounter profiles where the driver's license is a clinical artefact.

Version differences

HL7 v2.3 — DLN introduced with the three-component License Number + Issuing State + Expiration Date layout.
HL7 v2.3.1 — PID-20 Driver's License Number was deprecated; DLN itself remained, used in PD1 and other identity contexts.
HL7 v2.4 through v2.8 — no structural changes; the issuing-jurisdiction table (HL70333) was refined to cover non-US jurisdictions more cleanly.
HL7 v2.8.1 — HAPI javadoc confirms the three-component definition; DLN.2 explicitly bound to HL7 table 0333.
HL7 v2.8.2 — no structural changes.

Common mistakes

Sending the full state name in DLN.2 (California) instead of the code (CA) — DLN.2 is IS bound to HL7 table 0333 and expects the abbreviation; receivers that strict-validate will reject.
Omitting DLN.3 expiration date — downstream identity-verification workflows cannot enforce expiry and a registrar's audit log loses a load-bearing fact.
Using a non-DT format in DLN.3 (12/31/2028, 2028-12-31) — DT is strictly YYYYMMDD with no separators.
Including dashes or spaces in DLN.1 — most state license formats include them on the card, but conventions vary; agree on whether to preserve them per interface and apply consistently.
Treating DLN.2 as ISO 3166 country codes — HL70333 is a state/province/country table that overlaps with but is not identical to ISO 3166; cross-walk explicitly rather than assuming.

Examples

Minimal value — California license, expiry 31 Dec 2028:

D12345678^CA^20281231

Multi-component value — Texas license without expiration:

98765432^TX

Fully populated edge case — Ontario, Canada license with embedded dashes:

A1234-56789-01234^ON^20300630

In context — PD1 line populated with a driver's license for identity verification:

PD1|||CLINIC123^^^FACILITY||||||||N|||||||||D12345678^CA^20281231

In context — ADT^A28 add-person message with DLN attached for identity proofing in a profile-defined Z-field:

ZID|1|DRIVER_LICENSE|D12345678^CA^20281231

Common pitfall — full state name instead of the table 0333 code:

D12345678^California^20281231     <- WRONG; DLN.2 must be HL70333 code
D12345678^CA^20281231             <- CORRECT

FHIR mapping

The v2-to-FHIR Implementation Guide publishes ConceptMap-datatype-dln-to-identifier, which maps DLN to a FHIR Identifier resource:

DLN component	FHIR target
DLN.1 License Number	`Identifier.value`
DLN.2 Issuing State, Province, Country	`Identifier.assigner` (as a reference to an `Organization` representing the issuing jurisdiction)
DLN.3 Expiration Date	`Identifier.period.end`
(fixed)	`Identifier.type.coding.code = DL` (Driver's License) from `http://terminology.hl7.org/CodeSystem/v2-0203`

The Identifier.type is fixed to DL so the recipient can distinguish a driver's license identifier from other identifier types on the same person.

Engine considerations

Expiration enforcement: receivers should compare DLN.3 against the message timestamp and surface expired licenses to a curation queue or registrar review — silently accepting an expired identity document defeats the purpose of capturing the expiry.
Jurisdiction code validation: validate DLN.2 against HL7 table 0333 strictly; full state names and ISO 3166-2 forms (US-CA versus CA) are common defects.
License-number canonicalisation: agree per interface whether to strip embedded dashes/spaces in DLN.1; do not vary by record. Many MPIs match on normalised license numbers.
DT precision: DLN.3 is DT, not TS — engines that auto-attach time components break the expectation that DT is strictly YYYYMMDD.
Privacy treatment: a driver's license number is a strong identifier; logging, masking, and access controls should treat it as PHI.

How Vorro parses and produces DLN

On inbound, Vorro parses DLN.1 as a string and applies a per-interface canonicalisation policy (strip dashes/spaces or preserve verbatim). DLN.2 is validated against HL7 table 0333; values that look like full state names or ISO 3166-2 forms are mapped through an internal cross-walk and the original is preserved in provenance. DLN.3 is parsed as DT (YYYYMMDD) and compared against the message timestamp; expired licenses are routed to a registrar-review queue rather than silently passing through.

On outbound, Vorro emits DLN with all three components when available. DLN.1 is written using the canonical form configured for the receiver. DLN.2 always uses the HL70333 code (never the long name). DLN.3 is written in strict DT format. When mapping to FHIR, Vorro produces an Identifier with type.coding.code = DL, an assigner reference that resolves to the issuing jurisdiction, and period.end populated from DLN.3.

Sources

← Back to HL7 v2 Guide