Lessons from McKesson: Insight into FDA’s Stance on Clinical Decision-Support Software

The Class I recall of McKesson's Anesthesia Care software provides clues as to what FDA considers to be high-risk clinical decision-support software and high-risk bugs.

By Bradley Merrill Thompson

On March 14, 2014, FDA notified healthcare professionals of a Class I recall that McKesson initiated in 2013 of its Anesthesia Care software. Because FDA rarely issues a recall notice of that nature with regard to standalone software—software that does not play a role in operating a medical device—there are some important insights about FDA’s stance on clinical decision-support software (CDS) that we can derive from its action. 

The recall classification gives us some clues as to what FDA considers to be high-risk clinical decision support software, and high-risk bugs that might be found in that CDS. More specifically, FDA considers software that helps highly trained anesthesiologists make clinical decisions with regard to such things as spotting the potential for adverse drug reactions to be in the moderate range of the risk scale. And when it comes to defects, FDA concludes that a bug that populates a patient's record with the wrong data, for example, creates significant risk. When you combine those two factors, you get a Class I recall.

At a time when Congress is actively considering exempting CDS from FDA regulation, this recall helps us understand FDA’s current thinking. And the recall will get all the more attention because the company conducting the recall is a public supporter of the legislation that would deregulate the software being recalled.

What Does the Software Do?

McKesson explains its software as follows:

The McKesson Anesthesia Care system is a computer-based system, which collects, processes, and records data both through manual entry and from monitors which themselves are attached to patients, such as in the operating room environment. The McKesson Anesthesia Care system provides clinical decision support by communicating potential adverse drug event alerts proactively during the preanesthesia evaluation and at the point of care. The McKesson Anesthesia Care system is generally indicated in the anesthetizing environment when the anesthesia provider decides to perform a patient assessment, to generate a paper and/or electronic record of the administration of anesthesia to a patient, and to document care.

On its face, that sounds somewhat similar to an electronic health record (EHR) in the sense that McKesson highlights the recording of information. Indeed, in its brochure, McKesson emphasizes benefits to the hospital in terms of a better record, together with coding and other features that improve reimbursement. The brochure also stresses cost savings by suggesting that physicians and other caregivers will be much more efficient because the doctor will have to spend less time between procedures doing paperwork because she can, in effect, create the written record during the operation.

While most of these claims sound fairly benign, the brochure also touts the opportunity to detect potential adverse drug interactions. The brochure suggests that this can be accomplished both before the surgery begins as the anesthesiologist is previewing the case, as well as during the procedure. The software is designed to allow direct data entry from body sensors, although there is also an opportunity for manual entry. Presumably for it to work, the software has to meet certain standards for interoperability.

The software does contain some more sophisticated analytics, but those are focused more on population assessment for the hospital’s benefit. The software provides “performance analytics of organizational and clinical trends, including utilization, quality, and cost.”

Data Problems at the Root of the Recall

Back in 2012, FDA granted premarket clearance to the Anesthesia Care software, placing it in Class II. More specifically, FDA classified the software together with the underlying anesthesia delivery equipment under section 868.5160, covering, “Gas machine for anesthesia or analgesia.” This is not altogether unusual for clinical decision-support software because the FDA doesn’t have many specially targeted classifications just for CDS.

In March 2013, however, McKesson voluntarily initiated a recall after a customer reported to McKesson that on February 8, 2013, the data displayed did not match the actual patient data when the case was recalled in the anesthesia care record. Instead, the displayed data included data from another patient. Fortunately, nobody was hurt.

McKesson concluded that the recall should be placed in Class II, which according to FDA’s definition means the product “may cause temporary or medically reversible adverse health consequences or where the probability of serious adverse health consequences is remote.”

But that wasn’t the end of McKesson’s troubles. In August 2013, another customer reported of a malfunction. In this instance, according to McKesson’s report to FDA, the “user was unable to retain any medical history comments in the medical history screen of preanesthesia evaluation (pae) application.” 

Just two months later, another malfunction was reported. The report McKesson filed with FDA explained that a customer had reported a “loss of data between our company's software application and another vendor's physiological device.” McKesson’s investigation apparently pointed to the use of a particular operating system, the name of which has been redacted from the report.

In March 2014, FDA took action. FDA advised McKesson that a Class I recall was a more appropriate description. Based on FDA’s risk assessment focused on the first adverse event report—in fact, I understand that FDA actually made its decision before the other two adverse events were even reported—the agency declared that this recall merited its most stringent and demanding classification. 

FDA’s Previous Classification of Standalone Software Recalls

Class I recalls of standalone software are pretty rare. In May 2012, FDA placed in Class I a recall conducted by Baxa Corp. (acquired by Baxter Corp.) for its Abacus total parenteral nutrition calculation software. The software was reportedly producing dosing errors associated with ordering parenteral nutrition for patients. In FDA’s eyes, those dosing errors could lead to serious injury or death for the patients. FDA regulates this product under product code LNX, Medical Computers and Software, a preamendment category. That means the broad category of medical computers has been around since before the 1976 Medical Device Amendments, and FDA has not gotten around to classifying them officially.

Prior to that, FDA posted a Class I recall notice for Misys Healthcare Systems laboratory information system software, used to manage patient specimens, in December 2003. According to the recall report, use of the defective software could result in the release of laboratory test reports without quality assurance validation and without abnormal results flags for critical values and abnormal results. Like the Abacus product, this is a preamendments product that FDA has not classified.

