HL7 ICD Data Type: Insurance Certification Definition

The ICD (Insurance Certification Definition) data type was introduced in HL7 v2.5 to express a single rule in a payer's pre-certification policy: for patients of a given type (inpatient, outpatient, emergency, etc.), is certification required, and over what window? ICD appears in the IN3 segment, which carries insurance certification information attached to a coverage record. Each ICD occurrence is a self-contained tuple — patient type, required flag, and two date/time bounds — and a single IN3 typically carries multiple ICDs so a plan's certification rules can be enumerated per patient class.

Purpose

Payer certification rules are not uniform across encounter classes: an inpatient stay may require pre-authorisation while an outpatient lab order does not, and an emergency visit may waive certification entirely. Receivers (hospitals, scheduling systems, EDI bridges) need to know not just "does this plan require certification" in the abstract but per patient type and over what effective window. ICD packages those four facts into one repeatable field so an IN3 can declare the entire matrix in a single message rather than scattering it across custom Z-segments or out-of-band documents.

Components

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

Comp	Name	Sub-type	Length	Required	Description
ICD.1	Certification Patient Type	cwe	—	R	Patient class the rule applies to. HL7 table 0150 (e.g. `IP` inpatient, `OP` outpatient, `ER` emergency).
ICD.2	Certification Required	id	1	R	HL7 table 0136: `Y` certification required, `N` not required.
ICD.3	Date/Time Certification Required	dtm	—	O	Effective start of the certification requirement window.
ICD.4	Date/Time Certification Required	dtm	—	O	Effective end of the certification requirement window.

Note: the v2.8.1 base standard reuses the same component name "Date/Time Certification Required" for ICD.3 and ICD.4; in practice .3 carries the start and .4 carries the end of the certification-required window.

Most-used components

ICD.1 Certification Patient Type — the routing key; everything else qualifies a rule for this patient class.
ICD.2 Certification Required — the boolean answer the receiver actually needs to act on.
ICD.3 Date/Time Certification Required (start) — anchors when the rule begins to apply.

Where it's used

IN3-5 Certification Required (the canonical home — repeats per patient type).
IN3 certification overlay fields in eligibility-and-benefits messages.
Custom Z-segments emitted by US-payer EDI bridges that pair ICD with prior-authorisation reference numbers.
IN1 extensions in some site-local profiles that attach certification rules directly to the coverage record.
Outbound 278 (Authorization Request) generators that derive the patient-type and required-flag from ICD before constructing the EDI loop.

Version differences

HL7 v2.5 — ICD introduced with the four-component layout (patient type, required flag, start/end DTM).
HL7 v2.6 through v2.8 — no structural changes; HL7 table 0150 (patient type) and table 0136 (Y/N) bindings stabilised; ICD.1 sub-type tightened from CE to CWE alongside the broader CE→CWE migration.
HL7 v2.8.1 — HAPI javadoc confirms the four-component definition unchanged.
HL7 v2.8.2 — no structural changes; table refreshes only.

Common mistakes

Sending only ICD.2 = Y without ICD.1 — the receiver knows certification is required but not for which patient class, which makes the rule unenforceable.
Confusing ICD.2 = N with an absent ICD — explicitly emitting N declares "we checked and it is not required"; omitting the ICD declares only "we did not say."
Encoding patient type as a free-text string in ICD.1 (e.g. literal "Inpatient") instead of an HL70150 code (IP) — receivers that key off the code silently drop the rule.
Swapping ICD.3 and ICD.4 — emitting end before start; engines that parse left-to-right will compute a negative window and either reject or, worse, treat both as "always."
Treating ICD.3/.4 as required when the plan's certification rule is open-ended — both are optional; an unbounded rule should leave them empty rather than synthesising a placeholder like 19000101 or 99991231.

Examples

Minimal value — inpatient certification required, no window:

IP^Inpatient^HL70150^Y

Populated — inpatient certification required for June 2026:

IP^Inpatient^HL70150^Y^20260601000000^20260630235959

In context — IN3 with two patient-type rules:

IN3|1||||IP^Inpatient^HL70150^Y^20260101000000^20261231235959~OP^Outpatient^HL70150^N|||||||||||

Common pitfall — missing patient type:

^^^Y^20260601000000^20260630235959    <- WRONG; receiver cannot tell which patient class
IP^Inpatient^HL70150^Y^20260601000000^20260630235959   <- CORRECT

FHIR mapping

The v2-to-FHIR Implementation Guide does not publish a per-datatype ConceptMap for ICD. The mapping anchors on Coverage and its pre-authorisation extensions: the patient type becomes a coded qualifier (the HL70150 ValueSet aligns conceptually with the encounter-class binding on Coverage/Claim), the required flag drives a boolean extension, and the date/time bounds become period.start/period.end.

ICD component	FHIR target
ICD.1 Patient Type	`Coverage.extension[pre-auth-patient-type].valueCodeableConcept` (HL70150)
ICD.2 Certification Required	`Coverage.extension[pre-auth-required].valueBoolean`
ICD.3 Start	`Coverage.extension[pre-auth-required].period.start`
ICD.4 End	`Coverage.extension[pre-auth-required].period.end`

On the claim side, the same content maps to Claim.insurance.preAuthRef qualifiers when an actual authorisation reference is known; ICD itself only describes the rule, not a specific authorisation.

Engine considerations

Table validation: ICD.1.3 should be HL70150 and ICD.2 must be exactly one of Y or N — engines that accept lowercase or freeform values propagate dirty data downstream into 278 generation.
Window semantics: ICD.3 ≤ ICD.4 is a structural invariant; engines must validate ordering and either reject or auto-swap with provenance.
Open-ended windows: when only one bound is present, the rule applies from that bound onward (or up to it) — engines must not synthesise a sentinel for the missing side.
Repeating ICDs: IN3-5 can repeat ICDs with the ~ separator; engines must preserve repetition rather than collapse to the first occurrence.
Patient-type normalisation: receivers often expect HL70150 codes only; engines should normalise legacy synonyms (I → IP) before forwarding.

How Vorro parses and produces ICD

On inbound, Vorro parses each ICD as a four-tuple and validates ICD.1 against HL70150 (with a configurable synonym table for legacy senders) and ICD.2 against HL70136. ICD.3 and ICD.4 are parsed as DTMs with full precision preserved; if both are present, Vorro enforces start ≤ end and routes violations to a curation queue rather than silently rewriting. Each ICD becomes a CertificationRule value object attached to the coverage record, with the patient-type code, the boolean, and an optional Period.

On outbound, Vorro emits ICDs in HL70150 canonical form, always populates ICD.1 and ICD.2, and writes ICD.3/.4 only when the source rule carries an actual window — never synthesising sentinel dates. Multiple rules on the same plan are emitted as repeating ICDs in IN3-5 with ~ separators, ordered by patient type for receiver-side diff stability.

Sources

← Back to HL7 v2 Guide