Skip to content

anarchie

File-based, offline-first openEHR persistence, for experimentation, learning, and testing.

A Rust-based openEHR Clinical Data Repository (CDR) that uses flat files as its primary persistence layer instead of a database, and git as its versioning mechanism.

openEHR data is already document-oriented. A COMPOSITION is a self-contained, versioned clinical document, so the most natural way to store it is as a document on disk - one immutable canonical-JSON file per version. The EHR is a directory. A CONTRIBUTION is a git commit. The audit trail is the commit graph.

# scaffold a CDR, create a patient record, commit a composition
anarchie init --system-id anarchie.example.org
EHR=$(anarchie ehr new)
anarchie commit "$EHR" vitals.json -m "Admission observations"

Full walkthrough · Why anarchie? · Roadmap

  • The files are the database

    Every Composition is one canonical-JSON file on disk. The EHR is a directory. A human with ls, cat, jq, and git log can read the whole store - even without anarchie installed!

    On-disk format

  • Git is the version history

    A CONTRIBUTION is a git commit carrying the openEHR AUDIT_DETAILS as commit metadata and trailers. git log -- <path> is the version history of a Composition. Time-travel and diffing come for free.

    Versioning and git

  • Canonical and diffable

    openEHR defines a canonical JSON serialisation. anarchie round-trips the Reference Model through it byte-stably, so two equal Compositions produce identical files - and a re-commit of unchanged content diffs to nothing.

    The Reference Model

  • One Rust binary

    Validation, storage, AQL, the REST API, and an MCP server all compile into a single dependency-light binary. The only runtime dependency is the system git.

    Getting started

Status

anarchie is an early but already-working exploration. What works today:

  • Reference Model core - parse, validate the shape of, and canonically re-serialise openEHR Compositions (anarchie info, anarchie canonicalise).
  • Git-backed store - anarchie init, one git repository per EHR, and committing Compositions as Contributions with full version history (anarchie ehr, anarchie commit, anarchie cat, anarchie log, anarchie diff).
  • Validation - native RM + Operational Template validation, wired into commit so nonconformant data is rejected at the door with a precise openEHR path (anarchie validate, anarchie template).
  • Batteries included - anarchie init seeds an IPS-aligned set of starter templates by default; more can be added with anarchie pack.
  • AQL query engine - a SQLite path-extraction index with an AQL-to-SQL translator, plus ad-hoc and stored queries (anarchie index, anarchie aql, anarchie query).
  • Services - the openEHR REST API (anarchie serve) and a stdio MCP server for LLM agents (anarchie mcp).
  • Integrity - anarchie fsck re-validates every stored Composition against the RM, independent of the index.

Genuinely still ahead: ingesting .opt XML from Archetype Designer, terminology binding validation via sct, a FHIR / IPS projection, and prebuilt-binary distribution. See the roadmap.

Not for clinical use

anarchie is a research and design exploration. It is not a certified or production CDR and must not be used with real patient data.