About

About er7

A small, focused crate for one job: the ER7 encoding of HL7 v2 messages.

At a glance

Crateer7 0.1.1
PurposeParse, query, edit, and write HL7 v2 messages in ER7
LayerEncoding only — no dictionary, no validation, no transport
LanguageRust, edition 2024, MSRV 1.85
Runtime dependenciesnone, and that is a guarantee
LicenseMIT, Apache-2.0, BSD-3-Clause, GPL-2.0-only, or GPL-3.0-only
Sourcegithub.com/er7-rust/er7-rust/tree/main/er7
Cratecrates.io/crates/er7
API docsdocs.rs/er7
MaintainerJoel Parker Henderson

How it is built

The crate uses spec-driven development. A living specification in the repository’s spec/ directory is the source of truth for behaviour: every behavioural change starts there, then propagates to tests, then code, then docs. When the spec and the code disagree, the spec is right and the code is a bug.

Every guarantee carries a stable rule ID (R1R25), and a coverage table maps each rule to the test that enforces it — and the table itself is checked by cargo test, so a rule added without a test, or a section file added without an index entry, fails the build rather than waiting for a careful reader. Every crate in the family does the same, with its own rule prefix. Plans and tasks live as spec sections rather than as separate files, so a roadmap item and the rule it changes sit next to each other.

19 specification sections
25 numbered behavioural rules
126 unit, integration, and doc tests
7 runnable examples

Patient safety

This crate handles clinical messages about real patients. Two constraints follow, and they shape the whole design:

  • Absent, empty, and the explicit null stay distinct. Treating a null as empty leaves a withdrawn allergy on a record; treating an empty as a null erases a value that was never sent.
  • A message that arrives correct leaves unchanged. A silent alteration is worse than a visible failure.

No test, sample, example, or documentation page in this project contains real patient data. Every message is synthetic, with obviously fictional names and identifiers.

Contributing

Issues and pull requests are welcome at github.com/er7-rust/er7-rust. Two requests:

  • Include a synthetic message that reproduces the problem — never a real one, even redacted. A “redacted” message still carries dates, facility names, and identifier formats.
  • Behavioural changes start in the spec. The repository’s AGENTS.md and AGENTS/ guides describe the change loop and the four checks every change must pass.

If an answer turns out to be “this is deliberate”, it gets recorded in the spec’s open-questions section, so the next person finds the reasoning rather than re-asking.

License

Multi-licensed. Use it under any one of MIT, Apache-2.0, BSD-3-Clause, GPL-2.0-only, or GPL-3.0-only, at your option. Pick the one that fits your project and comply with that one; you do not need to comply with all five, and you do not need to say which you chose.

Healthcare integration code ends up inside organisations with very different legal constraints: a permissive license suits a vendor integrating into a proprietary product, while a copyleft license suits a public-sector project that wants derivatives kept open. Offering the choice means neither has to ask.

Citation

The repository carries a CITATION.cff. If you would rather have BibTeX:

@software{henderson_er7,
  author  = {Henderson, Joel Parker},
  title   = {ER7 Rust: Parse, query, edit, and write HL7 v2 messages
             in the ER7 pipe-hat encoding, with zero dependencies},
  url     = {https://github.com/er7-rust/er7-rust/tree/main/er7},
  version = {0.1.1}
}

This site

Built with SvelteKit and the Lily Design System™, prerendered to static HTML, and deployed to GitHub Pages by GitHub Actions. There is no server and no client-side data fetching; every page is a file.

Its source is at github.com/er7-rust/er7-rust.github.io. Corrections to these pages are as welcome as corrections to the crate.