A strange thing happens in health IT solution procurement, and by extension government initiatives that seek to influence it. See if you can disagree with the following characterisation of health provider organisations as solution purchasers.

Think You’re Getting What You Want?

CIOs and CMOs have known for years if not decades that:

• the data used inside their institution are their most important asset – either as a productive resource, or at least as an object of risk management. Most today would understand it as both.
• the data used inside their institution is not all produced inside their institution – lab data often comes from external lab companies; they obtain or would like to obtain GP data such as medications lists, problem lists and so on;
• their main vendor solution never supports the data richness actually required by clinicians – it is well known for example that most hospitals contain dozens if not hundreds of hidden specialist’s databases, often referred to as the ‘Access Database problem’;
• if they want to switch to a new vendor, the changeover costs related to the data alone are massive and the risks so great that this consideration alone paralyses them for years with the current ineffective solution;
• no one vendor can produce all the functionality they require – even the biggest vendor has a ‘roadmap’ containing numerous features the provider wants today; no large procurement doesn’t involve significant and horribly expensive ‘customisation’;
• they cannot possibly afford to buy all the functionality they require in one go – if they wrote down the full wish list and then published a tender for it with an open budget, the resulting price tag would undoubtedly be beyond their means;
• procurement of multiple ‘best-of-breed’ solutions for e.g. inpatient, ER, ambulatory etc, come with huge ongoing cost for data and workflow integration;
• they cannot possibly afford logistically to deploy all the functionality they want in one go – the human costs and challenges of change management not to mention solution integration make this impossible;
• asking for even the smallest change to the data schema or core functionality costs inordinate amounts of money and usually a long wait as well;
• it would be nice if their IT department could have access to ‘their’ data, but of course they can’t, not without the vendor’s say so and price tag.

I could make this list a lot longer. It doesn’t have to be this way, and yet daily we see published tenders effectively asking for a ‘complete solution’ across all main departments and functions of the hospital or clinic.  Worse, national agencies, although starting to talk about ‘open’ things like ‘open source’, ‘open interfaces’ and so on, don’t seem to realise what they really need to do to change things.

Giving Away Control

First of all, what’s wrong with buying either best-of-breed or enterprise solutions from the big vendors? After all, having a contract with just one ‘reliable’ vendor is very seductive. Well, it depends. If you as the purchaser only set requirements at the functional level, you are essentially giving away control to the vendor. You might contractually oblige certain functions to be available by certain dates (and we know how well that works in reality), but you’ve lost control over:

• the data – your main asset
• the standards that apply to the data
• the interfaces that you need to connect the data to applications and other systems

In fact, what you have done is to invest in the vendor’s way of doing things, which includes locking you in to their vision – the reverse of what you should be doing. I would go so far as to say that when a purchase like this is signed off, you have taken the first step to an expensive modern legacy solution that will cost you 5-10 years of progress.

Before I go any further, let me say that I have no intention here to indulge in ‘big-vendor bashing’ as is sometimes the fashion among some open platform evangelists. Big companies can do good things as well as bad. Today, they don’t provide platform solutions because providers don’t ask for them. They will however, if providers change their behaviour. Big vendors will always do what the market wants, and can do it well. My message is to providers and government: it’s your turn to get your act together. Don’t blame the incumbents. Start saying what it is you really want.

Going the Platform Route

As discussed in my last post, we need to be doing health IT on the basis of open platforms – i.e. published data standards, published content standards and published APIs – all independent of vendor products. For procurers, these are the control points you need to retain, and use as compliance tools.

Now, hospital trusts and other health provision organisations might say: but where are the platform-based solutions I need? Indeed, you won’t find your wish list out there as a product, and certainly not available via a single procurement. Not yet anyway. That’s because the market needs help to transition from its current form to a platform ecosystem form.

In any case, buyers need to stop thinking of holistic solutions as products, and think instead of the ‘solution’ as a platform-based process unfolding in time, in which they mandate the standards used, and are able to incrementally buy or build each new piece following financial ability and clinical priority.

In the future – a future we have not yet created – successful ‘procurement’ could take the following form:

