Few hospital executives doubt the value of integrating patient care devices into their core hospital information system (HIS). In fact, with Meaningful Use objectives for recording clinical documentation in the electronic medical record (EMR) and medical device interoperability set as 2014 and 2015 objectives, respectfully, biomedical/clinical engineering departments may already have been tasked with planning for these requirements. If you have not been involved in this biomed/IT interaction, get ready, because it is approaching rapidly and will require that biomedical and IT departments work together on a project that will have C-suite visibility. In this article, we will cover the overall process, team dynamics, tools that are available today to assist you, and topics important to the project that your IT team will undertake with your guidance.
Bridging the Divide
A project team for medical device-to-EMR integration efforts typically consists of representatives from clinical engineering, nursing, and IT. The nursing organization has worked with biomedical and IT departments in different capacities for many years, but with patient care device data integration projects, it is most likely the first time these three organizations have ever worked in unison. In fact, it is possible that this could be the first time biomeds and IT have worked together on a common project.
An important fact that cannot be overlooked (whether it is warranted or not) is that there is often a cultural divide between biomed and IT departments. Each department has different policies, processes, and procedures that guide their day-to-day work, and the environment that a biomed professional is accustomed to differs greatly from the environment an IT professional is comfortable in.
Over the course of an EMR integration project, the IT and biomed groups will be asked to implement a variety of interfaces, but how they go about getting that work done is where the differences come into focus. An analogy that may help is that we are effectively asking each group to put a new exhaust system on a vehicle. The IT team can pull the car into the shop, tear it down, make adjustments, hook test tools up to it, install parts, and then start it up and ship it out. The biomed team is asked to do the same work, but do it while the engine is running! They each have the same goals; the rub is that different constraints are placed on each group. The biomed team is dealing with a scarcity of full test environments, FDA quality standards, finite interface capabilities, and a “no downtime” mantra, while the IT group is dealing with feature/functionality changes, ever-changing IT project road maps, emerging technologies in computer science, and an overload of new systems to install and integrate.
Understanding that a divide commonly exists between biomed and IT departments and that each group has valid reasons for why they operate the way they do will be important. A symbiotic relationship between the two is possible. However, all parties need to realize that it is a work in progress and the efforts undertaken on an EMR integration project are building blocks to bridge the two groups.
Many medical device manufacturers and IT vendors have been working for several years to lay the groundwork for the interoperability of medical devices. Organizations such as Integrating the Healthcare Enterprise (IHE), Healthcare Information Management Systems Society (HIMSS), and the Association for the Advancement of Medical Instrumentation (AAMI) have all been working together tactically and strategically to advance interoperability. The IHE group represents software vendors and medical device manufacturers focused on defining standards for device integration. Each year, the annual IHE Connectathon event showcases a group of device manufacturers communicating with software systems using the standards developed in a vendor-neutral fashion. The Patient Care Device (PCD) domain is a part of the IHE organization, and within this domain, there are several profiles defined that contain the technical details of interoperability. Profiles that may be used include:
- Device Enterprise Communication (DEC): This transfers PCD data to enterprise applications (CIS, CDR, CDS, EHR, EMR, etc). It addresses the need for consistent communication of PCD data to the enterprise, which supports efficient patient care and heightened patient safety initiatives by reducing manual data entry (eg, patient demographics) and automatically populating PCD data into enterprise systems.
- Point-of-Care Infusion Verification (PIV): This brings infusion systems into the electronic medication administration process. The workflow provides for the electronic transmission of infusion information from a bar code-enabled medication administration system (BCMA) to an infusion pump, which reduces the need for manual programming of the pump and leverages the use of the pump’s onboard drug library to reduce medication errors.
- Alarm Communication Management (ACM): This defines the communication of alarms from alarm source systems to alarm management systems. This profile provides for alarm dissemination between alarm source devices and systems in a manner that, if complied with, enables multivendor and multidevice interoperation with phones, pagers, and other portable devices.
It is this domain and its membership that has worked to not only define interoperability standards, but also put them into production use at hospitals across the country. All of this work can be immediately leveraged by the project team as a guiding principle for how vendors should communicate with one another. Full information about the PCD profile can be obtained from the IHE Web site.
The transactions defined by the IHE PCD group are vetted by industry experts, open to public comment for further refinement, and tested each year at the annual IHE Connectathon event in Chicago. Hundreds of HIS vendors and medical device manufacturers attend this event to test and certify their systems with the assistance of the IHE organization and the National Institute of Standards and Technology (NIST). The result of all of this work is proven system integration practices and rules that any vendor in the marketplace can use in order to achieve device interoperability.
Not all medical devices and not all EMR systems have support for IHE profiles. In these situations there are IHE hubs, or IHE middleware, that can be used to translate the interface conversation from a proprietary medical device protocol into IHE-supported transactions. The same can be applied when the medical device is IHE-compliant but the EMR needs middleware to translate the IHE-compliant transaction into the required EMR format. The most common scenario in hospitals today is where neither side of the conversation is IHE-compliant. The industry is moving toward a plug-and-play infrastructure, but the reality is that biomed and IT departments will need to work with their multiple vendors to understand capabilities on each side of the conversation and determine how to tie it all together in a coherent fashion.
Leave No Stones Unturned
A review of the tasks associated with a sample medical device integration project is listed next. Use this list of project tasks as a checklist to ensure all bases are covered. A helpful breakdown of biomed, nursing, and IT responsibilities within each task is also listed to provide an understanding of the typical breakdown of responsibilities.
- Networking: Modern, commercially available medical devices typically come with local area network (LAN) ports and support the Transmission Control Protocol and Internet Protocol (TCP/IP) for input/output operations. You will need to ensure that patient rooms and treatment areas can support multiple LAN jacks. In addition, isolated virtual local area networks (VLANs) may be a requirement from your device manufacturer, so you need to identify if there will be a requirement for a customer-supplied firewall or dual homing on a vendor gateway device in order to get the data into your corporate LAN and the EMR.
Devices that support only serial port connections will require serial networks and a vendor gateway or serial port server that can translate the serial port protocol into TCP/IP for consumption on the hospital network. A biomed’s responsibilities may include providing asset inventory/location info, guidance on which treatment areas and/or patient rooms will be equipped with LAN aware devices, and meetings with medical device vendors to understand networking capabilities. IT responsibilities may include physical cable run work, network switch management, firewall configuration and updates, and routing configuration to ensure data transfer capabilities between medical device VLANs and the corporate network. Nursing will not have any responsibilities in regard to networking tasks.
- Interface Development: The medical device manufacturer will be able to provide specification documents that describe the message format of the outbound message data from its system. The specifications will differ by manufacturer unless an IHE approach is supported by all of your vendors. If all your vendors support the IHE PCD profiles, you will have only one message specification that your team will need to interface. Many hospitals have an enterprise interface engine solution and elect to run all interfaces through the engine so that it can deliver to the end system, in this case, the EMR. The interface engine team will take the specification from the medical device vendors and apply the appropriate transformation and mapping to all messages so that they are consumable by the EMR. Again, things get much easier if your medical devices and EMR support the IHE PCD profiles because no mapping and transformation is required, which means your interface engine team can focus on connectivity between the systems.
Clinical engineering responsibilities may include working with medical device vendors to understand the message specification and then coordinating work on the medical device gateways/central stations/etc, and to enter connectivity configuration information and route data into the hospital interface engine. IT responsibilities include interface engine development, specification review, connectivity validation, and working with the EMR vendor to understand the interface specification supported by the EMR. Nursing will not have any responsibilities in regard to interface development tasks.
- Nomenclature Mapping: The parameter data that comes from medical devices will have unique codes assigned to each parameter type, so for example, a heart rate may be known as code “128A.” A typical EMR system also has a code set that identifies medical device parameters. An IT resource will need to be engaged to build parameter mappings in the EMR so that when a heart rate coded as parameter “128A” comes into the system, the EMR knows how to map this to a value in its system. An important note here is that IHE-compliant systems adhere to the Rosetta Terminology Mapping profile, which is based on the ISO/IEEE 11073-10101 nomenclature. Nomenclature mapping steps will not be required when systems comply with these standards. Until then, this may be a step that needs to be addressed at your site as described above.
A biomed’s duties may include working with the medical device vendor to get a listing of the possible parameter code values. IT responsibilities include working with the EMR system to update and/or create mapping files to ensure the terminology nomenclature remains consistent across systems. Nursing responsibilities include verifying that the parameter mappings are correct and conducting a full review of what parameter values are available from the patient care device environment to ensure that no parameters have been overlooked.
- Testing: Testing of the integrated system before go-live can seem unorthodox to some IT professionals because they typically have full test systems for every solution managed. It is rare for a hospital to have a patient-monitoring test system, so the testing process typically follows one of two scenarios. The first scenario involves using a medical device simulator, which is provided by the medical device vendor. The simulator will create a medical device network and output data in the same format as the real system. The second scenario involves using the actual medical device systems, but sending their output to the test systems on the IT side. Every hospital has a different policy and risk tolerance around having real patient data show up in a test system, so reviewing the options available to validate your system with the entire team will result in an obvious best choice for your environment.
Clinical engineering responsibilities include validating connectivity of medical devices to the IT systems, validating medical device readings against the values showing up in the EMR, and working with the medical device vendor to understand what testing options are available for the given equipment. IT responsibilities include development and management of a test plan, validation of the data that is reported in the EMR, and performing test system configuration. Nursing has the responsibility of final sign-off and approval that the data being recorded in the EMR is in fact accurate, and that the new workflow being introduced to clinicians is well-documented.
- Training: The end result of a medical device integration project will appear to end users as just another feature in the EMR system. There may be certain new steps in the medical device-to-patient association process (such as scanning a bar-coded wristband, or selecting a patient from an ADT interface list), but the remainder of the user-facing items are EMR-related. Clinicians will need training on the use of the new, automated medical device data functionality in the EMR.
Biomedical responsibilities include receiving the same training that the clinicians receive so that the system and workflow required to get data in the EMR is understood. IT will be responsible for conducting EMR training. Nursing will review the training material and provide guidance on when and how the training will be delivered.
- Support Procedures: When a clinician makes a call to the help desk reporting a problem with the system, the first question that must be answered is, “Does this problem represent an error with a medical device or an error with an IT system?” The biomed department needs to have a well-documented method in place to verify that data is being created and transmitted from the medical device network. If data is being delivered to the hospital interface engine, it is almost a certainty that there is an IT issue causing the problem being reported. Many times, clinicians will call the biomed department to report a problem because it is medical device data that they are not receiving in their system. Few clinicians are aware of the technology and systems integration that is in place to make the heart rate appear in the EMR; they just know that if there is a problem with a medical device, biomed staff can fix it. Medical device vendors can supply the biomed department with test tools or data validation tools, which can be used in a triage process to determine if a problem report needs to be rerouted to the IT support group.
Integrated Integration—A Holistic Approach
The IHE PCD domain has been working hard to make this process even easier for everyone involved, and true plug-and play interoperability will become more of a reality with each new version of medical devices and EMR systems. Until then, having knowledge of the right tools and guidance that exist today will help you be successful in integrating PCDs with your EMR. By working together, health care technology management professionals, nursing, and IT can make it happen and can achieve successful medical device integration projects that result in significant patient safety improvements, measurable nurse workflow time savings, enhanced physician/clinician satisfaction, and more robust patient charts in the EMR.
Jeff McGeath, cofounder, vice president, and CTO of Accent on Integration (accentonintegration.com), Dallas, is a skilled technology strategist who converts ideas into comprehensive IT solutions that connect disparate technology systems and enable data integration across organizations. For more information, contact .