As a follow on the post EMR Adoption and Medical Device Connectivity, let’s look at connectivity basics and market requirements. We’ll cover some of the basics here, and explore actual connectivity solutions and the state of the art in subsequent posts.

Medical device connectivity has 3 basic components. At minimum, devices themselves must be able to export data. The next component is some sort of software that converts the device’s communications protocol into something that can talk to the target system (for this post, an EMR). Finally, the target system must have the ability to “talk to” or receive data from external systems.

Most current medical devices, and the vast majority of legacy devices, use a serial port to export data. Newer products typically use USB (universal serial bus) connectors that provide a standardized hardware interface. Older devices use some sort of serial D-connector with various pin-outs (the “pin-out” is the assignment of specific electronic signals to specific conductors or pins in the connector). Unfortunately, the pin-outs on medical devices are highly variable, frequently requiring different versions of cables that must be paired with the different connector pin-outs of devices. In some cases, use of the wrong cable can damage equipment.

The next high level piece of the device/EMR integration puzzle is software that translates data from the device to the EMR. The format of data coming out of medical devices is in a proprietary format, a format that can vary between vendors, between products from the same vendor, and even vary between different versions of the same product. The various device protocols need to be converted to some common format that can then be formatted into a format that can be understood by the EMR. This common format can be a health care specific format like HL7, or a computer industry standard like pdf files, comma delimited files or some flavor of XML. The particular standard is less important that the ability of both the conversion software and what the EMR or target system can understand.

Finally, the target system (EMR) must have the ability to receive data from external systems. This ability is usually a software module or option that supports device and other types of interfaces.

So, now we have 3 basic requirements for connectivity: device output, translation software, and the target system’s ability to receive data. We’ll talk about various ways to implement these 3 requirements in following posts.

Market segmentation has a big impact in how this type of connectivity is implemented. Market requirements vary based on the types of target systems and IT resources that are available. Hospitals have extensive IT resources that include programmers and a variety of technicians. Many other health care providers have little or no on-site IT resources, which obviously impacts their ability to implement and support connectivity.

Given the above, the connectivity market can be segmented into two key markets: hospitals who have IT departments, and everyone else who doesn’t. The folks without an IT department include physician practices (except perhaps for the very largest practices), outpatient diagnostic and surgery centers, and some ambulatory clinics. Frequently these segments are called acute and sub acute markets, but other terms are also used.

In house IT departments can obviously provide installation and ongoing support for an interface that is not available in sites without IT resources – this has a big impact on how connectivity is delivered to customer. Subsequent posts will focus on market requirements for each segment separately.