HL70092 is one of the smallest code tables in HL7 v2 — a single defined value, R, that marks an inpatient encounter as a re-admission. It rides on PV1-13 and is the field hospital quality and CMS reporting systems use to identify candidate cases for 30-day readmission measures.
Purpose
HL70092 answers a quality-reporting question: is this admission a re-admission of a previously-discharged patient. The exact rule for "what counts as a re-admission" is policy-defined — CMS uses a 30-day all-cause window for most conditions; commercial payers may use 15-day or 90-day windows; hospital quality programs may filter by discharge disposition. HL70092 itself does not encode the window or the policy — it is simply a flag that the sending registration system has classified the encounter as a re-admission under whatever rule applies locally.
Because the table is HL7-defined and has only one value, the field is effectively a binary present/absent flag: R means re-admission, empty means not asserted. There is no negative code (N, NR) defined in HL70092; receivers must treat absence as "not flagged as a re-admission" rather than as a positive non-re-admission assertion.
Where it's used
- PV1-13 Re-admission Indicator — the canonical home of HL70092, populated on inpatient ADT messages (A01 Admit, A04 Register, A08 Update) when the registrar has flagged the encounter as a re-admission.
Code list
| Code | Display | Comment/Description |
|---|---|---|
| R | Re-admission | The encounter is a re-admission of a previously-discharged patient under the sending facility's re-admission policy (commonly the CMS 30-day window). |
Code system OID
- OID:
2.16.840.1.113883.18.30 - Canonical URI:
http://terminology.hl7.org/CodeSystem/v2-0092
The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream v2.7+ profile demands OID-bound coded values on PV1-13.
HL7-defined vs user-defined
HL70092 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the single code is normative. Sites occasionally extend the table locally with codes like N (not a re-admission), P (planned re-admission), or U (unplanned re-admission); these extensions are non-conformant and break downstream FHIR mapping. Sites that need richer re-admission semantics should carry the additional concept on a sibling field or a Z-segment.
Version differences
- v2.1 – v2.2 —
Rdefined from the introduction of PV1-13. - v2.3 – v2.8.1 — Set frozen at one code; no additions. Modern profiles increasingly leave PV1-13 empty and carry re-admission classification on a downstream analytic system instead.
Common mistakes
- Treating empty PV1-13 as "not a re-admission". Empty means "not asserted by the sending system"; many EHRs never populate the field even for true re-admissions. Quality-reporting pipelines that depend on PV1-13 alone systematically under-count re-admissions.
- Sending
YorYESinstead ofR. PV1-13 isISand the only valid code isR. - Sending HL70092 on outpatient or observation encounters. The field is meaningful only for inpatient admissions; populating it on outpatient ADTs creates downstream quality-measure errors.
- Inventing a negative code (
N,NR). HL70092 has no negative value; absence is the negative. - Using HL70092 to encode planned vs. unplanned re-admissions. The single
Rcode cannot carry that distinction; carry it on a separate field instead.
Examples
A PV1 segment marking an inpatient encounter as a re-admission:
PV1|1|I|2W^210^A^MAIN||||1234567^SMITH^JOHN^A^^DR|||MED||||R|||1234567^SMITH^JOHN^A^^DR|INP|V12345^^^FAC^VN||||||||||||||||||||||MAIN|||||20260601120000
A PV1 segment for a non-re-admission (PV1-13 empty):
PV1|1|I|2W^210^A^MAIN||||1234567^SMITH^JOHN^A^^DR|||MED|||||||1234567^SMITH^JOHN^A^^DR|INP|V12346^^^FAC^VN||||||||||||||||||||||MAIN|||||20260601120000
Same R value translated to a FHIR Encounter snippet (no published ConceptMap; using the us-core-readmission convention):
{
"resourceType": "Encounter",
"id": "V12345",
"status": "in-progress",
"class": {
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IMP",
"display": "inpatient encounter"
},
"extension": [{
"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-readmission",
"valueCoding": {
"system": "http://terminology.hl7.org/CodeSystem/v2-0092",
"code": "R",
"display": "Re-admission"
}
}]
}
Mapping failure example — non-standard Y:
PV1|1|I|2W^210^A^MAIN||||1234567^SMITH^JOHN^A^^DR|||MED||||Y|||1234567^SMITH^JOHN^A^^DR|INP|V12347^^^FAC^VN
Y is not in HL70092. A conformant engine should route the message to a curation queue, preserve the original Y in the audit log, and either remap to R (the obvious intent) or pass through with a soft warning so the downstream quality-reporting system is not silently fed bad data.
FHIR mapping
There is no published HL7 v2-to-FHIR ConceptMap for HL70092 because the FHIR landing varies by implementation guide:
- Encounter.partOf — when the prior admission is known to the receiver, the new Encounter references it via
partOf, and the HL70092 flag is implicit in the relationship. - us-core-readmission extension — when only the flag is known, US-Core profiles carry it as an extension on Encounter.hospitalization.
- CMS measure-set computation — quality-reporting profiles typically derive the readmission flag at the analytic layer rather than carrying HL70092 forward.
In all of these landings, when the HL70092 code is preserved, it appears verbatim in Coding.code with system set to http://terminology.hl7.org/CodeSystem/v2-0092.
Engine considerations
- Single-character validation — PV1-13 is one character; engines should reject multi-character payloads outright.
- Case sensitivity — HL70092 codes are case-sensitive uppercase;
ris not valid. Normalize on ingest. - CWE upgrade path — In v2.7+ profiles PV1-13 may be transmitted as CWE rather than IS, allowing OID metadata in CWE.14 (
2.16.840.1.113883.18.30). Engines must handle both shapes. - Empty vs. asserted — Quality-reporting pipelines should treat empty PV1-13 as "not asserted" and prefer a separate analytic computation of readmission status rather than relying on the field alone.
- Z-segment alternatives — Hospitals that need planned-vs-unplanned re-admission distinctions commonly carry the concept on a ZPV or ZQM segment alongside HL70092.
How Vorro handles HL70092
Vorro validates PV1-13 against the single HL70092 code on ingest. R is forwarded to all downstream channels untouched. Values that fail validation — including lowercase variants, Y/YES/N/NO, and other vendor extensions — are routed to the terminology curation queue, where they either resolve to R (or empty, meaning not flagged) with a remap rule or pass through with a soft warning.
On outbound, Vorro emits HL70092 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. The original HL70092 code is always preserved when round-tripping through FHIR Encounter extensions.
Related pages
- PV1 segment — Patient Visit
- HL70004 code table — Patient Class
- IS data type — Coded Value for User-defined Tables
