HL7 Table HL70086: Plan ID

HL70086 is the v2 code table that names the specific insurance plan covering a patient on a particular visit — Blue Cross Blue Shield PPO, Aetna HMO, Medicare Part A, Medicaid, TRICARE, and any number of site-specific plan codes that a hospital negotiates with regional payers. It is carried in IN1-35 Plan Type (sometimes labeled Plan ID in older documentation) and is one of the most heavily extended user-defined tables in the v2 specification.

Purpose

When an IN1 segment arrives on an ADT or DFT message, the receiver needs to identify the plan precisely enough to drive eligibility checks, claim routing, and benefits adjudication. The payer identifier alone (IN1-3 Insurance Company ID) is not sufficient — Blue Cross Blue Shield, for example, has dozens of plan variants in a single state, and the difference between PPO and HMO routing matters at the claims clearinghouse. HL70086 supplies the plan-level code that disambiguates which product within the payer applies.

Because plans are inherently local — a hospital in Boston has different contracts than a hospital in Phoenix — HL7 publishes no fixed set of plan codes. The published examples are illustrative only; every site is expected to define its own value set against the HL70086 table number.

Where it's used

IN1-35 Plan Type — the canonical home of HL70086, populated on every IN1 segment that accompanies an ADT, DFT, or BAR message.
Some profiles repeat the value on IN2 for secondary metadata, and a few financial profiles surface it on GT1 (Guarantor) when the guarantor carries plan information separate from the subscriber.

Code list

The codes below are common examples. There is no normative HL7 list — every implementation publishes its own.

Code	Display	Comment/Description
BCBS-PPO	Blue Cross Blue Shield PPO	Preferred-provider product from a regional Blues plan.
AETNA-HMO	Aetna HMO	Health-maintenance-organization product from Aetna.
MEDICARE-A	Medicare Part A	Hospital insurance (inpatient, SNF, hospice, home health).
MEDICARE-B	Medicare Part B	Medical insurance (physician, outpatient, preventive).
MEDICAID	Medicaid	State Medicaid program; specific state often appended (`MEDICAID-MA`).
TRICARE	TRICARE	Uniformed services / military health coverage.
(more)	Site-specific plan codes	Any number of local codes for regional commercial plans, ACOs, employer carve-outs, and self-pay programs.

Code system OID

OID: 2.16.840.1.113883.18.28
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0086

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for IN1-35. In practice, however, because the codes themselves are local, CWE.12 (alternate code system OID) almost always carries a site-specific OID rather than the HL7 base.

HL7-defined vs user-defined

HL70086 is user-defined, and arguably the most user-defined table in the v2 specification — HL7 publishes essentially no canonical values, only the table number and the data type. Every implementation publishes its own value set and registers it under a site-specific OID. Conformant receivers must tolerate any value in the field, because every site's code list is different, and downstream systems rely on payer-specific routing rules rather than HL7-table validation to interpret IN1-35.

Version differences

v2.1 – v2.8.1 — Table number and binding have been stable since the first version. The lack of HL7-published codes is intentional and unchanged across versions.

Common mistakes

Treating HL70086 as a closed set. Receivers that reject unrecognized values will reject virtually every message from a different payer or region.
Conflating IN1-3 (Insurance Company ID) with IN1-35 (Plan Type). The company is the payer (BCBS); the plan is the product (BCBS-PPO). Two different fields, two different lookups.
Using free-text plan names in IN1-35. The field is IS-typed and expects a coded value; the human-readable plan name belongs in IN1-36 Plan Effective Date is not the right home either — the display name belongs in IN1-9 Plan Name or in the CWE.2 display component when IN1-35 is upgraded to CWE.
Failing to coordinate codes across sending and receiving systems. Because HL70086 is purely local, a sender's BCBS-PPO is meaningless to a receiver that uses BCPPO for the same plan; a translation table must be agreed up front.
Overloading the field with policy or group numbers. Those belong in IN1-8 Group Number and IN1-2 Insurance Plan ID, not in IN1-35.

