In the first installment on the IEC 80001 standard, I delved into the history of this particular standards effort and the patient safety needs the standard is supposed to address. There are two kinds of products being bought by providers that give rise to serious questions about patient safety:

  1. Medical device systems - that is medical devices that extend their capabilities by leveraging software running on general purpose computers, and
  2. IT-networks - the wired and wireless networks - both local and wide area networks - that connect medical devices to their own servers and client applications, in addition to connecting them to other systems of medical devices and/or health care information systems.

Medical device systems used to be deployed on their own private local area networks. This paradigm is breaking down for two reasons:

  1. Private networks result in "islands of information" that make it difficult to pass information between medical device systems and the greater IT infrastructure within the provider organization, and
  2. Medical devices that were once relegated to specific locations are becoming enterprise applications in use almost anywhere in the provider's enterprise.

It's just not practical to install multiple private networks across ever increasing portions of the enterprise. A mid to large sized hospital can have 50 to more than a hundred private networks supporting medical device systems. It is admittedly pretty easy (if not cost effective) to bridge private networks to move data between medical device systems and applications like ADT and EMRs. The real driver that is tearing down private medical device system networks is the fact that many devices are used across the entire enterprise rather than individual departments and units.

Medical device vendors loved private networks. Keeping the network all to themselves meant that they did not have to support other vendor's applications and devices on their network. Nor did they have to implement the full compliment of IT services for network integration, authentication and security. Such advantages are right in line with the embedded systems design mentality that forms the basis for how medical device vendors look at much of the world.

Biomeds loved private networks too, for many of the same reasons. As long as the network was isolated, they could "support" the network without really dealing with the usual IT support issues. If there was a network problem, they called the vendor who diagnosed - and frequently fixed - the problem remotely.

What's in IEC 80001

This standard is a process standard and does not proscribe how medical device systems should be networked. The standard specifies activities required of medical device and IT vendors in addition to provider organizations when one or more medical devices are connected to a network. The standard does not define specific risks, these are up to providers to identify and then mitigate.

Activities revolve around a formal risk management process - in fact this standard calls out ISO 14971, the very same risk management standard that medical device vendors use. (This also means that standards bodies get to sell you two standards documents so you can comply with just the one.) Most of the actual IEC 80001 standard document is a technical instruction manual for the people in provider organizations who do medical device network integration.

The standard has 4 goals:

  • patient safety
  • effectiveness (as in the enhancement of the delivery of care through safe and effective connectivity)
  • data and system security, and
  • interoperability

IEC 80001 attempts to balance these goals using a risk management framework.

This is an ongoing requirement, and not a one time shot. The risk management process in IEC 80001 must be used when networks intended to support medical devices are designed, when medical devices are first integrated into the network, and whenever any change is made to said network.

(Note that from this point forward, all terms in quotes are defined by the IEC 80001 standard - buy a copy and read it!)

The risk management process laid out in IEC 80001 starts before anything has been purchased. The standard refers to a "responsibility agreement" where vendors contractually agree to make available to providers all the information they need to apply an effective risk management process to a system that includes their products. We'll dig into how IEC 80001 might impact vendors in a subsequent post.

Cast of Characters

The standard calls out specific entities and roles. For example, the "responsible organization" is the provider organization - that is, any provider with networked medical devices from physician practices up to hospitals. We've already mentioned the "vendor." Within the responsible organization there is an organizational structure responsible for implementing the standard:

  • Top management - the person or group who is ultimately responsible for an IT-network incorporating medical devices
  • Medical IT integration risk manager - the guy who does the actual work that top management signs off on
  • IT-network maintainer - the party that is responsible for maintaining the network to which medical devices are attached

In a process much like the FDA's Quality System regulation (QSR), IEC 80001 stipulates that providers create a formal (i.e., documented) process for managing risk through out the life cycle of networked medical devices. There's no room for partial documentation or games like assigning responsibilities and withholding sufficient resources to get the job done - the standard renders all that transparent.

Under top management there is a cross-functional risk management team that includes all the skills and knowledge necessary to maintain "essential performance" of the network and integrated medical devices. In all likelihood, this team will be lead by the "medical IT integration risk manager."

Life Cycle Risk Management

With roles and responsibilitis out of the way, let's look at what actually gets done. First you have to implement your risk management framework:

  • Create a written risk management policy
  • Define and document a risk management process

