HL7 Table HL70083: Outlier Type

HL70083 flags DRG outlier cases — inpatient stays whose cost or length-of-stay exceeded the DRG's normal thresholds, qualifying for additional Medicare or commercial-payer reimbursement. It is a small, two-value table that sits on the DRG segment and travels with billing-relevant ADT and DFT messages.

Purpose

HL70083 answers a payer question: was this DRG-grouped inpatient stay an outlier, and if so, was the outlier driven by cost or by length of stay. The distinction matters because Medicare's Inpatient Prospective Payment System (IPPS) calculates outlier payments differently for cost outliers (charges exceed a fixed-loss threshold) and day outliers (LOS exceeds geometric mean LOS by a defined number of standard deviations — historically used through FY 1997, retained in HL7 for backward compatibility).

Because the table is HL7-defined and tiny, every conformant v2 receiver is expected to recognize both codes without local extension. Senders that need a richer outlier taxonomy — e.g., short-stay outliers, transfer outliers — carry that distinction in a separate field rather than overloading HL70083.

Where it's used

DRG-7 Outlier Type — the canonical home of HL70083, populated on inpatient billing-related ADT (A01, A03, A08) and DFT messages that carry a DRG segment.

Code list

Code	Display	Comment/Description
C	Outlier cost	Cost outlier — total billed charges exceed the DRG's fixed-loss outlier threshold.
D	Outlier days	Day outlier — length of stay exceeds the DRG's day-outlier threshold (legacy Medicare concept, retained for backward compatibility).

Code system OID

OID: 2.16.840.1.113883.18.27
Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0083

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 DRG-7.

HL7-defined vs user-defined

HL70083 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the code set is normative — receivers must accept both values without local extension. Sites that need richer outlier semantics carry the extra concept on a payer-specific extension or on a separate billing segment; they do not extend HL70083 with local codes.

Version differences

v2.1 – v2.2 — Both codes (C, D) present from the introduction of the DRG segment.
v2.3 – v2.8.1 — Set frozen at two codes; no additions, no deprecations. The D code is essentially legacy (CMS day-outlier payments ended for most DRGs in FY 1998) but remains in the table because international payers and historical claims still reference it.

Common mistakes

Sending HL70083 on outpatient or observation messages. DRG-7 is meaningful only for inpatient stays that have been DRG-grouped; populating it on outpatient DFTs creates downstream claim errors.
Treating absence of HL70083 as a non-outlier flag. The field is optional — an empty DRG-7 means "outlier status not asserted", not "not an outlier". Receivers that need a definite non-outlier signal must agree on a sending convention (often N from a local extension, which is non-conformant) or derive the flag from the outlier-payment fields.
Sending lowercase or display strings — cost instead of C. DRG-7 is IS data type and case-sensitive uppercase.
Confusing HL70083 with HL70055 (Outlier Days/Cost amount fields). HL70083 is the type flag; the actual outlier days and outlier cost amounts ride on DRG-8 and DRG-9.

Examples

A DRG segment for a cost-outlier inpatient stay:

DRG|470^Major joint replacement^MS-DRG|20260601120000|Y|01|C|3|15234.50|01

A DRG segment flagging a day outlier (legacy):

DRG|065^Intracranial hemorrhage^MS-DRG|20260601120000|Y|01|D|14|0.00|01

Same C value translated to a FHIR Claim snippet (no published ConceptMap; using the US-Core DRG outlier convention):

{
  "resourceType": "Claim",
  "extension": [{
    "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-drg-outlier-type",
    "valueCoding": {
      "system": "http://terminology.hl7.org/CodeSystem/v2-0083",
      "code": "C",
      "display": "Outlier cost"
    }
  }]
}

Mapping failure example — invented code:

DRG|470^Major joint replacement^MS-DRG|20260601120000|Y|01|S|3|15234.50|01

S (short-stay) is not in HL70083. A conformant engine should route the message to a curation queue, preserve the original S in the audit log, and either drop the field or remap to a payer-specific extension rather than silently coercing it to C or D.

FHIR mapping

There is no published HL7 v2-to-FHIR ConceptMap for HL70083 because the DRG segment as a whole has no canonical FHIR target — different implementation guides land DRG data on different resources. The most common landings are:

Da Vinci PAS Claim — DRG-grouped claims carry HL70083 in a DRG-outlier-type extension on Claim or ClaimResponse.
US-Core Encounter — some IGs surface the outlier flag as an extension on Encounter.hospitalization.
Custom Coding on Claim.diagnosis.packageCode — the DRG code itself rides here; outlier type is typically a sibling extension.

In all of these landings, the HL70083 code value (C or D) is preserved verbatim in Coding.code with system set to http://terminology.hl7.org/CodeSystem/v2-0083.

Engine considerations

Single-character validation — DRG-7 is one character; engines should reject multi-character payloads outright.
Case sensitivity — HL70083 codes are case-sensitive uppercase; c is not valid. Normalize on ingest.
CWE upgrade path — In v2.7+ profiles DRG-7 may be transmitted as CWE rather than IS, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.27). Engines must handle both shapes.
Legacy D handling — Day outliers are essentially extinct in US Medicare billing but appear in historical data and some non-US payer flows. Engines should preserve D rather than coerce it to C.
Empty vs. absent — Treat empty DRG-7 as "not asserted", not "not an outlier". Downstream rules that compute outlier status from amounts must not assume the absence of the type flag implies anything.

How Vorro handles HL70083

Vorro validates DRG-7 against the two HL70083 codes on ingest. Values that match are forwarded to all downstream channels untouched. Values that fail validation — including lowercase variants, accidental display strings, and invented sub-types like S (short-stay) or T (transfer) — are routed to the terminology curation queue, where they either resolve to C/D (and a remap rule is created) or pass through with a soft warning so downstream billing systems are not silently fed bad data.

On outbound, Vorro emits HL70083 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 HL70083 code is always preserved when round-tripping through Claim or ClaimResponse FHIR resources.

Sources

← Back to HL7 v2 Guide