CDRH Regulated Software Looking back, looking forward Medical Device Software Compliance Expert US Food & Drug Administration at the Regulatory Affairs Professional Society Indianapolis, Indiana
Goal of this Presentation A brief history of how FDA has approached regulation of software, especially stand-alone software, will be provided. An overview of why FDA has the authority to regulate software and how this supports the mandate to protect public safety will be provided. FDA strategy and ongoing work will wrap up the presentation touching on topics such as: MDDS, mobile medical apps, clinical decision support tools, electronic health records, and CPOEs. Does not include FDA External Activities 2
CDRH Software Regulatory Scope Medical Device Software Production System Software Quality System Software Electronic Records Software Clinical Investigations Software 3
Medical Device Software Software that meets the legal definition "an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is: intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals 4
Software can be stored and delivered as a: CD EPROM Floppy Disk Memory Stick Internet Download 5
CDRH Software Time Capsule 1985 to 1987 Therac 25 1986 House Committee Meeting 1989 Draft software policy 1991 Pre market software guidance 1999 Off the Shelve Software Guidance 2002 General Principles of Software Validation 2005 Cybersecurity Software Guidance 2011 Medical Device Data System Rule 2011 Medical Device Mobile App Draft Guidance 6
House Committee on Science and Technology On April 26 1986, the Subcommittee on Investigations and Oversight, held hearings on the use of advanced computer systems in medical care. One topic raised at that hearing was FDA jurisdiction over such systems. The FDA did not testify, but did submit an unsigned statement for the record. While the statement contained no analysis of the jurisdiction issue, it stated: Medical software products that are marketed separately from a computer (generally referred to as stand alone software) and used with a computer to form a system which operates as a medical device will be treated as a medical device. FDA statement, p.7. 7
FDA Policy for the Regulation of Computer Products In 1989, FDA published a draft guidance document, FDA Policy for the Regulation of Computer Products, that explained how FDA planned to determine whether a computer-based product and/or software-based product is a device, and how FDA intended to regulate this device type. The document became known as the Draft Software Policy. Since 1989, however, the use of computer products and software products as medical devices has grown exponentially. Consequently, FDA determined that because of the history, complexity, and diversity of computer systems and controlling software, it would be impractical to adopt one software or computer policy to address all computer and software medical devices. The Draft Software Policy was withdrawn, official notice of which appeared in the Federal Register on January 5, 2005 (70 FR 824 at 890). An appropriate regulatory approach should depend primarily upon the risk the device poses to the patient should the device (software or hardware) fail to perform in accordance with its specifications. 8
1991 Software Premarket REVIEWER GUIDANCE FOR COMPUTERCONTROLLED MEDICAL DEVICESUNDERGOING 510(K) REVIEW SCOPE: This guidance applies to the software aspects of premarket notification [510(k)] submissions for medical devices. It should be note that "software" encompasses programs and/or data that pertain to the operation of a computercontrolled system, electronic system, data base, expert system, whether they are contained on floppy disks, hard disks, magnetic tapes, laser" disks, or embedded in the hardware of a device, usually referred to as "firmware." 9
1991 Premarket The FDA is receiving an increasing number of applications to market medical devices that depend on software. Most electrically powered medical devices now employ some form of computer control, and because computer-controlled systems are complex and difficult to test adequately, the FDA examines evidence from every phase of system development including the preproduction phases of computer program development. The FDA is focusing attention on the software development process to assure that potential hazardous failures have been addressed, effective performance has been defined, and means of verifying both safe and effective performance have been planned, carried out, and properly reviewed. FDA believes that, in addition to testing, device manufacturers should conduct appropriate analyses and reviews in order to avoid errors that may affect operational safety. 10
1991 Guidance This guidance presents an overview of: 1) the kind of information on software FDA reviewers may expect to be included in 510(k) submissions, and 2) the approach FDA reviewers should take in reviewing computer-controlled devices. The nature and depth of the software documentation should depend on: (1) the intended use and function of the device, (2) the effect on and risk to the patient of potential device faults, (3) the role of software in the device, and (4) the regulatory level of control assigned to the device by the classification- panels. These factors are expressed later in Section 2 of this document as the "level of concern." This guidance IS NOT a tutorial on software development, quality assurance, or testing, and IS NOT a standard for such activities. 11
1999 Off the Shelf Software Off-the-shelf (OTS) software is commonly being considered for incorporation into medical devices as the use of general purpose computer hardware becomes more prevalent. The use of OTS software in a medical device allows the manufacturer to concentrate on the application software needed to run device-specific functions. However, OTS software intended for general purpose computing may not be appropriate for a given specific use in a medical device. The medical device manufacturer using OTS software generally gives up software life cycle control, but still bears the responsibility for the continued safe and effective performance of the medical device. 12
General Principles of Software Validation This guidance outlines general validation principles that the Food and Drug Administration (FDA) considers to be applicable to the validation of medical device software or the validation of software used to design, develop, or manufacture medical devices. This final guidance document, Version 2.0, supersedes the draft document, General Principles of Software Validation, Version 1.1, dated June 9, 1997. 13
GPSV This guidance describes how certain provisions of the medical device Quality System regulation apply to software and the agency's current approach to evaluating a software validation system. For example, this document lists elements that are acceptable to the FDA for the validation of software; however, it does not list all of the activities and tasks that must, in all instances, be used to comply with the law. The scope of this guidance is somewhat broader than the scope of validation in the strictest definition of that term. 14
2005 Cybersecurity Guidance A growing number of medical devices are designed to be connected to computer networks. Many of these networked medical devices incorporate off-the-shelf software that is vulnerable to cybersecurity threats such as viruses and worms. These vulnerabilities may represent a risk to the safe and effective operation of networked medical devices and typically require an ongoing maintenance effort throughout the product life cycle to assure an adequate degree of protection. FDA is issuing this guidance to clarify how existing regulations, including the Quality System (QS) Regulation, apply to such cybersecurity maintenance activities. 15
2011 MDDS Rule FDA on its own initiative, is issuing a final rule to reclassify Medical Device Data Systems (MDDSs) from class III (premarket approval) into class I (general controls). MDDS devices are intended to transfer, store, convert from one format to another according to preset specifications, or display medical device data. MDDSs perform all intended functions without controlling or altering the function or parameters of any connected medical devices. An MDDS is not intended to be used in connection with active patient monitoring. FDA is exempting MDDSs from the premarket notification requirements. 16
2011 Mobile Apps Draft Guidance The Food and Drug Administration (FDA) is issuing this draft guidance document to inform manufacturers, distributors, and other entities about how the FDA intends to apply its regulatory authorities to select software applications intended for use on mobile platforms (mobile applications or "mobile apps"). Given the rapid expansion and broad applicability of mobile apps, the FDA is issuing this draft guidance document to clarify the types of mobile apps to which the FDA intends to apply its authority. At this time, the FDA intends to apply its regulatory requirements solely to a subset of mobile apps that it is calling mobile medical applications or "mobile medical apps." 17
Draft Mobile Apps Guidance As is the case with traditional medical devices, mobile medical apps can pose potential risks to public health. Moreover, mobile medical apps may pose additional or different risks due to the unique characteristics of the platform. For example, the interpretation of radiological images on a mobile device could be adversely affected by the smaller screen size, lower contrast ratio, and uncontrolled ambient light of the mobile platform; FDA intends to take these limitations into account in assessing the appropriate regulatory oversight for these products. This guidance clarifies and outlines the FDA's current thinking. The Agency will continue to evaluate the potential impact these technologies might have on improving health care, reducing potential medical mistakes, and protecting patients. 18
Is your software a device? The legal definition is based on the intent of the product The legal definition is not based on the engineering definition of software functionality The legal definition does not contain any reference to any specific hardware, software or information technology 19
Any product could become a device A popsicle stick A magnet A cell or IP phone A palm pilot An RFID chip If the intended use meets the legal definition of a device, then the product is a device 20
There is no definitive list The product spectrum is highly diverse and complex CDRH addresses each situation with a case by case evaluation A detailed review of the information available ( i.e. labeling claims, advertising matter, or oral or written statements by such persons or their representatives) A manufacturer determination is a separate question 21
CDRH Software Questions My email address is John.murray@fda.hhs.gov Medical Device Software Compliance Expert United States Food & Drug Administration 301-796-5543 22