Rick Hampton Rick Schrenker

By the time you read this, IEC 80001-1 will have been approved. You have heard and read about it, including numerous times in 24×7 since at least 2008. The full title is, “IEC 80001-1 Ed.1: Application of Risk Management for IT-Networks Incorporating Medical Devices—Part 1: Roles, Responsibilities, and Activities,” which ought to give you a good idea of what it is all about. It seems to us that no standard in our careers has received so much attention at meetings and in (electronic) ink than this one, before or after its approval. So now that it is a real standard, what is its impact, immediately and later? What, exactly, does it mean at the pointy end of the stick?

First, it is crucial to keep in mind that 80001 is a voluntary standard. Unless adopted by an agency with regulatory authority, a health care organization cannot be forced to adopt it. That said, it would be foolhardy to not assess and address risks before integrating medical equipment on a general purpose IT network. If nothing else, 80001 gives the implementer things to think about.

Second, 80001 is a process standard. It identifies the components of a risk-management process at a fairly high level, but not how they are to be implemented. Supplementary technical reports to provide implementation guidance are already under development, but they are not normative. It will remain incumbent on the organizations that choose to implement 80001 to determine how to do so within their organizational structure, culture, and requirements.

Last but far from least, implementers need to recognize that 80001 is essentially an invented standard—that is, it is not retroactive codification of recognized best practices sifted from experience. At its heart, 80001 represents an attempt to proactively go about risk management in this brave new CE-IT world and avoid school-of-hard-knocks events that could lead to harm.

To be fair to the people who have worked on the standard (including us), 80001 has not been pulled out of thin air. It inherits greatly from ISO 14971 (“ISO 14971: Medical Devices—Application of Risk Management to Medical Devices”), the general risk management standard for medical devices, as well as ISO 20000 (“ISO/IEC 20000:2005 IT Service Management System”), the life cycle standard for information technology service management. The two provide tested foundational material that has stood the test of time. But, their combination is, as noted above, inventive in nature. We are reminded of Petroski’s warnings concerning the risks of extrapolatory design, which “goes beyond the envelope of experience and thus risks encountering unknown phenomena that may dominate the design’s behavior.”1 In a very real sense, every early 80001 implementation is an experiment, testing the hypothesis that methods derived from earlier standards are applicable to this different scope. If that seems a stretch, consider that the standard speaks to managing risks to safety, effectiveness, and security that derive from the integration of regulated and unregulated devices and systems. If that is not new ground, we don’t know what is.

Because it has not been done before, there are bound to be lessons that will be learned—Hard Knocks U will not be denied. That is not a criticism but a reasonable expectation; there are always trade-offs. That said, we see that the capability to identify and address risks that derive from its careful application are worth dealing with the uncertainties that go with it. For the record, we both support adoption of the standard and look forward to seeing it develop over time.

Moving on. So without reading the whole thing a few times through, what is the gist of this new thing?

There are four aspects of 80001 that we believe the standard communicates unambiguously:

  • The three risk components to be managed are safety, effectiveness, and security—and in that order of priority.
  • It is ultimately the responsibility of the “responsible organization” (typically, the health care provider) for risk management of medical devices interacting with an IT network.
  • “Responsible organization” includes health delivery organizations of all size, such as physician single and group practices, as well as hospitals, clinics, etc.
  • For the objective of 80001 to be met, the “responsible organization” will need to work closely with medical device manufacturers and providers of information technology.

For the objective of 80001 to be met, the “responsible organization” will need to work closely with medical device manufacturers and providers of IT.

80001 goes on to describe how to operationalize the above, introducing tools like responsibility agreements and change permits to address issues the standard’s developers were certain would arise. It is not clear to us what these documents will look like. We both have experienced difficulty getting medical device manufacturers and IT providers to part with information we believed we needed to do our jobs, and wonder how the mere existence of 80001 is likely to change that.

As noted above, coming technical reports should help adopters realize the standard; certainly they point to considerations for organizational road maps. The first four technical reports under development address:

  • Guidance for health care delivery organizations;
  • Step-by-step risk management;
  • Security; and
  • Wireless.

Others will be developed as well. Any organization considering 80001 for adoption will find these as must-haves.

So what can you do to get ready?

  1. Learn about the general concepts of risk management, including from outside health care.
  2. In addition to reading through 80001-1 and its supporting technical reports, learn about 14971, 2000, and ITIL. ITIL in particular is more reading than anyone would care to do, but the Web has a number of good articles describing it.

Rick Schrenker is a systems engineering manager, department of biomedical engineering, Massachusetts General Hospital, Boston; and Rick Hampton is the wireless communications manager, Partners HealthCare System, Boston. For more information, contact .

Reference

1. Petroski H. Design Paradigms—Case Histories of Error and Judgment in Engineering. New York, NY: Cambridge University Press; 1994:94-97.