Class II recalls of standalone software are more common, however. Recent examples include:

  • GE Healthcare Solar 8000M and Solar 8000i patient monitor software and its patient data module. The software acquires physiologic parameter data such as ECG, invasive pressure, noninvasive blood pressure, pulse oximetry, temperature, cardiac output and respiration. There was a potential safety hazard with the automatic-view-on-alarm feature, which would stop functioning under certain circumstances. 
     
  • Siemens CentraLink data management system. A multisystem data manager for instruments and lab automation systems, the CentraLink software consolidates data from all connected instruments so that an operator can review and edit patient and quality control results from a single location. Siemens reported that, “under extremely rare circumstances, a patient result that had been previously disabled may be released without proper review.” 
     
  • Carestream Vue PACS. This image-management system will archive, distribute, retrieve, and display images and data from all hospital modalities and information systems. The recall was prompted because under certain circumstances, “some images from multislice studies such as CT and MR may not load into the viewer application.” 

Some Class II recalls involve a bug that would cause the software to stop functioning, which could be a problem if it happens at an inopportune time. It’s a fundamentally different risk, however, from a piece of software that appears to be functioning but is actually providing incorrect information.

Interestingly, the Misys Class I and Siemens Class II recalls both involve premature release of information, which makes me wonder why they are in different classes. But we don’t have all of the information that FDA would have considered when it assigned the recall classifications.

Why You Should Care about the McKesson Recall

Now let me return to the policy implications of all of this, and why this recall is so important. This is a time of great uncertainty for the future regulatory approach to CDS. Right now, we are awaiting an FDA report to Congress that presumably will spell out the agency’s high-level thoughts on how CDS should be regulated. Congress required the report as part of section 618 of FDASIA; it was due in January of this year, but we understand that FDA hopes to be done with the report toward the end of March.

At the same time, some members of Congress have become impatient and have already introduced legislation to remove CDS from all FDA regulation. The SOFTWARE Act introduced in the House of Representatives and the PROTECT Act introduced in the Senate would both have that effect.

FDA has also said that, in addition to the report to Congress, the agency has plans to develop a guidance document describing those categories of CDS the agency plans to regulate. Publishing that draft guidance is a part of the FDA agenda for fiscal year 2014. Presumably, the agency contemplates going into a greater level of detail in that guidance document than the agency will in the report to Congress.

What’s the Lesson from McKesson?

So, while we wait for all of this to play out, along comes this recall. And the recall actually gives us a very good opportunity to more clearly understand FDA’s position on how it should regulate CDS and the associated risks of the software.

The McKesson Anesthesia Care software product seems to be pure clinical decision-support software, albeit with the option to download data automatically from various sensors. From the company’s description, the software simply provides analytic decision support, as opposed to software that controls the operation of another medical device or is designed and marketed to pair with a specific, branded medical device to analyze data from that device.  The software does not automatically control the anesthesia equipment; it simply informs the anesthesiologist. 

The issue with the McKesson software is a classic one that has been identified with electronic health records (EHRs): a bug that substitutes one patient's information for another patient’s data. So far, FDA has chosen not to regulate EHRs, despite taking the position that EHRs qualify as medical devices. So, if this problem were to happen with an EHR, presumably FDA would not get involved in the recall; it would simply leave it to the manufacturer to handle. But here, given the significance that FDA attaches to the functionality of the software—informing the decision of an anesthesiologist looking for a possible adverse drug reaction—this type of bug is enough to place the recall in the highest risk category. That's a big deal.

Now let me take those narrow conclusions and express more general observations.

  1. FDA seems to be saying that, in the right circumstance, a mere database lookup engenders risk, if the user is dependent on it. In McKesson’s case, the fact that the doctor uses the software during surgery where she may not have the opportunity to consult other records probably plays a role in FDA putting this software in Class II. I wonder if the FDA’s regulatory treatment of the software would be the same if the software merely aided the anesthesiologist before the procedure and not during it.
     
  2. FDA also seems to be saying that even clinical decision-support software aimed at supporting the most educated of healthcare professionals can be high risk if that dependency exists.
     
  3. FDA is highly concerned about failures that are not obvious to the user, where the user would not have reason to become suspicious or investigate further. A software error that simply replaces one person’s data with another may not be obvious to the user, and in this case could lead the doctor to provide the wrong treatment at a very critical juncture.

Bottom line, when all of these factors collide, FDA treats the risk as great.

Conclusion

Clinical decision-support software comes in many different shapes and sizes. Some software produces absolutely no risk to the patient while other types of CDS, if they malfunction, could lead to patient harm. For the last couple of years, as software developers have created a tidal wave of CDS, many have been working diligently to figure out how to distinguish high- from low-risk software. The challenge is that there are an incredible number of factors that impact the risk of software and drawing bright lines is exceedingly difficult.

It would seem that FDA does not plan to simply walk away from regulating high-risk CDS. FDA has to know that by placing this recall in the highest risk classification, members of Congress will take note. As we debate whether to remove by statute all CDS from FDA oversight, we need to decide as a society whether we want FDA to protect us from, for example, the risk that a physician could miss a drug interaction by relying on software that contains a bug and, in turn, put the patient’s life at risk.

These are not easy issues, and the distinction between high- and low-risk CDS has so far proven difficult to discern. The stakes are quite high, so we need to be careful how we proceed. While protecting the patient is paramount, we need to figure out how to do so with the lightest regulatory touch because the patient also needs future innovation in this important field of software development. While we try to sort that out, this recall gives us all food for thought.

Brad Thompson is a member of the firm at Epstein Becker & Green, P.C., where he counsels medical device, drug, and combination product companies on a range of FDA regulatory, reimbursement, and clinical trial issues. He also heads up the firm's Connected Health Initiative, and blogs for mobihealthnews.com. 
 

 

 

 

 

[image courtesy of SUMETHO/FREEDIGITALPHOTOS.NET]