Once this foundation is in place, it is time to finally do some actual risk management:

  • Each project must be planned, executed and documented (per the risk management policy and process)
  • Risk analysis - specific "hazards" are identified
  • Risk evaluation - a systematic method is used to evaluate each risk
  • Risk control - this is the process whereby risks are mitigated
  • Residual risk evaluation - the impact of mitigation strategies are tested and verified to identify risks that could not be satisfactorily mitigated
  • Reporting and approval -residual risks are documented and approved by top management as acceptable risks
  • Change management - any changes to the IT-network must be run through a formal change management process (unless you want to repeat the entire risk management project)
  • Monitoring - the essential properties of the network must be actively monitored as part of the risk management project plan

Final Documentation

A critical part of the information that goes into the risk analysis is certain information on the products, both medical device systems and components, and the IT-network. Like everything else in the IEC 80001 standard, this is a formal process and calls out for a contractual agreement between vendor and provider as to what information is to be exchanged and how it is to be treated by the provider. This "responsibility agreement" is similar to the Business Associate agreement required by HIPAA.

The "responsibility agreement" applies to both regulated medical device vendors and unregulated IT vendors. These IT vendors would obviously include network vendors like Cisco, Aruba and Meru. The risk management team is likely to also include HIT vendors and software infrastructure vendors like Citrix, Novell and Microsoft.

The result of this process is the "IT-network risk management file." Much like the Design History File or Device History File required of medical device vendors as part of the QSR, the "IT-network risk management file" is the first thing an auditor will want to see when checking provider's compliance with the standard.

It's really not worth spending a few years developing a standard if no one's going to adopt it. You can bet someone will step up and require the implementation of this standard. Here are 3 likely scenarios: the Joint Commission might require this for accreditation, CMS could make implementing IEC 80001 a requirement for reimbursement, or as a last resort, the tort bar might start force adoption of IEC 80001 through malpractice suits. Regardless of how the requirement comes about, it is very likely to happen.

Potential Impacts

Besides the obvious direct requirements of the standard outlined above, how might this standard change things for providers?

  • This will be a major operational requirement for providers on par with HIPAA. The process structure required by the standard is more formal than HIPAA, explicitly calling out top management and a multi disciplinary team. How smaller hospitals, or hospitals with outsourced IT will handle this will be interesting. Some are already thinking about outsourcing opportunities around IEC 80001 compliance.
  • This will drive a significant increase in formal project plans and documentation for medical device system and IT-network projects both. The days of documenting a hospital network on a few PowerPoint slides are fading. Similarly, IT-network design, installation, and management requirements will hit vendors and especially resellers.
  • The "responsibility agreement" will be a major bone of contention between providers and vendors. Can providers complete a meaningful risk analysis without knowing how certain features are implemented? What about bugs the vendor knows are in their products? If a bug triggers a cascading failure resulting in possible patient injury or death, calling the vendor after such an occurrence and hearing, "oh ya, we knew about that," becomes more than a frustration. I predict that providers will want access to many things vendors consider proprietary trade secrets.
  • While I didn't mention it above, the standard calls for each risk management project to identify specific intended use statements for each networked medical device application. The resulting risk management effort could easily result in new product specifications, designs, and verification. A byproduct of the more intimate interactions between vendors and their customers could result in a considerable improvement in connectivity requirements for new product development, ushering in a golden age of connectivity. Vendors may be able to avoid disclosing certain things if they do a better job of verification in the first place.
  • Scalability is a technical issues that gets little nor no attention now but will receive increasing focus under IEC 80001. Most of the "largest installation to date" systems complete much of their verification test at the customer site upon installation. The transparency driven by IEC 80001 will put an end to this, unless it is disclosed up front and the vendor and provider formulate a joint risk management plan to deal proactively with the situation.
  • The current laissez faire approach to wireless RF spectrum management will probably also fall to IEC 80001. Unintentional interference represents a significant risk to wireless medical devices. Continuous monitoring of the RF spectrum, trouble shooting tools and management processes are the mitigations for interference risk. Some day soon, every hospital will have an Anritsu Spectrum Master (and someone who knows how to use it) or some other product or service.
  • Finally, hospitals will need separate test and production environments for their networks so they can do all the verification of of the risk control strategies they develop in response to risks. This requirement extends beyond an AP and router on a bench. Hospitals will need to verify against a realistic enterprise environment. Fortunately there are vendors like VeriWave.

Perhaps the most intimidating challenge will be looking at all the hundreds of networked medical devices you already have deployed, and contemplating where to start.

What do you think will be the impacts on providers as a consequence of IEC 80001? Who do you think will mandate adoption?

UPDATE:  Today's news (here, here and here) about a new JAMA paper on the impact of RF interference from passive and active RFID systems on medical devices, raises a question. Shouldn't hospitals go through a risk management process (testing, policies and procedures, staff training) for every electronic medical device purchased and deployed in the hospital?

I wonder if this will be an issue in many hospital's IEC 80001 risk analysis?