Examples

A commercial PPO visit:

IN1|1|BCBS-PPO|BCBSMA|BLUE CROSS BLUE SHIELD OF MASSACHUSETTS||||GRP12345|EMPLOYER NAME||||20240101||||DOE^JANE^A|SE|19850412|123 MAIN ST^^BOSTON^MA^02118|||1||||||||||||||||987654321|||||||F|||||BCBS-PPO

Medicare primary:

IN1|1|MEDICARE-A|CMS|CENTERS FOR MEDICARE AND MEDICAID SERVICES||||||||20240101||||DOE^JOHN^B|SE|19450315|456 OAK ST^^BOSTON^MA^02118|||1||||||||||||||||1AB2-CD3-EF45|||||||M|||||MEDICARE-A

Medicaid with state suffix (site extension):

IN1|1|MEDICAID-MA|MASSHEALTH|MASSACHUSETTS MEDICAID||||||||20240101||||DOE^JANE^A|SE|19850412|123 MAIN ST^^BOSTON^MA^02118|||1||||||||||||||||100123456|||||||F|||||MEDICAID-MA

Mapping failure example — unknown plan code:

IN1|1|REGIONAL-PLAN-X|UNKNOWN PAYER|||||||||||||DOE^JANE^A|SE|19850412|123 MAIN ST^^BOSTON^MA^02118

Because HL70086 is entirely user-defined, no engine can call REGIONAL-PLAN-X invalid on its own; it can only flag that the site's local catalog has not yet registered the code. A conformant engine routes it to the curation queue, lets a finance analyst attach a payer, and creates a remap rule so subsequent claims route correctly.

FHIR mapping

HL70086 has no canonical FHIR ValueSet — and unlike most v2 tables, it is unlikely to ever get one, because the values are by definition site-specific. The v2-to-FHIR Implementation Guide recommends decomposing the plan code into two FHIR elements:

HL70086 intent	FHIR target
Identify the payer organization	`Coverage.payor` (a Reference to `Organization`) and `Coverage.payor.identifier`
Identify the plan product type	`Coverage.type` (CodeableConcept bound to a local ValueSet, often using SOP — Source of Payment Typology — codes)
Government program flag	`Coverage.subscriber` plus `Coverage.type` with NUBC SOP codes for Medicare/Medicaid/TRICARE

The original HL70086 code should be preserved as an extension on Coverage so the v2 outbound channel can restore IN1-35 verbatim.

Engine considerations

No closed-set validation — Engines should not reject messages based on HL70086 content alone. Validate the IN1 segment structurally, and route unknown plan codes to a terminology curation queue rather than rejecting the ADT.
Length — Plan codes vary wildly in length, from two characters to thirty. Do not hard-cap the field.
Case sensitivity — Most sites adopt uppercase by convention, but mixed-case is technically valid. Normalize on ingest only if the site value set explicitly requires it.
CWE upgrade path — In v2.7+ profiles IN1-35 may be transmitted as CWE rather than IS, allowing both the local code (CWE.1) and the payer-assigned plan identifier (CWE.4) to travel together. Engines must handle both shapes.

How Vorro handles HL70086

Vorro validates IN1-35 against the site's registered plan catalog on ingest. Values that match are forwarded untouched and used to drive payer-routing rules. Values that do not match are routed to the terminology curation queue, where a finance analyst attaches the code to a payer and product type; once registered, subsequent messages flow without intervention.

On outbound, Vorro emits HL70086 as IS for v2.5 and earlier profiles and as CWE with CWE.12 populated with the site OID (rather than the HL7 base OID) for v2.7+ destinations. Because the codes are local, the site OID is the source of truth — the HL7 base OID is only emitted when the destination explicitly requires it.

Sources

← Back to HL7 v2 Guide