Perhaps the strongest driving force in clinical/biomedical engineering and IT interactions is networked or wireless communications that extend the capabilities of the traditional embedded system device. Much of these extended medical device system capabilities, eg, data analysis, remote access, and databases of searchable clinical data, use off-the-shelf, general purpose computing equipment. These kinds of medical device systems continue to proliferate to meet the need to make clinical information available to a broader number of users and other systems. As medical device systems continue to be adopted and evolve, it is inevitable that health care technology management professionals and IT will find themselves dealing with certain issues together.

A survey recently published by the Association for the Advancement of Medical Instrumentation1 on the use of wireless technology in hospitals revealed a strong bias among biomeds for vendor-installed proprietary wireless connectivity. This attitude reflects the past approach to these systems where the medical device manufacturer installed the system and supported the IT components. For many reasons, this simple and familiar paradigm is being replaced by an approach where medical devices are becoming information appliances on a shared enterprise IT infrastructure that is managed by the hospital.

This transition raises the question of best practices for medical device systems. Organizations like The Joint Commission, Oakbrook Terrace, Ill, and ECRI Institute, Plymouth Meeting, Pa, are almost totally focused on conventional stand-alone medical devices, and offer neither accreditation requirements nor best practices for medical device systems. In biomed departments, the status quo finds us with a lot of smart people who want to do the right thing, and, mostly through exception handling or informal processes and collaboration, produce a pretty good outcome. In IT, the focus seems to be on “getting things done,” implementing a daunting electronic medical record (EMR) road map while slowly improving IT management, policies, and procedures to be in line with standards like ITIL,2 IEC/ISO 20000,3 or COBIT.4 Very few, if any, hospitals have implemented the full set of best practices laid out in the preceding standards.

With the inevitable confluence of biomedical/clinical engineering departments and IT, a critical question arises: How can we bring safety-critical best practices to medical device systems, and especially to our peers in IT? The following outlines a number of areas that represent common gaps in managing medical device systems. By adopting some variation of the practices described here, your hospital will be well on the way to achieving safety-critical best practices for medical device systems.

Inventory

The medical device inventory managed by biomed departments is usually top notch, thanks to occasional audits by The Joint Commission. Sometimes missing from biomed inventories are the firmware versions for embedded system devices. Firmware versions are important to manage because they can impact the device’s interface through the serial port and any network connections.

Common deficiencies of biomed department inventories are the off-the-shelf IT components of medical device systems. While the embedded system devices—for example, infusion pumps—are always inventoried, the servers, virtualized server environments, and network infrastructure that are also essential components of the infusion pump system are often missing.

A similar situation exists in IT inventories, where the full scopes of medical device systems—this time, the embedded system devices—are not inventoried. It is also typical of IT inventories to not identify the specific IT infrastructure items that are part of medical device systems.

Remediation for inventory shortcomings includes adding any missing information, such as firmware versions, and ensuring that entire medical device systems are inventoried in biomed departments, IT, or both. A complete and accurate inventory is an essential tool in managing both safety-critical and mission-critical systems. Hospitals can either combine IT and biomed inventories into one system, or run two separate systems. In the event of two separate inventories, some components must be duplicated in both inventories so that medical device systems are fully identified, as both biomeds and IT are responsible for different portions of medical device systems. An unsettling prospect is that the exercise to create a complete inventory could identify items unknowingly missed completely or counted twice.

Risk Management

The safest and easiest method to manage medical device systems is to implement a dedicated infrastructure. Unfortunately for enterprisewide deployments, like patient monitors, infusion pumps, and diagnostic point of care systems, the cost for these duplicate infrastructures is prohibitively expensive. Costs are reduced when medical device systems run in shared environments. This means that rather than running in identical system environments (as provided by a dedicated infrastructure), every installation is significantly different. In addition, decisions to upgrade or change that shared infrastructure must be considered in light of the requirements of each of the medical device systems that is supported. Consequently, it then becomes the responsibility of the hospital to ensure that the IT infrastructure is managed and supported in a way that does not compromise the safety and effectiveness of the safety-critical systems it supports.

Risk management provides tools for identifying risks with the greatest consequence and highest probability of occurring, and includes mitigation, management, and monitoring of those risks to minimize their occurrence and/or impact. Biomeds most often use risk management to determine preventive maintenance requirements and the frequency of equipment recalibration. IT uses risk management to ensure the security of information systems and the privacy of electronic health information. Few hospitals are currently using risk management to manage the patient safety of their medical device systems.

There are numerous risk management standards that serve as models for best practices. The ISO 14971 standard specifically addresses medical devices and is used extensively by regulated medical device manufacturers. This standard also serves as the basic framework for ISO 80001-1 for the risk management of IT networks incorporating medical devices. Upon the completion of a hazard analysis of medical device systems deployed on a shared infrastructure, a number of hazards would likely rise to the fore: inventory, configuration management, and change control.

Configuration Management

How a medical device system is configured, including the shared IT infrastructure, has a significant impact on its operation. Configuration changes can impact how the system operates—eg, what calculations are used to analyze data; the specific data acquired, displayed, and stored; and how the system supports a specific clinical workflow. Configuration also impacts the operation and performance of the supporting IT infrastructure. Compatibility among equipment models, firmware releases, and how they are all interconnected can have a critical impact on operation and performance. It is the capture and tracking of this information that lies at the heart of configuration management. A robust risk management process is used to guide configuration management, guiding the kind of configuration data to be tracked.

