Heterogeneity and interoperability? Sounds good: leveraging the IT infrastructure shared by multivendor/multimodality systems and applications, problem-free coexistence and seamless interoperability, freedom to choose best-of-breed solutions, online firmware/software updates, and configuration management … and everything connected wirelessly! When these increasingly complex systems of systems are deployed, though, emergent behaviors and unintended consequences often result, and if medical devices that rely on networking technology are included in the mix, patient safety will be compromised and the ultimate outcome will be disastrous.

In the past, vendors could “cable around” this integration problem, ensuring that network capabilities necessary for the safe and effective operation of their systems were controlled. With the ever-increasing drive toward the utilization of ubiquitous wireless technology and multivendor product interoperability, this is no longer a viable strategy. The situation is even worse with medical and health systems having to compete with other general-purpose components such as phones, pagers, RFID, Bluetooth accessories, location tracking, etc.

Clearly, what is needed is a process for proactively assessing the risks associated with deploying new networked technologies, determining in advance how best to control those risks, and ensuring that accumulated and residual risks are well understood and agreed upon—before the technology is deployed.

A complicating factor in most provider organizations—those who are ultimately responsible for the operation of these networks—is that risk management is seen as a postincident (aka forensic) activity, focused on what happened and how it can be prevented in the future. In other words, the responsible organizations who have the greatest need to proactively manage these risks may be the least equipped to do so—and that must change.

From a regulatory perspective, there has been quite a bit of activity in recent months with the updated European Medical Device Directive (MDD)1 regulations that clearly identify “stand-alone software” as a medical device, and the FDA’s proposed guidance on Medical Device Data Systems (MDDS)2 that designates them as Class I devices. The message should be getting clearer to health providers who, knowingly or not, integrate medical device networks or deploy in-house applications that otherwise might be considered medical devices: Are you ready to play the role of medical device manufacturers?

Standards to the Rescue: IEC 80001

An emerging standard seeks to address this problem area: IEC 80001 Application of risk management for IT-networks incorporating medical devices; jointly developed by ISO/IEC Joint Working Group 7. This consists of ISO TC215 Health Informatics (especially WG4 Security and WG7 Devices) and IEC SC62A Common aspects of electrical equipment used in medical practice; along with liaisons to other related standards groups. IEC 80001 picks up where ISO 14971 leaves off and addresses how accumulated and residual risks from medical and nonmedical equipment and applications should be managed in a heterogeneous networked environment, how controls and monitors should be identified and effected, and how remaining risk should be documented, communicated, and approved by senior management all before the technologies are deployed.

An interesting aspect to this problem is that it lies firmly in that demilitarized zone between clinical engineering and IT—a divide that has been the subject of recent activities such as the formation of the CE-IT Community3 among AAMI, ACCE, and HIMSS. Thus, any solution must pull together provider, medical device manufacturer, IT equipment manufacturer, regulator stakeholders, and also cross traditional organizational boundaries, to include clinical/biomedical engineering, IT, facilities, purchasing, etc. IEC 80001 indicates that these groups must work together to proactively understand the risks and benefits associated with networked technology deployment, and manage it so as to ensure safe and effective systems. Is your organization ready for this sea change?

Under the Hood

The draft 80001 standard is segmented into three key areas: roles and responsibilities, life cycle medical IT risk management, and required documentation.

Of first importance is identifying the responsible organization and top management ownership of the 80001 risk management process within a given institution or provider group, and giving them the ultimate responsibility for technology procurement, integration/deployment, and maintenance. A top priority in moving toward 80001 processes is for top management to charter a medical IT risk management function that has the multi-disciplinary expertise and organizational authority to carry out the specified risk management functions. Note that the standard does not take a prescriptive or cookie-cutter approach to how organizations should implement the risk management process. Instead, it leans toward defining general roles and responsibilities, processes, and documents to be adapted according to the needs of individual organizations.

