Developing effective and economic IT solutions for e-health has proven very difficult over some decades, although the general needs are easy to grasp:
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:
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.
Despite having some good applications, existing major products in healthcare are often monolithic private data siloes, often blocking users from working effectively with patient-centric data. Building a health IT environment to serve patients properly requires data services (EHR, demographics, process tracking etc) that are independent of products and enterprises. This can be achieved using a platform eco-system containing components that obey 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:
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:
A successfull platform will 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 application quality rather than data 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.
More on the platform paradigm:
An open platform defines coarse-grained components whose semantics need to be defined in such a way that:
Achieving these outcomes requires an advanced approach to models used in the components:
More on semantic architecture:
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:
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.
The ultimate goal in modelling process is not just to model individual plans, but to formally model Care Pathways. This provides the path from Evidence-Based Medicine clinical knowledge (best practice in complex cases) - currently published as PDFs or web pages - to a machine-based ability to represent and convert pathways for 'model patients' to actionable plans for individuals.
More on the process orientation:
Standards in e-Health have had a chequered history, with limited success beyond HL7v2 messages historically (and still) used for lab results and prescriptions. Even in mainstream IT, UML is falling out of use, because its committee-design prevents it from functioning properly in full-cycle modelling tools. Twenty years' involvement with de jure standards has led us to certain conclusions:
However, there is a larger problem with respect to e-Health standards: lack of coverage. Historically, health IT standards have been defined to control data, but have failed to address domain semantics. Consequently, even successful implementations of message or document standards have failed to achieve semantic interoperability of health information across enterprises and systems.
More on standards in e-Health: