Interprocess Communication

Posted by Martin P in Development, IHE      No comments

Oct
28

Any system as complex as RIS/PACS is inevitably made up of a number of elements.
RIS elements will include:

• HL7/IHE interfacing for registration, scheduling, and order notification and trnsmission.
• Independent scheduling (i.e. independent of HIS/PAS)
• Independent registration
• Worklist generation
• Dictation system integration
• Transcription management

… amongst others

In the case of PACS these may include:

• A DICOM services module
• A Storage management module
• HL7/IHE interfacing
• Worklist generation
• Image viewing (simple)
• Image viewing (advanced visualisation)
• Security management

….and many others

We’ll evolve this list & flesh it out in other posts on this blog.

One way to implement these elements is to generate a monster monolithic lump of software that does everything.  While some vendors choose to go in that direction (largely, to be fair, due to decisions made in the dim and distant past), from a software engineering perpective, that is self-destructive.  Even in proprietary software development, it is long appreciated that development teams should be kept modest in size.  In community-driven Open Source software there simply is no alternative but to provide features in self-contained modular units that small community teams can maintain.

Many of those modules will want to communicate with each other, or indeed with a central marshalling point, for a number of information transfers.  To avoid having to implement periodic polling (a heinous practice but unfortunately inevitable in many cases) , for example, the DICOM services may need to pre-emptively notify the image viewing modules that a new image/series/study is available.  In this example, the communication is almost certainly across different physical machines.

Equally, the modules themselves may be implemented via different technologies.  Technologies anticipated which may need to be involved in message transfer include Java, C#/CLR, PHP, Javascript, and likely others.

It is clearly beneficial to minimise the number of different mechanisms involved, and we are aspiring in the initial instance to a single mechanism.  We have enough experience in the crucible of real-world development to accept that ambitious aspirations sometimes fall by the wayside, and we are ready to adapt if necessary.

We have noted above that the requirements for messaging include cross-technology and both local and remote.  There is one other which we are considering a core requirement, and that is cross-application.  We believe that one (if not THE one) reason why healthcare applications have poor penetration globally is that they do not talk to each other very well. While HL7 messaging has become mainstream (and crucially so), ‘mainstream’ has only really happened since the turn of the century.  But end users do not get to see HL7 messaging – it happens in the background.  End users see RIS/PACS/LAB/PAS/HIS/ED/ICU et al sat on their desktop and each one must be logged into seperately.  Each time the patient view changes – the same patient must be found in each application.  This raises a risk that two applications on one desktop are focussed on different patients – and that simply has to be an invitation for mistakes.  How many times have tests/procedures been ordered for the wrong patient because the orderer didn’t notice the patient context in two applications is different?  I’ll bet it happens, and it shouldn’t.

It shouldn’t because its dangerous, but mostly it shouldn’t because it needn’t. The HL7 CCOW protocol is specifically designed to prevent (mostly) this scenario, but CCOW takeup is even slower than HL7 messaging.  I believe and have for some years that CCOW is one of the keys to IT truly working for Heathcare and we consider full CCOW support to be non-negotiable.  Of course that does not help with the other applications on the desktop, but I believe that in time CCOW will make its presence felt (despite the vendors).

CCOW comes with two mechanisms built in – ActiveX and HTTP. Disregarding ActiveX immediately as platform specific, we are left with HTTP. The question we have wrestled with is:

Can we use HTTP generally as a mechanism for IPC and specifically, build on the CCOW protocol to provide all of our messaging needs?

In fact it doesn’t take much scratching the surface to decide that the answer is no.  There are a number of scenarios with are not suited to the CCOW standard at all – specifically those involved in generating lists, or arrays of information.  But using the HTTP protocol as a transport layer, there are other higher-level layers that are specifically designed to fulfill those needs – XML and JSON being two in particular.  Of those, it is generally recognised (IMHO) that JSON is the more suited for regularised data transfer.

So for the moment, our plan is to use HTTP as a transport layer, with data-specific protocols layered over – certainly CCOW and JSON should see a good start to communication requirements and we can be prepared to add to that catalogue if necessary.  That means that each of the modules must have a embedded HTTP server serving at least those interfaces necessary for York.  In one sense that creates a complication but if we can keep the interface definitions simple (as, indeed, CCOW is once one  works out how to read the documentation), then the goal of modularity is made simpler.