# Moved: openEHR Tooling Guide
**URL:** https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926
**Category:** Software Program - open
**Tags:** wiki
**Created:** [10 April 2026 11:32 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926 "2026-04-10T11:32:41Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)
#### Post date: [10 April 2026 11:32 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/1 "2026-04-10T11:32:42Z")
# Moved to the openEHR Developer Guide
This draft has moved to the [openEHR Developer Guide](https://developer.openehr.org/tooling/).
The tooling guide is now maintained as a Zensical website. It is the first section of a broader developer guide, with implementation and conformance guidance to follow.
Please post corrections and additions on the [openEHR Discourse forum](https://discourse.openehr.org/) or open a pull request at [openEHR/developer.openehr.org](https://github.com/openEHR/developer.openehr.org).
---
### Author:  [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)
#### Post date: [10 April 2026 11:39 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/2 "2026-04-10T11:39:19Z")
This is a bit of a ‘starter’ attempt to create a Wikified entrypoint which we can build on. Feedback welcome. I have rough draft content for each of the sections enumerated above, but will post them one by one so I can edit for style and triple-check the details for accuracy.
---
### Author:  [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)
#### Post date: [21 May 2026 09:51 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/4 "2026-05-21T09:51:00Z")
[@SPB](https://discourse.openehr.org/groups/spb) as mentioned in the meeting I have started work on this overview, which aims to clarify for new developers/clinicians what tooling is available, what each thing does, and which tools are considered the ‘industry standard’ vs which ones are legacy/deprecated.
Am I on the right track here?
---
### Author:  [@Martin\_Koch](https://discourse.openehr.org/u/Martin_Koch)
#### Post date: [21 May 2026 10:30 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/5 "2026-05-21T10:30:47Z")
I was thinking to start out first with an inventory of everyting akin of an excel sheet, so it would be easier to filter and distribute the review work.
But if we are comfortable to dive right in the more “human-readable” format, you can count on me to review the lists of applications/software/scripts.
---
### Author:  [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)
#### Post date: [21 May 2026 12:15 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/6 "2026-05-21T12:15:55Z")
Excel sheets are a disaster area for text. I’m happy for other people to collate a spreadsheet from this data, but I will be continuing with a text-based series of articles.
---
### Author:  [@Martin\_Koch](https://discourse.openehr.org/u/Martin_Koch)
#### Post date: [22 May 2026 05:56 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/7 "2026-05-22T05:56:04Z")
Agreed! Lets all work on the official text-based documentation.
---
### Author:  [@joostholslag](https://discourse.openehr.org/u/joostholslag)
#### Post date: [22 May 2026 06:05 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/8 "2026-05-22T06:05:22Z")
Can we reuse the open source practise of the list of amazing for x on GitHub?
Explaining all the formats and language seems more of a specs and educational effort seperate from a tooling list to me.
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [23 May 2026 11:01 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/9 "2026-05-23T11:01:08Z")
@marcusbaw I know Discourse will be up for what are you proposing with wikified page set - but I was wondering what is your opinion on having a static website, rendered with mkdocs on github pages, based on markdown sources? it is also a “wiki”, easy to maintain, version control, cheap and easy maintenance, visually customisable.
---
### Author:  [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)
#### Post date: [23 May 2026 13:07 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/10 "2026-05-23T13:07:57Z")
Yes, a static documentation site based on Markdown source could be a better fit for what we want to do than Discourse is.
The reason I didn’t suggest it initially was that I didn’t want to start by suggesting yet another now toolset/platform, when we already have Confluence and Discourse.
However, it could be argued that a static generated site is just leaning more into our existing GitHub presence.
Very happy to go with the static site idea - I have extensive experience with static documentation sites using [Material for Mkdocs](https://squidfunk.github.io/mkdocs-material/) or [Zensical](https://zensical.org/) frameworks - but the choice of framework is immaterial as long as the source is in Markdown, it’s easy to switch framework. I know you’ve used Antora a lot, sadly I have no experience with it but I’d give it a go since all openEHR specs are in Antora already.
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [23 May 2026 18:30 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/11 "2026-05-23T18:30:47Z")
No, Antora would be too complex for this.
Markdown on github, with static build with Mkdoc is much easier to manage and sufficient for the job, in my opinion.
But it is up for the group to take a direction.
---
### Author:  [@legend1](https://discourse.openehr.org/u/legend1)
#### Post date: [24 May 2026 18:00 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/12 "2026-05-24T18:00:40Z")
I think everybody here knows markdown and static pages. I personally don’t know Material for Mkdocs or Zensical but I guess with markdown knowledge it’s easy to handle. Let the group decide. Also open for Github pages.
---
### Author:  [@sheeren.khalifa](https://discourse.openehr.org/u/sheeren.khalifa)
#### Post date: [30 June 2026 11:33 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/13 "2026-06-30T11:33:04Z")
This may be my newcomer brain speaking, so please season generously with salt, but I wonder if there are two slightly different audiences being discussed here: the people maintaining the documentation and the people trying to read and learn from it.
From a maintenance perspective, Markdown in GitHub sounds sensible. My only hesitation is around the reader-facing experience, especially for newer users (like myself) who may not be as familiar with GitHub, Markdown, or the many acronyms floating around.
If the GitHub side is mostly the backend/source of truth, and the output is a well-structured, searchable, visually friendly documentation site, then that seems like a good direction. But I think the success would depend heavily on how beginner-friendly the published site is: clear navigation, introductory pathways, glossary/appendix, and key Discourse learnings surfaced somewhere more permanent.
In other words, my concern is less “GitHub bad” and more “please don’t make the learning curve wear a disguise and call itself documentation.”
Apologies if this has already been covered elsewhere. I’m still deep-diving through Discourse and have accepted that I may emerge in approximately 2037.
---
### Author:  [@dmccaf](https://discourse.openehr.org/u/dmccaf)
#### Post date: [30 June 2026 12:19 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/14 "2026-06-30T12:19:30Z")
Well put @sheeren.khalifa. I think from my understanding of the proposed solutions the rendered git approach would deliver the user friendly interface you’re hoping for. e.g. [https://www.mkdocs.org/](https://www.mkdocs.org/) is itself built with Mkdocs, with its source editable on Github.
I like @joostholslag’s suggested approach of it being open source itself, where we could have maintainers that could approve any proposed changes through a pull request flow.
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [30 June 2026 19:35 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/15 "2026-06-30T19:35:35Z")
That is exactly correct @dmccaf … the sites that are generated my mkdocs are just normal web pages but very easy to put together.
Example here [Pharmacogenetics Data Modelling - A Step Towards Personalised Prescribing - openEHR CKM Team UK reviews](https://apperta-ckm.github.io/nhs-pgx/PGX-001-%20Background-to-PGX-project/)
And it is not locked into github though gh pages is very convenient
---
### Author:  [@marcusbaw](https://discourse.openehr.org/u/marcusbaw)
#### Post date: [30 June 2026 20:06 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/16 "2026-06-30T20:06:41Z")
> [@sheeren.khalifa](#):
>
> “please don’t make the learning curve wear a disguise and call itself documentation.”
Totally hear this @sheeren.khalifa and the aim will be to make readable, accessible, and less technical documentation than we had before.
> [@ian.mcnicoll](#):
>
> sites that are generated my mkdocs are just normal web pages but very easy to put together.
I’m fine with any Markdown-on-Git based approach - it gives us simple editable source and it can be presented in a range of ways (even multiple ways from the same source).
MkDocs is [going through a little bit of a hiccup right now](https://squidfunk.github.io/mkdocs-material/blog/2026/02/18/mkdocs-2.0/) so I’ve personally transitioned to using [Zensical](https://zensical.org/) for everything. Here’s an example Zensical-driven site [sct - sct](https://pacharanero.github.io/sct)
Equally nice is a new framework my son showed me this week called [DocMD](https://docmd.io/) which is popular in the Rust community.
The difference between all of these is just a few lines of configuration, because for the most part they all **consume Markdown as source**. If we go with that, we can use anything we want, we can change in the future. It doesn’t matter all that much as long as what we produce is readable, well written, and helpful.
---
### Author:  [@sheeren.khalifa](https://discourse.openehr.org/u/sheeren.khalifa)
#### Post date: [1 July 2026 11:17 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/17 "2026-07-01T11:17:46Z")
On a side note, I found this PGx modelling page really interesting. I worked on similar modelling in my previous role, where we broke things down in more detail using real PGx reports, so it definitely sparked a lot of thoughts and questions for me.
I can see a few ways this could potentially be made more granular to improve data structuring, although this would depend on the use case ofc, but I won’t go too deep here as I don’t want to add too much noise to the thread. Thanks again for sharing.
---
### Author:  [@ian.mcnicoll](https://discourse.openehr.org/u/ian.mcnicoll)
#### Post date: [1 July 2026 14:43 UTC](https://discourse.openehr.org/t/moved-openehr-tooling-guide/11926/18 "2026-07-01T14:43:16Z")
Thanks - happy to have a conversation about pgx in a separate topic. The published archetype and example template are at
> **[Project: Team UK reviews](https://ckm.openehr.org/ckm/projects/1013.30.124/dashboard)**
>
> Project for archetypes led by the UK-based editorial team. | The Clinical Knowledge Manager (CKM): A powerful collaboration tool for clinical data models. Powered by Ocean Health Systems.
We are now also working on familial cancer screening and polygenic risk scoring.