HL7 Base64 OBX Generator

Format data for the OBX-5 Encapsulated Data (ED) type.

Save

Calculator

Inputs

Plain text or an existing Base64 string.

Live output

Results

OBX Segment
OBX|1|ED|Document||^application^PDF^Base64^SGVsbG8gV29ybGQgUERGIENvbnRlbnQ=||||||F

Report

Export and share

Document

Copy and share

Assumptions

  • When **Input is already Base64** is off, the tool uses browser text encoding with `btoa`, so it is best suited to plain text examples rather than raw file uploads.
  • The generated segment is a simple OBX example and does not validate local implementation-guide requirements, length limits, or document metadata.
  • The selected content type labels the ED components, but the tool does not inspect the payload to confirm it truly matches that media type.

Sensitivity preview

No numeric sensitivity scenarios are available.

Related Tools

View All

About this Base64 Encapsulator

HL7 v2 interfaces sometimes place encapsulated content into OBX-5 using the ED (Encapsulated Data) data type. This tool helps you assemble a basic ED-style value and sample OBX segment when you are testing how content type, encoding, and payload components fit together.

Who this calculator is for

  • Interface analysts building or troubleshooting OBX segments that carry embedded payloads.
  • Developers who already have text or Base64 content and need an ED-style field layout for testing.
  • Teams documenting how an interface expects content type and encoding components to be arranged.

When to use it

  • Use it when you want a quick ED-format example for a sample OBX segment.
  • Use it when you already have Base64 content and need to place it into the standard component order.
  • Use it to compare how PDF-, image-, and text-labeled payloads look inside an HL7 field.

How to use this calculator

  1. Paste your Data (either raw text or an existing Base64 string).
  2. Select the Content Type (PDF, JPEG, Text).
  3. Check Input is already Base64 if you pasted a string that is already encoded.
  4. The tool generates the full `OBX|...` segment ready for your message.

Key assumptions

  • When **Input is already Base64** is off, the tool uses browser text encoding with `btoa`, so it is best suited to plain text examples rather than raw file uploads.
  • The generated segment is a simple OBX example and does not validate local implementation-guide requirements, length limits, or document metadata.
  • The selected content type labels the ED components, but the tool does not inspect the payload to confirm it truly matches that media type.

Accuracy and testing

Review formula sources, default test cases, assumptions, unit handling, rounding rules, and changelog for this calculator.

View accuracy page

How this calculator works

The ED data type structure is: `Source Application^Type of Data^Data Subtype^Encoding^Data` Example: `^Application^PDF^Base64^JVBERi0xLj...`

Inputs explained

Data / Text

The content you want to encapsulate. Can be plain text or a raw Base64 string from a file.

Content Type

The MIME type category (Application, Image, Text) and subtype (PDF, JPEG, Plain).

Understanding your results

The output is a sample HL7 OBX segment showing how the ED field is assembled. Review it before using it in a real interface or production message flow.

Key Features

  • OBX Segment Generation
  • MIME Type Formatting
  • Base64 Encoding Logic

Tips & Best Practices

  • If sending large files (>10MB), consider using the **RP (Reference Pointer)** data type instead, which sends a URL link rather than embedding the full file.
  • Ensure your receiving system supports the ED data type (most modern PACS and EMRs do).

Glossary of Terms

OBX Segment
Observation/Result segment. Used to carry clinical data, notes, or files.
Base64
An encoding scheme that represents binary data in an ASCII string format.

Frequently Asked Questions

What is the ED data type?
ED stands for Encapsulated Data. It allows non-text data to be embedded in an HL7 message.
What is the format?
Source^Application^Type^Encoding^Data. Example: `^Application^PDF^Base64^JVBERi...`
Can I send large files?
Technically yes, but large Base64 strings can bloat interface engines. Typically files > 10MB are better sent via link (RP data type) than embedded.
What implies 'Base64' encoding?
Component 4 of the ED field specifies the encoding. 'Base64' is the standard for binary data.
Does this generate the whole segment?
Yes, it generates a sample OBX segment you can paste into your message.