Each medical device system has a very specific configuration to which the medical device manufacturer designed and tested its system. To exceed that configuration is to use the impacted medical device systems in a way that was not intended or tested by the manufacturer, or cleared by the FDA. Making changes to medical device system configurations that fall outside the manufacturer’s specifications can result in system failures—and sometimes in catastrophic failures.

The biomed department often limits its interest in configuration management to medical device modules that may come back from service with factory defaults. In contrast, the IT department tends to focus on developing and maintaining its preferred configurations for IT to ensure reliable operation and performance. Medical device systems add a new level of requirements to configuration management where the impacted IT infrastructure has to be maintained in accordance with the specifications and configurations provided by the medical device manufacturers. The more medical device systems supported, the more complex this task becomes.

Change Control

When medical device manufacturers leverage off-the-shelf IT components to design medical device systems, the importance of change control grows exponentially. While a conventional stand-alone medical device may change only a few times over a several-year manufacturing life cycle, the IT components in medical device systems seem to change every 6 to 18 months. This results in a considerable sustaining engineering effort for manufacturers and a substantial change control requirement for hospitals.

For every Microsoft Windows patch (which are released weekly), discontinued server or network router, or new firmware version for an IT component, change control is necessary for the continued safe and effective operation of medical device systems.

The concept of change control is typically a new one for biomed shops that have historically limited their focus to the embedded system medical device. Virtually every IT department has some degree of change management, although few are sufficiently rigorous to ensure medical device systems remain safe and effective. Change control for mission-critical systems is done at a different level of rigor than change control for safety-critical systems. While IT may have more experience with change control, biomedical/clinical engineering departments provide the safety-critical perspective necessary to minimize or avoid sentinel events.

Common gaps in change control start with risk management that is focused on patient safety rather than security and privacy or preventive maintenance and recalibration. Detailed and current specifications for each medical device system, spanning the embedded system devices and all supporting IT infrastructure (client devices, servers, virtualized environments, networks, and peripherals) must be maintained and referenced when considering changes. Due to the short life cycles of IT equipment and potential lags in verification testing from medical device manufacturers, hospitals may be faced with implementing a configuration change that is not supported by the medical device manufacturer or cleared by the FDA. In this situation, risk management is critical, as is robust verification and validation testing to ensure these “unsupported” changes do not introduce some system defect that could impact patient safety. Rolling lightly tested changes out in phases to “see what happens” is a common approach to mission-critical systems. Life-critical systems require a rigorous and disciplined approach to the testing phase of change control.

What’s Next?

The preceding topics represent the most obvious gaps in medical device system governance. It is not coincidental that at least some of these gaps are symptomatic of the traditional separation of embedded system medical devices and information systems. The root problem here is not suboptimal organizational reporting structures, but the continued separation of medical devices and IT—even when medical devices now include systems with IT components.

Together, both biomed and IT departments are responsible for the effective management of medical device systems, yet few hospitals have audited both departments’ policies and procedures to determine if and where any operational gaps may exist. In most cases there is little or no awareness of the other department’s written policies. Hospitals that really want to take the bull by the horns may want to assess those two sets of policy to fill any gaps and harmonize the two departments’ operations. The result could be two separate but complementary policies and procedures, or a single set for which each department has partial responsibilities. Such an effort has nothing to do with organizational reporting structures, but fostering a more clear and unambiguous collaborative environment in which to support and manage medical device systems.

The advent of medical device systems will likely have a larger long-term impact on IT than it will on biomeds. The traditional role of the biomed will always exist; but once a medical device system is introduced, the support and management of the IT infrastructure will be transformed forever. While the industry is grappling with this issue, there continues to be news stories on the potential regulation of health care IT. The FDA has already issued draft guidance documents (on mobile medical applications5) or public statements6 and legislation7 about there being a patient safety mandate to regulate certain health care IT applications.

The FDA was the prime mover behind the creation of IEC 80001-1 in an effort to encourage providers to move to a more safety-critical level of management of medical device systems, and the pressure is only going to increase. At some point in the not too distant future, biomed and IT departments will likely operate under some sort of quality system, such as an abbreviated version of the FDA’s Quality System regulation adopted by medical device manufacturers.

Tim Gee is connectologist and principal at Medical Connectivity Consulting, Beaverton, Ore; medicalconnectivity.com For more information, contact .

References
  1. Fuchs K, Kosmala R. AAMI members weigh in: Survey sheds light on use of wireless technology. Biomed Instrum Technol. 2011;45(6):435-439.
  2. Information Technology Infrastructure Library. Available at: www.itil-officialsite.com Accessed August 1, 2012.
  3. The first international standard for IT service management. Available at: en.wikipedia.org/wiki/ISO/IEC_20000. Accessed August 1, 2012.
  4. Created by the Information Systems Audit and Control Association. Available at: en.wikipedia.org/wiki/COBIT. Accessed August 1, 2012.
  5. Draft Guidance for Industry and Food and Drug Administration Staff—Mobile Medical Applications. Available at: www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm263280.htm. Accessed August 1, 2012.
  6. Impact of Potential FDA Regulation of EMRs, Medical Connectivity. Available at: medicalconnectivity.com/2010/10/08/impact-of-potential-fda-regulation-of-emrs. Accessed August 1, 2012.
  7. Obama Signs Law to Regulated HIT—Someday, Medical Connectivity. Available at: medicalconnectivity.com/2012/07/11/obama-signs-law-to-regulate-hit. Accessed August 1, 2012.