Laying the Groundwork for IEC 80001-1

Since we last reported on the state of IEC 80001-1 (hereafter, we will refer to the base standard as 80001-1 and the set of related technical reports as 80001-x), the committees engaged in its development have focused on providing implementers with tools to help steer these still-evolving efforts. 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.” In this article we will bring you up to date regarding progress made during the recent Association for the Advancement of Medical Instrumentation (AAMI) annual meeting by the committees and their working groups. We will also share our understanding of the emerging relationships between 80001-x to other work, such as Medical Device Data Systems (MDDSs).

The base standard is approaching the 1-year mark since its adoption, and work continues within the standard committee on the first set of associated technical reports (TRs). As a reminder, the base standard, 80001-1, is considered normative: Claiming compliance with the standard requires being able to demonstrate meeting all of its reqirements. TRs, on the other hand, are not normative, but instead support the standard in some fashion. The current set of 80001 TRs being developed are intended to provide guidance to implementers—whether providers, manufacturers, or IT vendors. Three documents supporting key aspects of 80001 are well on their way to being ready to be balloted. These documents address:

• Guidance for wireless networks: This TR is focused on wireless technologies from an agnostic viewpoint. However, there are particular wireless technologies that are predominant in health care delivery organizations (HDOs) and thus garner a higher level of content (eg, 802.11). Where appropriate, these differences are pointed out and discussed. In addition, while it does not focus on a single wireless technology, it is assumed that the attached wired infrastructure is an Ethernet-based IP network. This document does not intend to propose a regimented step-by-step process for implementing a wireless medical IT network or a process for mitigating the risk associated with a particular wireless technology. While the TR addresses the fundamentals of risk management—eg, cellular telephones, WMTS, microwave links, two-way radios, etc—it uses Wi-Fi as the main example.

  The reason for this is twofold. First, virtually all hospitals now have a Wi-Fi network. Therefore, there is a common experience on which to base further discussions. Second, the Wi-Fi network is of high priority in hospitals for connecting medical devices. To reiterate, though, all the issues discussed for Wi-Fi technologies are applicable for other wireless technologies.

• Guidance for the disclosure of medical device security needs, risks, and controls: This provides HDOs, medical device manufacturers, and IT vendors with a framework for jointly addressing security risks. Of the TRs now in the works, this one is the most “high-level.” Since health care organizations have been working to implement better security for some time now, thanks in no small part to HIPAA requirements, this TR only needs to amplify those characteristics found in medical networks and not found in others.

• Step-by-step risk management of medical IT networks: Practical applications and examples: Following 80001-1 subclause 4.4, it sets out a process to specifically address risk analysis, risk evaluation, and risk control for creating or changing a medical-IT network. As stated in the title, this TR contains many examples of the practical application of the 80001-1 standard. The reader is reminded these are examples only, and that requirements for managing risks at one health care provider will likely not suffice to manage risks at any other health care provider.

  Two other TRs, not far behind, focus on describing how HDOs can organize to meet the programmatic requirements of the standard and provide models for responsibility agreements (RAs). They address:

• General implementation guidance for HDOs: This TR is intended to direct HDOs of all types and sizes through the process of establishing risk-management programs appropriate to each particular medical IT network and its intended application. Templates intended to assist in organizing and documenting the process are being developed.

• Guidance for implementing the RA: Key to implementing IEC 80001-1 will be agreement and cooperation between all stakeholders in the process, whether they are employed by the HDO, a medical device manufacturer, or IT vendor. This TR describes how the HDO should define the roles and responsibilities of all parties involved in the deployment of medical devices and applications on the health information services network.

Fundamentally Important

We find the issues being considered in addressing these two TRs not just interesting and instructive, but also fundamentally important in that they provide guidance on both how an HDO can organize itself to comply with 80001, and the fundamental tool 80001 provides to define the relationships with other key stakeholders—medical device manufacturers and IT vendors.

Regarding the former TR, tailoring a program that meets the normative provisions of 80001 while taking into account an HDO’s business model will be a challenge all will face, keeping in mind the stipulations of 80001 span the spectrum of focus, size, and complexity of HDOs, from the general-practice office through the regional delivery system.

As for the latter TR, it is fair to say that there are different schools of thought as to what should be covered by an RA. It should come as no surprise to the clinical engineering community that medical device manufacturers and IT vendors are reticent to provide information they consider proprietary, while provider-based engineers and technicians want any and all information they deem pertinent to being able to conduct effective risk management. The result of the difference of opinion has been reflected in disagreements regarding the scope of the report.

Two additional TRs are getting under way as well. One will provide guidance on how ISO 20000—an IT service management standard—complements IEC 80001-1 and vice versa. The other will offer guidance to HDOs for assessing the capability to conform with 80001.

