hl7 0.2.1

HL7® implementation using Rust: parse, navigate, validate, modify, and render Health Level Seven (HL7) messages. HL7 v2 (releases 2.1-2.9) lives in `hl7::v2`; the HL7 v3 RIM and message envelope in `hl7::v3`; room for `hl7::fhir` as that standard is implemented. HL7®, and FHIR® are the registered trademarks of Health Level Seven International and their use of these trademarks does not constitute an endorsement by HL7. This project is an independent work.
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

# AGENTS.md

Instructions for coding agents (Claude Code, Codex, or any other) working in
this crate. `CLAUDE.md` is a pointer to this file — keep this one canonical
and don't fork the content between the two.

## What this is

A thin umbrella crate: `src/lib.rs` and nothing else, about fifty-five
lines, whose entire content is `pub use hl7_2 as v2;` and
`pub use hl7_3 as v3;` plus its own doc comment. It exists so a caller can
`cargo add hl7` and get `hl7::v2` and `hl7::v3` instead of depending on
`hl7-2` or `hl7-3` by name — one module per HL7® standard, so a
"message", a "segment", or a "code" in one standard is never confused with
the same word in another.

Today that's `hl7::v2` and `hl7::v3`. Room is left for `hl7::fhir` as that
standard gets implemented, its own crate, re-exported here the same way.

## Layout

```
src/lib.rs   The whole crate: `pub use hl7_2 as v2;`, `pub use hl7_3 as
             v3;`, the `derive` feature forwarding to hl7-2/derive, and the
             crate-level doc comment (which is also the one doctest this
             crate has).
```

There is no `spec/index.md` here — this crate is too thin to need one.
`hl7-2`'s spec covers `hl7::v2`, and `hl7-3`'s covers `hl7::v3`; this
crate only re-exports them.

## Working conventions

- **This crate carries no logic of its own.** Parsing, validation,
  dictionaries, all of it lives in `hl7-2` (and, in time, the other
  per-standard crates). If a change here does anything beyond adding or
  wiring up a `pub use`, it almost certainly belongs in the crate being
  re-exported instead.
- The `derive` feature does nothing but forward to `hl7-2`'s own `derive`
  feature (which in turn pulls in `hl7-2-derive`). Don't grow it into
  anything else.
- No tests of its own beyond the doctest in the crate-level doc comment —
  that's intentional, not a gap. Behavior gets tested where it lives, in
  `hl7-2`.
- Adding a new standard (`hl7::fhir`, ...) means adding a new sibling
  crate with its own dictionary, tests, and spec, then one `pub use` line
  here. It does not mean growing this crate's own logic.
- Every public item must have a doc comment; `src/lib.rs` carries
  `#![warn(missing_docs)]` to enforce it.
- Before finishing a change, run:
  ```sh
  cargo test -p hl7 --all-features
  cargo clippy -p hl7 --all-targets --all-features -- -D warnings
  cargo fmt --check
  ```

## Non-goals (don't "fix" these without discussion)

- Implementing HL7 behavior directly in this crate. That's `hl7-2`'s job
  (and future standard-specific crates' job), never this one's.
- Flattening the `v2` module away, or otherwise hiding which standard a
  type belongs to. The per-standard namespace is the point.

---

HL7®, and FHIR® are the registered trademarks of Health Level Seven International and their use of these trademarks does not constitute an endorsement by HL7.