Tim Gee

For more than 20 years, medical device manufacturers have been designing networked systems. These medical device system networks were designed to operate physically separate from the enterprise network.

In private networks, manufacturers applied the same design principles to the network implementation of their systems as they did to embedded system devices. Variables were kept to a bare minimum; implementing only those networking and system features required to support their design.

This design approach offers significant benefits, including reduced product development costs and time to market, due to fewer networking features and configuration options; an increased ability to quickly troubleshoot system problems; and the ability to more quickly resolve problems for customers.

Because they operated on a stand-alone basis, there was no need to keep installed medical devices current with commonly available technology. It is not unusual to find medical device systems installed in hospitals using obsolete coax media like Ethernet ThickNet or ThinNet, and long-discontinued network hubs and routers. The system software in servers and workstations, not to mention the actual hardware itself, is often long out of date. Operating system patches, an almost weekly event with Microsoft Windows, were not applied to these private systems because there was no need. Virus scanning and protection, and network security, were also eliminated as requirements by making these systems private.

The majority of private medical device systems were maintained and serviced by the manufacturer; biomedical engineering served as the manufacturer’s hands and eyes for enabling remote dial-up modem communications for problem diagnosis and replacing and configuring components. This simple, straightforward approach enabled manufacturers to provide reliable systems that were fast to diagnose and repair in the event of a problem.

Rather than designing medical device systems as information appliances operating in an enterprise environment, manufacturers applied embedded system design approaches to broader systems. Because they had their network to themselves, there was no need to design a system that coexisted with other applications or systems. Nor was there a need to monitor and manage those systems as a typical information technology (IT) system can be managed, with remote monitoring, access, and control by IT Operations.

This freedom to design their own system environment resulted in systems that were either difficult or impossible to operate in an open enterprise network environment. The perennial challenge of establishing and managing patient context (which device data on the network belongs to what patient) provides an illuminating example. Many early medical device systems used static IP addresses to identify the location of devices on the network. Then, through an application, a user would associate a patient with a specific location, like room 402 West. Almost all contemporary enterprise networks use the dynamic host control protocol (DHCP) to dynamically assign IP addresses to devices each time they connect to the network. Many hospitals are frustrated by extra work and error-prone exceptions necessitated by medical device systems that continue to require static IP addresses.

A common method for enabling bed-to-bed waveform viewing in-patient monitoring systems is for each patient monitor to continuously multicast the data from all active physiological parameters. This means that each patient monitor can “hear” all the data that’s being acquired by all the other monitors on the network. This is a simple and efficient design solution for a network of about 20 or 30 patient monitors. The resulting multicast traffic requires that a network be no larger than the overall system’s ability to manage and process both the multicast data, and other data like alarms, patient context, and review of retrospective data.

Converging Networks

Both technology advances in IT and evolving clinical requirements are breaking down private medical device systems and forcing them onto the enterprise network. Factors contributing to this breakdown are desires for improved patient safety, shorter lengths of stay, and improved staff productivity. The result is an evolution in where and how medical devices and the resulting data are used in care delivery.

Enterprisewide deployments of medical devices, like infusion pumps, patient monitors, and point of care diagnostic testing (POCT) devices, make the installation of a separate network impractical. These systems are converging with both wired and wireless enterprise networks.

The private network barrier is facing increased pressure for access to medical device data. Data acquisition for integration into flow sheets and anesthesia systems has evolved into “advanced clinical documentation” for electronic medical records (EMRs), extending beyond patient monitors and ventilators to infusion pumps and vital signs monitors. In response, many medical device manufacturers have developed gateways to preserve their private network and still get data on to the enterprise network. In spite of gateways, medical device systems are still being pulled inexorably onto the enterprise network, where IT must struggle with demands for special configuration requirements like VLANs and dedicated SSIDs for wireless networks.

Test and Certification

When medical device systems are installed, the manufacturer tests the system’s performance to ensure that it meets specifications. The documentation of this performance test is commonly referred to as “certification” of the system’s operating environment. When a system is on a private network, effectively managed by the manufacturer, this is never an issue; each time the manufacturer changes the system, it tests again to ensure that the changes meet specifications. When the medical device system is installed on an enterprise network, either completely or partially, the scope of the manufacturer’s testing grows to include much of the enterprise network.

Because the enterprise network is managed by the hospital, the manufacturer loses sight of how the operating environment of its product might have changed since installation. These changes can be as basic as changing IP addressing ranges or schemes, or installing a new version of firmware into a network appliance, and can result in medical device system problems. Major changes—including switching to a new network vendor, the installation of a new application on a network that changes performance characteristics, and the redesign and deployment of a revised or upgraded network (often in response to the deployment of a new application)—can also impact medical device systems.

