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  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” . 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?
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.
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.
There are still many details to be considered for the architecture to work efficiently and across other services that the Spine provides. For example,
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.