Specs
This site doesn't restate the conversion rules. Each project's own spec/index.md is the normative, section-by-section specification and the single source of truth for its
behavior:
Core, transports, and tooling
- hl7-2 spec — the HL7 v2 dictionary: data types, message structures, parsing modes, mutation, validation
- hl7-3 spec — the RIM backbone classes, coded values, and the three-level message envelope
- hl7-2-mllp spec — HL7 v2 framed on a TCP stream (MLLP)
- hl7-2-soap spec — HL7 v2 carried in a SOAP envelope over HTTP
- hl7-3-soap spec — HL7 v3 carried in a SOAP envelope over HTTP
- hl7-2-from-xsd-into-json-dictionary spec — HL7 v2.xml XSDs → the JSON dictionary
hl7-2reads - hl7-2-xml-lite-helper spec — the shared minimal XML reader the v2.xml-facing crates use
The umbrella hl7 crate and the two *-derive crates
(hl7-2-derive, hl7-3-derive) have no spec/index.md of
their own — hl7 is a thin re-export with nothing normative to state, and each
derive crate's macro behavior is documented in its own README (and, for hl7-3-derive, in hl7-3's typed module) rather than as
a spec.
Format conversions
- hl7-2-from-er7-into-xml spec — ER7 → v2.xml XML
- hl7-2-from-xml-into-er7 spec — v2.xml XML → ER7
- hl7-2-from-er7-into-json spec — ER7 → typed JSON
- hl7-2-from-json-into-er7 spec — typed JSON → ER7
The two forward specs (ER7 → XML, ER7 → JSON) are kept consistent with each other
except where the target format forces a difference (see each one's own §0 for exactly
where they're meant to diverge: JSON uses real arrays/null, XML follows
v2.xml's element/attribute constructs). Each reverse spec documents, in its own
§1.1, why it needs no HL7 v2.5 data-type dictionary at all: every element or key name its
forward counterpart writes already carries its own position, so reversing the conversion
is a purely structural, position-based rebuild.