How to make interoperability with medical equipment possible

At Ingenious, we've been building medical software for 8+ years. We have written our fair share of code in the Healthcare industry, from custom EMRs and EHRs to digital imaging software for helping surgeons conduct surgeries.

Whenever clients ask me about the challenges of building such solutions, I say that building software is the "simple part", while interoperability with medical equipment is the "nearly impossible one".

Why is interoperability so hard?

• As medical equipment needs to be battle-tested, whatever already works will likely be unchanged unless necessary. Communication ports and technologies are one of those things that already work.
• Development teams rarely get equipment for testing purposes. Nobody has a spare ultrasound machine or a blood analyzer they can send for a month or two for engineers to play with it.

For all these reasons, it's tough to change the status quo. Companies that have already developed their integrations won't be sharing how (because it's tough). Vendors prefer to innovate in other areas rather than helping newcomers interact with their equipment because that means supporting users that are not paying customers.

Still, interoperability with medical equipment is possible. Here's what you need to know to interface with Ultrasound Machines (DICOM) and Blood Analyzers (ASTM).

DICOM - Ultrasound Machines & CT Scanners

Ultrasound machines and other imaging equipment have a network interface where they can push data to your servers using (S)FTP.

Data will come in the form of a DICOM file, and while the format is standard and there are many libraries to explore it, each device will store data in different attributes.

Building a server that can handle multiple machines from several clinics needs some normalization and probably implementing a DICOM Modality Work List to avoid retyping patient information at the workstation.

ASTM - Blood Analyzers

Blood Analyzers are more complex to interface with as the equipment needs to establish a conversation with your server to perform the work.

Blood Analyzers don't have a network interface but a serial (RS232) port to which they write data. Usually, clinics connect a small box (Lantronix) to this port in charge of translating serial data into TCP/IP packages to a given IP and port.

The data you receive on your server is ASTM. ASTM defines a standard that works as a low-level protocol specifying how to chunk and decode messages and as a high-level protocol defining what data goes where within the ASTM message.

Unlike DICOM files that can be received without a response from your server, blood analyzers will require your server to engage in a conversation. It will first query your server for the different tests it needs to run on each sample, and minutes (or hours) later, it will resume connection with the results.

Conclusions

In my experience building ASTM and DICOM servers, ASTM is the toughest to get right. The sole nature of the conversational protocol makes it hard to test as you need to book time with a real machine and either move to the facility or have somebody at the clinic that can help you conduct tests.

DICOM and MWL are more straightforward as many tools already handle the lower-level protocol, and your job consists in reading the files and applying the needed business logic.

In any case, equipment interoperability is one of the challenging parts of building software for the Healthcare industry, so if you are planning on doing so and need some help, please drop me a line, and I'll be happy to help.