Expand description
Derive macros for hl7-2: map a
struct’s fields to HL7 v2 message paths once, in the type definition,
instead of writing the same accessor calls at every call site.
This crate is not used directly. hl7-2 re-exports both macros behind
its derive feature, so the dependency to add is:
hl7-2 = { version = "0.2", features = ["derive"] }Keeping the macros in a crate of their own is what lets the default
build of hl7-2 keep exactly one dependency: syn and quote are
compiled only for callers who ask for the macros.
use hl7_2::{FromHl7, ToHl7, Raw};
#[derive(FromHl7, ToHl7)]
struct Result {
#[hl7("OBX-3.1")] code: String,
#[hl7("OBX-5")] value: Option<String>,
#[hl7("OBX-6.1")] units: Option<String>,
#[hl7(nested)] patient: Patient, // its own FromHl7
#[hl7(raw)] raw: Raw, // the escape hatch
}One attribute per field, and a field with none is skipped on read
(it must implement Default) and on write:
| attribute | on read | on write |
|---|---|---|
#[hl7("PID-5.1")] | read the path | write the path |
#[hl7(nested)] | the field’s own FromHl7 | the field’s own ToHl7 |
#[hl7(raw)] | the whole message | skipped |
| none | Default::default() | skipped |
§When hl7-2 is not called hl7_2
The generated code names the crate absolutely, as ::hl7_2, so that it
works wherever the type is defined without the caller importing
anything. A caller who renames the dependency —
hl7 = { package = "hl7-2" } in Cargo.toml, or a workspace that
aliases it — has no ::hl7_2 for the macro to reach, and the generated
code stops compiling. Say where it is instead, once, on the struct:
#[derive(FromHl7)]
#[hl7(crate = hl7)] // or `crate = "::some::path::to::hl7_2"`
struct Patient {
#[hl7("PID-5.1")] family: String,
}