HL7 Table HL70270: Document Type

HL70270 is the HL7-defined vocabulary for the kind of clinical document being transmitted in a Medical Document Management (MDM) message. It lives in TXA-2 Document Type, the second field of the TXA segment, and tells the receiving EHR what to file the attached or referenced document as — a discharge summary, an operative report, a progress note, an autopsy. The codes are deliberately terse two-letter symbols inherited from early dictation and transcription workflows, where short codes were typed by hand into legacy transcription queues.

Purpose

HL70270 answers a single filing question: where in the patient chart should this document land. The receiving system uses the TXA-2 value to route the document to the right tab (Notes, Imaging, Operative, Pathology), apply the correct retention policy, and decide which clinical roles are notified when a new document of that type arrives.

The list is intentionally narrow and oriented at the most common dictated and transcribed encounter documents from the late 1990s. Modern document workflows often need finer granularity (subtypes of progress note, specialty consultation flavors, structured CDA document types) — and for those, sites either layer a local extension on top of HL70270, or transmit a parallel LOINC document type code in TXA-3 (Document Content Presentation) and an obscure CWE field, leaving TXA-2 carrying the broad HL70270 bucket.

Where it's used

• TXA-2 Document Type — the canonical home, present on every MDM^T01 through MDM^T11 message and on referenced ORU documents.
• Some legacy ORU profiles populate OBR-4 with HL70270 codes when the result is a transcribed narrative rather than a structured observation; this is non-standard but common.

Code list

Code system OID

• OID: 2.16.840.1.113883.18.116
• Canonical URI: http://terminology.hl7.org/CodeSystem/v2-0270

The OID is what Vorro emits in CWE.14 (Coding System OID) when downstream profiles demand fully-bound coded TXA-2 values.

HL7-defined vs user-defined

HL70270 is HL7-defined, but in practice it is one of the most heavily extended tables in v2. The fourteen codes above cover broad filing buckets only; specialty document workflows (cardiology subtypes, oncology treatment summaries, hospitalist hand-off notes) almost always require local extensions. Sites that extend HL70270 should mint codes in the user-defined range and bind them to a local OID, not overload the HL7-defined two-letter values.

The cleaner long-term path — and the one the v2-to-FHIR IG endorses — is to populate TXA-2 with the HL70270 broad bucket for backward compatibility and carry the precise LOINC document type code in a separate field, then map only the LOINC value to FHIR DocumentReference.type.

Version differences

• v2.3 — HL70270 introduced alongside the MDM message family; initial set: HP, CN, DS, OP, PN, PR, SP, TS.
• v2.3.1 — AR (Autopsy report) added.
• v2.4 — CD (Cardiodiagnostics), DI (Diagnostic imaging), ED (Emergency department report) added to accommodate departmental document workflows.
• v2.5 — PC and PH added for psychiatric workflows.
• v2.6 – v2.8.1 — Set frozen at fourteen codes; no further additions. Implementations are expected to rely on LOINC document type codes for any further granularity.

Common mistakes

• Sending the display string in TXA-2 — Discharge Summary instead of DS. TXA-2 is the code, not the human-readable label.
• Treating TXA-2 as free text and emitting a local mnemonic (DCSUM, DC-SUMM, D/C). Conformant receivers will reject or quarantine.
• Extending HL70270 inside the HL7-defined namespace with local two-letter codes (OR for operative, RX for prescription). New codes must live in a locally-owned table with a local OID.
• Confusing OP (Operative report) with PN (Procedure note). OP is a surgeon's narrative from the operating room; PN is for shorter non-OR procedures.
• Picking PR (Progress note) for any document that doesn't fit elsewhere. PR has a specific clinical meaning (interval progress in an ongoing encounter); a transfer narrative belongs in TS.

Examples

A discharge summary TXA segment:

TXA|1|DS|TX|202606101430|||||1234^SMITH^JOHN^A^^^MD|||||DOC-99821||AU||AV

An operative report:

TXA|1|OP|TX|202606101130|||||4567^JONES^MARY^B^^^MD|||||DOC-99822||LA||AV

The same DS value carried into a FHIR DocumentReference.type snippet — note that HL7 v2 DS maps to LOINC 18842-5, not to a v2-0270 Coding:

{
  "resourceType": "DocumentReference",
  "type": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "18842-5",
      "display": "Discharge summary"
    }]
  }
}

Mapping failure example — unknown vendor code:

TXA|1|DCSUM|TX|202606101430|||||1234^SMITH^JOHN^A^^^MD

DCSUM is not in HL70270. A conformant engine should quarantine the message, preserve the original code in the audit log, and either resolve through a local remap rule (DCSUM → DS) or surface the message for terminology curation rather than silently coercing to DS.

FHIR mapping

The v2-to-FHIR IG does not publish a ConceptMap for this table; the mapping below follows the obvious correspondence, mapping each HL70270 code to its closest LOINC document type code:

DocumentReference.type is a CodeableConcept bound to http://hl7.org/fhir/ValueSet/c80-doc-typecodes, which is a LOINC-driven value set. The original HL70270 code should be preserved as an additional coding entry on the CodeableConcept so round-trip back to HL7 v2 is possible.

Engine considerations

• Two-character validation — TXA-2 codes are exactly two characters; engines should reject longer payloads rather than truncate.
• Case sensitivity — HL70270 codes are uppercase; lowercase ds must be normalized or rejected.
• CWE upgrade path — In v2.7+ profiles, TXA-2 may be transmitted as CWE rather than IS, allowing CWE.14 to carry 2.16.840.1.113883.18.116. Both shapes must be handled.
• Dual-coding — When a sender also has the precise LOINC document type, engines should preserve both the HL70270 broad bucket and the LOINC code so downstream consumers can choose the right granularity.

How Vorro handles HL70270

Vorro validates TXA-2 against the fourteen HL70270 codes on ingest. Values that match pass through untouched. Values that fail validation — local mnemonics, vendor extensions, accidental display strings — are routed to the terminology curation queue, where a remap rule resolves them to the closest HL70270 code (and, where available, the corresponding LOINC document type) or passes them through with a soft warning so receivers are not silently fed unknown codes.

On outbound, Vorro emits HL70270 as IS for v2.5 and earlier profiles and as CWE with CWE.14 populated for v2.7+ destinations. When a FHIR DocumentReference arrives upstream with only a LOINC code, Vorro reverse-maps to the closest HL70270 bucket via the v2-to-FHIR ConceptMap so MDM-consuming systems still receive a valid TXA-2 value.

Related pages

• TXA segment — Transcription Document Header
• HL70271 code table — Document Completion Status
• HL70272 code table — Document Confidentiality Status

Sources

• HL7 Terminology — CodeSystem v2-0270 Document Type
• HL7 v2 product brief