Reflections on the Clinician-Centric Approach of openEHR and its impact on Software Engineering

Implementation
1

Dear community,

Over the past weeks, several discussions with our software development team have made me more aware of just how strongly clinician- and modeller-centric the openEHR ecosystem is. The openEHR website explicitly states that IT developers are not involved in content development, and when I look back at conference talks and community presentations, most are understandably focused on modelling, clinical use cases and other high-level concepts rather than the engineering side of implementing openEHR-based applications.

This is clearly a strength for clinical acceptance and for the quality of the models themselves. However, I’m increasingly wondering whether the same focus might make things harder for engineers who need to build production systems on top of these models.

A few concrete issues our team has run into:

  • A template may look clean and elegant in Archetype Designer, but the resulting compositions easily become multi-thousand-line JSON objects that are difficult to construct programmatically in a type-safe and maintainable way. Many small differences between CDR implementations of Better and EHRbase do not make the job easier.

  • Web templates and FLAT compositions do help, but FLAT feels like it lives at the edge of the specifications. For example, the contribution endpoint doesn’t appear to support FLAT at all. This creates uncertainty for us: is it safe to rely on FLAT long-term if it’s not uniformly defined across endpoints and implementations?

  • Our tech stack is TypeScript-based. As far as we can tell, many openEHR tools and SDKs that simplify development are Java-centric, leaving us without a clear path toward a well-supported developer experience.

This raises a question for the community: How are teams who are further along in building production-grade openEHR systems handling these challenges?
Are others running into the same kinds of issues, or is there something our engineers are missing in their approach? Would there be interest in opportunities for exchange specifically on a software-engineering level, not just modelling? Our engineers would be very happy if people with more experience in these areas were willing to share their wisdom.

I’d really appreciate hearing how others have navigated this space.

6 Likes
2

TypeScript is a logical pick for a frontend focused openEHR development. I picked Dart for my tools which is less logical :sweat_smile: (unless Flutter is used for the frontend)

Last year I started porting my tools to TypeScript: TypeScript library for AM / RM / OPTs

What is your approach? Did you use the OpenAPI generator or do you write your tools by hand? I know @gmickel is a great fan of AI coding. Were you successful using AI agents to write your tools?

3 Likes
3

Hi, I think the openEHR ride is different for every individual and company, it also has to do with current experience and mental models of “how things should be done” or “what’s good and not so good”. I was lucky when I started with openEHR, I was very green on both areas and gave openEHR a try back in 2006. In a couple of months in, I realized the complexities behind it’s implementation, but understood the real problem it tried to solve, and that wasn’t an engineering one, it was a clinical one, though it generated challenges for the engineering/technical side of things, but those challenges where really side effects of current engineering processes that didn’t fit how healthcare worked. In other words: we can’t develop software for healthcare like we do for e-commerce or accounting.

On your first issue, if your team worked with any other standard, like HL7 v2.x, CDA, FHIR or DICOM, you will realize those structures are big and difficult to construct programmatically. It also has to do on how software is structured, since some approaches might be better than others, like we use a lot of dynamic programming languages to handle complexity instead of, for instance, Java, so we have the same functionality with less code. One note: if you are constructing JSONs directly, that might not be the right approach. A better way is to construct RM objects then use a generic serializer to JSON or whatever format.

On your third issue, 20 years ago there were no libraries in any language available to work with openEHR. Individuals and companies created them out of necessity, in whatever technology they were working on at the time, and later shared them with the community which also contributed to test and improve. This was a completely open source approach and was growing organically and still does. In general if you want a “well supported developer experience” you need to pay someone to do that for your team or follow the same path as others and build your own stuff, and if you want open source it. So I think this isn’t an issue of the community but it’s about your expectations from it and the conflicts/frustrations it generates to you.

