Following on from the Software Program Board initial kickoff meeting today, this topic is for community members to introduce themselves to the other members of the community and (as we didn’t have time to get around everyone in the call today) perhaps mention what sort of things you are interested in seeing emerge from the work of the SPB. I imagine there will be a huge variation in backgrounds and ideas, and I think this represent a huge opportunity for openEHR to shift gears into a ‘batteries included’ platform.
2 Likes
Hi everyone,
my name is Martin Koch and I’m a biomedical engineer currently working for the Catalan Health Service.
I’m here because in our team we build custom software to support our clinical and modelling workflows on top of openEHR. Over time we’ve realised that much of what we build could and should be released as open source, because:
-
it could help other modellers facing similar challenges, and
-
it could help software vendors better understand which functionalities their users are missing in current products.
From working with the openEHR ecosystem, I’ve also noticed that there is already a lot of valuable code and resources in the openEHR GitHub space that are effectively “buried” because it’s not obvious how to find, use or integrate them.
Examples include things like the ANTLR4 parser for archetypes or the Reference Model in JSON format: they are there, but not always easy to discover, understand, or apply in real projects.
What I would love to see from the Software Program Board is a stronger, more accessible platform, almost like a marketplace, where:
-
end users and developers can easily find applications, tools, and libraries for specific purposes,
-
projects can show concrete examples and usage patterns, and
-
people can have constructive discussions around how to implement and evolve these tools.
To give a flavour of what I’m working on:
-
AQL Manager – a tool to write, format and manage an AQL collection:
AQL Manager -
Archetype Companion – my latest project, developed in the openEHR fellowship program, to make working with archetypes more approachable:
Archetype Companion
I’m very interested in helping make openEHR software and tooling more discoverable, more usable, and more collaborative for the whole community.
5 Likes
I’m Marcus Baw, I am a GP-turned-coder, or ‘General Hacktitioner’ as I like to call myself. I’m based in York, UK and previously have a wide clinical background ranging from anaesthesia to prison GP. I’m a clinical informatician, clinical safety officer, and software developer (Ruby, Python, Rust main languages, but increasingly LLM-driven development means I mainly write specifications in Markdown).
Importantly for this group, I have a small regular paid (‘mates rates’ 
) commitment to provide openEHR sysadmin services which is mostly for forum/server maintenance & updates, admin, websites, github, etc.) I can use some of this time to support software development for openEHR, especially the official work that the SPB decides to have working groups work on.
I’m here because I’ve always thought openEHR is a great idea but it lacks that ‘batteries included’ immediate developer usability, and implementation has such a steep learning curve that it is not really feasible unless part of a large organisation. We can make that better. I also feel we could be building and sharing more open source stuff directly from the openEHR organisation for everyone to benefit from.
Click this button to set your Watching notification status for the Software Program category and always get notifications of activity here.
Watch this category
4 Likes
Hi all,
I’m James Shelbourne, Chief Engineer at Avenue3, a tech consultancy based in Leeds specialising in modern health‑tech solutions. I spend most of my time helping teams design and build reliable systems in regulated environments.
My background spans healthcare, education, telecoms, finance, government and defence, and I’ve worked across a range of technology stacks — mainly .NET, JavaScript/TypeScript, React, Angular, Infrastructure‑as‑Code (Terraform, etc.), and various SQL platforms. Over the years I’ve picked up a fairly broad mix of tooling, which helps me bridge the gaps between engineering, architecture and delivery teams.
From our initial discussion last week, I’m very much aligned with the themes others have mentioned. I think one of the biggest early wins would be making documentation clearer, easier to navigate, and more approachable for new starters, along with improving the onboarding tooling and experience.
Internally, we’ve built tooling to streamline our development cycle so we can focus more on domain logic rather than on the implementation details of openEHR itself. I imagine others may have developed similar approaches, so perhaps there’s an opportunity to consolidate or share ideas here.
Looking forward to getting involved and helping wherever I can.
2 Likes