HL70337 names the patient type for which insurance certification is being requested. It is a small four-value HL7-defined table introduced in v2.4 to support pre-authorization workflows on the IN3 (Insurance Additional Information — Certification) segment. The codes distinguish the urgency of the encounter (emergency, urgent) from the elective character of the admission (inpatient elective, outpatient elective), which matters because payers apply different pre-certification rules to each category.
Purpose
HL70337 answers the payer's first triage question on any certification request: what kind of encounter is this? Emergency and urgent encounters are typically pre-certified retrospectively (or not at all); elective inpatient admissions almost always require prior authorization; elective outpatient procedures fall somewhere in between depending on the procedure code. By carrying the patient type as a coded value in IN3-2, the sender tells the payer system which review pathway to invoke without forcing the payer to infer it from the diagnosis or the admit type.
The table is intentionally narrow. It is not a clinical acuity score, not a triage level, and not a substitute for the encounter class on PV1-2. It describes only the certification context.
Where it's used
- IN3-2 Certification Patient Type — the canonical and only home of HL70337, carried on every IN3 segment that travels with an admission, referral, or pre-authorization request.
Code list
| Code | Display | Comment/Description |
|---|---|---|
| ER | Emergency | Encounter is an emergency presentation; certification, if required, is retrospective. |
| IPE | Inpatient elective | Scheduled inpatient admission requiring prior authorization. |
| OPE | Outpatient elective | Scheduled outpatient procedure or service requiring prior authorization. |
| URG | Urgent | Encounter is urgent but not a full emergency; certification rules vary by payer. |
Payer-specific extensions are common in the wild (vendors invent codes like OBS for observation or SDC for same-day-surgery), but those are local user-defined extensions on a parallel field, not additions to HL70337.
Code system OID
- OID:
2.16.840.1.113883.18.232 - Canonical URI:
http://terminology.hl7.org/CodeSystem/v2-0337
The OID resolves on the HL7 Terminology server and is emitted in CWE.14 when IN3-2 is transmitted as CWE in v2.7+ profiles.
HL7-defined vs user-defined
HL70337 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative. Vendors needing richer certification context (observation, partial hospitalization, ambulatory surgery) should not extend HL70337 directly; they should populate the additional context on UB-04 type-of-bill fields or on the certification-specific subfields of IN3 rather than overloading IN3-2.
Version differences
- v2.1 – v2.3.1 — Table did not exist. Certification context was carried as free text or inferred from PV1.
- v2.4 — HL70337 introduced with the four current values (ER, IPE, OPE, URG) as part of the financial-management chapter rework.
- v2.5 – v2.8.1 — Set frozen at four codes; no further additions.
- v2.9 — HL70337 itself unchanged; IN3-2 may be transmitted as CWE with OID-bound metadata.
Common mistakes
- Sending PV1-2 (Patient Class) values like
I,O, orEin IN3-2. PV1-2 is HL70004, not HL70337; the codes overlap conceptually but the tables are different and IN3-2 will fail conformance validation. - Using
URGfor any non-elective admission.URGmeans urgent but not emergent; a true emergency presentation belongs inER. - Omitting IN3-2 on observation encounters because none of the four codes fits. Observation status should be carried on IN3-12 (or the type-of-bill field on UB04 segments); IN3-2 should still be populated with the best-fit value (typically
OPEfor elective observation). - Treating the codes as case-insensitive. HL70337 codes are case-sensitive uppercase;
eris not a valid code. - Inventing local codes like
SDS(same-day surgery) orOBS(observation) inside HL70337. HL70337 is HL7-defined and cannot be extended locally.
Examples
A minimal IN3 segment for an elective inpatient admission requesting pre-certification:
IN3|1|CERT123^^^AUTH|IPE|20260615|20260620|||3^DAYS||REVIEWED|N|||||||PHYS123^WELBY^MARCUS
An emergency encounter with retrospective certification:
IN3|1|CERT789^^^AUTH|ER|20260601||||||PENDING|Y
FHIR ServiceRequest snippet conveying the same IPE context. Because there is no direct ValueSet, the original v2 code is preserved as an extension while the priority is set to routine:
{
"resourceType": "ServiceRequest",
"id": "cert-123",
"status": "active",
"intent": "plan",
"priority": "routine",
"extension": [{
"url": "https://terminology.hl7.org/CodeSystem/v2-0337",
"valueCoding": {
"system": "http://terminology.hl7.org/CodeSystem/v2-0337",
"code": "IPE",
"display": "Inpatient elective"
}
}]
}
Mapping failure example — vendor code in IN3-2:
IN3|1|CERT555^^^AUTH|OBS|20260610
OBS is not in HL70337. A conformant engine should route the message to the curation queue, preserve the original OBS in the audit log, and either remap to OPE (the closest HL7-defined value) or pass through with a soft warning rather than silently dropping the field.
FHIR mapping
There is no direct one-to-one FHIR ValueSet for HL70337. The v2-to-FHIR Implementation Guide spreads the concept across multiple FHIR elements:
| HL7 v2 (HL70337) | FHIR target |
|---|---|
| ER | ServiceRequest.priority = stat; Encounter.class = EMER |
| URG | ServiceRequest.priority = urgent; Encounter.class = EMER or AMB |
| IPE | ServiceRequest.priority = routine; Encounter.class = IMP; intent = plan |
| OPE | ServiceRequest.priority = routine; Encounter.class = AMB; intent = plan |
Because the mapping is many-to-many, the original HL70337 code must be preserved as an extension on the FHIR resource if the receiver needs to round-trip back to HL7 v2.
Engine considerations
- Multi-character validation — IN3-2 carries 1–3 character codes; engines must accept the three-character codes
IPE,OPE,URGand the two-characterER, and reject everything else. - Case sensitivity — HL70337 codes are case-sensitive uppercase; normalize on ingest.
- CWE upgrade path — In v2.7+ profiles IN3-2 may be transmitted as CWE with OID
2.16.840.1.113883.18.232in CWE.14. Engines must handle both IS and CWE shapes. - Round-trip preservation — When mapping to FHIR, store the original HL70337 code as an extension; the FHIR target uses three different elements and is not reversible without the original value.
How Vorro handles HL70337
Vorro validates IN3-2 against the four HL70337 codes on ingest. Values that match are forwarded to downstream channels untouched. Values that fail validation — including lowercase variants, payer-specific extensions like OBS or SDS, and accidental display strings — are routed to the terminology curation queue, where a remap rule maps them to the closest HL7-defined value while preserving the original in the audit log.
On outbound, Vorro emits HL70337 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations that advertise OID-bound coded values. When translating to FHIR, the original HL70337 code is always preserved as an extension on the target ServiceRequest or Encounter resource so the v2 outbound channel can restore the IN3-2 value byte-for-byte.
Related pages
- IN3 segment — Insurance Additional Information, Certification
- HL70482 code table — Order Type
- IS data type — Coded Value for User-defined Tables
