The NHS has around one million employees and serves most people in England and Wales. We could easily imagine a slightly larger organisation serving the whole UK, although for historical reasons Scotland and Northern Ireland are separate. Another large public healthcare organisation is the US Veteran’s Administration, which manages around 160 veterans hospitals and countless clinics in the US. Brazil has an organisation called SUS – the universal healthcare system – which provides public sector care for 160m people not on private care. Smaller countries have similar, generally large, organisations, at least by the standards of each country. Large private organisations such as Kaiser Permanente and Partners Healthcare are in the same position, with the same needs.

There has been an endless search by such organisations over the 25 years I have been involved in e-health for the silver bullet to solve their IT challenge.

The silver bullet psychology comes into play because they recognise it is a very difficult challenge, one so vast it usually feels overwhelming. When looking into the abyss, the human psyche functions in a magical or religious mode. And IT in healthcare is an abyss: it isn’t just about computerisation of lab results or invoices, it is a global enterprise memory system for clinical and administrative records, models of best practice, and increasingly, a source of intelligent decision support for its workers. There is probably no more knowledge- and information-rich or dependent domain than healthcare.

IT in healthcare is not just about solutions either – i.e. applications, databases and so on. It is, or should be, about understanding a very complex problem space. The data are complex, the cognitive process of professional workers is complex, medical science continually generates new results, and everything is interlinked.

Anyone who knows anything about engineering for complexity knows that silver bullet thinking has no place. There simply is no magical solution available for informatising health, or any other complex domain. Only patient, careful study of the problem space and equally patient study of paradigms and strategies, and finally doing good engineering will bring results. Such work that ideally involves clinical, administrative and engineering professional working together.

It would certainly be nice if there were a silver bullet available – the lack of a coherent approach has led to thousands of incompatible IT systems and products being installed across provider institutions and clinics across the sector, and then trillions of dollars spent on trying to make them work together. Which they mostly don’t.

The strategy adopted by most healthcare provider organisations to solve the information challenge has been primarily to assume that nothing can be done about all these non-interoperable systems and products, and that all we can do is try to make them talk to each other – after all, they have been engineered to have their own conceptual schemas, private languages and data models. The touchstone here is ‘interoperability’ and it has become a silver bullet in the minds of those who decide plans and procurement within the giant healthcare institutions on which most of us rely. (I’ve made some previous comments on the religion of interoperability, concluding that without a common computable ‘language of healthcare’, no real progress will be made).

The way ‘interoperability’ is realised is via ‘standards’. And so the general approach for large healthcare organisations is to go shopping for standards, on the assumption that if they make the right choices, do a bit of local customisation, local industry and vendors of procured products will create all the necessary interoperability magic. This was the basis of the NHS National Programme for IT (NPfIT), an epic failure by any objective cost/benefit analysis (e.g. this one). The various huge programs in the US did not fare much better.

The reality of standards is far different from their promise. Nearly all e-health standards are highly self-inconsistent (due to design-by-committee) and mutually incoherent (due to lack of a platform vision in industry + political motivations of SDOs). Much more on this here (from 2009), and still largely true today.

Is there an alternative? Well, clearly we need an information technology environment that has internal standardisation of relevant elements (information models, languages etc). But this is an abstract characteristic of such an environment, not something you can retrospectively engineer on top of the 90% mess below the waterline. How do we actually build such a thing?

Firstly we need to understand what it is that needs to be built. The short answer is an adaptive computing platform for the organisation, something I discussed at length here. Do we need a ‘platform’ for each organisation? Well clearly many of the semantics of healthcare are very similar across organisations, so many elements of a platform should be common internationally. However, there is much that is specific to the NHS, VA, Brazil’s SUS, Kaiser or any other such large provider.

My view today, after 25 years of working in and observing the e-health space is that any large organisation has to devise its own platform, i.e. a single coherent information architecture. Naturally they don’t want to have to literally develop it all (or even much) from scratch, but they do need to do non-trivial work to source and integrate scientifically developed and proven architectural elements (models, languages, methods, processes etc) to create the organisational platform. Some things they need to develop on their own (at least clinical models of information and process). The resulting architecture needs to be completely coherent at all levels: typing, languages, tooling, semantics, or it will just be a recipe for endless chaos.

If such a platform existed in the NHS, all developers would just be working either on different parts of it, or on applications that use it. Every little discovery by a developer would have a place to be recorded and add to the platform. Commercially procured systems would have to obey its APIs, data standards, query languages, and be driven by its clinical models.

In this approach, interoperability and standardisation are outcomes, not the permanent, expensive, non-scaling activities they are today.

So much for the ‘what’. The real question is the ‘how’: how does an organisation like the NHS achieve a health computing platform for its whole, complex operation?

My conclusion is that it should create its own R&D arm – the equivalent of a small university – that takes seriously the need to understand the problem domain, and that develops the technical capabilities to pursue the numerous clinical and engineering R&D activities that are needed to come up with a computing platform to serve its workers and patients. Most of the disciplines found at any technical university are implicated in e-health, including philosophy (epistemology, ontology, logic, Bayes, …), mathematics, statistics, biology (cellular, genomics, proteomics, …), clinical medicine, systems design, electrical engineering, software engineering, computer science, psychology of socio-technical systems, and economics. Most of these disciplines would exist in their ‘applied’ form, something conspiciously weak in mainstream universities. Establishing such an institution within or very close to the large organisations doing healthcare would provide one crucial condition for proper learning: direct and permanent access to the object of study, and the object of change.

In this view, the ‘platform’ is no longer a product: it is an edifice of knowledge, learning, and methods: a permanent process that generates solutions based on common foundational knowledge.

Many would find the suggestion that a university, or something like it, is needed to solve e-health, as over the top. I would argue that this simply reflects the true scale of the unsolved problem, and the low probability that today’s limited horizon thinking will make any difference. We need to think big.