NEWFree ROI Calculators — quantify what prior auth and siloed data are costing your organization.Prior Auth ROI Siloed Data ROI
HL7 v2Code Table6 min read

HL7 Table HL70052: Diagnosis Type

HL70052 is the small, stable HL7-defined code table that classifies why a diagnosis appears on an encounter. It sits in DG1-6 Diagnosis Type on every ADT, DFT, and BAR message that carries a DG1 segment, and it answers the question "is this the admitting diagnosis, the working diagnosis, or the final discharge diagnosis?" The table has been present and unchanged since HL7 v2.1.

Purpose

HL70052 distinguishes the role a diagnosis plays in the encounter timeline. The same ICD-10 code (say, J18.9 community-acquired pneumonia) can appear three times across an encounter — once as the admitting diagnosis at registration, once as a working diagnosis during the stay, and once as the final discharge diagnosis after the chart is closed. HL70052 is what lets a receiver tell those three instances apart without inferring from message timing.

Because the table is HL7-defined and only three values deep, every conformant v2 receiver is expected to recognize all three codes without local extension. Sites that need additional roles (e.g., billing diagnosis, post-operative diagnosis) typically use HL70053 Diagnosis Classification in DG1-17 rather than extending HL70052.

Where it's used

  • DG1-6 Diagnosis Type — the canonical home of HL70052, populated on every DG1 segment.
  • Some legacy profiles also echo the value into PV1-19 (Visit Number) qualifiers; the canonical field remains DG1-6.

Code list

CodeDisplayComment/Description
AAdmittingThe diagnosis assigned at the time of admission, before workup.
FFinalThe discharge or final diagnosis after the encounter closes.
WWorkingA working / interim diagnosis during the stay, often updated as workup progresses.

Code system OID

  • OID: 2.16.840.1.113883.18.17
  • Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0052

The OID resolves on the HL7 Terminology server and is the value Vorro emits in CWE.14 when a downstream profile demands OID-bound coded values for DG1-6.

HL7-defined vs user-defined

HL70052 is HL7-defined. The table number falls inside the HL7-reserved range (HL70001–HL70999), and the three-code set is normative — receivers must accept A, F, and W without local extension, and senders must not invent additional codes inside this table. Sites that need richer classifications (billing, post-op, comorbidity) use DG1-17 with HL70053 Diagnosis Classification, which has a larger code set.

Version differences

  • v2.1 — Table introduced with three values (A, F, W).
  • v2.2 – v2.5 — Unchanged.
  • v2.6 — DG1-6 redefined from IS to CWE to allow OID-bound coded values; the underlying HL70052 code set is unchanged.
  • v2.7 – v2.8.1 — Set frozen at three codes; no further additions.
  • v2.9 — HL70052 itself is unchanged; the standard introduces DG1-30 onward for newer classification semantics rather than extending this table.

Common mistakes

  • Sending the display word in DG1-6 — Admitting instead of A. DG1-6 is IS (or CWE in v2.6+ profiles), and the code value is the single-character symbol.
  • Using F (Final) on admission ADT^A01 messages because the EHR pre-populated a tentative discharge diagnosis. F must only be sent once the diagnosis is genuinely final; use W (working) until then.
  • Treating W and A as interchangeable. A is captured once, at admission; W may be updated many times during the stay. A receiver building an audit trail of clinical reasoning needs the distinction.
  • Defaulting unknown diagnosis type to F. If the role is not known, the DG1 segment is usually premature; do not send it with a guessed type.
  • Extending HL70052 locally with B (billing), P (post-op), or vendor-specific values. HL70052 is HL7-defined; use HL70053 Diagnosis Classification in DG1-17 for those concepts instead.

Examples

An admitting diagnosis on an ADT^A01:

DG1|1|I10|J18.9^Pneumonia, unspecified organism^I10|Pneumonia|20260601120000|A

A final discharge diagnosis on an ADT^A03:

DG1|1|I10|J15.9^Bacterial pneumonia, unspecified^I10|Bacterial pneumonia|20260605143000|F

Same A value translated to a FHIR Encounter.diagnosis snippet:

{
  "resourceType": "Encounter",
  "diagnosis": [{
    "condition": { "reference": "Condition/pna-1" },
    "use": {
      "coding": [{
        "system": "http://terminology.hl7.org/CodeSystem/diagnosis-role",
        "code": "AD",
        "display": "Admission diagnosis"
      }]
    }
  }]
}

A CWE-typed DG1-6 (v2.6+ profile) carrying OID metadata produces a fuller Coding:

{
  "use": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v2-0052",
      "code": "F",
      "display": "Final"
    }]
  }
}

Mapping failure example — unknown vendor code:

DG1|1|I10|J18.9^Pneumonia^I10|Pneumonia|20260601120000|B

B is not in HL70052 (likely a sender attempting "billing"). A conformant engine should route the message to a curation queue, preserve the original B in the audit log, and emit a FHIR Encounter.diagnosis.use with data-absent-reason: unknown rather than guessing.

FHIR mapping

The HL7 v2-to-FHIR Implementation Guide publishes ConceptMap-table-hl70052-to-diagnosis-role, which projects the three HL7 codes onto the FHIR diagnosis-role ValueSet:

HL7 v2 (HL70052)FHIR (diagnosis-role)
AAD (admission)
FDD (discharge)
WCC (chief complaint / working)

Encounter.diagnosis.use and Condition.use are bound to http://hl7.org/fhir/ValueSet/diagnosis-role. The FHIR value set is richer than HL70052 — codes like billing and post-op have no v2 equivalent in this table — so round-trip mapping from FHIR back to v2 must collapse those FHIR-only roles onto the closest HL70052 code (usually F) and preserve the original FHIR code as an extension.

Engine considerations

  • Single-character validation — DG1-6 is one character; engines should reject multi-character payloads outright.
  • Case sensitivity — HL70052 codes are case-sensitive uppercase; f is not valid. Normalize on ingest.
  • Temporal sanity check — A F diagnosis arriving before any W or on an A01 (admission) message is almost always a sender bug; flag rather than forward silently.
  • CWE upgrade path — In v2.6+ profiles DG1-6 may be transmitted as CWE rather than IS, allowing OID metadata in CWE.14 (2.16.840.1.113883.18.17). Engines must handle both shapes.
  • Round-trip preservation — When mapping to FHIR Encounter.diagnosis.use, store the original HL70052 code as an extension so the v2 outbound channel can distinguish W from A when the FHIR value reads as something unusual like pre-op.

How Vorro handles HL70052

Vorro validates DG1-6 against the three HL70052 codes on ingest. Values that match are forwarded to all downstream channels untouched. Values that fail validation — including lowercase variants, vendor extensions like B, and accidental display strings — are routed to the terminology curation queue, where they either resolve to one of the three canonical codes (and a remap rule is created) or pass through with a soft warning so downstream systems are not silently fed bad diagnosis roles.

On outbound, Vorro emits HL70052 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.6+ destinations that advertise OID-bound coded values. The original HL70052 code is always preserved when round-tripping through FHIR Encounter.diagnosis.use.

Sources

← Back to HL7 v2 Guide

Ready to Integrate This Into Your Workflow?

Talk to a Vorro expert about implementing HL7 v2 in your specific environment.

Browse HL7 v2 Guides
HL7 Table HL70052: Diagnosis Type | Vorro Academy | Vorro