I have read with interest the recent blog post by Ewan Davies where he describes the meaning of open platform. Some people are viewing this now as EMR 2.0 and an implementation of the ideas from a recent article on this website, quoting Gartner as saying that there has been too much reliance on single vendor closed proprietary systems.

There are several reasons why this is important, and luckily it falls in line with a number of things that have been going on nationally at INTEROPen, and locally within University Hospital Southampton (UHS).

In case you did not know, UHS is an integrator model for EMR, and benefits from access to all, or most, of the data held in its systems. These are not necessarily implementations of the standards that Ewan talks about in his blog, but by using Integration Engine technology from Intersystems (there are others available as well), we are achieving success and hope to drive our vendors towards those standards.

We will also increasingly select vendors on the basis they can support open data and look to move away from those that cannot.

Data migration

So why do we want to do it?

Because if we continue to buy software from monolithic vendors who lock the data into proprietary and closed data models, we will be subject to whatever that vendor wishes to do or not to do.

At the end of the contract, data migration is such a complex task that it is, in fact, unachievable and the choices are very stark: either accept the vendor contract terms for renewal, or accept a very sub-optimal access to historic data should you move.

There are also some horrendous double running costs in the transition. None of this sits very well with the concept of lawful procurement and competition.

To be fair, until recently it would have been difficult to think of doing things in this open way as the database technology coupled with performance and information governance issues would make extremely challenging.  These are the reasons why the previous advice from the likes of Gartner was that if you wanted to achieve HIMSS level 7, there is only one way to do it: buy big.

Make no mistake however, it continues to be in the commercial interests of software vendors to build it big and build it proprietary. We have to battle against these forces to some extent. This battle will not be won unless it actually becomes in the interests of suppliers to work in this way, so we need to reach a tipping point.

How do we do it?

There are, it seems, two approaches to open data, from my perspective at any rate. There is the OpenEHR model which structures the underlying data in a common standard way using archetypes of clinical data modelling. As Ewan says in his article, these are typically commercial offerings that are not open source, but they do in theory allow you to move your data between vendors.

For most of us however, we will have what you might call legacy platforms where the data sits in a proprietary structure and the applications that run on that data require it to be so. This is where Health Level Seven (HL7) and Fast Health Interoperability Records (FHIR) come in, because they allow a vendor to open up that data by supporting standard plug-ins, or APIs (application programme interfaces).

If they have a FHIR interface that allows a new app vendor to use that data, both in a read and write way, then we can achieve openness without needing to port all of the data.

Where’s the catch

In fact, the monolithic vendors are not against going the open FHIR route, since they can use it as a way to suck more data into their proprietary platform, making it even more “valuable”, and this is something we must guard against.

I am therefore in favour of sitting an open platform alongside the proprietary ones –  to allow an exchange of data, and over time moving much more towards the open platform. It will be a challenge getting the EMR vendors to work like this.

Road to Nirvana

The lesson here is to not only support the standards, but have a clear vision of the architecture you want to support, and stick to that.  If we don’t do this, we will be left with bigger and bigger monolithic systems from a smaller and smaller vendor pool. That cannot be a good thing.

The good news is there is a path, and that OpenEHR and FHIR are different but not incompatible.

This is going to take strength in contractual negotiation and a clear vision that must be maintained. We as CIOs need to get behind it if it is going to work, otherwise we will be picked off by a supplier market that does obviously have at least some self-interest, and interest of shareholders at heart.

We may succeed, we may not but I think it is worth trying. If we do not, well whatever, nevermind.

Related Posts