CDRH Regulated Software Looking back, looking forward

CDRH Regulated Software

Looking back, looking forward

John F Murray Jr

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.

CDRH Software Regulatory Scope

•  Medical Device Software

•  Production System Software

•  Quality System Software

•  Electronic Records Software

•  Clinical Investigations Software

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

Software can be stored and delivered as a:

CD EPROM Memory Stick

Floppy Disk Internet Download

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

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.

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.

1991 Software Premarket

•  REVIEWER GUIDANCE FOR COMPUTER-

CONTROLLED 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 computer-

controlled 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."

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

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.

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

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.

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

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.

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

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

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.

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

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

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

CDRH Software Questions

•  My email address is

–  [email protected]

•  John F Murray Jr

–  Medical Device Software Compliance Expert

–  United States Food & Drug Administration

–  301-796-5543