The Relation to MDDS

Before moving on to our next topic, the relationship of 80001 to MDDS, we believe it is important to catch our breath and reflect on exactly where we are at this point: The baseline standard is approved; and guidance documents to support its implementation from varying organizational and technical perspectives are being developed.

It bears appreciating that while 80001-1 may be cast in paper, it is not cast in stone. Nor should it be. Neither the standard nor its incomplete TRs are grounded in experience. To our knowledge, there are no instances of HDOs, medical device manufacturers, and general-purpose IT providers collaborating to manage the risks posed in safely, effectively, and securely incorporating medical devices on general-purpose IT networks as described by 80001. While we know several organizations are working on such projects, including ours, none have yet reached completion. This remains a new endeavor, and we would be very surprised if experience does not provide feedback to be factored in as implementations are realized.

As to MDDS, the last time we checked, we—at Partners—are one of three HDOs so far who have listed our software devices with the FDA. How we chose the devices we listed, actually got them into the system, and how we plan to proceed is a story for another time. For now, it is sufficient to note that we have connected commercial medical devices that have long been regulated by the FDA through our existing, and now regulated, software pipes, to (currently) unregulated electronic medical records. For now, consider the very plausible system design where medical devices will connect to the electronic medical record (EMR) via a general-purpose IT network as well as an MDDS, whether developed externally or internally. At that point, the provider of the MDDS takes on the role of a medical device manufacturer, with respect to 80001.

Nobody promised this would be easy.

The intrinsic complexity of this work is beginning to become clearer. While the intent of 80001 is to provide stakeholders with a framework with which to approach integration from a risk-management perspective, it is practically impossible to do so without considering other perspectives as well. Before beginning the functional work of step-by-step risk management, organizational issues have to be addressed, including identifying which of the stakeholders is responsible for what. Risk itself turns out to be multifaceted, extending beyond just safety. Specific technologies need greater focus, like wireless and security systems and components. To do medical IT risk management, you need to take IT service management into consideration. And, try as a health care provider might to avoid it, in order to achieve its objectives it may ultimately have to come to terms with being a regulated device manufacturer. These and other issues, including some of which that are yet to be identified, have to be addressed throughout the life cycle of an integrated network. Some will likely emerge simultaneously, and trade-offs will need to be considered. We are reminded of the saying by Ashleigh Brilliant, “It’s not easy taking my problems one at a time when they refuse to get in line.”

What About Now?

Before completing this update, we would like to address a question many have posed to us, namely, “What should we be doing now?” Before providing a brief checklist of initial things to consider, we need to emphasize the answer each of us has given until now: “Read the doggone standard! And, then, read it again!” This remains our fundamental advice. We recognize how frustrating this must be to hear, but the question is not all that different from a question of the not-too-distant past, “What should I do to address HIPAA?” Or, even more broadly, “What should I do to establish an equipment management system?” The answers to those depended, and continue to depend, on a lot of factors specific to the implementing organization.

As we hope came through in the above, the same can be said of 80001-1. It is a process standard to be applied to systems of complexity that vary as functions of scope, time, intended use, and other aspects change. Therefore, no cookbook recipe can be devised to guide its universal application.

To start laying the groundwork for future implementation, each institution will need answers to the following questions, which address important organizational issues that must be resolved to achieve success.

• Do you have any medical devices communicating over general-purpose IT networks? Where you do:
• Who manages the support and maintenance of the medical devices and networks?
• What process management standards do they already follow?
• Risk management?
• IT service management?
• Others?
• What documentation of the network exists, and who is familiar with it?
• What roles do the medical device manufacturers play in supporting the combined system? How about the IT vendors? How do they plan to support organizations implementing 80001-1?
• Is there a group in your organization addressing 80001-1? If not, how might you start one?

In summary, in addition to the base standard, the first set of guiding technical reports should be available in the next few months, and others should soon follow. As people put them to use, we expect early adopters will discover things that could inform us all. We invite anyone adopting 80001 to share their results, both with the standards committee and the larger community—via writing an article or presenting at a conference.

For those in hospitals, how did you communicate to top management the role 80001-1 has to play, and how did management respond? What issues arose while developing RAs, and how were they addressed? For medical device manufacturers, it would be good to share how you have organized your processes to respond to 80001. What issues have arisen in response to requests for assistance or information pertaining to 80001 from a hospital? Have the requests differed—ie, in terms of information requested—and how have you responded? Answers to the same questions from IT systems and service providers would be valuable as well, as would knowing how you have organized to respond to requests for help to integrate with regulated devices.

---

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 .