Tackling Health IT Patient Safety Issues

An upcoming regulatory framework to address patient safety issues around health IT, including medical devices and electronic health records, needs to place an emphasis on cybersecurity concerns, says federal adviser Julian Goldman, M.D.

Before the government shutdown, the Office of the National Coordinator of Health IT, the Food and Drug Administration and the Federal Communications Commission were working on co-developing the risk-based regulatory framework for health IT, which is due in January. The effort was mandated by Congress in the Food and Drug Administration Safety Innovation Act of 2012.

Goldman is co-chair of the Food and Drug Administration Safety Innovation Act Workgroup's regulatory subgroup. The FDASIA workgroup is an advisory panel to the HIT Policy Committee of the ONC.

The committee recently approved the FDASIA workgroup's recommendations on key factors to consider when creating the regulatory framework.

"It's well understood that addressing security requires a constant vigilance and changes [for] monitoring of system components and addressing risks," says Goldman in an interview with Information Security Media Group [transcript below].

"When we think about the health IT system, including medical devices, the ability to effectively perform software maintenance and address newly identified cybersecurity threats is a key part of maintaining the integrity and safety of the system," he says.

Cybersecurity was discussed at length when drafting recommendations for the framework, Goldman says.

The ONC, FDA and FCC will consider the recommendations when they resume collaboratively developing a proposal for the framework.

One of the expectations, Goldman says, is the ability to monitor networks to identify unusual activity.

"It's essential to know whether data's being lost within a health IT system or whether the transformation of data is incorrect," he says.

For instance, the conversion of measurements could lead to potentially lethal doses of medication. "There's a need for comprehensive surveillance both at the core technology level, the performance of the system, and then also of the ability of the system to support clinical care," he says.

In the interview, Goldman also describes:

• The main themes of the workgroup's recommendations to the HIT Policy Committee;
• Key risks posed by health IT products that the workgroup addressed;
• Research by Partners HealthCare, an integrated delivery system in Boston, on various cybersecurity risks of implantable medical devices.

In addition to his role on the FDASIA workgroup, Goldman is medical director of biomedical engineering at Partners HealthCare. A practicing anesthesiologist at Massachusetts General Hospital, Goldman is also director of the hospitals' program on medical device interoperability. He also founded a federally funded, multi-institutional medical device interoperability research program in 2004 to promote innovation in patient safety and clinical care by leading the adoption of patient-centric integrated clinical environments.

Workgroup Activity

MARIANNE KOLBASUK MCGEE: Briefly describe what the workgroup was assigned to do?

JULIAN GOLDMAN: The workgroup is FDASIA, [which stands] for the Food and Drug Administration Safety Innovation Act Workgroup. The FDASIA working group was formed to provide recommendations to the Office of the National Coordinator's Committee on Health IT.

MCGEE: What was the main thrust of the recommendations that the workgroup made to the HIT Policy Committee?

GOLDMAN: When one looks at the larger picture here, we know that from an FDA regulatory perspective or a medical-device perspective there's a regulatory pathway for the traditional medical devices that we're all familiar with. It could be a blood-pressure monitor; it could be an implantable device like a pacemaker; it could be a whole range of medical devices. But there are also medical devices that people have been looking at, such as apps, telehealth devices, also health IT infrastructure and EHRs, and there has been a lot more confusion about whether those things should fall in or out of scope for I'll call it traditional FDA regulation.

A lot of the discussion in the committee was about formulating a pathway, and the working group made recommendations that it's important to clarify which elements or components of the health IT system are in and out of scope for more detailed regulation. Some of the key recommendations were related to clearly identifying what should be in and out of scope for regulatory consideration. Ideally, it would be possible to say that there are certain health IT-related technologies and applications which from the beginning one could identify as not needing to go through an FDA regulatory pathway. That was one of the main thrusts of the recommendations.

Other main thrusts were about addressing the regulatory ambiguities and duplication that exist today within the frameworks from the FDA, ONC or the FCC, and these are separate federal agencies that historically have not had a long history of collaboration around medical devices and health IT. Through the process of the working group's discussions, meetings and presentations, we attempted to identify a number of areas of regulatory ambiguity.