In addition to the risk management team, a key role is that of the medical IT integration risk manager (which can be a group or individual) who has the authority and resources to perform the bulk of the risk management process. When looking at the list of responsibilities, the role shares many of the traits of the emerging profession of a clinical systems engineer, which has evolved separately through ACCE.4

The core of the 80001 standard lies in the definition of a “life cycle process for risk management” of IT networks that incorporate medical devices. The process is project oriented, starting with the clear document of an organization’s risk management policy and process, and then addressing each change to the network as a project that is initiated with requirements and a project plan, followed by risk analysis, evaluation and control, and ending in residual risk evaluation and approval. All of this is performed proactively before any network modifications are made and systems/applications are brought online.

Key also is the follow-on monitoring of these networks, ensuring that the risk control measures are effective and that no new hazards have been introduced due to unmanaged changes to the network.

Finally, to make this all work, a minimal set of documents must be produced and managed. These include responsibility agreements and an IT-network risk management file. This file serves as the ultimate repository for all artifacts generated during the risk management process, including agreements, residual risk disclosures, risk analysis and evaluation, risk control measure implementation, and verification testing results, executive approvals, etc. Anything that is associated with the 80001 process ends up recorded in this file.

A sticking issue with technology vendors is the disclosure of residual risks, especially since in the wrong hands (those of their competitors) intellectual property and know-how may be disclosed. Thus, the 80001 standard details the “requirements for a mutual responsibility agreement (contract) among all parties of an IT-network project, and provides a basis for service and support agreements (contracts) among those engaged in installing, using, reconfiguring, maintaining, and decommissioning IT-networks incorporating medical devices.”

On the Horizon

The first 80001 candidate draft (CD) completed ballot of 2008/March yielded more than 250 comments. The next CD document should be published for ballot 2008/Q4, with a draft international standard ballot anticipated in 2009 and full publication in 2010. That means that now is a great time to roll up your sleeves and get involved! In addition to the core process-oriented document, task groups are working on additional guidance such as a getting started annex that will help jump-start 80001 risk management, an example of 80001 applied to wireless LANs, a discussion of the unique security risks that these types of networks present, document examples, and much more.

Also, standardized document formats and interchange will be defined (that is, for residual risk disclosure) in order to facilitate management of this information by the responsible organizations who may have to factor in thousands of devices from hundreds of manufacturers. In order to learn from one another’s experiences, an online community is being developed to facilitate dialogue on this topic, sharing questions and ideas, as well as case studies and anecdotes in applying IEC 80001 to specific organizations and projects.

Given the time line for this standard and associated guidance development, now is the perfect time to get involved and make your voice heard. Though at first reading it may appear fairly mature and complete, at this point there are quite a few modifications under consideration, even to the title of the document. Ways to engage in this activity include:

  • Review the document and provide feedback from your real-world needs;
  • Join ISO/IEC JWG7 to ensure that your critical requirements are addressed; and
  • Champion 80001 projects within your organization.

To find out more about how you can become involved in this important work, contact one of the JWG7 co-chairs: Todd Cooper () or Sherman Eagles ().

Todd Cooper is president of Breakthrough Solutions Foundry Inc, which services the medical device informatics and interoperability arena. He is an ISO/IEC JWG7 co-chair, and chair of a number of device informatics standards groups within ISO, IEEE, IHE, and HL7. For more information, contact .

References

  1. Enterprise and Industry. Recast of the Medical Devices Directives public consultation. http://ec.europa.eu/enterprise/medical_devices/consult_recast_2008_en.htm. Accessed June 16, 2008.
  2. Food and Drug Administration. Devices: general hospital and personal use devices; reclassification of the medical device data system. http://www.fda.gov/OHRMS/DOCKETS/98fr/E8-2325.pdf. Accessed June 16, 2008.
  3. CE-IT Community Web site. www.CEITCollaboration.org. Accessed June 16, 2008.
  4. American College of Clinical Engineering Web site. www.ACCEnet.org. Accessed June 16, 2008.