Interoperability. This is one of our industry’s most frequently used buzz words and a key objective we seem to want to associate with every IT implementation project.  However, when you’re thrown into the start (hopefully) or middle (usually) of an “interoperability project”, are you so consumed with the urge to “git-r-done”™ that you don’t take the time to critically evaluate the project documentation you’re handed?  Do you just assume that the due diligence necessary to validate approach and objectives for the project was completed?  Do you take the time to review what’s come before - before you go forward?

As consultants, we’ve all been there and have the scars to prove it. We’ve been charged with managing to a too tight  timeline, or working with clients who consider that the due diligence portion of the project “left the station” prior to our arrival, or we’re being tasked to clean up a project heading south that needs instant traction in a northern direction.  Assumptions are made, planning starts, implementation begins, and issues ensue.  Whatever the pressures, there is usually a good reason to examine the due diligence documentation to understand if the foundation undergirding the project you are about to grab the reins to still holds true.      

So, that leads us to the subject of this blog; Dotting i’s and Crossing t’s… What Are The Areas of Due Diligence for a Biomedical Device Interoperability Project?  Well, the short answer goes back to a rather well worn project management-ism … it depends. While not meant to be facetious and never meant to be a final answer, what needs to be evaluated really does depend on the nature of the project, previous work completed, and numerous other variables that should be taken into account.  What I will suggest is not meant to be an exhaustive list, as I am sure each of you could add an additional area or two based on your project experience.  However, I will suggest a core set of due diligence areas that should be reviewed before you take off running on your project.

Let’s begin by putting some boundaries or scope around my thoughts.  For the purpose of this discussion, I’ve listed below my idea of the goal, definition, and landscape of experience with interoperability associated with biomedical devices.

Interoperability Goal:  Bi-directional conveyance of data from multiple unrelated biomedical devices by electronic means to a specific recipient

Interoperability Definition:  Capability of automated data transmission without the need for manual involvement

Interoperability Landscape:  Infrastructure Readiness Assessment & Biomedical Device Inventory Capabilities

I will discuss each of the following in more detail in this blog and Part 2 to be published next week, but here’s the list of core areas to which due diligence must be applied for any successful device interoperability project.  

• Scope
• Data Elements
• Application Limitations
• Connectivity Strategy
• Policies/Constraints (inhibiting data flow)
• Positive Patient ID
• Connectivity Capabilities
• Connectivity Solution Assumptions
• Connectivity Time Frame

When I suggest we need to perform due diligence with regard to scope, what I’m suggesting is that before you move forward with a device interoperability project, you need to make sure you have identified the full complement of devices that are even capable of collecting data you might want to transmit and be filed into an electronic medical record (EMR) or other clinical information system (CIS).  What are the discrete data elements these biomedical devices can transmit? Are there upgrades needed to the firmware in the devices to make them capable for communication?   Are these standalone devices, or are they already networked as part of some proprietary system? Which departments in the hospital are using the biomedical devices that you want to integrate? Are these high, medium, or low acuity patient care areas? Are you going to focus on inpatient, outpatient, or emergency locations? Does any location provide additional challenges that need special attention, such as operating rooms, magnetic fields, x-ray use, etc?

A lot of times it seems that the scope of a device interoperability project starts and ends with the devices. By that I mean, a category of devices is selected to be integrated (usually starting with physiological monitors) in a particular care setting (critical care) and in a certain timeframe (when the clinical documentation/nurse charting application is to “go live”). Perhaps, I would like to suggest, the scope of a project should be based on how clinical workflow can best be improved in a particular area of the hospital by having device connectivity.  In any case, due diligence should be paid to understanding the scope of devices to be included in the project and the reasons for selecting that group – be it the ability to improve workflow or because its easiest to integrate data from a certain category of devices first.

By the time you work through these scope issues, you will have clarified the level of complexity of the interoperability project before you.  My short-hand reminder is that due diligence around scope is associated with three main items (the 3 Ds): Department, Devices, and Data. 

Data Elements:

We reviewed a little bit about defining the data elements associated with a device in the discussion of scope above.  However, here we want to look a little deeper into the comparison of what information can the biomedical devices send versus what piece of information does the clinical staff really want to obtain. It is important to ask these questions as part of your due diligence.

Does the data collected by the device that you want to place into the EMR need any type of manipulation or additional piece of information to be clinically useful to nurses and other care providers? Is there other device data such as settings, length of use, or device status that would be useful to be captured along with the actual clinical data to help with clinical decision making? 

Data is the ultimate deliverable in any interoperability project, and it’s all about getting it right… the right data, at the right time, for the right patient, delivered to the right location… to assist the clinical staff in making the right decisions.  I can’t emphasize enough that you need to apply due diligence to understanding what data should be collected and how it will be used when planning a device interoperability project.

Application Limitations:

This is a very broad topic, but what I’m suggesting here is that it is important to perform due diligence to understand if there are any processing limitations associated with the clinical or EMR application that could constrain in some manner how data collected by a medical device can populate that application.

Is there a limit to the number of interface connections that can be implemented, or is there additional cost that will be incurred for each connection or type of connection? Is there any limitation on how the HL7 messaging format is used for delivery to the EMR? Are there any clinical specialties that would require a 3^rd party solution of some kind to acquire the full complement of data required?  Are there any 3^rd party transaction limitations to prevent overburdening of the system to be considered?

The main goal for due diligence for this section is to make sure that you understand the constraints or limitations that a particular EMR solution might present to your project and allow you to prepare some contingency solutions that you can use to help facilitate your client’s decisions through this type of “gotcha” mine field, which many of us don’t find until well into project implementation.

Connectivity Strategy:

There are a few different types of connectivity strategies.  For example, there are integrated, interfaced, and mixed options.  An integrated system refers to a connectivity solution that uses all of one manufacturer’s components.  It provides modules or interface “slaving” to connect its device (usually a patient monitoring device) through a central station also manufactured by that vendor.  An interfaced strategy uses a 3^rd party solution (i.e., not the application or the device manufacturer) to accomplish connectivity. A mixed system is one where the hospital has both integrated and interfaced components as part of its connectivity strategy.

The best connectivity strategy (works best, costs less, etc.) is dependent on the biomedical device inventory in place. If all monitors in the inventory are by one manufacturer, then using that manufacturer’s integrated connectivity solutions might be best – at least for the first wave of device integration. If the goal is to optimize workflow in a patient care area and there is a hodge-podge of devices from different manufacturers, then an interface solution seems best.  Due diligence must be paid before making a decision as to connectivity strategy.

Okay, that’s enough for this blog. Stay tuned for next week’s conclusion when I’ll finish reviewing “that to which due diligence must be paid” in a medical device interoperability project.