HL7 Table HL70069: Hospital Service

HL70069 carries the hospital service responsible for the patient during a visit — Medical, Surgical, ICU, ER, and so on. It is one of the most-used PV1 fields and one of the most heavily customized: HL70069 is a user-defined table, meaning HL7 publishes a list of suggested codes (the examples below) but every site is expected to extend it with its own service mnemonics. It lives in PV1-10 Hospital Service and uses the IS data type.

Purpose

HL70069 answers: which clinical service "owns" the patient for the duration of this visit? The service drives the patient's bed assignment, the on-call roster that gets paged, the cost-center that bills for the encounter, and the routing of downstream orders and results. A patient admitted to MED (Medical Service) shows up on the medicine team's census; a transfer to ICU triggers nurse-staffing recalculation and ventilator-bundle order sets.

Because HL70069 is user-defined, the actual codes in production at any given site reflect that site's service grid — community hospitals may use only MED, SUR, OBS, PED, and ER; academic medical centers run dozens of subspecialty services (HEME, ONCBMT, NEPHTX, CTSURG) that exist nowhere else.

Where it's used

• PV1-10 Hospital Service — the canonical home, populated on every ADT, ORM, and ORU that carries visit context.
• PV1-38 Servicing Facility (in some profiles) where the service is broken out separately from the facility code.
• Scheduling (SCH) and master-file (MFN) messages that need to communicate which service owns a slot or a resource.

Code list

The codes below are the HL7-suggested examples published with HL70069. Sites routinely extend the list with their own service mnemonics; expect local codes alongside these.

Code system OID

• OID: 2.16.840.1.113883.18.22
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0069

The OID resolves on the HL7 Terminology server. Because HL70069 is user-defined, sites that extend the table with local codes typically issue their own OID branch under the institution's root and emit the local OID in CWE.14 to disambiguate locally-defined codes from the HL7 suggested set.

HL7-defined vs user-defined

HL70069 is user-defined. The HL7 standard publishes the examples above as a starting list, but conformant senders may use any code that the local trading partners have agreed on. There is no normative requirement that a receiver recognize MED, SUR, or any other specific value — interoperability for HL70069 is achieved through trading-partner agreements, not the base standard.

In practice, the suggested codes above have de-facto adoption in US community hospitals; the long tail of subspecialty services is site-specific.

Version differences

• v2.1 — Table introduced with a short suggested list (MED, SUR, OBS, GYN, ICU, ER, NUR).
• v2.2 – v2.3 — Suggested list expanded to include PED, CAR, PSY, URO, CCU.
• v2.4 – v2.5 — NIC, ONC, ORTHO, RHB added to the suggested list.
• v2.6 – v2.8.1 — Suggested list stable; the user-defined nature of the table means real-world variation continues regardless of the published examples.

Common mistakes

• Treating HL70069 as HL7-defined and rejecting unknown codes on ingest. The table is user-defined; receivers must accept local codes that come with a trading-partner agreement, not reject them as invalid.
• Confusing PV1-10 Hospital Service with PV1-3 Assigned Patient Location. The service owns the patient; the location is the room. A MED patient can be physically located in a surgical ward overnight because of bed pressure.
• Sending the long display name instead of the code — Medical Service instead of MED. PV1-10 is an IS-typed field; the value is the code, not the label.
• Failing to map local extensions. A hospital that uses HEMEONC for a combined hematology-oncology service must publish that mapping to receivers; otherwise downstream FHIR consumers cannot route the Encounter correctly.
• Defaulting empty PV1-10 to MED. An empty field means "not asserted"; defaulting silently routes the patient to medicine on the receiver side.

Examples

A typical admission to the medical service:

PV1|1|I|2000^2012^01||||004777^GOOD^SIDNEY^J^^^MD|||MED||||ADM|A0

ED arrival with subsequent transfer to ICU (two PV1 segments across two ADT^A02 messages, second one shown):

PV1|1|I|ICU^B12^01||||004777^GOOD^SIDNEY^J^^^MD|||ICU|||||ADM|A0

Same MED value translated to a FHIR Encounter.serviceType snippet:

{
  "resourceType": "Encounter",
  "id": "vis-99821",
  "serviceType": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v2-0069",
      "code": "MED",
      "display": "Medical Service"
    }]
  }
}

Local-extension example — a hospital using CTSURG for cardiothoracic surgery:

PV1|1|I|CTICU^2012^01||||004777^GOOD^SIDNEY^J^^^MD|||CTSURG||||ADM|A0

A conformant engine accepts CTSURG on the strength of a trading-partner agreement and maps it (via a site-local ConceptMap) to whatever FHIR service-type code the receiver expects.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-table-hl70069-to-service-type, which maps the HL7-suggested codes to the FHIR service-type ValueSet. Because HL70069 is user-defined, the published ConceptMap covers only the suggested codes:

Local extensions require site-specific ConceptMap entries — the v2-to-FHIR IG explicitly punts on long-tail subspecialty codes.

Engine considerations

• User-defined table semantics — Engines must not reject unrecognized codes outright; instead, route to a curation queue and consult the site's trading-partner agreement.
• Local OID branching — Sites that extend HL70069 should issue a local OID under their institution root and emit it in CWE.14 to disambiguate local codes from the HL7-suggested set.
• Length — IS field length is 3 characters historically but most engines accept up to 20; local mnemonics like ORTHO, CTSURG, HEMEONC are common.
• Case sensitivity — Codes are conventionally uppercase. Normalize on ingest.
• CWE upgrade path — In v2.7+ profiles PV1-10 may be transmitted as CWE with OID metadata in CWE.14.

How Vorro handles HL70069

Vorro maintains a per-trading-partner HL70069 dictionary that includes both the HL7-suggested codes and every local extension the partner has registered. Inbound PV1-10 values are validated against the partner's dictionary; unknown codes are routed to the terminology curation queue where they are either added to the dictionary (with a new ConceptMap entry to the destination's service-type ValueSet) or flagged for the integration analyst.

On outbound, Vorro emits HL70069 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations. The original HL70069 code is preserved when round-tripping through FHIR Encounter.serviceType.

Related pages

• PV1 segment — Patient Visit
• HL70009 code table — Ambulatory Status
• IS data type — Coded Value for User-defined Tables

Sources

• HL7 Terminology — CodeSystem v2-0069 Hospital Service
• HL7 v2 product brief
• HL7 v2-to-FHIR IG — ConceptMap HL70069 to encounter-service-type