As of end of 2018, I’ve been working on openEHR for almost 15 years, beginning with my exposure to openEHR archetypes during a European Union research project, around 2003 or so.

During these fifteen years, I tried to explain my (sometimes incorrect at the time) understanding of openEHR to many people who occupied various positions: junior software developers, product managers, general managers, investors, academics, ministers of health, marketing professionals. It would be a long list.

Looking back, I can see that I have not been able to articulate some key points clearly when I was talking to policy makers. That is, people who get to cast a vote or make a decision when it comes to choosing how to use technology in healthcare.

This post is an attempt to focus on aspects of openEHR that are relevant to policy makers, but it should be of interest to many people in other roles since we’re all affected by the decisions of policy makers as patients, if not as people in other roles in healthcare(IT).

I also aim to address some misunderstandings, though some of my attempted clarifications will be based on a subjective view of openEHR.

Let’s set the context first. As of today, we have a health IT market that favours big software vendors in both primary and secondary care settings. There are many factors that led to this setting and there are many that keep it as it is. I won’t go into those in length here, as interesting as that discussion may be.

When setting the scene for my arguments in favour of openEHR, I accept this reality. I know we have big vendors at the moment and I think they’re here to stay, mainly because in a free market economy healthcare behaves a lot like airline industry: dynamics of economies of scale kick in when you’re supposed to provide support for a hospital information system running across 15 hospitals with a total of ten thousand beds.

The second reality I accept is that in this free market economy, firms will do exactly what the nature of the firm dictates: maximise their profits. I leave it at that, no moral judgement, no opinions. This is simply a fact we all live with. Policy makers have to operate in this setting, though based on how healthcare is viewed in a particular country, i.e. as a basic human right or a privilege, they should have the necessary instruments to regulate the firms at some level and therefore attempt to deliver better outcomes for all of us, patients.

I suggest that openEHR is a good policy instrument that can fit into our reality. Its role, as I see it, is to keep competition in place as healthcare and healthcare IT moves forward. What makes such such a role necessary? The broken procurement model we have at the moment.

As things stand, most procurement models create a market where competition takes place prior to procurement but it ceases to exist effectively following the procurement. Prior to procurement, there is competition between firms of all sizes but once the decision is made, especially for a comprehensive solution such as a hospital information system or a GP system, the dynamics change.

Adopting a new system has a significant, sometimes huge cost for a healthcare provider. Some of this cost is hard to measure: we can come up with monetary metrics based on the hours nurses, clinicians and administrative staff spent learning the new system but can we come up with a metric that lets us measure the cost in terms of actual health of patients, who during the adoption phase may have access to fewer number of nurses or clinicians? Can we measure the efficiency lost as installation of or transition to a new system causes clinicians to search for check boxes on the screen or make calls to figure out where the functionality they’re looking for is? Not easy is it?

Administrators and policy makers know this very well. So do the vendors. Therefore, post-procurement dynamics is entirely different. When things go wrong after the procurement, it is not easy to figure out why they went wrong and who is responsible for it because all stakeholders have an explanation. This makes it hard to use fines as a risk management tool for the policy makers.

If you think about it, pretty much all that is available to policy makers for managing risk is financial checks, certification checks etc. and fines. Fines of all shapes and sizes, which no one wants to use because they don’t solve problems.  Due to enormous complexity and intangible costs of migrating between systems, both providers and policy makers do their best and try to live with what they have, trying to avoid contractual lose-lose situations.

A second aspect of post-procurement setting that is hard to estimate is extensions to the system. Sure, policy makers can ask for guarantees and clearly defined costs for changes that may emerge but the problem is there is a category of changes no one can predict.

Say, for whatever purposes a department wants to collect some clinical data they did not collect before and they also want to have report and build forecasts based on this data. This requirement may emerge due to changes in the practice of medicine itself or due to a new national/regional policy. All parties are now in uncharted territory. The vendor can come up with a cost based on the previously stated rate, if there is one, but the size of the work may simply make the extension unaffordable.

This is how feral applications are born. Clinicians and sometimes administrators have a need but they do not have the budget to buy it, so they build it in house. These feral apps usually contain very valuable tacit know-how, since they’re built directly by the clinicians but they lack technical capability and scalability. It is also very hard to share them or reuse them because clinicians or in-house teams are not usually interested in becoming software vendors.

Please note that these problems do not necessarily emerge because the vendor is leveraging their position and charging high rates. Having worked at large vendors for years, I know that sometimes the underlying technology or architectural choices or simply lack of experience in a particular clinical domain makes it really expensive to extend an existing solution.

The factor that is no longer in the equation post-procurement, the factor that could be used to address the problems I stated above is competition. It is how free markets operate (with varying degrees of regulation). Our problem is that beyond the procurement, there is no real competition.

It is not possible for a small and specialised SME to step in and develop the extension that the clinicians are asking for, simply because the vendor owns the product and they are under no obligation to provide access to their system internals or their IP to third parties.

