Download CDRH Regulated Software - Sterling Medical Devices

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
October 2011
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
October 2011
John F Murray Jr
2
CDRH Software Regulatory Scope
• 
• 
• 
• 
• 
Medical Device Software
Production System Software
Quality System Software
Electronic Records Software
Clinical Investigations Software
October 2011
John F Murray Jr
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
October 2011
John F Murray Jr
4
Software can be stored and delivered as a:
CD
EPROM
Floppy Disk
October 2011
Memory Stick
Internet Download
John F Murray Jr
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
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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."
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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."
October 2011
John F Murray Jr
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.
October 2011
John F Murray Jr
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
October 2011
John F Murray Jr
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
October 2011
John F Murray Jr
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
October 2011
John F Murray Jr
21
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
October 2011
John F Murray Jr
22