The honest story about implementing openEHR as an EHR-vendor

New to openEHR?
1

Hi,
I am fairly new to the OpenEHR world, I got some training on managemet level from @Hanna_Pohjonen and Jan de Lange. And got a one day technical training from @sebastian.iancu (Code24) and Joost Holslag.
I have a long term relationship with one of my clients, a small EHR vendor (5 devs) that specializes in Youth Care and Mental Care. This client is thinking about completely overhauling their data model.
Key requirements:

  1. To become more flexible to be able to expand and evolve their EHR software
  2. To get a mature way of working with forms/ questionnaires

We are currently looking at OpenEHR. We are already convinced OpenEHR is really cool. But we also think that OpenEHR is rather complex. We are afraid it will cost us time, instead of save us time.

We are looking for developers and CTO’s of EHR-vendors that want to share their honest story about implementing OpenEHR in their software:
a. What were your expectations and did they come true?
b. What expected problems did you run into?
c. What unexpected problems did you run into?
d. What about performance?
e. How do you perceive your amount of freedom before and after implementing OpenEHR?
f. Are there any examples of EHR vendors that started implementing OpenEHR and aborted? What were their primary reasons to do so?

I would love to hear your thoughts! As comments to this thread, or during a nice cup of (online) coffee.

Thanks in advance!

3 Likes
2

Hi @jorritspee and welcome!

I’ll tell you a little bit of my story with openEHR. It started back in 2006 when I was a junior Java dev and was hired to implement this thing called openEHR (that was a bunch of specs that supposedly helped in some areas of EMR/EHR design). That was for a ICU EMR. Then I learned that healthcare information was complex, heterogeneous, non-structured, and very customized, which make it difficult to reuse. I also learned that reusing clinical data is basically the whole point of an EMR/EHR. Then, after studying the specs, testing @rong.chen Java Reference Implementation and tools, I realize openEHR actually solved some of those problems: 1. helps to standardize and share clinical data, 2. gives a blueprint for EHRs with long term longitudinal (life long) and and transversal (different orgs) data, 3. it changed the development paradigm by separating data from it’s definition (knowledge), 4. it was mainly about structured data.

After that I was very attracted by this new approach and continued to study the specs, get into the community more and more, and tried to apply openEHR principles in many projects.

Then in 2011 I had this idea of promoting openEHR in Latin America, so I thought of putting all my knowledge and experience into an online course. This course was the first online course 100% about openEHR in Spanish at that time and it was a success. This course has since then been offered early. But after 2-3 editions I realized I needed to show my students how to actually use openEHR in a working system (there were no open source openEHR clinical data repositories at that time), so I decided to create a very basic openEHR CDR that would be open source, just for my students to play with.

Then in 2013 I released the first version of EHRServer, the first open source openEHR CDR out there, and it actually server it’s purpose of training and having something to actually test openEHR principles. It had templates, EHRs, compositions and a very basic querying mechanism. This was maybe 4 months of work and one dev (me).

Then from the experience of designing and building EHRServer, I learned a lot about clinical data repositories, and decided also to put that knowledge and experience into a course on hoe to design and build openEHR clinical data repositories. One thing is you can build your own openEHR CDR for a specific purpose without implementing the whole openEHR specs.

Years went by and I had some clients in the openEHR area, mainly in EU, they tried to build their own openEHR platforms, and some failed, IMHO I think it was because they put technology and openEHR itself before having a business case. Is like pushing a solution that is trying to find a problem to solve.

For me, I think openEHR takes about 5 years to master, and it’s not a spec that organizations can just implement and everything will go well, there are many parts, and each part requires a certain set of skills, experience, and motivation, but all should be circumscribed to a business case, without that, a solution might not see the light.

