HL7 IS Data Type: Coded Value for User-Defined Tables

The IS data type has existed since HL7 v2.1 and represents a single coded value drawn from a user-defined table. On the wire, IS is indistinguishable from ID — both carry a bare token with no display name and no code system. The difference is governance: IS values are agreed between trading partners rather than fixed by HL7. Classic IS fields include PV1-2 Patient Class (table 0004), PV1-3 Assigned Patient Location's point-of-care component, PV1-10 Hospital Service, and the location-component fields scattered through PL composites.

Purpose

IS gives implementations a coded-value primitive whose value set is owned by the site or the trading-partner agreement rather than by HL7. The intent was to keep the wire format consistent for codes everywhere while acknowledging that location, service, and class codes vary far too much between facilities to be standardized centrally.

Format and constraints

IS is a primitive: no components, no sub-components.

The value is a short coded token from a user-defined HL7 table (i.e. the table number is in the HL7 reserved range but the contents are defined locally).
Tokens are typically 1–10 characters, but the user-defined nature means real-world IS values include things like EMER, INP, ICU-N, or site-specific abbreviations.
The table identifier is named on the field's profile (e.g. [HL70069] Hospital Service is technically user-defined despite the HL7 prefix).
No display name and no code system are carried.
Case sensitivity is profile-specific; most sites uppercase by convention.
Length: historically 1..20 in v2.5 and earlier; v2.7 deprecated fixed maximum lengths in favour of conformance-profile constraints.
An empty field is null; an unknown value is a conformance error against the local table.

IS vs ID vs CWE / CNE

IS — code from a user-defined table; trading-partner agreement governs the values.
ID — code from an HL7-defined table; HL7 governs the values.
CWE / CNE — composite triplets (code + text + system) introduced in v2.5; many fields formerly typed IS were promoted to CWE because user-defined tables benefit most from an explicit code-system identifier.

Where it's used

PV1-2 Patient Class (IS, table 0004) — E, I, O, P, R, B, C, N, U.
PV1-3 Assigned Patient Location → PL-3 Point of Care (IS, table 0302).
PV1-3 → PL-4 Room (IS, table 0303) and PL-5 Bed (IS, table 0304).
PV1-10 Hospital Service (IS, table 0069).
PV1-14 Admit Source (IS, table 0023) in earlier versions; CWE in v2.7+.
PV1-16 VIP Indicator (IS, table 0099).
PV1-39 Servicing Facility (IS, table 0115).
MFI-3 File-Level Event Code in some master-file structures.
OBR-24 Diagnostic Service Section ID (IS, table 0074).

Version differences

v2.1 through v2.4: IS used pervasively for location, class, and service codes.
v2.5: CWE introduced; many IS-typed fields began the long migration to CWE in later versions to allow display text and explicit code-system identifiers.
v2.7: many former IS fields (admit source, discharge disposition, financial class) promoted to CWE.
v2.7.1 through v2.8.2: IS retained for the most stable user-defined fields, notably PV1-2 Patient Class and the PL location components.

Common mistakes

Sending a display name (Inpatient) instead of the local code (I). IS is the token only.
Sending an IS code into an ID field, or vice versa — the wire shape is identical, so it parses fine but conformance fails against the wrong table.
Sending the receiver's table (I) when the sender's table uses a different token (INP) — IS values are negotiated per trading partner, and unmapped local codes drift silently.
Sending a CWE triplet (I^Inpatient^HL70004) into an IS field — the ^ is interpreted as a component delimiter and the receiver rejects the segment.
Treating IS as universally HL7-defined. Engines that hardcode tables against an HL7 reference set will reject perfectly valid site-specific codes.

Examples

Minimal:

Site-specific patient class:

EMER

Hospital-service code:

SUR

In context — PV1-2 Patient Class as an IS from table 0004:

PV1|1|I|3W^301^A^MERCY||||9988^REYES^MARTA^L^^^MD|||SUR

In context — PV1-3 Assigned Patient Location whose point-of-care, room, and bed components are all IS:

PV1|1|I|ICU-N^207^B^MERCY^^N^Tower2^4||||9988^REYES^MARTA^L^^^MD

Common pitfalls:

WRONG:  PV1|1|Inpatient|3W^301^A^MERCY||...
        `Inpatient` is display text; PV1-2 expects the coded value from table 0004.
RIGHT:  PV1|1|I|3W^301^A^MERCY||...

FHIR mapping

A primitive's FHIR target is dictated by the containing element. The v2-to-FHIR IG publishes:

IS → CodeableConcept — the canonical mapping when the FHIR target is a coded concept and the local table can be expressed as a code system URI.
IS → code — used when the FHIR target is a bare code primitive backed by a value set.
IS → string — used when no concept mapping exists and the value must be conveyed as opaque text.

Because IS tables vary by site, the practical mapping decision is often local: the integration platform supplies a per-tenant code-system URI to attach to the value.

Engine considerations

Validate each IS field against the local table for the trading partner, not against a global HL7 reference set. Mixing the two is the most common cause of false-positive conformance errors.
Maintain explicit per-partner code maps; do not assume two sites use the same tokens for "Inpatient" or "Emergency".
Uppercase normalize on ingress unless a partner profile specifies otherwise.
Treat unknown IS values as routable warnings rather than fatal errors during onboarding — IS tables drift, and surfacing a curation queue is more practical than dropping messages.
When promoting an IS field to a CWE-typed target downstream, attach an explicit code-system URI; bare codes lose meaning the moment they leave the trading-partner channel.

How Vorro parses and produces IS

Vorro's parser scopes IS validation per trading partner. Each tenant supplies a code-set definition that names the local table, the legal values, and an optional CodeSystem URI for FHIR egress. Unmapped IS values are routed to a curation queue with the source segment retained so an integration analyst can map the value once and replay the message — we do not silently drop or coerce.

On outbound, Vorro emits IS as a bare uppercase token with no display text and no caret. Where the receiver is known to require CWE, we promote at configuration time rather than at message time, which keeps the wire output deterministic and avoids the common bug of emitting a triplet into a field that strictly expects IS.

Sources

← Back to HL7 v2 Guide