Meaningful Use and IEC 80001-1

What is all the hubbub these days about “meaningful use”? Also in the news lately is IEC 80001-1. What is that about, and how does it come into play with meaningful use? Let’s take a look.

Meaningful use comes from the recovery act’s HITECH and electronic health record (EHR) section. While health information technology (HIT) and EHR use have been around for some time, the pressure to get on board was not really applied until last year. In January of 2009, President Obama set the goal to computerize all health records within 5 years.

The American Recovery and Reinvestment Act of 2009 (ARRA), signed into law the following month on February 17, 2009, amends the Social Security Act by establishing incentive payments to eligible professionals and organizations to promote the adoption and meaningful use of interoperable HIT and qualified EHRs. In other words, it is not enough to simply say that you are employing EHRs; you must show that you are getting “meaningful use” from them as well. After some public discussion, the Centers for Medicare and Medicaid Services (CMS) released the final rule defining how hospitals and health care providers can demonstrate meaningful use to qualify for federal incentive payments from HITECH and the ARRA dollar pool—most often called the Health Information Technology for Economic and Clinical Health Act, or the HITECH Act. The final rule defines who is eligible for payments, gives details about payment from the program, and identifies the measures they will look for to qualify meaningful use. Current plans are to continue the incentives until 2021.

Comply or Lose

Another aspect is that if you do not comply by 2015 you will start losing money. Not really a penalty, but rather a reduction of your normal Medicare payments (99% in 2015, 98% in 2016, and so on).

This will drive a lot of organizations to invest in and grow their HIT. In the nick of time there is a new standard to help out. Begun a few years back, IEC 80001-1 has now been approved. The voluntary standard assesses risks of network changes before implementing the change (see the November “Networking” column). It borrows from ANSI/AAMI/ISO 14971:2007: Medical Devices—Application of Risk Management to Medical Devices.

Officially called “IEC 80001-1: Application of Risk Management for IT-Networks Incorporating Medical Devices—Part 1: Roles, Responsibilities, and Activities,” it is a great idea long needed in HIT. The new standard is best summarized by quoting its scope-purpose section:”Recognizing that medical devices are incorporated into IT networks to achieve desirable benefits (for example, interoperability), this international standard defines the roles, responsibilities, and activities that are necessary for risk management of IT networks incorporating medical devices to address the key properties. This international standard does not specify acceptable risk levels.”

The “key properties” are safety, effectiveness, and data and systems security. The standard does not specify acceptable risk levels, leaving it up to the organization to define their own appropriate risk levels.

There are guides coming from AAMI/IEC that will help those implementing the standard, which should appear in draft form later this year. It looks like the guides will cover security issues, wireless aspects, as well as a step-by-step setup guide for risk management. They will be called IEC 80001 Technical Reports and will be known as 80001-2, -3, etc, when released next year (fall/winter 2011). I highly recommend keeping an eye out for the draft versions and reading through them.

Maintaining Safety

There have been many examples of why this standard is important. One thing that happens when adding new components to a network is a resultant system of systems. Systems that work well in a stand-alone environment may not play well with others. There is the story from Europe that told of unexpected network failures after a new application was installed. The service engineers sent by the manufacturer found no problems with their product; everything checked out fine. After a while, it was discovered that the new application was sending large amounts of data tagged as voice data. Since voice data is real-time data, it was given traffic priority. This rather needless hogging of network bandwidth was causing the trouble. That sounds like a fun one to troubleshoot (not)! The Internet is rife with stories like this. The impact on patient safety is serious business, and the new standard helps in identifying what the network change risks are before implementation.

The main goal of IEC 80001-1 is to apply appropriate risk management to IT networks incorporating medical devices consistent with ISO 14971. It aims to address the key properties considered necessary to maintain patient well-being. The standard recognizes that risk management must be applied throughout the entire life cycle of the network—that is, through all the changes that occur during the life of the network.

The new standard has three main portions: roles and responsibilities, life cycle risk management in medical IT networks, and document control.

Roles and Responsibilities

Roles and responsibilities are defined with the focus on the key role of the medical IT network risk manager. The risk manager is responsible for the management of the entire risk management process and the execution of the process to maintain the key properties. Again, the aim is to address the key properties of safety, effectiveness, and data and system security to protect the patient.

The risk manager is tasked with bringing a cross-functional team together to completely assess the clinical need, technical requirements, and network interoperability. This same group will also be needed to help implement any solutions. This group includes care providers, the medical device manufacturer, IT equipment manufacturer, regulator stakeholders, clinical/biomedical engineering, IT, facilities, purchasing—basically representing all functions and stakeholders that are involved with or using the network. IEC 80001-1 points out that these groups must work together to proactively understand the risks and benefits as well as to manage them to be safe and effective.

Another part of this is the responsibility agreement (or contract) with medical device manufacturers and IT technology providers to obtain the information necessary for the process. Each risk management project starts with a list of medical devices and IT equipment. It will show the intended use of the medical devices and their required performance/configuration, and it lists the documents and technical information to be supplied for risk management, any residual risk documentation, the name of responsible parties, the scope of activities, and a definition of roles and responsibilities in event management. The medical device manufacturers will need to make available technical information appropriate to the creation of risk management documentation. The manufacturer might see certain technical information as sensitive in nature, but this can be protected with a confidentiality agreement as part of the responsibility agreement.

Risk Management and Document Control

Briefly, life cycle risk management in medical IT networks covers the process itself, defining:

• Risk management policy, process, planning, and documentation;
• Specific project information that includes risk analysis, evaluation, control, residual risk evaluation, and reporting;
• Change-release and configuration management; and
• Live network risk management with monitoring and event management.

Document control is mostly the risk management file, which is the set of records and other documents that are produced by a risk management project. The file includes the responsibility agreements, risk project and network descriptions, and all configuration documentation.

IEC 80001-1 is a support mechanism that will facilitate the adoption of HIT and the EHR. One of the key areas addressed by the standard is the development of a change-release management process to ensure all changes to the IT network are assessed, approved, implemented, and reviewed in a controlled manner. This will make sure changes are delivered, distributed, and tracked, leading to release of the change in a controlled manner with appropriate input and output and configuration management. Whew! Sounds great! At first it does sound like a lot, but what are the trade-offs? Is it worth it to preserve patient well-being? Once you can dig into the standard and look at the flow of risk management piece by piece, it is pretty clear. After establishing your process and running through it once or twice, it will get easier. Check out the Internet and use any tools, templates, and guidelines to your advantage—why reinvent the wheel? By ensuring that network risks are managed, you will have a solid foundation to grow your HIT and EHR system!

EHR Incentive Programs

You can find out more about the EHR Incentive Programs from the Department of Health and Human Services’ Centers for Medicare and Medicaid Services Web site. From the main page of www.cms.gov, navigate to the Regulations and Guidance section linked in the middle of the page. From there, click on EHR Incentive Programs, which will take you to the official Web site for the Medicare and Medicaid EHR incentive programs. There you will find the entire 864-page final rule, or the 276-page version, as it appeared in the Federal Register. (42 CFR Parts 412, 413, 422 et al. Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule).

There are also several summaries and training documents. Scroll down to discover the other documents posted.

---

Jeff Kabachinski, MS-T, BS-ETE, MCNE, is a contributing writer for 24×7. For more information, contact .