In last week’s blog we began our discussion about the areas that require due diligence before plunging into a medical device interoperability project. We set, for the subject of this blog, the following definitions:
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

We also identified the following as the “core set” of due diligence areas. (Items in italics were discussed last week.)
•    Scope
•    Data Elements
•    Application Limitations
•    Connectivity Strategy
•    Policies/Constraints Inhibiting Data Flow
•    Positive Patient ID
•    Connectivity Capabilities
•    Connectivity Solution Assumptions
•    Connectivity Time Frame

For this week’s blog we will continue reviewing the areas highlighted with bold text. If you look back at last week’s list, you will see that those items focus on the “what” of a project - devices, data, specific applications and the strategy to pull all that together. This week’s grouping is more focused on the “where” of a project and how your project must live and interact within the larger digital environment or landscape in the hospital. So, let’s continue with … areas to which due diligence must be paid.     
 
Policies/Constraints Inhibiting Data Flow:
The focus here is on the general environment in which device data will “live”. This will require spending time with the IT Department to determine if there are any current policies that will need to be reviewed and/or adjusted for the biomedical devices to be connected within the hospital’s network.  As a general rule and based on the age of the equipment, biomedical devices are not yet as “networking savvy” as their pure, networking counterparts. So items like VLAN segregation, DHCP, resource group assignments, port restrictions or minimizing SNMP will need to be reviewed and discussed with IT specialists and the IT Governance Group for resolution.

If that last sentence made your eyes glaze over or your head hurt, like it usually does mine – don’t worry. I have found that hospital IT Departments are becoming more and more familiar with working with and balancing the needs for biomedical device data safety and security with access and flow. The key here is to get them involved upfront and actively engaged to author the required solutions.

Positive Patient ID:
For the purpose of this discussion, I will be hitting only the highlights of this topic, as it could be a much broader and probably is a blog or two in and of itself. The two options for positive patient ID boil down to direct and indirect. While the most common method currently used is indirect, the goal is to have direct positive patient ID. A lot of effort is being placed in this area by several different vendors in the industry.  

In the indirect method, two pieces of data are used for verification. The bed location is used as a “surrogate” for true patient identification information, and the measurement data coming from the biomedical equipment is associated with the bed – and subsequently, with the patient that is currently assigned to that bed. So, for you techies out there, the bed location information in PV1 of the HL7 message contains the measurement data for the patient assigned to that location (i.e., John Doe is registered to bed ICU-04, so HL7 messages from ICU-04 are filed in John Doe’s EMR file).  

The goal for positive patient ID is to provide additional data elements that can be inserted into PID segments of the HL7 messages at the device integration level – maybe using a bar code scanner or other device to ID the patient and not use the bed location as a surrogate. This will add an additional verification data point.

Knowing and understanding the patient ID strategy will allow you to determine the complexity of the project and guide solutions or decisions for other areas of the project based on this framework.

Information to Determine Connectivity Capabilities:
You need to be concerned with your biomedical devices and their capability for connectivity and communication. I approach this by gathering different data elements about each device in a spreadsheet. This allows you to do some analysis on the capabilities for each of the device types. The type of information you would gather would include:
Network Capability – Yes or No
Wired or Wireless – Yes or No
Wired Physical Connection – DB9, DB22, RJ45, etc
Wireless Protocol – Bluetooth, 802.112, other
Transport Protocol – RS232, TCPIP, other
Data Protocol – Proprietary, 11073 General, other
This data could also be included in a medical equipment management system to track this information and assist in the long term biomedical equipment replacement strategy of the hospital. In the short term, this information will provide the foundation for your connectivity strategy and determine the type of hardware infrastructure you will need to put together for your project.
[As a side note: Santa Rosa presented a webinar on this topic, “How Smart Are Your Medical Devices?” Click http://www.santarosaconsulting.com/Webinars/How-Smart-Are-Your-Medical-Devices-Webinar.aspx to listen.]

Assumptions for Connectivity Solutions:
You should review any assumptions or requirements for the project that may have an impact on its success. These could be wide ranging and cover a variety of issues. I will run through a few of the more common ones that come to mind to give you some examples.

Will you be connecting your devices wired or wirelessly? Are there enough data and power drops to accommodate all of the devices you will deploy? Are there enough network hardware (ports, switches, routers, IT closets) to handle the device load? Are there enough data base and/or specific application licenses to cover the project scope? Are there any other device implementation projects (printers, scanners, bar-code readers) that would compete for resources and attention in the same time frame?

This information will allow you to understand the landscape and other project constraints that you may need to deal with in order for your project to be successful.  

Timeframe for Connectivity:
Here I am suggesting that you focus on a data driven analysis to determine a realistic “can do” timeline for your project.  
If you’ve taken the above steps, you should now understand the broad scope of the project, areas in the hospital that will be impacted, staff that must be engaged and vendors that have to be brought into the process. Now you are ready (after your thorough due diligence) to set a project schedule with a realistic (or at least well understood) go-live date. You’ll be able to more confidently negotiate and drive the biomedical interoperability solution selected, make sound recommendations on the biomedical device replacement strategy for short term and long term goals, help to manage the expectations of clinical staff and know which patient care areas are the best candidates for early adoption.    

Performing a well reasoned “due diligence analysis” of the areas I’ve suggested above is not all you have to focus on in a medical device interoperability project, but it will help you think through the work that needs to be done and help you guide your client to a more successful outcome. I hope this was enlightening, thought provoking, and helpful.