The recent recall (links below) for McKesson’s Anesthesia Care system raises interesting questions about potential information system failure modes as well as what system/software functions cross the imaginary line between unregulated EHRs and regulated medical devices.
First the facts. The FDA announced McKesson’s voluntary recall of its Anesthesia Care system in several on-line (here, here and here) postings. This trio of postings is interesting because the first links only to the second, the second does not link to either of the other two. The third also does not link to the other two, and was not part of any of the announcements, but it is the most complete.
The statement of the reason for the recall is that, “There was an occurrence where the patient case data did not match the patient data when the case was recalled in the anesthesia care record (ACR) in that it included data from another case." It was further noted that, "Use of this affected product may cause serious adverse health consequences, including death.” In the third link the FDA identifies the product as,
"...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 system provides clinical decision support by communicating potential Adverse Drug Event alerts proactively during the pre-anesthesia evaluation and at the point-of-care. The 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."
At this recall posting, the FDA identified the cause of the data mix-up as a software design problem. In response to my inquiry to McKesson for additional information on this matter they referred me to www.fda.gov which is not exactly helpful since this is, of course, the FDA's main home page.
The kind of misfiling of patient data seen here is an often identified potential problem of all patient data systems including EHRs, or EHR-like products. Related problems are patient data simply getting lost (as opposed to e-filed elsewhere) or garbled/changed. An example of lost is an earlier McKesson recall of an imaging archiving system in which when merging two patient records into one the resulting patient record, "...is missing the Contrast Allergy information for the second patient record," i.e., part of the data disappeared. Examples of changed are included in my recent discussion of two reported EHR errors in which an entry in inches was converted to centimeters, and 2.5 entered the record as 25.
The McKesson Anesthesia Care recall was determined by the FDA to be Class I which by definition means that there is, “...a reasonable probability that the use of or exposure to a violative product will cause serious adverse health consequences or death.” Violative here expressly means that the device is not in compliance with the laws and regulations administered by the FDA. Presumably a system cannot be violative unless it is in fact a medical device that was subject to these laws and regulations in the first place. This then raises the interesting question of what made this system a medical device as compared with other EHR or patient record products that are not being regulated as medical devices. In this regard McKesson's explanation of what the McKesson Anesthesia Care system is that it is an "Anesthesia Information Management System (AIMS) that streamlines anesthesia preoperative and intraoperative workflow. This anesthesia information management system supports fast, accurate clinical documentation and helps to reduce the risk of medication errors."
Besides the recall, that the McKesson Anesthesia Care system is a medical device is further illustrated by the fact that at least Version 15.0 was brought to market under the FDA's 510(k) process. According to the FDA 510(k) record it was cleared in April, 2012 under the product code BSZ, Gas Manchine, Anesthesia. What is not in the public record is how this route to market came to be, or whether there were earlier versions that were not FDA cleared. In this regard some version of McKesson Anesthesia Care was available as early as 2008, as noted here. The Gas Machine designation is also curious since McKesson does not actually provide the gas machine but only the information system. Unfortunately the 510(k) record does not include the usual 510(k) Summary which would provide some more details. This lack of a Summary is a deficit, and an inadvertent one I have been told, in the FDA 510(k) database in the time period.
So this information system is a medical device, but why? One reason may be that it functions as an accessory to a specific medical device, the gas machine, and accessories to medical devices are generally regulated with the same classification as the underlying device. The ability of the system to interface directly with monitors for data gathering may also play a role here as compared to the more common EHR-type product in which data is primarily entered by the human operator. If this is the case, then there might be interesting questions with respect to current efforts to have a variety of medical devices "communicate" directly with the EHR, which makes it begin to sound like a Medical Device Data System (MDDS) which is a regulated medical device. However MDDS's have restrictions that might put such functionality beyond that of an MDDS. That the McKesson Ansesthsia Care system also provides Clinical Decision Support (CDS) might also influence its status as a medical device. Although the FDA clearly regulates some CDSs, it has yet to declare that it can, should or will regulate all CDS. CDS is another overlap with EHRs which are mandated by Meaningful Use (MU) to provide CDS and yet EHRs are not regulated as medical devices. Note that the ONC created certification of EHRs for MU purposes is far different from FDA regulation based on it's safety mandate.
That this recall happened at all is another factor in the medical-device-or-not story. McKesson is said to have communicated directly with its customers with a Clinical Alert, and such communication is certainly a good thing. However a "clinical alert" is not necessarily a recall, and other information system providers might not be so diligent.
Mixed terminology can also cause confusion when such information reaches the end user. The official status of recall, in my opinion, raises the ante above that of other forms of voluntary communication. At the least it creates a public information stream, which is how I found out about it, which transcends the immediate issue to include general elucidation of the potential problems of patient data systems. Also on the subject of public information, I did not find anything on this alert/recall at McKessons's website which, unfortunately, is not uncommon for other manufacturers and recalls. I suppose one could argue that if you aren't a current customer you don't need to know about it, but I don't find that argument satisfactory.
This recall also re-raises the question, at least for me, of which patient data systems are or should be FDA regulated. This in turn reminds us that such regulation is not just a market gate-keeper function but also involves design controls, quality systems, postmarket surveillance, complaint handling, mandatory adverse event reporting (MDRs) , public disclosure --and of course recalls, all of which are or maybe absent in unregulated products.
I would equate this with FDA’s approach to other medical device connectivity systems where: 1) medical device data is acquired by the system, 2) device data, perhaps along with manually entered data, is used by software to produce calculated values, trends or graphics that are used for diagnosis, therapy decisions or patient care.
Such systems often start as unregulated products and as the market for the product matures, adoption grows, and patient risk becomes more self evident, the FDA eventually steps in and regulates - often framed as reclassifying the product from Class III to Class I or II.
The first cath lab data acquisition and reporting systems, interfaced to hemodynamic recorders and graphics tablets were not regulated. Nor were the first Labor and Delivery information systems that provided fetal monitor surveillance, annotation and archival. Ditto for early MDDS and alarm notification systems.
A possible exception to this was in the late 1980s when we developed an analog to the anesthesia information system for perfusionists operating heart lung machines during bypass. The product was created for the heart lung machine manufacturer who was already regulated. As the developers, we didn’t follow a Quality System, so I can’t imagine they got the product cleared prior to going to market.
I’ll bet a reader can tell us about when these anesthesia clinical information systems started getting regulated…
Hi Tim,
What an interesting post. Just yesterday I was having a conversation with a few people about EHR and FDA regulation. I asked the question, “If tomorrow the FDA required EHR software to be regulated, what would happen to the industry?”
The agreement in the car was that if they did regulate the EHR industry it would kill almost every EHR out there, which is why we don’t see it happening. Although, this is an interesting case that gets pretty close.
I’ll be doing a post on this soon. I’d love to hear your insight.
John, I’m curious to hear Bill’s opinion of the impact.
I would ask your fellow riders how many would be okay with losing a family member in a hospital due to an unsafe EMR and resulting sentinel event. Would they be okay with that?
We work in an industry that kills 200,000 of its customers every year. The people who think the cost of ensuring that EMRs are safe is too high - and we already know of cases where patients have been killed by faulty EMRs - should go work in an other industry.
The irony is that best practice for developing any kind of software is to follow a basic quality system similar to the FDA’s Quality System regulation. Apparently those who think FDA regs will kill the EMR industry must have an awfully low opinion of the quality of software written by most EMR vendors.
I’ll bet Cerner, who already has a lot of code regulated by FDA, will not miss a beat when FDA starts regulated parts of EMRs. Vendors who can’t write code at a software capability maturity model (CMM) level of at least 3 (out of 5) should be driven out of business for sheer incompetence.
One can’t help but think about the EMRs that run on a foundation of rickety code written 20 or 30 years ago. But even that can be mitigated by restricting that code to applications that don’t impact patient safety, like ADT, patient accounting, EVS, etc.
I’m sure those companies would gladly rework software that represents a patient safety risk - because they don’t want to kill patients.
What is it that EHR developers are not now doing (e.g. not having a quality system or design controls in place) that they would have to start doing if their products were regulated? In turn, is it acceptable that they are not now doing those things? And to get personal, do you want your own health care to be dependent on software systems developed by people who aren’t up to the challenge of being regulated?
The no EHR argument is I think nonsense. Capable vendors would step up and do their work in a manner compliant with regulations. This is the same as for MDDSs and other regulated computer/software medical devices. There are those that have chosen to do it consistent with regulation, and they have regulated devices in the market place.