HL7 ED Data Type: Encapsulated Data

The ED (Encapsulated Data) data type carries an inline encoded binary payload — a PDF report, JPEG image, WAV audio clip, DICOM object, or structured document — inside an HL7 v2 message. It was introduced in v2.3 as the mechanism for embedding non-textual results in OBX-5 when OBX-2 is ED, and it remains the standard way to ship a binary attachment over MLLP when an out-of-band file transfer is not available. Five components — Source Application, Type of Data, Data Subtype, Encoding, and the encoded Data itself — describe both the payload and how to decode it.

Purpose

ED solves the problem of moving a binary blob through an inherently text-oriented pipe-and-hat message stream. Rather than referencing a file by URL (which is the job of RP), ED inlines the payload as text after encoding it — almost always Base64 — and tags it with enough metadata for the receiver to write the bytes back to disk and open them in the right viewer. Typical uses are radiology PDF reports, scanned documents attached to ORU^R01 results, EKG waveforms exported as PDF or proprietary blobs, and structured CDA documents carried as SD payloads.

Component table

Source: HAPI HL7v2 v2.8.1 javadocs (ED). Lengths are no longer published as fixed maxima in v2.8.1 (—). ED has 5 components.

Most-used components

• ED.2 Type of Data — broad MIME-style category; AP for application-typed blobs, IM for images, SD for structured documents.
• ED.3 Data Subtype — specific format; PDF is by far the most common in production traffic.
• ED.4 Encoding — almost always Base64. A (no encoding) is only safe for pure ASCII text and is rarely used. HEX and QP exist but are uncommon.
• ED.5 Data — the encoded bytes. Engines must treat this as opaque and round-trip it byte-for-byte.
• ED.1 Source Application — used to disambiguate when multiple producers send into the same downstream document store.

Where it's used

ED is referenced in any field that may carry a binary attachment, but in practice almost all production traffic uses it in:

• OBX-5 Observation Value when OBX-2 Value Type is ED — the canonical home of inline binary results.
• MFA-5, MFR-5 Master File Application-level Response — embedded file responses.
• Custom Z-segments carrying scanned consent forms, ID images, or insurance card pictures.
• Some site profiles use ED in segments like ORC or RXA for medication-package-insert PDFs.

Version differences

• v2.1 / v2.2 — ED did not exist. Binary content was either out-of-band or shoehorned into TX/FT.
• v2.3 — ED introduced with the five components documented above. OBX-2 gains ED as a value-type code.
• v2.4 – v2.6 — Subtype table HL70291 expanded to include PNG, DICOM, and OCTET-STREAM. Behavior otherwise unchanged.
• v2.7 – v2.8.1 — ED structure unchanged. Length constraints removed from the standard; size limits become an MLLP/engine concern, not a data-type concern.

Common mistakes

• Forgetting to escape HL7 delimiters inside ED.5. Base64's alphabet (A–Z a–z 0–9 + / =) is safe, but Hex and A (no-encoding) payloads can contain raw ^, |, &, ~, `` and will tear the message apart unless HL7-escaped (F, S, T, R, E).
• Mixing up ED.2 and ED.3. ED.2 is the broad category (AP, IM, SD), ED.3 is the format (PDF, JPEG, DICOM). A PDF report is AP^PDF, not SD^PDF and not PDF^AP.
• Shipping multi-megabyte payloads over MLLP without segment fragmentation or out-of-band transfer. Base64 inflates the payload by ~33%; an 8 MB PDF becomes ~11 MB on the wire. Many MLLP receivers cap inbound messages at 5–10 MB.
• Declaring A (no encoding) for non-ASCII data. A means the data is already safe HL7 text. Binary bytes must be Base64-encoded.
• Inconsistent line wrapping in Base64. Some encoders wrap Base64 at 76 columns with rn; HL7 line-terminators (r) inside ED.5 will be parsed as segment boundaries. Strip newlines before placing into the field.

Examples

Minimal value — a tiny PDF

MERCY_RAD^AP^PDF^Base64^JVBERi0xLjQKJ...

