Previously on this blog, we have had detailed discussions about healthcare IT infrastructure, how to monitor it, and how to keep track of workflows in hospitals or clinics. Something that came up in each of those discussions was the integration engine, and there’s a reason for that: to use an anatomical metaphor, it is the central nervous system of any medical infrastructure. In this post I take a closer look at what an integration engine is, what it does, and how to monitor it.
Any medical IT environment is made up of a hodgepodge of software, hardware, protocols and more. Take a look at this graphic:
What you can see is that there are modalities (imaging equipment) storing images to a Picture Archiving and Communication System (PACS). There is also a Radiology Information System (RIS), a Hospital Information System (HIS) and a Laboratory Information System (LIS). Quite often, these systems are provided by different software vendors. Additionally, there are medical protocols like Health Level 7 (HL7) and Digital Imaging Communications and Management (DICOM) in use.
So yes, I’d say that my usage of the word “hodgepodge” earlier was completely justified.
When there are so many disparate systems and protocols in use, it is impossible to get them to talk directly with one another. What you need is something in the middle. Something that integrates, so to speak. And thus, we have the integration engine.
The integration engine is the hub of the IT environment. It receives messages from different systems, modifies them into formats that can be understood by receiving systems, and subsequently distributes the messages. It does this using multiple formats, including HL7, DICOM, Fast Healthcare Interoperability Resources (FHIR) and HTTP-based requests.
The integration engine provides channels for this communication. Here’s an explanation from our Healthcare IT monitoring primer (available for download below):
The interfaces that receive and distribute messages are called “Channels” and these can be “Inbound” or “Outbound”. In most scenarios at least two channels are required, as the inbound channel receives data from a source system and the related outbound channel transmits the data to the target system. Most integration engines also support caching or saving messages that could not be sent due to network errors or problems on the target system.
The central nature of the integration engine means that if it is down, a lot of hospital workflows will be impacted. For this reason, monitoring it is essential. An unintended benefit of monitoring the integration engine is that you will also know the health of connected systems or devices.
Most vendors provide a REST API that you can use to query the health and status of an integration engine. Using this approach, you can monitor aspects like free memory, free disk space, CPU usage, and so on. You can often also get information about the various channels, such as the number of messages sent and received, messages in queues, and so on.
However, you should monitor the integration engine using monitoring software, and not just over the REST API. Why? Well, if the integration engine goes down, then the REST API might not be accessible, either. You need an external system keeping tabs on it.
You can monitor the same elements that you would using the REST API. The number of messages processed by each channel is a good metric. You can also check if there are errors contained in the messages. Furthermore, available memory of the integration engine server is important due to the number of messages that are likely passing through. And, if there’s a connected database, it would be good to know the read/write latency to the database.
Now that we’ve looked at the integration engine at a high level, in a future blog post we’ll give you a specific example of one, and demonstrate how to monitor it.
And if you’re an IT professional working with healthcare IT infrastructure, why not download our Monitoring Primer below. You’ll learn more about how to monitor many more aspects of the medical IT environment, such as the PACS, RIS, LIS, HIS, and other aspects.