The other main thrust was to strongly consider better post-market surveillance of health IT products. We all recognized and discussed at length ... that without data, without understanding the performance of devices of health IT and understanding and identifying problems related to the device's use, we really can't improve the quality of health IT components and the safety of those components. Better post-market surveillance was another major thrust for the working group.

Key Risks Posed by Health IT

MCGEE: What are some of the key risks posed by health IT? How did the workgroup recommendations address that?

GOLDMAN: The workgroup identified a number of actual and/or theoretical risks from health IT and cited studies. For example, an increase in mortality in a study involving children is included in the final documentation that's freely available on the HHS website. Another key area of risk was identified as not only the potential for health IT to be misused or for health IT to not perform as intended in supporting clinical care, but also that the vision or the promise of health IT may not be fulfilled. Many members of the working group recognized that the inability of the marketplace to fulfill the vision of health IT is something that has to be addressed. It's in a sense too limiting to think about only addressing problems that are surfacing. We also have to look at the cost of the inability to innovate if regulation is heavy-handed or unclear and if, consequently, manufacturers are unable to deliver products to the marketplace to help us care for our patients.

Addressing Cybersecurity Risks

MCGEE: How do the recommendations address cybersecurity risks related to health IT? What are the risks, and what sorts of IT health products are most vulnerable to cybersecurity issues?

GOLDMAN: I would say that cybersecurity was a topic that was brought up frequently within the working group discussions, but the focus of the working group analysis was not specifically related to cybersecurity. There were many things that are related to cybersecurity and influence it. For example, it's well understood that security, or addressing security, requires a constant vigilance and changes [for] monitoring of system components and addressing risks. When we think about the health IT system, including medical devices in this case, the ability to effectively perform software maintenance and address newly identified cybersecurity threats is a key part of maintaining the integrity and safety of the system, and that was discussed at some length.

It was identified that the future regulatory framework should not preclude our ability to, number one, monitor the health of the system easily and identify and report problems; and, number two, to ensure that it's not burdensome to maintain the integrity of the components through whatever means is appropriate to address cybersecurity. Cybersecurity we all know is a complex topic. As part of our research program based at Partners HealthCare and Massachusetts General Hospital, our research program on medical device interoperability convened a group not too long ago to respond to the Government Accountability Office's request for information about the cybersecurity risks of implantable medical devices. [We] produced an analysis on a white paper for the GAO. In looking at and understanding security requirements, cybersecurity issues both with stand-alone medical devices and network medical devices is a key part of the activity of our ... research program.

Post-Market Surveillance

MCGEE: How does the workgroup recommend that post-market surveillance of HIT products be improved?

GOLDMAN: The workgroup spent considerable time discussing the importance of reporting health IT-related problems and the fact that not only should they be reported, but they have to be aggregated and resolved. In fact, the work kicked off with recognition and review of the Institute of Medicine report, which discussed the need for a more effective way to track, identify and track problems in medicine broadly. An exact or specific method of doing it was not part of the core recommendations, although the need for reporting was discussed.

Reporting is fairly complicated. It's a challenge whether it's related to medical devices, health IT or patient care in general. But in this case, there are unique challenges because if we look at the reporting, for example, of medical devices, if there's a problem with the medical device, [that] was in some way related to a patient injury or potential patient injury, we have a clear pathway to report that to the FDA. That reporting might be done by a medical practitioner, by a hospital or by a medical device manufacturer once they become aware of the problem.

But in the case of health IT, if the health IT components - the EMR, EHR, routers, switches, network infrastructure, whatever it might be - are not FDA-regulated medical products, then it's highly unlikely that problems will be reported to the FDA through a conventional pathway. When we look at a future regulatory framework and a way to maintain and improve the safety of health IT, we have to recognize that events will occur across a much wider space that's a regulated and non-regulated component space. The traditional method that's already in place of reporting to the FDA probably is not going to be sufficient unless the FDA changes the scope of its ability to receive reports, and we educate people about that.

