The Challenge of e-Health for IT

Developing effective and economic IT solutions for e-health has proven very difficult over some decades, although the general needs are easy to grasp:

semantic interoperability within and across enterprises;
semantic interoperability between layers of functionality within a system;
being able to compute intelligently on the data;
being able to directly support team-based, long-running clinical processes.

The question of interoperability across enterprises is no longer just a question of sharing lab results or even moving a patient record when the patient moves; today it is about being able to aggregate all the data of the patient, no matter where created, so as to employ analytics for personalised and preventative medicine.

Various universal difficulties are well-known: massive data diversity, and a high rate of change in workflows, clinical protocols, and data definitions. There problems mean that conventional IT methods cannot be used.

At a practical level, other problems conspire within the health provider context to prevent easy improvements:

rogue clinical DBs: the main EMR solution rarely supports the data richness actually required by clinicians – it is well known that many hospitals contain dozens if not hundreds of hidden specialist’s databases, often referred to as the 'Access Database problem';
changeover costs: the incoherence of current environments and huge data volumes, coupled with the need for 24x365 availability typically paralyse management for years, until the current system becomes untenable, and a new massively expensive monolithic purchase is made, to restart the cycle of constant failure;
no one vendor is big enough to produce all the functionality needed in a healthcare enterprise, and they will never be able to do so, due to the wide variation in business processes across enterprises, jurisdictions, and particularly across countries;
prohibitive integration costs turn seemingly attractive 'best-of-breed' procurements into a financial nightmare;
big bang procure and deploy disasters: no enterprise can afford to logistically deploy a new monolitic solution in one go, so it makes little sense to do the procurement that way;
data lock-in: big vendors do not publish their data models, and make it difficult for data produced by the enterprise to be re-used.

In summary, the two problems that must be overcome to make IT successful in healthcare are: semantic complexity of the problem space and logistic complexity of the work environment.

The open Platform as a Paradigm

Existing major products in healthcare are monolithic private data siloes, often blocking users from working effectively with patient-centric data. The future is solution components obeying openly published specifications, produced by an eco-system of plug-and-play vendors. By freeing data to move through enterprises and products, we free the business.

An open health computing platform, based on open, integrated specifications for incrementally deployable components is the key to getting value from IT in healthcare.

Naive conceptions of 'platform' must be avoided:

a platform isn’t the same thing as a list of standards;
a platform is not just a set of APIs - it also requires information models, models of domain content and process and solid underlying formalisms;
a platform is a process, not a product;
a platform cannot be designed by a committee;
a platform must be efficient for developers to use.

An open platform consists of freely published information models, domain semantic models and APIs. The keys to moving to a platform in e-health are as follows:

semantic model architecture: formalisms and knowledge models of the problem space; information and process models for the work context;
a map of the components of the platform, since these are the unit of specification.

The open Platform Economy

A good platform must be specified and maintained by the industry it serves. If it does this well, the result will be a platform economy of plug-and-play vendors competing on quality rather than lock-in. This will of course take time, and will be different to the current health IT environment in one crucial aspect: the interfaces, information models and knowledge definitions that define the platform components are known to the customer organisation, and used as requirements to which vendors must comply. This puts the customer and user community in the driving seat operationally and financially.

Semantic Architecture

An open platform defines coarse-grained components whose semantics need to be defined in such a way that:

fully model domain information as well as work environment processes;
separate domain modelling from IT development, and make domain models runtime-deployable;
single-source modelling: ensure domain models are defined independently of technology, including OS, DB, message and document formats, but can be machine converted to the required forms.

Achieving these outcomes requires an advanced approach to models used in the components:

domain-level formal languages and tools in which information and work processes can be flexibly modelled;
a continuous delivery factory approach to managing domain modelling by domain professionals;
multi-level modelling, with distinct layers for persistable data, domain data groups, domain data-sets, domain process plans, UI/UX precursors;
underpinning of semantics with ontologies, including BFO, RO, IAO and others;
each platform component should be architected as a model-execution engine.

Process Orientation

In healthcare working environments, work is done in terms of goal-oriented processes, designed to respond to an endless stream of real-world events, from customer requests to changes in a patient's heart rate. To make IT support processes in health, we need to formalise two things:

models of ideal process - known as Care Pathways and Guidelines in healthcare;
models of patient-specific Work Plans - based on Care Pathways where available.

This requires modelling of plans of processes, tasks, and data-sets as first-order domain artefacts for deployment in an plan execution engine that supports human workflow rather than trying to replace it. Process models require a formalism, which is a significant challenge in healthcare not satisfiable by deterministic approaches such as BPMN. The openEHR Task Planning formalism, based on advanced industry work such as YAWL as well as our long-term involvement in the Activity-Based Design (ABD) project at Intermountain Healthcare provides an alternative.

Taming e-Health Standards

Standards in e-Health have had a chequered history, with limited success beyond HL7v2 messages historically (and still) used for lab results and prescriptions. Twenty years involvement has led us to certain conclusions:

ad hoc collections of standards do not work together - significant costs are involved, and integration may not be economically achievable;
standards designed by committees are of poor quality and should be avoided;
the only way to create standards that work together is to design them together, as a platform;
avoid standards that are not published with formal expressions and an open source implementation.