A question came up on the Biomed Listserv the other day about Philips' new VM line of low acuity patient monitors (press release). The initial comment noted that the new VM line looked pretty impressive (it does), is HL7 ready, and questioned whether Philips OEMs the monitors or makes them themselves (they are Philips designed and made at a Philips plant in China). Given the innovative nature of this new line of patient monitors, I thought you, my gentle readers, might find it of interest.

I got a download on the new Philips VM line at AAMI. To my knowledge, this is the first line of medical devices that directly outputs HL7 from the device. Previously, medical devices output a proprietary protocol over a wireless or wired network to a server that converts the data to HL7. The server in turn "talks" to the other side of the HL7 interface, your EMR. The server also aggregates data feeds from multiple devices into one interface to an EMR or some other information system.The HL7 standard has (too) many configuration options and a high degree of variability in how it is implemented from vendor to vendor. Consequently, the state of the art for HL7 interfaces is a table driven interface that supports variations like data element labels, field lengths, and the ability to enable or disable individual fields in the interface. Some interfaces also support multiple versions of HL7. A table driven interface provides the necessary (at least up to this point) variability to integrate with the widest variety of other vendor's HL7 interfaces. The bottom line: to date, HL7 is not a "plug and play" interface.

According to the Philips engineers I talked to at AAMI, the VM line outputs a fixed HL7 data stream through the Ethernet port on the back of the monitor. From what I learned, there is no table driven configuration of the HL7 output. (The fact that low acuity patient monitors targeting patients that are at least somewhat ambulatory doesn't have wireless connectivity is a topic for another time.)

In a perfect world, the host side of the HL7 interface (there are always two sides - the device and the host) can be configured to support the Philips VM implementation of HL7. Your world may be less than perfect - painful even if your host can't configure to match Philips' implementation of HL7.

The direct HL7-out from the device, static nature of the interface, and absence of any table configuration utility makes the Philips VM HL7 implementation radical. If anyone can pull this off, Philips can; as the largest patient monitoring vendor they swing a lot of weight. Also the HL7 standard has been around a long time and has perhaps matured to the point where a non-configurable interface will work. Time will tell.

I'm sure many on the list would be interested in hearing from biomeds who've implemented the HL7 interfaces on the VM monitors, as well as more info from someone at Philips.

Evolving HL7 to a truly plug and play interface is good thing - I would recommend monitoring vendors duplicate Philip's HL7 implementation - there's no good reason not to, and several good reasons to do it. A lot of the variability in standards like HL7 is simply vendors who insist on including some quirk that they have already implemented (and don't want to spend the NRE to change), or have some misguided notion that their implementation of HL7 is "better" because it's different.

If you're buying VM patient monitors and expect to integrate them with some electronic charting application (and who isn't within the life of a new patient monitor?) best make sure your host system will support the Philips VM implementation - before you buy.

UPDATE: Conversations with Philips at the 2008 HIMSS conference indicated that the HL7 interface on the VM line of patient monitors is configurable.  It was not clear whether configurability was added since the introduction in 2006, or was there all along.