We’re trialling a new site for Developer documentation, this will not affect how the Specifications, forum, or Confluence work, but it creates a single point of technical reference which will enhance all the other web presence we already have.
If you have feedback then you can discuss it here, or if you are able, make a PR to the site itself. Source code here:
It’s a brand new site and a trial of using Zensical (basically Markdown processed into a static HTML site) which is similar to MkDocs, Docusaurus, and similar.
We’d love to see suggestions for additional sections - all ideas welcomed!
There are no fixed criteria for how that tooling list was created. I used agents and asked for all the tooling that it could find, ideally with corroborating evidence like links to Company, source code, or Install/Pricing page
If you submit a PR to the developer.openehr.org source repo (linked above) with your CDR query tool, it’ll be accepted. At this stage I’m more interested in comprehensive inclusion than the age of the tools.
GitHub stars and other measures can then help people decide what’s suitable for their uses.
Other contributions are also welcome such as additional commentary on some of the oldest tooling, which I suspect is now obsolete.
Thansk to all who have made PRs, I’ve merged them all today, minor changes only for consistency, but if I’ve changed things too much then let me know and I’ll fix.
@marcusbaw Looking for some assistance on the categorisation of tools.
My tool ehr-ctrl is a query tool; it allows you to create and execute AQL queries, as well as other API queries against a CDR.
BUT - it also allows CDR data to be created, templates to be maintained, and queries to be maintained.
It doesn’t seem to fit nicely into the current categories - any thoughts on where it would go?
I don’t think it’s my imagination but I suspect a lot of us are independently using agentic coding for side-projects, to develop the openEHR tools we always wished we had the time to build. It’s incredible that we can do this - and I am as guilty of it as anyone else here - but there is the slight risk that our quite small community will be flooded with many superficially-polished but incomplete projects and it becomes even more confusing for the newcomer to evaluate where to get started.
I would suggest that we try to collaborate on projects and, where appropriate, adopt some into openEHR International’s ‘custodianship’ - it would be nice to be able to point to official SDKs in various languages, official CDR implementations, and official CKM-like tools.
The first step is knowing what we’re all working on!
For my part I’ll list the stuff I’m working on here, including the stuff I hadn’t felt ready to ‘announce’ as it didn’t feel ‘done’. But in a spirit of avoiding duplication of effort, here’s (some of) what I’ve working on:
anarchie - an experimental CDR and Rust SDK for openEHR, which uses files on disk for persistence, and deliberately doesn’t use a database. [pre-alpha]
gitehr - a file-based, offline-first, Git-driven EHR system, which solves interoperability by inverting the traditional organisation-centric EHR approach in favour of a genuinely patient-owned record. Not an openEHR project as such but I am hoping to make it openEHR compatible with anarchie. [pre-alpha]
sct - something I published months ago but probably of use to some openEHR developers - a SNOMED-CT toolchain that works locally - CLI, MCP, lexical and semantic search, fast fuzzy search, FHIR termserver, and crossmapping to other terminologies. [beta]
clincalc - an (eventually) comprehensive set of fast, provenanced local clinical calculators which use stdioJSON in and out, via CLI, API, MCP, and is usable from Python via FFI. [alpha]
greenbook - a computable representation of the UK’s Green Book for immunisation/vaccination, that can compute vaccination ‘completeness’ for an individual patient based on FHIR vaccination records and historical Green Book editions. [pre-alpha]
Most of this is ‘side-project’ that has fallen out of work I’ve done for RCPCH or the NHS more widely.
If there are obvious synergies with other projects I am happy to talk about collaboration, mergers, and idea sharing!
sct sounds interesting, not too deep into the whole SNOMET-CT topic myself, but might give it a look in the future
greenbook also sounds like a common problem, we’re waiting for digital vaccination records forever in Switzerland. You don’t have an online (deployed) live demo of it somewhere by chance?
Here’s my list of sideprojects:
oehrpy (inactive) - a Python SDK for openEHR. Not production ready, but it powers the next project on the list
open-cis (inactive) - a PoC of a clinical information system, based on openEHR, using oehrpyinternally
openEHR Explorer - the openEHR query tool I’ve announced already. It’s a tool I’m using myself almost daily and improving it as I go. I’ve also given it to my team for feedback. Clearly has feature overlaps with ehr-ctrl by by @richard.kavanagh , but the approach is a little different. For now I think both projects can benefit from eachother.
Absolutely - I only just found out about FerroEHR last week - it looks like a much more mature project than my version. I will look at the opportunity to coalesce or combine.
Yes, I figured this would be a universal problem that needed solving, so the design of the data model which stores the vaccination schedules is deliberately not bound to the UK, although inherently as I used the UK’s Green Book and SNOMED dm+d for it, there could be an unconscious ‘UK bias’, but I’d be happy to try to engineer that out for more global applicability.
Love the work you’ve published and will almost certainly be using openEHR Explorer as a dev/test tool for anarchie.
On the overlap with anarchie: they are separate CDRs and I think that’s fine, different storage designs are worth exploring. The thing I would hate to see duplicated is everything underneath the CDR, because that’s where most of my time went. So I pulled that entire layer out into standalone crates and published them on crates.io. Most of them are code-generated from the machine-readable specs (the BMM json files, the XSDs, the ITS-REST OpenAPI), so when openEHR updates a spec I re-run the generator and the types follow.
openehr-lang - BMM / P_BMM object model and ODIN reader, this is what my code generator runs on (source)
openehr-its - canonical JSON, canonical XML, the generated ITS-REST 1.1.0 contract, and the simplified formats (FLAT, STRUCTURED, web template) (source)
openehr-adl - ADL 2.4 engine: ADL2/cADL/ODIN parsing, AOM2 validation, flattener, OPT2, and ADL 1.4 to 2 conversion (source)
One design note on the query side, since query tooling came up earlier in the thread: I skipped ANTLR. openehr-query is a hand-written lexer and parser, and FerroEHR compiles the resulting AST straight into PostgreSQL SQL. No interpreter sits in the request path, so AQL ends up about as fast as the equivalent hand-written SQL.
Quick question: where/how should I ask for adding tools to the lists?
I’m also wondering if that’s just focused on open source and open access tools, but also closed source licensed tools too. I mean, is the idea to list all openEHR tools and systems there?
I agree, the age of AI is certainly accelerating the development of software tools, both by the mainstream product providers and the technical enthusiasts alike.
I’m not sure I 100% agree with the suggestion of some form of central custodianship for this kind of work.
I can only imagine that would stifle the activity and introduce bureaucracy and opinions that would prove to be unhelpful in the long run. As an outsider, there is already a murky opaqueness (personal opinion ) to certain functions within parts of openEHR. I would not want to see any limitations on people getting involved. Some projects will fall by the wayside, and some will flourish - that’s to be expected.
For visibility, here’s what I am working on:
C# libraries for openEHR, currently covering data types, the RM and EHR structures.
These are all open source and published on Nuget for C# developers to use.
C# libraries for parsing and serialising compositions in a variety of formats (i.e. JSON, including flat format).
These are all open source and published on Nuget for C# developers to use.
C# code for generating concrete C# classes from OPT templates, allowing easier creation and consumption of openEHR templates (with built-in parsing and serialisation).
I take your point about not wanting to get stuck in murky and slow corporate treacle. But, I think low-level libraries and SDKs are exactly the sort of thing we should be adopting under the openEHR International banner, pulling into the openEHR GitHub org, and promoting as a good way in to building openEHR persistence.
) to certain functions within parts of openEHR. I would not want to see any limitations on people getting involved. Some projects will fall by the wayside, and some will flourish - that’s to be expected.
.