My conclusions are:

  1. The first problem is not having people with the right knowledge, skill set and experience working in the project.
  2. A huge problem is not understanding the full scope of an EHR implementation, for instance, it’s not about openEHR components only (recently in a call with a client I explained different use cases and the architectural components needed, like a demographic repository, a terminology server, admission and scheduling, etc.) so understanding full scope is key, with or without openEHR.
  3. Not understanding the full scope and the problems openEHR solves s a huge risk. Recently I have seen marketing materials of openEHR that state it’s focused on data persistence, where the specs don’t say anything about persistence, so there is also misinformation around it, but you will find that around any spec out there.
  4. Performance is a tradeoff: openEHR adds kind of an abstraction layer over the data, which is standardized and defined based on knowledge elements (archetypes and templates), then the query formalisms are another abstraction layer over specific queries on a DBMS (for instance AQL needs to be transformed to SQL). That abstraction adds a lot of value, I can talk about this for hours, then things won’t perform as they were implemented natively just on code and database. Though there are many mechanisms to overcome this like preemptive caching and load balancing (there is no general solution since this should be analyzed case by case).
  5. In healthcare informatics “freedom” is kind of an anti-pattern, I mean if you can do whatever, you will do whatever, and that affects data reusability and accessibility. openEHR adds a methodology, that is very flexible, but is still a set f constraints. The nice thing is in the openEHR methodology you can do whatever you need to do in terms of data and records, so in that sense I prefer the word “flexible” than “freedom”. So the clinical modeling process is constrained, the data models should be based on the openEHR reference model, the information bits should be based on openEHR archetypes and full records and documents based on openEHR templates. But inside those you can do anything you need.
  6. The primary reasons for aborting or failing in the market I think are mentioned above: 1. not understanding what openEHR is for, 2. not having a business case, 3. an important thing I didn’t mention is you will have a big initial learning curve with openEHR, so that is also a risk (technically and strategically), 4. there could be a technical reason, for instance choosing an incorrect underlying implementation technology (I can tell you more in private).

Today I continue thinking openEHR is the way to go in EHR design and development, I’m still doing my courses, I think this approach should be known by professionals and companies even if they do not implement it at all. In fact recently I have finished developing the evolution of my initial EHRServer: https://atomik.app/

Hope that helps :slight_smile:

5 Likes
3

We are not an EHR vendor but have worked with a number of back-end vendors and front-end app developers over some years.

I think you really need to separate the question into 2 parts.

  1. Applications developers who use openEHR
  2. openEHR system developers - CDRs and tooling.

(1) is not really all that difficult at all, once you get past a few misconceptions.

(2) Is hard (especially performance) and I suspect @pablo is not far off in his 5-year journey, though with better documentation/training I would expect that now to be closer to 2 years.

I always advise existing EHR vendors to avoid developing their own CDR, even if they believe they have the in-house capacity to do so. There are several credible CDR alternatives, both open and closed source, with good implementations of AQL, REST API etc, and more coming along. It is IMO, much more sensible to get your devs up to speed as consumers of CDrs and tooling by using existing products. If nothing else you will be deploying re-platformed applications much faster and will start to see the value of openEHR, and giving your devs familiarity with the environment, If further down the line, you feel that you want to build a full CDR stack, your devs will find that much, much easier. I know of a company that did exactly that - it took them less than 12 months to develop an in-house CDr because they already understood the principles by spending some years as ‘consumers’.

So the question you should perhaps be asking IMO, is “Do we actually need to develop a full opnEHR stack, at least ‘right now’”?

4 Likes
4

It depends on what one understands from “master”, IMO 5 years to master openEHR is fair, since for me “mastering” this is: 1. understand the specs, at least RM, AOM and ADL. 2. be able to do modeling (archetypes, templates, terminology, using CKM, archetype editors/template designers, etc), 3. to be able to create programs following openEHR principles.

With education you can get a good understanding of the specs, and some modeling skills, but for good modeling skills and being able to build something from scratch, training is not enough, experience is needed.

So we should separate what “mastering” openEHR is, from what “using” openEHR is. Using is mainly understanding the specs and using stuff built by others (maybe the “masters”).

A fun note: I remember getting so obsessed about learning openEHR back in 2007-2008 that I printed out archetypes in ADL and took notes on the ADL on paper while checking the specs on the computer. It was difficult to do everything on the computer since I had only one 17" screen. Fun times!

1 Like
5

Hi Jorrit,

It was great to discuss openEHR with you a while ago! You posted some great questions - I imagine others in your position will have similar questions, so I will share our experience from CODE24 here as well - from my perspective as co-owner and architect at CODE24.

