DV_QUANTITY
A number, carrying the units the template permits and the magnitude range each unit states.
v0.1.1 published. The round trip runs against a real CDR, in CI.
openEHR operational templates, compiled into forms, in pure Rust.
FerroCHART walks an operational template and derives a field from the Reference Model type and the constraint at each node. The layout, labels, and visibility rules a person authors on top live in a separate overlay, so a template revision replays that work and reports what happened to it. A browser renders the form and reads that overlay, so a form grows as it is answered. The page below says exactly where the line still is.
Ferro for the Rust family FerroCHART shares with FerroEHR, FerroTERM, and FerroBRIDGE. CHART for the thing a clinician fills in.
Measured over the vendored corpus
What the compiler does to a real template corpus
The figures come from running the derivation over the openEHR CKM templates this repository vendors. The totals are asserted in the test suite, and a snapshot inventory covers every template in the corpus, so a change to any of these numbers fails the build.
Templates that derive a form
121 of 123
Of the 123 vendored CKM templates, 121 read, and every one that reads derives a form.
Fields derived
2621
Each with the units, value set, date precision, or repeatability its node constrains.
Groups they sit in
1775
A
CLUSTER whose upper occurrence is above one becomes a repeatable group.
ADL generations read
2
ADL 1.4 and ADL 2 normalize into one internal constraint model, so the derivation is written once.
Measured over the 123 templates this repository vendors, by the test
suite of the commit this page was built from. Every figure is an
assertion rather than a note: a change to any of them fails the
build, and scripts/checks/site.sh fails when this page
and the suite disagree. The
build order says what
each release added, and the tracker is the live version.
The mechanical half
A field comes from the type and the constraint at its node
No form is hand-written per template, and no field is hand-coded per archetype. The Reference Model type at each node decides the field kind, and the constraint decides what the field permits.
DV_CODED_TEXT
A selection over its value set, with the rubrics the template's own terminology states for each code.
DV_DATE_TIME
A date field at the precision the constraint states, rather than at whatever a widget defaults to.
CLUSTER
A group, and a repeatable one when its upper occurrence is above one.
The full rule table, class by class, is section 5 of the architecture document, where every row carries its Reference Model section. The design chapter is its shape.
The half nobody has built
Your layout survives the template revision, and you are told what changed
Field order, grouping, labels, help text, defaults, and conditional visibility are in no openEHR specification. A person spends hours on them. Then the template is revised.
FerroCHART keeps that work in a separate overlay, keyed by the identity of the node it decorates. Recompile from the revised template, replay the overlay, and every entry comes back classified:
- matched
- moved
- ambiguous
- reordered
- retyped
- disappeared
- new
Nothing is discarded, and nothing is silently rebound. An entry the new template no longer resolves is kept against its old key, so a later revision that restores the node restores its layout. A move is a suggestion for you to accept, because rebinding layout onto a node you did not choose is how a form ends up on the wrong clinical concept.
None of the openEHR form implementations surveyed for this project reports what a recompile did to hand-authored layout. That report is the reason this project exists, and the problem chapter names what each surveyed approach does instead.
Who it is for
Four questions, four answers
Will it read my templates?
Both ADL generations are read and normalized into one internal constraint model, so the field derivation is written once rather than once per generation. Against the vendored CKM corpus, 121 of 123 templates read and all 121 derive a form.
Which CDR does it work with?
Any of them. FerroCHART is a client of the openEHR ITS-REST API and is never a compile-time dependency of a CDR, so it works against the CDR your hospital already runs. A form builder tied to one CDR is no use to the people who asked for this. The ITS-REST client, the composition builder and the FHIR terminology client are written, and the round trip runs against a real CDR on every pull request.
What is actually published?
Binaries for four Linux targets, a distroless container image,
and a standalone compose.yaml. Every asset is
checksummed and carries a Sigstore attestation, so you can check
where a binary came from before you trust it. The published
binary carries the form surface and the renderer in one process:
it compiles the operational templates you point it at, answers
the API, and serves the screens at /ui.
May I use it, and what does it cost?
The Business Source License 1.1, with no open-core tier: the compiler, the overlay, the server, and the tools are in one repository under one licence. Reading, building, modifying, and redistributing the source is free, and so is every non-production use. Production use is free for personal use, research, teaching, and a non-profit or public body outside the course of a business; any other production use needs a commercial licence. Each version becomes Apache License 2.0 four years after it is published. A commercial licence is arranged with Cadasto B.V., the Licensor, which handles the business side of FerroCHART: write to info@cadasto.com or use the Cadasto contact page. Technical questions go to the maintainer.
Where the project is
What works, and what does not
The whole path runs, from an operational template to a COMPOSITION and back, against a CDR that enforces openEHR's rules for itself. What is missing is the half no specification governs, and this list is how you tell the two apart.
Works today
- Both ADL generations read into one internal constraint model.
- The derivation table and the form definition it produces, over the whole vendored corpus.
- The overlay store, its key, and the replay report of what matched, moved, disappeared or became ambiguous.
- A browser renders the form: a control for each of the eighteen field kinds, repeatable groups that open with what the template requires, a reason instead of a value, and a visible hole where a template determined nothing.
- The browser reads the layout a person authored: the order they put the questions in, the names and help text they wrote over the archetype's, the values a form starts with, and the rules that decide when a question appears. So a form grows as it is answered rather than asking everything at once.
- Entered values are judged against the operational template before any request, built into a COMPOSITION, posted over ITS-REST and read back into the same form.
- That round trip runs against a real CDR on every pull request, not against a mock.
- Releases for four Linux targets, a container image, and a compose file, signed and attested.
Does not work yet
- There is no authoring surface for the overlay. The browser reads one and the store writes one, so a layout is written by hand today rather than laid out on a screen.
- No form can commit. The server serves the routes and the browser has the client for them; what is missing is the control on the form.
- The WCAG 2.2 AA claim is held per screen and has not been audited end to end.
The tracker is the scope. Every issue carries its acceptance criteria, and a release is cut when its milestone reaches zero open issues.