By John R. Zaleski, PhD, CPHIMS
Many hospital systems are beginning to plan for or are already engaged in the process of integrating data from medical devices at the point of care into electronic medical records (EMRs). The value of this information spans the range from facilitating automated data collection and entry in high-acuity environments such as operating rooms (ORs), intensive care units (ICUs), and general wards (GWs), to enabling clinical decision support systems and remote management of patients in home health environments.
A survey of more than 300 hospitals and vendors conducted last year by health care technology research firm CapSite shows that medical device integration (MDI) is on the upswing.1 As reported in InformationWeek Healthcare, 44% of those responding had purchased an MDI application recently, most of them in 2011 or 2012.2 This trend is expected to continue, as upward of 54% of US hospitals plan to purchase new medical device integration (MDI) solutions, according to the survey.3
For each of these enterprises, adding an MDI system involves unique implementation challenges. For the benefit of the institution that is considering MDI deployment, this article summarizes the challenges experienced from the perspective of a practitioner and how to prepare for them from an implementation perspective.
The deployment of an MDI solution within a health care environment for the first time is more often than not a learning experience involving much trial and error. Health care enterprises that have normally maintained a clean separation between clinical engineering (CE) and health care information technology (HIT) departments can find themselves developing a hybrid relationship between the two. Sometimes a hybrid role is established between the HIT and CE departments in which an individual or set of individuals is charged with both software interface and hardware connectivity responsibilities.
This paper seeks to provide a checklist of items that an organization may use to help guide their questions and decision-making processes as they embark on a nascent MDI implementation. The checklist items presented here are intended to provide guidance. However, a thorough and detailed treatment of the process would require much more space than is available here.
In an effort to whittle down the scope, I will limit the following assessment to surgical services and operating room environments. My focus will be on the stumbling points and key aspects of integration surrounding surgical services (ORs) and intensive care units (ICUs), and the integration and connectivity of these data to an existing enterprise or departmental EMR system.
MDI in the Enterprise Environment
High-level data flow from medical devices at the point of care in either the ICU or the OR can be depicted approximately as shown in Figure 1.
 |
|
Figure 1: The basic objective of MDI is to communicate data from the bedside medical device to the end-point electronic medical record system, clinical information system, or related repository. |
The OR and the ICU are high-acuity spaces in which rich and intense amounts of data can be collected in support of patient care management. Frequencies of data collection are highest in these environments, as the data collected from these patients are important to intervention and treatment of the patients. In these environments, these data in effect speak for the patients, who are usually sedated.
The types of medical devices usually found in these settings are shown notionally in Figure 1. To provide more details reflecting the usual distribution of these devices, Table 1 provides a brief qualitative summary. In terms of acuity, the hierarchy is normally OR > ICU > General Ward (for example, medical surgical units). This table attempts to identify the types of medical devices that are normally associated with each department, the rate of data collection typically required, and how they are distributed across the departments.
 |
|
Table 1: Medical devices normally used in specific clinical environments together with their usual data update requirements as defined by clinical need per decision-making and charting requirements. A = physiologic monitors; B = anesthesia machines; C = mechanical ventilators; D = infusion systems; E = cardiopulmonary bypass machines; F = specialty monitoring devices (eg: intra-aortic balloon pump, neurological monitoring, end-tidal CO2 monitoring, etc). |
Those individuals involved in MDI rollouts for ORs and ICUs must determine with clinical staff (anesthesiology, nursing, respiratory therapy) the requirements for data integration with existing EMRs. In particular, the rates of data collection must be identified along with the expected findings that are to be recorded. The interfaces between the MDI system and the EMR must be the focus of attention early in the process. Specifically, the chosen MDI vendor must become an integral part of the MDI development activity and must participate in regular meetings on status with the enterprise.
During the process of qualifying the MDI vendor prior to procurement, the health care provider should answer the following questions:
1) Can the MDI vendor meet the device connectivity requirements for the spaces to be integrated in the hospital or hospital system?
2) Can the MDI vendor scale their system from the department(s) to the entire enterprise as the hospital system is able to expand?
3) What are the costs associated with anticipated rollout and expansion? Will new server hardware be required to scale from one department to one hospital and beyond? What are those costs?
4) Is the MDI vendor revealing all of the costs required for the implementation? Is the health care enterprise expected to carry any of the cost burdens from a procurement, management, implementation, and support perspective?
5) How does the MDI vendor translate proprietary formats into more standardized data formats? What is the requirement for hardware at the point of collection?
6) If the MDI vendor has hardware located at the point of collection, does it meet necessary UL and clinical requirements?
7) Is the MDI vendor’s product cleared by the FDA minimally as a Medical Device Data System (MDDS) or otherwise cleared for proximal use with patients?
Specifics related to exactly how the MDI vendor intends to transport data from the bedside or point of collection to the EMR need to be understood as well. In ORs or ICUs many physiologic monitors may communicate with existing HL7 Gateways through network ports. This greatly simplifies data collection, since there are no requirements for data translation from proprietary into standardized communication protocols. However, many more medical devices require translation from these proprietary protocols to a standardized messaging format prior to synchronization and transmission from the point of collection to the EMR. Some medical devices, like the Philips Intellivue MP5 monitor shown in Figure 2, may provide both serial as well as network connectivity.
 |
