LII:Medical Device Software Development with Continuous Integration/Defining Medical Device Software

-----Return to the beginning of this guide-----

What is medical device software?

Globally, when writing software for medical purposes, that software may or may not be subject to regulatory scrutiny. In the U.S., we may or may not be required to submit an application for Food and Drug Administration (FDA) 510(k) Premarket Notification. What does this mean? How do we know? Its all a little confusing. It was time to consider a series of articles on the subject.

Regarding medical device software, the global IEC 62304 standard on the software life cycle processes of medical device software states it's a "software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right." In the U.S., the FDA states that "any software that meets the legal definition of a [medical] device" is considered medical device software. A similar "software can be a medical device" interpretation was also made by the European Union in 2007 with an update to its European Medical Devices Directive, when "used specifically for diagnostic and/or therapeutic purposes."

All these definitions refer to such software as a medical device. I also chose to navigate through 21 CFR Part 820.30 on design controls in quality system regulation; however, this regulatory code also deals with medical device classification, something that should be left to the FDA and other regulatory entities, not a design team working on the quality system. We are not fully qualified to determine whether or not we are working on a medical device, let alone what classification it is. Left on our own, we can likely come up with many great excuses as to why we think our product is not a medical device!

View as a medical device

In 21 CFR Part 820.30 on design controls, we are presented with the following:

(a) General. (1) Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.

(2) The following class I devices are subject to design controls:

(i) Devices automated with computer software; and

(ii) The devices listed in the following chart.

Section	Device
868.6810	Catheter, Tracheobronchial Suction.
878.4460	Glove, Surgeon’s.
880.6760	Restraint, Protective.
892.5650	System, Applicator, Radionuclide, Manual.
892.5740	Source, Radionuclide Teletherapy.

In Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations, author Thomas H. Faris offers us a definition of a medical device:

Medical Device: Any equipment, instrument, apparatus, or other tool that is used to perform or assist with prevention, diagnosis, or treatment of a disease or injury. As an industrial term of art, a “medical device” typically relates to a product that the FDA or other regulatory authority identifies as a regulated device for medical use.

I’ve been contemplating a detailed writeup on this subject, but I haven’t had a good idea of where to begin, especially since my own regulatory experience is, at best, limited. Today I stumbled upon this article on the subject over at MEDS Magazine. Author Bruce Swope offers a little bit of insight on the three medical device classifications:

Generally, these three classes are determined by the patient risk associated with your device. Typically, low-risk products like tongue depressors are defined as Class I devices, and high-risk items like implantable defibrillators are defined as Class III devices. The marketing approval process is usually determined based on a combination of the class of the device and whether the product is substantially equivalent to an existing FDA-approved product. If the device is a Class I or a subset of Class II and is equivalent to a device marketed before May 28, 1976, then it may be classified as an Exempt Device. A 510(k) is a pre-marketing submission made to the FDA that demonstrates that the device is as safe and effective (substantially equivalent) to a legally marketed device that is not subject to Pre-market Approval (PMA). For the purpose of 510(k) decision-making, the term “pre-amendment device” refers to products legally marketed in the U.S. before May 28, 1976 and which have not been:

• significantly changed or modified since then; and
• for which a regulation requiring a PMA application has not been published by the FDA.

PMA requirements apply to Class III pre-amendment devices, “transitional devices” and “post-amendment” devices. PMA is the most stringent type of product marketing application required by the FDA. The device maker must receive FDA approval of its PMA application prior to marketing the device. PMA approval is based on the FDA’s determination that the application contains sufficient valid scientific evidence to ensure that the device is safe and effective for its intended use(s). For some 510(k) submissions and most PMA applications, clinical performance data is required to obtain clearance to market the device. In these cases, trials must be conducted in accordance with the FDA’s Investigational Device Exemption (IDE) regulation.

Ultimately, however, we cannot classify our own medical device software. That is the job of the FDA, which has offered guidance and driven regulation on medical software as a medical device over the years.