FDA's New Push on Software as a Medical Device

Written by Jeff Boatman - CQA and Sr. Subject Matter Expert at QPharma

On October 26, 2006, FDA issued a Warning Letter to Patterson Technology of Effingham, IL, for marketing an adulterated medical device. That "device" was their EagleSoft patient recordkeeping software package (I am passingly familiar with EagleSoft: my dentist uses it). In that Letter, FDA claimed that EagleSoft constituted an "unclassified" medical device, subject to GMPs and Design Controls (21 CFR 820.30(a)(2)(i)).

Immediately after this Letter was issued, I received a number of inquiries both directly from software companies and through associates. What did this Letter mean? How can software which does not itself "treat, diagnose, or mitigate a disease or function" (21 U.S.C. 321) possibly be a medical device? And what does it mean to be an "unclassified" device, when the Safe Medical Device Act specifies that within the United States, a Medical Device is always Class I, Class II, or Class III?

My short-term advice was: you should have basic quality systems in-place anyway, you should be doing design controls anyway. In my opinion, FDA had no legal authority to issue such Warning Letters since there was no such thing as an "unclassified" device in the Act but hey, that didn't stop them from going after a company marketing identification tags for subdermal implantation and pursuing them for years in the courts, only to finally have a judge rule that no way did Congress give FDA that authority. But since you should be doing these basic quality things anyway, don't bother fighting it.

Meanwhile, the number of software applications that potentially touch upon the medical care of the public has absolutely exploded. This is especially true in two areas: handheld devices used by Sales Reps to collect and transmit patient information (directly or through physicians), and web-based "cloud" systems.

This year, John Murray, CDRH's Subject Matter Expert on software (and therefore the person who largely determines FDA's policy on software enforcement) has been particularly busy. He has drafted a number of new guidance documents, including off-the-shelf software used inside medical devices and "cybersecurity" (more a list of topics than an actually useful guidance, IMHO...sorry, Mr. Murray). But his biggest contribution, hands-down, was a video he made earlier this year, CDRH Regulated Software: An Introduction.

In this video, Mr. Murray clarifies that he (meaning, of course, FDA) has determined that... (Click to read more) 
...any software application, regardless of its origin or functionality, that is used in connection with the diagnosis, treatment, or mitigation of a disease or condition will automatically be considered a medical device. This goes far beyond any previous definition by the Agency; General Principles of Software Validation, for example, talks about the regulated impact of software that is used inside a computerized medical device as well as software used to manufacture a device (this would also apply to drugs under 211.68) and the very general "quality system" validation requirement under 820.70(i). But to say a software app is subject to GMPs is a far cry from saying that the application is itself a medical device.

Mr. Murray goes on at some length defining different types of software that would be a device. Software that is used to maintain records of a patient's treatment, or which are used to determine treatment (so that covers the EagleSoft situation). Software that is used to collect or transmit information that is then used to design a medical device or drug for a patient (I was recently on a project directly related to this, which I'll describe in a moment). Software that analyzes or transforms analytical data to assist in diagnosis (that's a more obvious and traditional definition).

But then what? Okay, so that software application that captures MRI images and analyzes them to produce data files that result in a joint implant specifically for patient Joe Arthritis is a "medical device," subject to Design Controls and a general quality system. That's useful information, and it's useful to know that FDA may be looking over your shoulder. But does that mean you must register as a medical device developer or manufacturer (which, by the way, isn't free anymore)? What exactly will be the policy on determining the all-important class of the device, especially if you are marketing or distributing the software independent of a traditional medical device? I still don't understand what Patterson's obligation would be today as far as having to actually file a submission...would EagleSoft be considered a Class I device, subject to Design Controls because of the "automated devices" provision of 820.30? Surely it cannot be Class II (what on Earth would be the pre-1977 predicate device)? Where in 21 CFR 862-892 is this covered, other than a handful of very narrow, indication-specific cases? Does this mean patient care software that is not pre-classified (as is true in almost all cases) and involves any significant risk - even if it is not itself diagnosing or treating a patient - will require a full-blown Premarket Approval? Is that really in the interest of the healthcare industry, and more narrowly, is that really within the legislative intent of Congress?

In another project I worked on, a client developed a small program that converted the results of a In-Vitro diagnostic device, designed for an adult, into the corresponding values that "would have been" recorded for a pediatric patient. This was done as part of an IDE on the main device by the device manufacturer; that's a pretty clear review and approval pathway. But what if this software had been produced by a completely different company - what class would this "device" be? Is FDA really expecting a flood of submissions for these types of applications - and are they even prepared for it?

And is this being done because it is fully within the existing framework of U.S. law and regulations, or just to parrot the E.U.'s new (well, 2007, but just finally approved) Medical Device Directive, which includes a lot of these same definitions?

Don't get me wrong: I do appreciate Mr. Murray's concerns for patient safety. The number and complexity of software applications that could impact the public health has grown far faster than the existing regulatory apparatus could have predicted. What worries me is that these policies are being developed on the assumption that existing laws and regulations already adequately address this new paradigm, and I have serious doubts about that. It seems to me that the proper channel is to promulgate a new regulation (and, heaven forbid, perhaps even ask Congress for a refinement of the SMDA) and run this through the usual process of public comment, and not to spring this on an unsuspecting and unprepared industry through guidances and Internet videos. At the very least, a comprehensive guidance document should have been published in the Federal Register before declaring new a policy. I fear that this is going to result in the same mass confusion as happened when CDRH tried to single-handedly run Part 11, resulting in myriad guidances that far exceeded the original scope in 11.1 or, for that matter, the predicate Electronic Records and Electronic Signatures in Interstate and Global Commerce Act (which was merely to demonstrate that an electronic record was equivalent to a paper record).

And we all know what happened in that case: Part 11 was, in effect, taken away from CDRH in 2003. In his video presentation, Mr. Murray declares that a paper-based patient record is not a medical device, but the same record stored or transmitted electronically is. Is this deja vu? I fear that if CDRH wages a one-man campaign of new requirements and obligations for software not classically considered "devices," history may repeat itself.