This loss of control and visibility by medical device manufacturers results in greater time and effort required to diagnose problems. The time required to affect a correction can also increase significantly. The worst-case scenario is when the problem is the result of a change in the operating environment made by the hospital that is either outside the manufacturer’s specifications or entails a variable the manufacturer did not realize would affect their system. Many manufacturers will insist on repeating test and certification of their system’s operating environment after major changes to the enterprise network. There is, of course, a charge for this.

The IT Perspective

Many CIOs believe their core mission is to provide a reliable IT infrastructure for all the applications and systems automating hospital operations. IT departments are very production oriented, often with standard operating procedures for change control, risk management, security, and privacy. Often, as the only hospital department with project managers, IT is used in a leadership role in the selection, installation, and management of complex systems. Specific configuration methods and standards determine how client workstations, servers, and networks are deployed and managed. An area of frequent contention with medical device system manufacturers is wireless security, which determines how data is encrypted on the network and how devices are authenticated as legitimate users allowed to connect to the network.

The evolution of automation in the hospital started with general accounting, patient accounting, and hotel functions like admit, discharge, and transfer (ADT). Since that stage 25 years ago, automation has been moving ever closer to the core mission of hospitals: the delivery of care. When medical device systems are deployed on the enterprise network, IT’s role transitions from “mission critical” to “life critical.” Some in IT are uncomfortable with the fact that an error on their part could result in a patient injury or death.

The influence of medical devices on IT is small but growing rapidly. The volume of medical device systems, as measured in scope or budget, is often small compared to the overall IT budget. Yet nothing else in the realm of IT comes close to the core mission of hospitals, the delivery of patient care. The potential negative impact of problems with medical device systems is similarly large; unlike with ADT or patient accounting, problems with medical device systems can have catastrophic consequences for patients.

Working Together

As medical device systems become more automated and more integrated with other systems in the hospital, these devices are becoming information appliances. Recently released medical device systems are increasingly facile in enterprise IT environments. This evolution results in substantial change for both biomedical/clinical engineering and IT.

It is not important who reports to whom, but it is critical that the essential changes necessitated by converging medical device and enterprise networks are made successfully. Managing medical device systems in an enterprise operating environment require changes in both biomedical/clinical engineering and IT operations. The first step in successfully navigating these changes is an audit of both biomedical and IT operations. In a sense, biomeds need to adopt some IT systems methodologies, and IT needs to learn some biomedical safety and rigor. The result of an audit is often the identification of a number of areas in both biomedical/clinical engineering and IT that need greater attention to detail. Any operational gaps discovered in the audit are addressed with new standard operating procedures (SOPs) for medical device systems.

These SOPs can be divided into five areas: medical device system life cycle management, physical installation, operations, preventive maintenance, and problem management. Under each of these categories, SOPs are detailed to bring the best of both biomedical/clinical engineering and IT into a new operating plan. New processes, and most likely new information systems, are required to ensure efficient coordination between biomeds and IT. The days of poor handoffs or finger pointing will be gone. Who “owns the clock” to track the closure of service incidents that cross biomedical/clinical engineering and IT is a major consideration with no easy answer. The best IT help desk applications lack the tools to effectively manage medical devices, and the best biomedical asset-management applications lack the support for complex, distributed, and interrelated medical device systems deployed across the enterprise.

Once the SOPs are completed, the next phase is rehabilitation. All those medical device system wiring closets that have poor ventilation, inadequate or no uninterruptible power supplies (UPS), and little or no monitoring for servers or UPS must be brought into compliance with the new SOPs.

Once medical device systems are deployed on the broader enterprise IT infrastructure, the management—and particularly the risk management—of those systems are the responsibility of the hospital. A more formal and rigorous risk management process will be needed. The IEC 80001 end user standard that is in development refers to ISO 14971 as a model for medical device system risk management. An assessment will be needed to determine if any existing systems require remedial risk management. The new risk management processes will be consistently applied to new system installations and changes in the operating environment.

Planning for and managing medical device systems requires a substantial test environment. The scope and extent of the medical device system verification test lab will ultimately be defined and evolve based on the outcomes of risk management applied to specific systems. At minimum, the lab will require actual and/or simulated medical devices, all necessary servers and gateways, and a representative network infrastructure (both wired and wireless).

This new medical device system chimera will also necessitate some new roles in your hospital. These new roles may be filled by existing staff, or additional full-time employees (FTEs). If the hospital is transitioning to full 24/7 on-site support, it will require additional FTEs. A medical device system lead, responsible for both the medical device systems and their proper operation and integration into everything from the EMR to messaging middleware, remote surveillance, and other applications, is needed to coordinate both biomedical and IT efforts. Specialized project managers, analysts, and integration engineers are also needed to manage the medical device system life cycle.


Tim Gee is a principal consultant at Southfield, Mich-based Santa Rosa Consulting’s patient care device integration and point of care technology practice, which provides consulting services and solutions to hospital clients. For more information, contact .