Industry Focus – Enterprise Messaging in Healthcare, Part 1

The global focus on healthcare transformation over the past decade has brought focus to IT organization’s role in improving the quality, coverage and cost of providing care for patients. Enterprise Messaging within healthcare is a big topic as healthcare itself covers a huge area from an IT perspective. Using the UK’s NHS IT systems as an example, we can examine some of the messaging requirements in healthcare where a topic-based messaging appliance such as Solace may be used to help in their implementation.

Enterprise Messaging in healthcare has been principally leveraged as a mechanism for information sharing either in the form of system synchronization or real-time information distribution.  From a patient’s point of view, information sharing is particularly important. For example, a patient who visited different hospitals and specialists within a system using messaging based synchronization gets the benefit of collated and correlated clinical, medical and social information, so diagnosis can be more accurate and overall care can be of much higher quality.  Additional benefits can include reduction or elimination of repetitive tests and procedures.  Collectively these benefits can have a dramatic affect in accelerated diagnosis and overall cost reduction.

There are many ways of architecting a national healthcare system to achieve information sharing. In the UK, the backbone of providing patient information and shared services at the national level is called the Spine [1] and there are many applications from Local Service Providers (LSPs) connected to the Spine. The Spine is a part of the NHS National Program for IT (NPfIT), which aims provide “a single, centrally-mandated electronic care record for patients and to connect 30, 000 GP(s) to 300 hospitals, providing secure and audited access to these records by authorised health professionals” [2]. British Telecom is responsible for implementing the Spine, as well as the LSPs for the London cluster and South of England cluster.

To connect local applications to the Spine, the NHS IT authority – Connecting for Health (CfH), employed a loosely-coupled architecture based on messaging. LSP applications need to send different types of messages to the Spine requesting information and services. The Spine then returns information and services in the form of messages.  This project, spanning more than 10 years, has been claimed to be the largest civilian IT project in the world.

Message Handling Service

With such a big project and complex system in the Spine, where exactly in the architecture does a messaging appliance like Solace play a part?

Figure 1: MHS Interactions

To talk to the Spine, all applications need to do it via a Message Handling Service (MHS), of which its specification is defined by CfH. In fact, all senders and receivers of the Spine messages must implement an MHS. MHS is responsible to move messages between applications that request external services and applications that implement such services. For example, if an application from an LSP needs to find demographic information of a patient (such as name, address, date of birth, NHS number), it will need to send a message via the LSP’s MHS node to the Spine MHS node, and the Spine’s MHS node will route the message to its Person Demographic Service (PDS) to

process the request. The Spine will then return the patient demographic data to the LSP system via the Spine MHS. See Figure 1 for the MHS interactions, where LRS stands for Legitimate Relationship Service that is to make sure the requestor has the authorization to retrieve the patient data.

MHS is currently implemented as a software component that supports both HL7 and non-HL7 XML messages, and operates under either Web Service (synchronous) or ebXML (asynchronous, reliable) mode. HL7 messaging is very complex but hugely important for healthcare systems to talk to each other. It is used not only for conveying data but also invoking actions. However, message format is not what we should concern here. If Solace appliances are to be used to play a part in MHS, all HL7 or non-HL7 messages will be wrapped in message payloads. The question is, how much does the Solace SDK cover MHS functionalities?

Let’s look at the main tasks that an MHS is supposed to perform.

Figure 2: MHS Functional Components

• MHS Service Interface.  The abstract interface between the MHS and a system that is sending or receiving HL7 (via HL7 processor) or non-HL7 messages.
• Header processing. The creation and processingof (ebXML or web service) header elements.  This also includes the parsing of header elements, the interaction with contract properties, and the passing of elements to and from the message service interface.
• Message packaging.  All messages, HL7 or non-HL7, ebXML or web service, need to be wrapped in SOAP envelopes. This part is responsible for the building of the ebXML and web service envelopes, including the ebXML SOAP attachment structure.
• Routing.  Responsible making any routing and address mapping decisions required.
• Reliable messaging.  Responsible for the delivery and acknowledgement of reliable messages.  This component deals with persistence, retries, error notification, and acknowledgement of messages requiring reliable delivery.
• Transport Binding.  The abstract interface between the MHS and the various protocol stacks.
• The HL7 Processor is a logical component that may be external to MHS. It is responsible for marshalling and unmarshalling HL7 messages.

Figure 3: MHS with Solace SD

Based on what an MHS normally do, we can architect Solace into MHS, and partially replace the function of Routing, Reliable Messaging and Transport Binding.

Summary

There are still many details to be considered for the architecture to work efficiently and across other services that the Spine provides. For example,

1. How to utilise Solace’s topic routing strength to help the Spine to fan out to thousands of local applications and service requestors effortlessly?
2. The Spine is currently using SeeBeyond eGate with heavy customisation as the messaging gateway called TMS (Transaction Messaging Service). How efficient is TMS to receive thousands of guaranteed messages per second and fan out to the service providers on one hand and response to service requestors on the other?
3. Some Spine services such as PDS, LRS and PSIS (Personal Spine Information Service, delivers detailed patient clinical data), use HTTP but some others such SDS (Spine Directory Service, locating hospitals, doctors and nurses etc.) and SBS (Spine Security Broker) are just TCP/IP based protocol. How can Solace integrate with those services so Solace can provide a unified messaging platform for the Spine?

If the above questions are addressed, topic-based messaging platform will ease the development of MHS across thousands of healthcare systems, cut down the mounting cost of NHS IT program, and provide a solid scalable platform for better care for patients.

Let’s leave the discussion open and I will further elaborate this messaging solution in Part 2 of this blog. Watch this space.