Therefore, we end up with a healthcare IT market which makes it very hard for SMEs to pass the procurement threshold and compete with large vendors within the providers’ boundaries in terms of cost and innovation. We have a post-procurement bubble in which the provider and those who passed the procurement threshold have to live with each other.

Speaking of innovation, lack of competition in the post-procurement provider means that vendors who make it into the bubble are now unintentional gatekeepers to innovation. Clinicians or in house teams worried that their good ideas may simply turn into resellable IP for the vendor again choose to go on their own way, delivering more feral applications.

An openEHR based computing platform solves these conundrums by introducing competition beyond post-procurement. Such a platform is the missing tool for risk management (and more) in the tool belt of policy makers.

Let me try to provide some real life scenarios that shows how openEHR can be used as a policy tool.

Procurement makes it mandatory for vendors to support standards based APIs for accessing clinical and non-clinical data. HL7 FHIR is the strongest candidate for this purpose at the moment.

When a requirement to develop new functionality emerges, like the data collection/reporting extension I mentioned above, we now have multiple options. The provider can choose to go with the vendor. They can go with an in-house team developing an openEHR based application, which talks to existing systems using FHIR, or they can bring in a specialised SME who will develop the openEHR application.

There is a huge difference between this setting and what I discussed before. In this setting, clinicians and in-house teams use a health computing platform to develop their own solutions which eliminates the problems of feral apps. All the technical challenges are handled by the underlying platform, which can be proprietary or open source.

The resulting application and innovation belongs to the provider alone and it can be used beyond its point of origin much, much easier since it runs on the platform. Sure, it would require customisations but a standard computing platform means that there is a common lingo for developing applications and expertise can be shared and disseminated across providers since openEHR allows all applications to be developed based on a ubiquitous clinical language. Sunk costs of a feral application are replaced with reusable, transferable knowledge and skills.

SMEs are now free to enter the bubble by offering solutions, training and education targeting the health computing platform, which connects to vendor solutions via messaging standards such as FHIR. Which gives everyone more options for collaboration; in-house team working with an SME. SME reselling and supporting in-house team’s application across the healthcare market, targeting the underlying platform.

This, ladies and gentlemen, is your innovation strategy that is based on introducing competition without introducing risk into the provider’s post-procurement bubble. This strategy allows healthcare providers to become innovators and competitors on their own.

This approach does not require the vendors to commit anything beyond the messaging APIs, most of which already claim to support. It allows policy makers to go with big vendors without unintentionally blocking the SMEs. It allows the providers to compete with the vendors directly, to develop in-house know-how without having to acquire extremely specialised technical skills, which is provided by openEHR platform implementations.

It is not a revolution, it is a roadmap for evolution via which new solutions and service models emerge. Nothing stops vendors with large technical staff from offering hardware or private-cloud support for the health computing platform or developing solutions on the health computing platform themselves, in case a vendor is bound by technical limitations of its existing software, as I mentioned above.

An openEHR based health computing platform is therefore a critical risk management and innovation infrastructure. Like all infrastructure that creates economic value, such as telephone lines, electricity, railways, it is a prime candidate for national or regional programmes to put in place. By supporting the adoption of a health computing platform, policy makers can help create a new kind of eco-system. Open source or proprietary, these are all choices left to adopters and no single choice or technology defines the platform or the eco-system on its own. It is all about flexibility.

You can find a lot of information on openEHR if you visit the openEHR foundation’s web site, I won’t go into details of it to explain why it is a good choice for the purposes given above. A few points are worth making though.

openEHR is designed to build systems. It is envisioned, designed and improved through decades to allow developing clinical systems. It defines semantics of storing clinical data, accessing and querying it and developing applications on top of it. It is created to provide a health computing platform. It also includes sharing data between different openEHR implementations within its scope but this is not its primary use case. It works well with existing standards from HL7, IHTSDO etc.

openEHR has been tested in real life and it has delivered. You will hear people say that it is an academic exercise, something that is not used or when used, it would require you to throw away all of your investment and replace it overnight with openEHR based versions of everything.

These are all incorrect statements. openEHR, as a clinical systems development platform, have been running critical systems for years. If you go to openEHR.org, you’ll see various impressive real life projects, managing the clinical data of millions of patients, using openEHR platforms implemented by different vendors (see the whitepaper). Therefore, openEHR is the right policy tool and platform choice for the model I suggested above.

Finally, I’ll repeat my core arguments. We need competition beyond procurement to unlock innovation and create better health IT solutions. A health computing platform based on openEHR can be the missing policy tool we need and it can be introduced with zero disruption and relatively very little cost, especially with support from national and regional programmes.

openEHR community is diverse and it is possible that some of them may not agree with my suggestions but many would be willing to help and discuss. So just let us know if you have any questions or comments. I’d be equally happy to be corrected on anything I’ve written above.