Source application MERCY_RAD, type AP (application), subtype PDF, encoding Base64, payload truncated.

Multi-component — image with full Source Application HD

MERCY_RAD^MercyRadiology.PACS^L^IM^JPEG^Base64^/9j/4AAQSkZJRgABAQEAYABgAAD...

Note ED.1 (HD) is itself a composite of three sub-components separated by & in production — shown here with ^ because it occupies a single ED slot and sub-component delimiters are & within ED.1 itself. In a real message the HD would be MERCY_RAD&MercyRadiology.PACS&L.

In-context excerpt — OBX with embedded PDF report

OBR|1|ORD-9981^MERCY|ACC-9981^MERCY|RPT^Radiology Report^L||||||||||||||||||F
OBX|1|ED|RPT^Radiology Report^L||MERCY_RAD^AP^PDF^Base64^JVBERi0xLjQKJeLjz9MKMyAwIG9iago8PC9MZW5...==|||||F

OBX-2 declares ED, OBX-5 is a five-component ED carrying a Base64-encoded PDF. Engines render this by Base64-decoding ED.5 and writing the bytes to a .pdf file.

Common pitfall — unescaped delimiter in A-encoded text

LAB|TX|FT|A|Result: Na^140 K^4.1 (note the ^ breaks the message)

Encoding A (no encoding) was chosen for plain text, but the report body contains literal ^ which the parser interprets as a component separator. Either Base64-encode the payload or HL7-escape the delimiters (NaS140).

FHIR mapping

The v2-to-FHIR Implementation Guide publishes ConceptMap-datatype-ed-to-attachment and ConceptMap-datatype-ed-to-documentreference. The encoded data in ED.5 lifts into Attachment.data after a re-encode to Base64 (FHIR mandates Base64 regardless of ED.4's value), and the type / subtype / encoding triple collapses into a single Attachment.contentType MIME string.

Engine considerations

• Size limits. MLLP messages above ~5 MB stress many engines and downstream parsers. For payloads above 1 MB, prefer RP with an out-of-band URL.
• Base64 inflation. Plan capacity assuming a ~33% size increase from binary to Base64-encoded ED.5.
• Round-tripping. Engines must treat ED.5 as an opaque byte string and never re-wrap, re-line-break, or alter case. A single altered byte breaks Base64 decode.
• Delimiter escape. When ED.4 is A or Hex, the engine must HL7-escape any literal delimiter bytes (|, ^, &, ~, ``) before serialization and reverse the escape on parse.
• HAPI accessor. HAPI v2.8.1 exposes ED as ca.uhn.hl7v2.model.v281.datatype.ED with typed getters for each component; ED.5's Data property is a ST whose value is the encoded string.

How Vorro parses and produces ED

Vorro's HL7 parser treats ED.5 as an opaque encoded byte stream and never inspects its contents during parsing — the bytes are passed unmodified into the canonical message model along with the type/subtype/encoding triple. The decode step (Base64 to raw bytes, or HL7 unescape for A/Hex) happens only when a downstream destination explicitly asks for the binary payload, so a pass-through route from one MLLP partner to another never touches the encoded blob. Inbound size is checked against a per-route ceiling (default 10 MB on the wire) and oversized payloads are diverted to the engine's attachment store with an RP-style URL substituted on the outbound side if the downstream profile allows.

On outbound, Vorro emits Base64 for any payload that isn't already 7-bit safe ASCII, strips all newlines from the encoded string, and HL7-escapes any literal delimiter bytes before placing them in ED.5. ED.2 and ED.3 are populated from the source attachment's MIME type via a lookup table, defaulting to AP^OCTET-STREAM when the MIME type is unknown.

Related pages

• RP data type — Reference Pointer (out-of-band attachment)
• HD data type — Hierarchic Designator
• OBX segment — Observation/Result

Sources

• HAPI HL7v2 v2.8.1 javadoc — ED data type
• HAPI HL7v2 v2.8.1 apidocs index
• HL7 v2 product brief
• v2-to-FHIR ConceptMap — ED to Attachment
• v2-to-FHIR ConceptMap — ED to DocumentReference