On your main question, I would say teams do what I explained: they build what they need to build at the infrastructure level then build on top, hopefully automating a lot of stuff. Personally, I needed to build my own tools to support RM, serialization and parsing GitHub - CaboLabs/openEHR-SDK: Java/Groovy Support of openEHR Operational Templates, Reference Model, Data Generators and other tools for www.CaboLabs.com projects, I also build 3 different openEHR repositories (including the first open source openEHR CDR GitHub - ppazos/cabolabs-ehrserver: Open platform to manage and share standardized clinical data, designed by @ppazos at CaboLabs Health Informatics. ), iterating and improving them, now after some years I have a product (https://atomik.app/), and also build something to help me with common tasks when working with archetypes and templates, like generating composition samples from templates automatically: https://toolkit.cabolabs.com/

It’s a complex problem, there will be challenges, has a learning curve, but you will get there!

3 Likes
4

Thanks for your comments, I’m a SE myself and had similar problems.

  1. The differences are something we have to clean up, and vendors also need to be pushed to clean this up. This can take time. In regards of specification problems please forward this to the specification board !
    I know myself that I had some small flavors (fixed now btw), but none of which i felt so far really stopped me from developing software supporting both.
    What small differences between Vita and Better are you talking about, I work with both platforms regularly, could you maybe point these out ?
    For the standard openEHR API i dont have any problems so far (apart from FLAT more about it down below).
    I don’t see the size of the JSON as a problem; it’s normal since it contains complex content.
    Technicians should not fear technical abstractions :wink:
    The structure overhead can be dealt with in FLAT or structured formats.
    I personally prefer canonical since the other formats miss technical details, and FLATs are not language independent, if you build an frontend on German FLATs, they won’t work for English ones, since the JSONpaths change.
    I use it mostly for AI or as export for our data scientists.

  2. Regarding the FLAT format: we are currently cleaning this up and specifying it. We are aware of the problem, and it’s being solved right now.

  3. TypeScript is a frontend language. Everyone would definetly love if there would be some TypeScript lib provided by Cistec, looking forward to it :slight_smile: Archie and the openEHRSDK are more used in the backend context (which where also implemented and released by vendors) + see @borut.jures comment.

Some general points:
We as a community definitely need to improve both the tooling for developers and the specification itself.
The accessability is not as good as it should be.
This is why HIGHmed, developed/funded many open-source tools (including the initial ehrbase and the initial openEHRSDK in a collaboration with VITA).
We as a community are also currently reworking the specification to make it more accessible, but there’s a lot to do and manpower is sparse.
I think Cistec should consider having somebody in the specifications team as a vendor, so issues can be addressed directly and help with this improvements.

In general, openEHR is a do-ocracy :slight_smile: If there are actual problems, address them in the community. If you feel the need to tackle something, feel free to form a workgroup together with the spec. I was in the same position as you and did (and doing it) exactly that successfully on several occassions :slight_smile:

In regards of the software engineers, what exchange are you thinking about specifically ?
For me i would really like to have some specific points like the FLAT you mentioned, cause this is stuff that need to be addressed then.
Maybe also some suggestions what can be improve etc.

7 Likes
5

Thanks for your thoughtful comments so far!
In general it is good to know that other people were in similar situations. And of course we are not expecting that perfectly established tools are send by email for us to use :smiley: It can be reassuring that developing our own set of tooling for implementing openEHR is part of the process, and we are not going down the wrong rabbit hole. We will try to publish as much as possible open-source!

I will keep an eye out for more concrete examples when our developers raise an issue. Maybe I will also be able to get them to contribute here directly, instead of me attempting to convey technical difficulties, of which I understand only parts myself :sweat_smile:

5 Likes
6

Thanks so much if you need any input or help let me know !
Maybe if it would be possible @HHeiser talk with the devs maybe we could get a list of potential improvements/stuff that is not well aligned and work on that together.

I will keep an eye out for more concrete examples when our developers raise an issue. Maybe I will also be able to get them to contribute here directly, instead of me attempting to convey technical difficulties, of which I understand only parts myself :sweat_smile:

Yeah, it’s typical that you fix it internally and then forget about it.
I’m guilty of that too, lol.
Also, check internally if there is interest in getting involved in the specification team :slight_smile:

1 Like
7

The nice thing is that you can choose the strategy there: build all infrastructure in-house or fully reuse whatever is out there in any technology (as a black-box service) or anything in between.

I would recommend any startup to just use whatever is out there, even if it’s in a technology they don’t know, since in 10 minutes with an AI assistant you can have a working tool ready to be used. But I don’t know what’s your company situation and maybe you are more advanced into product building.

All the best,
Pablo.

1 Like
8

@HHeiser looking around I have found there is a developer facing page on the openEHR website, though some links might help get someone started, I doubt the contents really help any developer do practical things Developer ecosystem – openehr.org

I’m wondering if on the openEHR side there is any plan to actually create more developer facing content (technical content), or if that is delegated to specific vendors.

3 Likes