This month we will try to tackle a very challenging topic: change management. This topic has inherited many new and complex aspects in our world of converging medical devices and information systems because of the interconnections and interdependencies that now exist.

For example, in the "good old (pre-21st century) days," a firmware update for an infusion pump might have meant swapping out the old ROM chip with a fresh, manufacturer-provided ROM chip; powering the unit up again; rerunning a series of basic inspection, safety, and, possibly, calibration checks; documenting those changes for your records; and, if recall-related, providing that information back to the manufacturer. These steps all happened before returning the IV pump to clinical use and allowed us to honestly assert that the device was in compliance with the manufacturer's unadulterated product specifications.

Today, more and more IV pumps (and most other health care devices) are being designed with two-way communication capabilities that allow the sharing of life-critical data to and from electronic medical records (EMRs) and computerized decision support systems (DSS). For IV pumps, these capabilities may allow immediate warning of potentially dangerous drug interactions, allergies, or dose-error risks, and they facilitate the accurate and automatic logging of drug and dosing information into the EMR. The devices themselves also can contain local copies of drug-identification and dosing tools and rules to allow them to function untethered from other components of the hospital-based real-time information and communication technology (ICT) systems, in order to support mobile care in ambulance or home settings.

Each such individual IV pump therefore contains its own ICT systems, and when interconnected to the hospital ICT systems, the CE and BMET must realize that many, or most, of their medical devices actually are functioning in a complex "system of systems" environment that has many more change management complexities than before (See http://en.wikipedia.org/wiki/System_of_Systems_Engineering to find some starting points about this rapidly evolving research area.)

Change management encompasses new and complex aspects due to the interconnections and interdependencies that now exist in medical devices and information systems.

In considering 21st century change management issues, we need to consider several different issues such as software version management, security and patch management, verification, and validation not only at the individual device/product level, but at the subsystem, system, and system of systems levels. The scope of such testing could be almost completely open-ended and unattainable if we took on the task of testing each and every function at each and every unit/system level, so we need to begin to define a more rational approach. In discussion with many other authors from this column, a few basic concepts recur: 1) the decisions about what to manage and document are going to necessarily be risk-driven; 2) the "old" focus on unit-testing is likely to be necessary but not complete unless all other related systems and subsystems have already been tested and documented in a way that ensures that the sole risks are isolated in the discrete device/product; 3) unit, system, and system of system interfaces are likely to represent a whole new class of change management focus points; and 4) emergent properties such as unexpected system messages, system behaviors, and even human behaviors represent a rich and complex new area of change management concern.

Taken in Order

1. Risk-driven decisions must focus on identifying and documenting all life- and treatment-critical features, functions, controls, and interface behaviors. In addition, if the device/product plays a critical role in a larger system, such as remote alarm annunciation, those functions must also be identified and documented. "Must-have," "should-have," and "doesn't really matter" might be three reasonable groupings to use. "Must have" could include features like dose accuracy and occlusion alarms. "Should-have" features might be optional features, like local, device-based drug libraries in infusion pumps for products that are only and always exclusively used in a fully connected network application with a centralized drug library. "Doesn't really matter" might be optional features you rarely even use on most, or all, of the products you own.
2. At the unit device/product level, there is no question that all life-critical and operationally necessary functions have to be tested and documented as safe, secure, and appropriate in the full range of uses and settings before and after any change is planned or executed. This requires either obtaining or creating a concise list of testable performance measurements and criteria to either "pass" or "fail" a device. If the intended version or patch cannot be tested against such criteria, the version or patch should be deferred until such testing can be accomplished. Simply installing a new version or patch and hoping that nobody gets hurt is not adequate. In addition, the device and tests must pass both the validation and verification (V&V) thresholds: Validation dictates that the product—and the tests—are still suitable for all intended applications; and verification dictates that the features and functions still meet all of the applicable safety and performance specifications. Such tests need to test not only the "proper" operation of the product, but also all reasonably likely improper operations (such as inadvertent failure to recharge the battery, or forgetting to turn the alarm back on).
3. At the subsystem level (such as the intensive care unit) the "Must have," "Should have," and "Doesn't really matter" triage continues. The ability of the wireless network to reliably receive and forward all life-critical alarm and clinical data would fit in the first category. Automated billing and, perhaps, connection to the EMR/EHR might fit in the second category. Filter-replacement-interval notification might fall in the third category.
4. At the system of systems level, we need to carefully consider intersystem behaviors that could interfere with (at least) the life-critical features and functions. Again, we need to consider proper and improper system behaviors. For example, if a wireless network failure could create an undetected open-loop drug-administration risk to the patient, then we will really need to add that failure mode to our testing regimen for the device, subsystem, and system of system environments. In addition, since devices themselves may inherit new interdependencies in the overall system of systems environment (such as multiple IV pumps on a single patient that must share dose and drug data successfully in order for any of them to administer a drug), we need to consider, catalog, test, and document that the changes we are about to install—or have installed—did not harm the safe environment of care for the patient.

So, where does this all leave us? It should be clear that this topic is pretty new and there are not yet clear or complete guidelines to follow for change management. We should consider this a prime opportunity to become leaders in this dialogue, though, because not only is it based on our heritage of technical and engineering training, but our information systems colleagues are depending on us to fulfill that role.

The change management systems must constantly evolve. We need to be sure to:

• Pre-evaluate, pre-plan, and then test and document the obvious/necessary life-critical features and functions that you anticipate will be affected by each change;
• Constantly stay vigilant for untested device/software/system failures that emerge that your existing plans did not anticipate; and
• Be sure to create and document appropriate new formal test methods into your formal testing processes to cover those flaws to make the change management system more robust.

"21st Century Change Management for Healthcare Technologies" would be a great project for the emerging CE-IT Collaboration program hosted by AAMI, ACCE, and HIMSS. We should be certain to call on other high-risk/high-reliability industries and specialties such as aviation, software and systems engineering, and pharmaceutical manufacturing at the outset, too, to help us leverage all of the past excellent work in related areas. That will avoid wasting our precious time and effort by "reinventing the wheel" or, worse yet, by repeating serious mistakes that others have already learned.

Elliot B. Sloane, PhD, Villanova University; is cochair HIMSS/RSNA/ACC IHE Strategic Planning Committee; cochair ACCE/HIMSS IHE patient care device domain; and a member of 24x7's editorial advisory board. For more information, contact .