|
Figure 2: MP5 Intellivue Monitor serial and network ports that support communication of data from the point of collection to the MDI vendor’s product or to the EMR. |
Defining Integration Requirements
The EMR vendor must work closely with the MDI vendor to ensure that interfaces between the two can be achieved. Normally, the accepted communication methodology between MDI provider and EMR vendor is through results transactions from a version of HL7 (for example, v2.3 or 2.5). The questions that need to be addressed include the following:
1) Can the EMR receive the data at the rates required by the health care enterprise?
2) Can the data be delivered to the EMR vendor at the required rates?
3) Are networking modification required to ensure uninterrupted data communication?
4) Is wireless data communication a requirement, and does the health care enterprise have the necessary infrastructure to ensure high availability and high quality of data communication?
Semantic Data Requirements
Figures 3 and 4 illustrate transactions from an anesthesia machine and physiologic monitor, respectively, from an OR. Data from various machines must be mapped to the inbound standard interfaces that can then be posted as findings within the recipient EMR systems. Parameters must be mapped to specific parameters that clinicians normally validate. Different medical devices can and do produce parameters with different names and units of measure (UOMs). Some medical devices from different vendors also can and do produce parameters for which direct one-to-one mappings are not possible.
 |
 |
|
Figure 3: Typical HL7 transaction taken from an anesthesia machine at the point of care in an OR. (Click to enlarge.) |
Figure 4: Typical HL7 transaction taken from a physiologic monitor at the point of care in an OR. (Click to enlarge.) |
A key part of the process of validating the intake of data must involve ensuring that all modes of operation of medical devices are verified in terms of the data produced by these machines, and that their intake into the EMR is validated against expected fields. The possibility that a medical device may produce a parameter that is unknown in some mode of operation or that is mapped incorrectly to a field in the EMR must be ameliorated. Otherwise, a real hazard can be introduced to the patient and the clinician.
Confusion resulting from parameters that map to different fields draws valuable time away from the clinician and distracts focus from the patient.
Conclusion
The intent of the key factors and questions I’ve presented here is to raise the attention of staff and to begin to educate them as part of a departmental or enterprise rollout of an MDI solution. I hope that this concise discussion will help to guide the focus of those beginning such a rollout and to cause them to seek more insight before undertaking such an implementation. 24×7
References
1. CapSite. 2012 Medical Device Integration Study. August 2012. Available at: http://capsite.com/news/press-releases/54-of-u-s-hospitals-plan-to-purchase-new-medical-device-integration-mdi-solutions/. Accessed June 13, 2013.
2. Terry K. Medical Device Integration Software Surges In Hospitals. InformationWeek Healthcare. August 15, 2012. Available at: http://www.informationweek.com/healthcare/electronic-medical-records/medical-device-integration-software-surg/240005592. Accessed June 13, 2013.
3. Perna G. Report: Hospitals Looking at EHR Integration. Healthcare Informatics. August 9, 2012. Available at: http://www.healthcare-informatics.com/news-item/report-hospitals-looking-ehr-integration. Accessed June 13, 2013.
John R. Zaleski, PhD, CPHIMS, is chief informatics officer and executive vice president for Nuvon Inc, Philadelphia. For more information, contact [email protected].
