Request for comments
What this project wants to learn
A one-maintainer project with no production traffic of its own. The crates are specified, tested, and benchmarked — and none of that says whether they are right for the messages real systems send. That gap closes when somebody who runs an interface says what they saw.
What helps most
- “Here is a message shape you get wrong.” Redacted, minimal, reproducible — the single most valuable thing anyone can send.
- “We evaluated this and chose something else, because X.” A lost evaluation with a reason is worth more than a won one without.
- “Your reasoning in §N is wrong, and here is why.” The specs argue in prose precisely so the argument can be attacked.
- “We ran it against our traffic and nothing broke.” Boring, and currently unobtainable any other way.
- “This claim oversells.” Overclaiming in healthcare software is a defect and is treated as one.
Answer by GitHub issue, by email for anything about your own environment, or by a pull request
against the relevant spec section. One paragraph about one question is a real contribution. Never send a real HL7® v2 message — redact it first with er7-redact.
The questions
| Question | What we want to know | |
|---|---|---|
| Q1 | Does the value tree match the messages you actually receive? | Absent, empty, and the explicit null stay distinct. Does anything your senders emit not fit the fixed hierarchy? |
| Q2 | Are escape sequences decoded in the right places? | er7 decodes sequences wherever they appear — a recorded divergence. Has that ever bitten you? |
| Q3 | Is the path syntax the one you would have guessed? | What did you type that did not work, especially coming from HAPI, Mirth, or another tool? |
| Q4 | What does the built-in redaction policy miss? | What did you have to add? What did it redact that you needed to keep? |
| Q5 | Should a pseudonym be cryptographic? | FNV-1a with a u64 key is a stable stand-in, not a security primitive. Does that reasoning survive your threat model? |
| Q6 | Does "the same patient" need to mean more than "the same text"? | A pseudonym maps a value, not a patient. Is that a problem you actually have? |
| Q7 | Is the zero-dependency stance load-bearing, or is it theatre? | Did it matter in a real review at your organisation, or did your process not care? |
| Q8 | Is the minimum Rust version window right? | Current stable minus two — roughly three months. Is that enough for your organisation? |
| Q9 | Are five licences useful, or just confusing? | Did the choice help, or did your legal review treat an unusual expression as a red flag? |
| Q10 | Is performance anywhere near your bottleneck? | Or is I/O what dominates? Batch files in the hundreds of megabytes are the known unsolved case. |
| Q11 | What is missing that stops you adopting this at all? | No validation, no typed segment model, no transport — deliberately. Did one of those absences stop you? |
| Q12 | Does the documentation earn trust or spend it? | Did the candour read as rigour, or as a project protesting too much? Which document did you actually use? |
| Q14 | What does a defensible Safe Harbor statement need from a tool like this? | If you have taken a data set through a review, what did the reviewer actually ask for — a per-identifier coverage table, or something else? |
Every answer gets recorded, whatever it is; a “no” comes with reasoning, in the spec, where you can argue with it; and you get credit unless you ask not to. Question numbers are stable and never reused.
The canonical document is RFC.md at the repository root — the full version of every question, what an answer would change, which spec section records it, and the decisions already made.