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

From LIMSWiki
Jump to navigationJump to search
-----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."[1] In the U.S., the FDA states that "any software that meets the legal definition of a [medical] device" is considered medical device software.[2] 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."[3]

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[4]:

(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.[5]

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.[6]

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.[7][8][9]

References

  1. International Electrotechnical Commission (2006). "Medical device software – Software life cycle processes" (PDF). International Standard IEC 62304, First Edition 2006-05. International Electrotechnical Commission. https://webstore.iec.ch/preview/info_iec62304%7Bed1.0%7Den_d.pdf. Retrieved 27 April 2016. 
  2. Murray Jr., J.F. (March 2010). "CDRH Regulated Software: An Introduction" (PDF). U.S. Food and Drug Administration. http://www.fda.gov/downloads/Training/CDRHLearn/UCM209129.pdf. Retrieved 27 April 2016. 
  3. "Directive 2007/47/ED of the European Parliament and of the Council" (PDF). Official Journal of the European Union. European Union. 5 September 2007. http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF. Retrieved 27 April 2016. 
  4. "Title 21--Food and Drugs, Part 820--Quality System Regulation, Sec. 820.30 Design controls". CFR - Code of Federal Regulations Title 21. Food and Drug Administration. 21 August 2015. https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/CFRSearch.cfm?fr=820.30. Retrieved 27 April 2016. 
  5. Faris, T.H. (2006). Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations. ASQ Quality Press. p. 118. ISBN 0873896742. 
  6. Swope, B. (July 2011). "Executive Overview of FDA Medical Device Approval Requirements". MEDS Magazine. The RTC Group. http://medsmagazine.com/2011/07/executive-overview-of-fda-medical-device-approval-requirements/. Retrieved 27 April 2016. 
  7. Vogel, D.A. (2011). "Chapter 3: The FDA Software Validation Regulations and Why You Should Validate Software Anyway". Medical Device Software Verification, Validation, and Compliance. Boston, MA: Artech House. pp. 27–36. ISBN 9781596934238. https://books.google.com/books?id=LYxH-zUSOTgC&pg=PA27. 
  8. Office of Device Evaluation, Center for Devices and Radiological Health (9 September 1999). "Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices" (PDF). U.S. Food and Drug Administration. http://www.fda.gov/downloads/MedicalDevices/.../ucm073779.pdf. Retrieved 26 April 2016. 
  9. Center for Devices and Radiological Health (11 May 2005). "Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices". U.S. Food and Drug Administration. http://www.fda.gov/RegulatoryInformation/Guidances/ucm089543.htm. Retrieved 26 April 2016.