The other part that's quite interesting as we look at the FDASIA working group activity is we can see linkages to other things that are occurring nationally in terms of national initiatives. For example, the FDA has had a pilot program on something called MDEpiNet, Medical Device Epidemiology Network. The idea of MDEpiNet is, in part, to leverage the EHR to record and document medical device-related problems. A commonly mentioned example is based on a pilot study from the National Children's Hospital, in which one can look at the EMR and identify that a ventilator was swapped out on a pediatric patient. Now normally, one does not change a ventilator when it's in use on a patient, so that helped to flag that potentially there was a problem with the device. It isn't hard to see the connection between detecting a device issue and then recording information. If you're using an EMR for that task, you would theoretically have physiological information about that patient and clinical information so one could ascertain whether the device problem was in some way related to affecting the patient's outcome or caused an injury.

Also, the other emerging activity is the FDA UDI, or unique device identifier, which is essentially a unique ID, like a license plate, for medical devices. As that starts to roll out in the next few years, it will enable EHRs to collect specific information that's the UDI from a medical device and have that as part of the record.

We're also seeing some of that thinking in meaningful use Stage 3 with regard to how to use the EHR to collect and facilitate reporting of adverse events. In these other discussions, much of the focus has been on adverse events related to patients. Historically, I should say, the discussion is about adverse events related to patients. Now we're talking about not only problems with devices and facilitating reporting of the device failure or problem, but we're also starting to look at ... identifying health IT components and system problems, and using the technology to identify and potentially report that. After all, we all know how common it is [that] we see in our consumer devices and our automobiles that they detect problems, [for example] the check-engine light comes on, and then we can download a code from the memory device within the car and it lets us know that the engine may have been misfiring or there's a problem with the anti-lock braking system. In other domains, we have an expectation that sophisticated electronic systems have some level of self-monitoring data storage and that facilitates reporting and analysis. Eventually, if you look, for example, at automobiles, the manufacturer identifies that there's potentially a broad problem and is able to fix that, and hopefully fix that before people are stranded in their cars somewhere.

Identifying Issues with HIT Products

MCGEE: How might improvements in post-market surveillance potentially help regulators or device makers better identify cybersecurity issues with HIT products?

GOLDMAN: If one looks at a typical IT network, there's an expectation that one can monitor the health of that network. It's an expectation that one can look at unusual activity, one can look at changes in network bandwidth, and it's possible to detect the early onset of a distributed-denial-of-service attacks, for example. Certainly there are many other things that can be detected when one monitors networks. Surveillance of a network and surveillance of inappropriate activity, or anything else that one could be looking for, is an essential part of modern networking technology, whether it's wired or wireless technology. The idea that that type of capability needs to be brought to health IT systems is a core part of the thinking. Surveillance is a key part of that, and surveillance of the health of the devices, their device performance, the health IT system performance, is part of it. That's real-time. Then, also [there's] surveillance and identification of problems. It's essential to know whether data's being lost within a health IT system or whether the transformation of data is incorrect. For example, the conversion of kilograms to pounds or pounds to kilograms, which could then be used for dosing of medications that are potentially lethal if not administered in the right dosages. These are problems that have been reported already. There's a need for comprehensive surveillance both at the core technology level, the performance of the system, and then also of the ability of the system to support clinical care.

MCGEE: Now that the workgroup made its recommendations, what's next in this process?

GOLDMAN: The workgroup made its recommendations and the workgroup reported those recommendations to the Health IT Policy Committee. That has been completed already and the Health IT Policy Committee has accepted those recommendations. Then, as the process moves along, these recommendations are going to be made available to the agencies that are responsible: ONC, FDA and FCC. They will work on the regulatory framework. There will be an opportunity for public comment and for further input into this. The FDASIA Act of 2012 calls for the HHS Secretary to post a report by January 2014 that contains the proposed strategy for a risk-based regulatory framework pertaining to health IT. We have a fairly short timeline for this work to be completed.