Interoperability

Integrating disparate computer systems into the NHS

Integrating disparate computer systems into the NHS is a very important factor in achieving cost-effective information systems for healthcare. These disparities come from a number of sources, for example:

• scope and purpose of clinical and supporting information systems, for example lab, radiology, patient administration;
• scope and purpose of ICT systems and technologies, for example network infrastructures, data storage, mobile platforms and medical devices;
• age and integration-readiness of the installed base, the so-called 'legacy systems problem', including co-existence of successive generations of technology (for example there is still a good amount of pre-Internet technology in daily use); and
• ICT system vendors old and new, who have necessarily made specific technology choices and may also be competing on the basis of those choices.

So, plurality of many kinds is a given, and the question is how to cope with it. A the time of writing, I have just returned from an HL7 international Working Group Meeting, where several cross-cutting themes were emerging clearly as key coping strategies.

What is your integration paradigm?

This question has attracted considerable attention in the HL7 international standards organization over the last couple of years, and whether or not you use HL7 standards, their emerging answer is interesting.

Three complementary high-level patterns — paradigms — for integration have been identified, nicknamed the 'three legged stool' of healthcare information systems integration:

Documents: in this pattern, the unit of integration is a clinical document. Such a document is intended as an entire clinical communication in its own right, containing:

1. human readable information, ensuring that a minimally capable receiving system can make its content available to a human reader in a safe way;
2. identifying information for the patient that is the subject of the clinical document, together with other key administrative information such as the identity of the healthcare practitioners involved in the care described in the document; and
3. optionally, structured coded information such as SNOMED CT coding for the care events, diagnoses etc described.

Messages: in this pattern, the unit of integration is an interaction, an exchange of messages between systems playing defined roles in response to a trigger situation. The content of these messages is defined to suit the interaction, and messages range from simple parameter-based queries to complex structures of clinical information.

Services: in this pattern, the unit of integration is a 'service', a chunk of business functionality supported by a related set of interfaces (organizing a whole enterprise’s information systems architecture in this way is becoming increasingly popular, under the buzzword 'Service Oriented Architecture' (SOA)). Typically, such interfaces are initially “wrapped” around existing systems, making the interface independent of the underlying system and so enabling easier replacement of existing systems provided that the interfaces can be sustained.

The point of the 'three-legged stool' saying is that these three concepts are at this time not so much competing but complementary strategies (though they can compete in a specific context), and that in general different situations call for different technical solutions.

Healthcare information can be very long-lived and heavily re-used, and so needs to be able to travel not only across specific interfaces, but potentially across many generations of technology and between a number of regional and local systems. What the “three legged stool” picture conveys clearly to me is that clinical information, even when standardized, still needs to be able to fly through disparate technology “airspaces” in a way that does not destroy or confuse its intended meaning.

Datatypes and common information models

There is a growing repertoire of technologies available to effect data migration and integration between systems, but achieving meaningful sharing of information, especially clinical information, is still a difficult challenge.

Harmonized standards for datatypes

The most basic issue in practice is the ability to convert data at all between two formats. Even with the cleverest tools, conversion cannot work safely if required information is just not there or is represented so differently that no safe conversion is possible.

An early achievement of the still relatively new CEN ISO HL7 Joint Initiative has been the establishment of a harmonized repertoire of abstract datatypes, an early pioneer now following the path to formal joint standardization after completion of the major substantive work.
Even if they did nothing else, two disparate systems that each respected this standard would be able to send and receive data faithfully. Without this capability the higher aims of full meaningful information exchange do not have a chance.

Common information models

Beyond faithful transmission of data, meaningful sharing of information presupposes a common understanding of both content and context. Explicit representation of context is one of the aims of the clinical document paradigm outlined above – the other paradigms depend to a greater or lesser extent on implicit context, and full representation of context remains something of a visionary “holy grail” for clinical systems integration.

Achieving common understanding of content, in contrast, is by now the subject of concerted standardization effort at a number of levels. The NHS Data Dictionary stands as an early significant effort of this kind (also covering datatypes); recent examples in the UK include:

• Scotland: definition of a repertoire of common information components for healthcare information, used for example in the Emergency Care Summary.
• England: development of a common set of information components (“templates”) used across >10 kinds of clinical documents defined in the Connecting for Health Messaging Implementation Manual.

More recently, an international effort has started to develop standardised healthcare information components, intended to underpin future development of standards. The Clinical Interoperability Council is chartered to develop “a process whereby a master set of data elements with their attributes will be defined, using a common process and a common set of attributes. The attributes will include a name (terminology), a unique and unambiguous definition, units, data type and complete value sets”.

The CIC intends to sustain “an informal relationship with all clinical professional societies, including the international community, interested institutes of health, and other professional organizations with interested in clinical data standards content and use” thus ensuring that its output is clinically driven and independent of technology-specific and vendor-specific interests.

Nowadays each healthcare information system vendor has no choice but to develop their own information model, and the disparities between these are an inevitable barrier to interoperability. We can hope that as the work of the CIC comes to fruition, increasingly there will be standardized information components that can be used as a configuration input across disparate information systems, ensuring that when information is shared between them, there will be less technical pain and, more important, less risk of subtle errors affecting patient safety.

Ann Wrightson, CSW Group.