Necessary clarification: Please note that the term implementation in the text below refers to development of a software platform based on openEHR. I realised that the term is overloaded in the health IT space, implying adoption of a standard sometimes. That is not what I mean by ‘implementation’.

Recently, I found myself in more than one discussion during which I was trying to explain what openEHR is to someone. It is common to adopt a different explanation of key concepts based on the occupation of the audience. The modelling side of things matter most to clinicians and policy makers and we talk in different terms than a conversation between software developers, architects etc.

The openEHR mail lists also reflect this natural distinction; there is technical, modelling, implementers etc.. I think I’ve realised something though, we end up having technical conversations with clinicians and implementation discussions with software developers. There is nothing wrong with it of course but I think the openness of the standard (it is in the name after all) is causing some problems in its adoption. This post is meant to express my thoughts about this pattern and it may or may not help you when you’re trying to understand some aspects of openEHR.

Since openEHR web site provides access to specifications and there are free modeling tools available to everyone, the introduction to openEHR has no barriers. Great, exactly what is needed. You can also access the discussion lists where implementation and technical issues are discussed. The implicit idea is that people should access resources that would be helpful and relevant for them.

Since openEHR focuses very strongly on giving the clinician control of what clinical information is going to be represented and processed, most people initially focus on model development, core concepts such as archetypes, templates etc.. Thanks to freely available tools such as the archetype editor and template designer, along with the models in the public CKM instance it is possible to get a good understanding in an acceptable amount of time which depends on your familiarity with the core EHR and information system concepts.

It gets harder after that. The natural flow of learning is to start with the models, archetypes etc and then move on to using these models for actual software development. This is where people begin to cross a threshold that marks harder territory ahead. There is still nothing wrong with this of course, you’re free to work on anything you want.

However, even if you’re a software developer who is tasked with developing a piece of software that uses openEHR to some extend, you may still be trying to get your head around something that you may not necessarily need to deal with. The single most important fact you should acknowledge is the following:

openEHR implementation is a large piece of work, it is hard and it is complicated.

This does not mean that openEHR is hard and complicated. There is such an important difference between the first and the second statements, the latter being a blanket statement that covers everything related to openEHR.

The key difference between the two statements is implementation. If you’re implementing openEHR, you’re looking at a real challenge. It is the challenge that exists in every project that aims to make complicated things easy and accessible. openEHR is designed to deliver computable health by letting clinicians define concepts and the rest should happen in a streamlined fashion. It does not end there though, the software developer is also supposed to be able to build the software that is based on the concepts defined by clinician in the same manner; it should be easy. Making this happen is hard, really hard.

It is the reason there are openEHR vendors out there. The easier you want to make something complicated, the harder your job is. Someone has to build a conceptual vault of some sort that will lock the complexity in. As much as I hate Apple analogies, I can’t avoid them sometimes: it is just like the iPhone and iPad line of products. Swiping with your finger is simply amazing in terms of interaction with a computer. No mouse, no keyboard, the screen is all you need. So simple. That simplicity has enourmous research and technology behind it that has cost Apple a lot of money. Apple does not put out its design specs for its products online, they don’t even give you a user guide. The simplicity and design around it is so good, you’re just supposed to be able to use it and it works as intended. Very impressive.

You don’t find users speculating about the way Apple’s cpu in iPhone works, you don’t even see most developers of applications (apps as we call them now) speculate about inner details of the platform (some do but they’re a lot less than the group who simply uses the platform and tools as provided by Apple)

openEHR does not do the same. It lets everyone access all that is available. There is a distinction, an attempt to address different groups of people, clinicians, developers, implementers but no barriers. The result is, people end up confused. The answer to “how do I use this?” becomes unclear. Especially software developers begin to think about actual platform implementation and the inevitable conclusion arises: “openEHR is hard” It would indeed be hard if you try to do it all.

It would be hard to use SQL if you had to implement a relational database just to use SQL. The archetype query language (AQL) is easy to learn, implementing a server that supports it is hard. Easy to use technology requires other people doing complicated things. Complexity acts like energy sometimes, you can transform it but you can’t simply make it disappear.

This is what openEHR vendors do. This is what Ocean Informatics has spend millions of pounds/dollars/yens/liras for (choose your currency as you see fit). Vendors, openEHR implementers give clinicians and software developers tools to make things easy for them. Developing those tools, those platforms is hard work, it is complicated, it takes people with skills and a lot of effort.

If you’re finding openEHR hard, please ask yourself the following question: “what aspect of this really large ecosystem I’m finding hard?”. Is it something for which someone already has an offering? Are you really sure that the complicated task belongs to you?

When I make these points, I usually get the looks that I gave to people at times when they tell me that I should not worry about the inner workings of something and use what is available. I don’t always like it, I want to understand it completely and maybe build my own solution for the problem I’m trying to solve. This is OK, it is OK for you to think like me, but acknowledging that building something is hard does not always mean it is something you have to do to use it. With openEHR, you’re free to do it, but it will cost you.

You’re absolutely free to step outside of your organisational roles, we all have one of those. Go ahead and build a whole stack of software if you want to but don’t underestimate the task ahead. If it is hard, well, there is a reason for that as I’ve written above.

If you’re finding something hard and there is nothing there that makes it easy, no offering from anyone, that means we have something to discuss; a point which we can improve to make things better in an openEHR ecosystem.

So next time you find yourself resorting to blanket statements such as openEHR is hard, please consider the possibility that you may be reaching into somebody else’s speciality. You’re free to do so, but you’ll pay the same price that they’ve paid.