• the procurer mandates the platform required, in terms of integrated standards for data, APIs, workflows, knowledge resources and so on;
• the procurer describes some of the key functions required, but treats the problem of creating final functionality as a joint effort with the contractor, in order to take proper account of hidden difficulties of clinical workflows, change management and so on;
• the responding contractors will be a new kind of solution integrator, who embraces platform standards, and does the technical work of obtaining and connecting the specific applications and services needed by the provider.

Central Funding Needs

To get to such a world, the ‘commons problem’ of the platform needs to be solved, at least partially, by government agencies, since it is unrealistic and undesirable for every hospital group and GP organisation to come up with their own platform definition. As described in my last post, the platform itself must be regarded as a process, not a product, and therefore requires a ‘standards factory’ approach, typically at national or even pan-national level.

So funding of technical aspects of platform development by experts in the field is needed. There are many good ingredients already available from which to create a larger health computing platform, so I believe this is doable. Strangely however, funding in both the private and public spheres seems mostly to be concentrated on apps. Unfortunately, this won’t solve the platform need, and may well make things worse, since it will cause proliferation of different local data ‘standards’, APIs and so on.

What Procurement Needs: Roadmap Tools

This won’t be enough however. For a healthcare provider to embark on a procurement that is going to lead to a platform-based future, they are going to need some tools. The main tool they need is a way of developing a procurement roadmap, that consists of a series of purchases of needed items over time. If we think about any current large provider IT environment, there is the usual mess of dozens of non-communicating systems, limited ability to use or reuse data outside of the original applications that came with the incumbent solutions.

The only possible way out of this involves bringing in a platform infrastructure incrementally. Some of the early deployments on a provider’s roadmap would be:

• key back-end data services, including standards-based EHR, demographics;
• key knowledge services providing access to terminologies, clinical content models, computerised guidelines etc;
• data bridges from the existing EMR systems to these new services;
• establish some APIs for accessing a few key types of clinical data, e.g. medications list, problems list, allergies list

It will take some time for such deployments to provide business value. But there are possible ways value can be provided quickly, but only if it is done in a coordinated way with the help of government agencies. For example, bringing in problem and medications lists in structured form from GP systems has immediate value in a hospital. If a standard health data platform is assumed, then this particular integration problem only has to be solved once for each GP vendor, or even fewer times, if GP vendors use any common standards. In the UK, they do (e.g. openHR, GP2GP). If each hospital trust in the UK were to solve this problem on its own, it will be expensive and inefficient. However, a large part of the solution, including data conversion specifications could be developed once and published for use in each environment, enabling relatively quick implementation of a local solution in each place.

Over time, the roadmap will start to include more business level services, e.g. clinical workflow tools, and applications, e.g. patient pathway, care plan management and so on. The platform-based infrastructure will grow up in and around the existing solutions, which may continue for some years. Slowly, the important data will be siphoned out of each private data silo into the open data environment, and will become available for use by standard API based applications.

This whole process for a provider organisation could easily take a decade. Functional value will be added incrementally, with some pain along the way. However, the overall strategic value after some years will be of a new kind compared to the past: the provider will eventually have control over its own data, its IT platform as a compliance specification for purchasing, and will be largely free of vendor lock-in.

What Can Be Done Now?

What would I change right now? Here are some ideas:

• governments and large companies should start funding a technical platform definition effort properly. Being obsessed with ‘apps’ won’t solve this.
• government agencies need to start building procurement tools for providers to use in the future
• government agencies need to consider creating libraries of transition artefacts to enable re-use of transitional solutions, e.g. the GP to hospital data connection described above
• provider organisations need to lobby the relevant federal department or body to do these things
• providers need to start thinking in terms of a 10-year platform transition plan, and stop dreaming of big solutions that solve everything – buying these prevents progress in the market and you are funding the vendor’s product vision rather than getting your real needs solved.

In the UK, the ‘Safer Wards, Safer Hospitals’ Fund needs to be reviewed. In its current form, the money will be spent on trust-specific applications, with little progress made on platform.

Some of the corporate-led efforts in the US may run the same danger.

In my view, we have 10 years ahead of us to make the open platform ecosystem a reality. It’s only going to happen if central agencies start taking the platform as a technical and economic concept seriously, start to understand it, and start to fund the transition.