hl7

What it is

A thin re-export and nothing else: `hl7::v2` is the `hl7-2` crate and `hl7::v3` is `hl7-3`, with room left for `hl7::fhir`. Nothing lives at the root, because a "message", a "segment", and a "code" mean different things in each standard and one flat namespace would only invite mixing them up.

// hl7/src/lib.rs, in full, minus the documentation
pub use hl7_2 as v2;
pub use hl7_3 as v3;

That is the entire crate. It exists so that a caller can depend on “HL7 for Rust” rather than on a specific standard, and so that hl7::fhir has somewhere to land when that standard is implemented.

Cargo features

cargo add hl7
cargo add hl7 --features derive   # pulls in hl7-2's derive macros

Use

use hl7::v2;

let message = v2::parse("MSH|^~\\&|LAB||EPIC||20240101||ORU^R01|1|P|2.5\r\
                         PID|1||241900||SMITH^JOHN")?;

assert_eq!(message.structure_id(), "ORU_R01");
assert_eq!(message.get("PID-5.1")?.as_deref(), Some("SMITH"));

And when a system speaks both standards:

use hl7::{v2, v3};

// v2: delimited text, addressed by path.
let admission = v2::parse(er7_text)?;
let patient_id = admission.get("PID-3.1")?;

// v3: XML, walked by element name.
let interaction = v3::message::parse(xml_text)?;
let control_act = interaction.control_act;

The modules

hl7::v2 — the hl7-2 crate

HL7 v2, releases 2.1 through 2.9. The format most healthcare data still moves in. Parse, navigate, validate, modify, and render, in three modes.

hl7::v3 — the hl7-3 crate

HL7 v3: the Reference Information Model, and the three-level message envelope built from it. A foundation, not a full implementation — read that crate's own scope section first.

hl7::fhir — not yet

Deliberately unclaimed, so the name is free when that standard is implemented.

Why the root is empty

HL7 is not one standard but a family of them, and they have little in common beyond the name and the problem: v2 is delimited text, v3 is XML, FHIR is resources over HTTP.

A “message”, a “segment”, and a “code” all mean something different in each. Flattening them into one namespace would only invite mixing them up — in a domain where mixing them up means a clinical record. So nothing lives at the root, and the module you want is the version your senders speak.

When not to use it

Depend on hl7-2 or hl7-3 directly if you specifically want one standard with no umbrella indirection. There is no functional difference — this crate is a re-export — but a direct dependency states your intent in the manifest and keeps one crate out of your dependency tree.

This crate has no spec/index.md of its own: a thin re-export has nothing normative to state. The specifications that govern it are hl7-2's and hl7-3's.

Related crates