a.) What were your expectations and did they come true?

We started to implement the openEHR specification from the ground up when we established CODE24, back in 2011. This decision was already made based on 2–3 years experience with previous projects, with work based on openEHR technology and specifications. Expectations were that openEHR technology would help us to have a clean and a scalable backend system, based on international standards, to allow us rapid developments and integrations with other systems, as well as the ability to (re)use clinical knowledge captured in community-developed information models (archetypes).

Did it come true? Yes, initially it was a big investment to implement all specifications, but we managed eventually and it still serves its purpose, and made us grow into what is now CODE24. It also helped us to be more agile and quickly adopt new technologies like FHIR, or participate in NL-wide projects like MedMij - which we did not envision back in 2011.

We also expected that more vendors would come to understand the openEHR vision concerning health-data and patient centric systems, and that they would join this cause and adopt the specifications. Although this has improved over the years, starting from just a few implementations and vendors to a larger community nowadays, it is a slow process and did not yet come true completely in the way we thought it would 12 years ago.

b.) What expected problems did you run into?

In general, implementing a complex standard such as openEHR requires a certain dedication (focus) and experience. These are hard to gain directly, you need to build them and this requires time and patience - which we knew it upfront.

On the technical level, we knew it would be complex to build a query engine that scales enough and also allows the two-level modelling approach of openEHR. But we eventually found an architecture and various indexing and query optimizations that help us with this problem.

Problems around the speed of adoption of openEHR technology were also expected, because you’ll need other parties “speaking” openEHR for better interoperability - but luckily this is constantly improving, especially lately.

c.) What unexpected problems did you run into?

Over the years we bumped into multiple unexpected problems, but we always found solutions, often provided by the openEHR specifications or technology. We also contributed to the specification, sharing our experiences and findings with the community, and trying to promote it in future releases.

Some of the main unexpected problems were related to integrating and using non-clinical concepts in clinical focused applications: such as demographics or administrative concepts, resources or physical items (for the resource planner), or social care information.

Other problems were related to national standards or regulations that we had to comply with, and they did not go well with international standards - various information models and techniques, care process aspects, etc.

d.) What about performance?

The openEHR specifications do not mandate a specific physical or technical infrastructure, nor a specific implementation design. Therefore, the performance is also subjective to the vendor’s solution and their technology stack.

What we learned over the years is that performance is highly dependent on infrastructure, use cases and work-load, and efficiency of the application layer, or on functional requirements that have been (in)efficiently implemented. In general, from our perspective the performance is good, and we always see possibilities to optimize it even more. We never hear performance complaints from the end-users that work with our system.

e.) How do you perceive your amount of freedom before and after implementing openEHR?

CODE24 can not really answer this question - we don’t have a “before” moment. But we are very happy with the freedom we have now (“after”). With the openEHR archetypes and templates we have all the freedom and flexibility we need, and with the openEHR Reference Model we have the solid “technical layer” that we can freely use.

On the other hand, complying with the standard and with internationally published archetypes is sometimes limiting this freedom a bit. But we think it is for a good purpose, namely: interoperability.

f.) Are there any examples of EHR vendors that started implementing openEHR and aborted? What were their primary reasons to do so?

I cannot directly recall such vendors. If there were any, I imagine that the technological complexity may have played a role.

Another reason could have been that their customers were not directly asking for openEHR-based software, so vendors may be tempted to adopt other solutions that better serve their purposes.

2 Likes
6

That is a excellent point @Pablo.

There are really 3 kinds of implementer (and some do more than 1)

  1. Back-end CDR builders (persistence/querying/versioning)
  2. Tooling builders (ADL, AOM)
  3. Consumers (REST API and other service layers)

Increasingly (1) can be met with a choice of existing products. That was not the case for the pioneers like Ocean, Code24, Cabolabs and Better.

(2) is highly specialised, though the web template format has allowed hackers like me to contribute.

(3) is where the majority of ‘implementers’ will find themselves, and that is a whole lot easier space. The challenge there reflects the complexity of health data management, not of openEHR per-se. Even then it is quite easy top get going, the problem being knowing how best to architect a system for it to scale.

2 Likes