Contains Nonbinding Recommendations

Draft – Not for Implementation

Content of Premarket Submissions for

Device Software Functions
______________________________________________________________________________

Draft Guidance for Industry and

Food and Drug Administration Staff
DRAFT GUIDANCE

This draft guidance document is being distributed for comment purposes

only.

Document issued on November 4, 2021.

You should submit comments and suggestions regarding this draft document within 90 days of
publication in the Federal Register of the notice announcing the availability of the draft
guidance. Submit electronic comments to https://www.regulations.gov. Submit written
comments to the Dockets Management Staff, Food and Drug Administration, 5630 Fishers Lane,
Room 1061, (HFA-305), Rockville, MD 20852. Identify all comments with the docket number
listed in the notice of availability that publishes in the Federal Register.

For questions about this document regarding CDRH-regulated devices, contact the Digital Health
Center of Excellence at [email protected]. For questions about this document regarding
CBER regulated devices, contact the Office of Communication, Outreach, and Development
(OCOD) at 1-800-835-4709 or 240-402-8010, or by email at [email protected].

When final, this guidance will supersede Guidance for the Content of
Premarket Submissions for Software Contained in Medical Devices, May
2005.

U.S. Department of Health and Human Services

Food and Drug Administration
Center for Devices and Radiological Health
Center for Biologics Evaluation and Research
 Contains Nonbinding Recommendations

Draft – Not for Implementation

Preface
Additional Copies
CDRH
Additional copies are available from the Internet. You may also send an email request to CDRH-
[email protected] to receive a copy of the guidance. Please include the document number
337 and complete title of the guidance in the request.

CBER
Additional copies are available from the Center for Biologics Evaluation and Research (CBER),
Office of Communication, Outreach, and Development (OCOD), 10903 New Hampshire Ave.,
Bldg. 71, Room 3128, Silver Spring, MD 20993-0002, or by calling 1-800-835-4709 or 240-402-
8010, by email, [email protected] or from the Internet at
https://www.fda.gov/vaccines-blood-biologics/guidance-compliance-regulatory-information-
biologics/biologics-guidances.
 Contains Nonbinding Recommendations

Draft – Not for Implementation

Table of Contents

I. Introduction ............................................................................................................................. 1
II. Background ............................................................................................................................. 2
III. Scope ....................................................................................................................................... 4
IV. Definitions............................................................................................................................... 5
V. Documentation Level .............................................................................................................. 7
VI. Recommended Documentation ............................................................................................... 9
Documentation Level Evaluation ................................................................................... 11
Software Description ...................................................................................................... 11
System and Software Architecture Diagram .................................................................. 13
Risk Management File ................................................................................................... 15
Software Requirements Specification (SRS) ................................................................. 18
Software Design Specification (SDS) ............................................................................ 19
(1) Basic Documentation Level........................................................................................ 19
(2) Enhanced Documentation Level ................................................................................. 20
Software Development and Maintenance Practices ....................................................... 20
(1) Basic Documentation Level........................................................................................ 20
(2) Enhanced Documentation Level ................................................................................. 21
Software Testing as part of Verification and Validation................................................ 21
(1) Basic Documentation Level........................................................................................ 21
(2) Enhanced Documentation Level ................................................................................. 22
Revision Level History................................................................................................... 22
Unresolved Anomalies (e.g., Bugs, Defects, or Errors) ................................................. 23
VII. Additional Information ......................................................................................................... 23
Regulatory Considerations for Software Functions ....................................................... 23
Off-The-Shelf (OTS) Software Use in Medical Devices ............................................... 24
Comparison of Guidance to IEC 62304 and ANSI/AAMI/IEC 62304 .......................... 25
Appendix A: Documentation Level Examples ............................................................................. 27
Appendix B: System and Software Architecture Diagram Chart Examples ................................ 31
 Contains Nonbinding Recommendations

Draft – Not for Implementation

1 Content of Premarket Submissions for

2 Device Software Functions
3 ______________________________________________________________________________

4 Draft Guidance for Industry and

5 Food and Drug Administration Staff
6
7 This draft guidance, when finalized, will represent the current thinking of the Food and Drug
8 Administration (FDA or Agency) on this topic. It does not establish any rights for any person
9 and is not binding on FDA or the public. You can use an alternative approach if it satisfies the
10 requirements of the applicable statutes and regulations. To discuss an alternative approach,
11 contact the FDA staff or Office responsible for this guidance as listed on the title page.
12

13 I. Introduction
14 This guidance document is intended to provide information regarding the recommended
15 documentation sponsors should include in premarket submissions for FDA’s evaluation of the
16 safety and effectiveness of device software functions, which are functions that meet the
17 definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C
18 Act). 1 The recommendations in this guidance document pertain to device software functions,
19 including software in a medical device (SiMD) and software as a medical device (SaMD). 2
20 When final, this document will replace FDA’s Guidance for the Content of Premarket
21 Submissions for Software Contained in Medical Devices 3 issued on May 11, 2005, and it will
22 update FDA’s thinking related to the documentation FDA recommends sponsors include for the
23 review of device software functions in premarket submissions.
24
25 This guidance identifies the software information generally necessary for evaluating the safety
26 and effectiveness of a device in a premarket submission. The recommendations in this guidance
27 also may help facilitate FDA’s premarket review. This guidance describes information that

1
The term “device” is defined in 201(h) of the Federal Food, Drug, and Cosmetic (FD&C) Act to include an
“instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article,
including any 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 intended to affect the structure
or any function of the body of man...” and “does not include software functions excluded pursuant to section 520(o)
of the FD&C Act.”
2
See FDA website on “Software as a Medical Device (SaMD),” available at https://www.fda.gov/medical-
devices/digital-health-center-excellence/software-medical-device-samd.
3
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/guidance-content-
premarket-submissions-software-contained-medical-devices.

1
 Contains Nonbinding Recommendations

Draft – Not for Implementation

28 would be typically generated and documented 4 during software development, verification, and
29 design validation. The least burdensome approach was applied to identify the minimum amount
30 of information that, based on our experience, would generally be needed to support a premarket
31 submission for a device that uses software. During premarket review, FDA may request
32 additional information that is needed to evaluate the submission. For example, in order to
33 demonstrate a reasonable assurance of safety and effectiveness for devices that use software,
34 documentation related to the requirements of the Quality System Regulation (QSR) (21 CFR Part
35 820) is often a necessary part of the premarket submission. As part of QSR design controls, a
36 manufacturer must “establish and maintain procedures for validating the devices design,” which
37 “shall include software validation and risk analysis, where appropriate.” (21 CFR 820.30(g)).
38 The documentation recommended in this guidance is based on FDA’s experience evaluating the
39 safety and effectiveness of device software. However, sponsors may use alternative approaches
40 and provide different documentation so long as their approach and documentation satisfies
41 premarket submission requirements in applicable statutory provisions and regulations. For the
42 current edition of the FDA-recognized consensus standard(s) referenced in this document, see
43 the FDA Recognized Consensus Standards Database. 5 For more information regarding use of
44 consensus standards in regulatory submissions, please refer to the FDA guidance titled
45 Appropriate Use of Voluntary Consensus Standards in Premarket Submissions for Medical
46 Devices 6 and Standards Development and the Use of Standards in Regulatory Submissions
47 Reviewed in the Center for Biologics Evaluation and Research. 7
48
49 The contents of this document do not have the force and effect of law and are not meant to bind
50 the public in any way, unless specifically incorporated into a contract. This document is intended
51 only to provide clarity to the public regarding existing requirements under the law. FDA
52 guidance documents, including this guidance, should be viewed only as recommendations, unless
53 specific regulatory or statutory requirements are cited. The use of the word should in Agency
54 guidance means that something is suggested or recommended, but not required.
55

56 II. Background
57 The purpose of this guidance is to describe FDA’s thinking on the recommended documentation
58 sponsors should include in premarket submissions for FDA’s evaluation of the safety and
59 effectiveness of device software functions. This thinking recognizes recent changes to the FD&C
60 Act made by the 21st Century Cures Act (Cures Act), which amended section 520 of the FD&C
61 Act and excludes certain software functions from the device definition. It also considers the
62 rapidly evolving nature of digital health and recent FDA recognized consensus standards related
63 to software. This guidance, as described in Section III (Scope), is intended to complement other
4
As a reminder, manufacturers of device software must create and maintain software-related documentation in
accordance with the requirements of the Quality System (QS) Regulation (21 CFR 820.30 Subpart C – Design
Controls of the Quality System Regulation).
5
Available at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/search.cfm.
6
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/appropriate-use-
voluntary-consensus-standards-premarket-submissions-medical-devices.
7
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/standards-development-
and-use-standards-regulatory-submissions-reviewed-center-biologics-evaluation.

2
 Contains Nonbinding Recommendations

Draft – Not for Implementation

64 existing guidance documents that provide recommendations related to software, including the
65 guidance documents listed below. The following guidance documents represent a subset of FDA
66 guidances with digital health content 8 relevant to premarket software documentation activities.
67 Please note the list is not exhaustive and is subject to change:
68
69 • Multiple Function Device Products: Policy and Considerations 9
70 • Off-The-Shelf Software Use in Medical Devices 10,11
71 • Design Considerations and Premarket Submission Recommendations for
72 Interoperable Medical Devices 12
73 • General Principles of Software Validation 13
74 • Content of Premarket Submissions for Management of Cybersecurity in Medical
75 Devices 14
76 • Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS)
77 Software 15
78
79 FDA encourages the consideration of these guidances when developing device software
80 functions and preparing premarket software documentation.
81
82 The emergence of consensus standards related to software has helped to improve the consistency
83 and quality of software development and documentation, particularly with respect to activities
84 such as risk assessment and management. When possible, FDA harmonized the terminology and
85 recommendations in this guidance with software-related consensus standards, such as the
86 following examples. The following standards are not intended to represent an exhaustive list and
87 are subject to change:
88
89 • ANSI/AAMI/ISO 14971: Medical devices - Applications of risk management to
90 medical devices
91 • ANSI/AAMI/IEC 62304: Medical Device Software - Software Life Cycle Processes
92 (also referred to as “IEC 62304” in this guidance)
93 • ANSI/AAMI SW91: Classification of defects in health software
94

8
Available at https://www.fda.gov/medical-devices/digital-health-center-excellence/guidances-digital-health-
content
9
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/multiple-function-
device-products-policy-and-considerations.
10
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-
medical-devices.
11
See section VII.B to learn more about referencing Off-The-Shelf (OTS) Software Use in Medical Devices.
12
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-considerations-
and-premarket-submission-recommendations-interoperable-medical-devices.
13
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-
software-validation.
14
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-
submissions-management-cybersecurity-medical-devices-0.
15
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-
networked-medical-devices-containing-shelf-ots-software.

3
 Contains Nonbinding Recommendations

Draft – Not for Implementation

95 The Agency encourages the consideration of these FDA recognized consensus standards when
96 developing device software functions and preparing premarket software documentation.

97 III. Scope
98 For the purposes of this document, FDA refers to a software function that meets the definition of
99 a device as a “device software function.” For example, a device software function may control a
100 hardware device or be part of a hardware device 16 (i.e., Software in a Medical Device, or SiMD)
101 or be a device without being part of a hardware device 17 (i.e., Software as a Medical Device, or
102 SaMD). 18 For any given product, the term “function” is a distinct purpose of the product, which
103 could be the intended use or a subset of the intended use of the product. For example, a product
104 with an intended use to analyze data has one function: analysis. A product with an intended use
105 to store, transfer, and analyze data has three functions: (1) storage, (2) transfer, and (3) analysis.
106 As this example illustrates, a product may contain multiple functions.
107
108 This guidance is intended to cover:
109
110 • firmware and other means for software-based control of medical devices;
111 • stand-alone software applications;
112 • software intended to be operated on general-purpose computing platforms;
113 • dedicated hardware/software medical devices; and
114 • accessories to medical devices when those accessories contain or are composed of
115 software.
116
117 This guidance applies to all types of premarket submissions that include one or more device
118 software function(s). Premarket submissions include:
119
120 • Premarket Notification (510(k));
121 • De Novo Classification Request;
122 • Premarket Approval Application (PMA);
123 • Investigational Device Exemption (IDE);
124 • Humanitarian Device Exemption (HDE); and
125 • Biologics License Application (BLA).
126
127 This guidance does not apply to automated manufacturing and Quality System software 19 or
128 software that is not a device. For further information or to clarify the documentation
129 expectations, please contact the responsible FDA review division.
16
For the purposes of this guidance, a software function that is “part of a hardware device” is software used to
control a hardware device, or software necessary for a hardware device to achieve its intended use.
17
Ibid.
18
Additional resources on determining whether a software product contains device functions are provided in section
VII.A.
19
As part of Quality System Regulation production and process controls, 21 CFR 820.70(i) states, “When computers
or automated data processing systems are used as part of production or the quality system, the manufacturer shall
validate computer software for its intended use according to an established protocol. All software changes shall be
validated before approval and issuance. These validation activities and results shall be documented.”

4
 Contains Nonbinding Recommendations

Draft – Not for Implementation

130
131 Generally, the recommendations in this guidance apply to the device constituent part of a
132 combination product 20 (such as drug-device and biologic-device combination products) when the
133 device 21 constituent part includes a device software function. For more information, contact the
134 FDA review division that will have the lead review for the combination product.
135
136 Other FDA guidance documents may recommend additional software-related documentation for
137 inclusion in a premarket submission. For example, recommendations regarding cybersecurity
138 information to include in a device premarket submission can be found in the guidances Content
139 of Premarket Submissions for Management of Cybersecurity in Medical Devices and
140 Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software. 22
141 Section II (Background) references other relevant guidance documents that supplement the
142 recommendations contained in this guidance.
143
144 Device software functions subject to specific special controls may require additional software-
145 related documentation in a premarket submission. As applicable, please refer to the relevant
146 special controls for the device.
147
148 This guidance does not apply to the software-related documentation that may be needed to
149 evaluate postmarket software device issues, including corrections and removals.
150
151 While this guidance identifies the documentation sponsors should include in premarket
152 submissions, this guidance is not meant to provide recommendations regarding how device
153 software should be developed, verified and validated. For recommendations on device software
154 development, verification and validation, please consult software-related FDA recognized
155 consensus standards and other software-related FDA guidance documents mentioned in this
156 guidance (e.g., General Principles of Software Validation 23).
157

158 IV. Definitions

159 The following terms are used for the purposes of this guidance:
160
161 Device Software Function - Software function that meets the device definition in section 201(h)
162 of the FD&C Act. “Software as a Medical Device (SaMD)” and “Software in a Medical Device
163 (SiMD)” 24 are device software functions. As discussed above, the term “function” is a distinct

20
21 CFR 3.2(e).
21
Section 201(h) of the FD&C Act.
22
As part of the software validation and risk analysis required by 21 CFR 820.30(g), software device manufacturers
may need to establish a cybersecurity vulnerability and management approach, where appropriate. FDA
recommends that this approach include a set of cybersecurity design controls to ensure medical device cybersecurity
and maintain medical device safety and effectiveness. Such design controls may make it more likely that FDA will
find your device meets its applicable statutory standard for premarket review.
23
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-
software-validation
24
See footnotes 1 and 2.

5
 Contains Nonbinding Recommendations

Draft – Not for Implementation

164 purpose of the product, which could be the intended use or a subset of the intended use of the
165 product.
166
167 Off-the-Shelf Software 25, 26 - A generally available software component used by a device
168 manufacturer for which the manufacturer cannot claim complete software life cycle control (e.g.,
169 operating system, printer/display libraries).
170
171 Serious Injury 27- An injury or illness that:
172 1) Is life threatening,
173 2) Results in permanent impairment of a body function or permanent damage to a
174 body structure, or
175 3) Necessitates medical or surgical intervention to preclude permanent impairment
176 of a body function or permanent damage to a body structure. Permanent is defined
177 as irreversible impairment or damage to a body structure or function, excluding
178 trivial impairment or damage.
179
180 Software as a Medical Device (SaMD) 28, 29 - Software that meets the definition of a device in
181 section 201(h) of the FD&C Act and is intended to be used for one or more medical purposes
182 without being part of a hardware device. 30
183
184 Software in a Medical Device (SiMD) 31 - Software that meets the definition of a device in
185 section 201(h) of the FD&C Act, and is used to control a hardware device or is necessary for a
186 hardware device to achieve its intended use. Typically, SiMD is embedded within or is part of a
187 hardware device. 32
188
189 Software Verification and Software Validation - This guidance uses the terms “software
190 verification” and “software validation,” which are described in further detail below.
191
192 • For the purposes of this guidance, software verification is confirmation by objective
193 evidence that the output of a particular phase of development meets all the input
194 requirements for that phase. Software verification involves evaluating the consistency,
195 completeness, and correctness of the software and its supporting documentation, as it is
196 being developed, and provides support for a subsequent conclusion that software is
197 validated. Software testing is one of several verification activities intended to confirm
198 that the software development output meets its input requirements. Other verification
199 activities include walk-throughs, various static and dynamic analyses, code and document

25
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-
medical-devices.
26
See section VII.B to learn more about referencing Off-The-Shelf Software Use in Medical Devices.
27
Serious injury as defined in 21 CFR 803.3(w).
28
For examples, refer to the following FDA webpage: https://www.fda.gov/medical-devices/software-medical-
device-samd/what-are-examples-software-medical-device.
29
See footnotes 1 and 2.
30
See footnote 16.
31
See footnotes 1 and 2.
32
See footnote 16.

6
 Contains Nonbinding Recommendations

Draft – Not for Implementation

200 inspections, module level testing and integration testing. For example, the input and
201 output of the design phase are known as Software Requirements Specification (SRS) and
202 Software Design Specification (SDS), respectively. In this case, software verification
203 would involve confirming by objective evidence (e.g., reviews, traceability analysis) that
204 the software design as documented in the SDS (i.e., output) correctly and completely
205 implements all the requirements of the SRS (i.e., input).
206
207 • For the purposes of this guidance, software validation refers to establishing, by objective
208 evidence, that the software specifications conform to user needs and intended uses, and
209 that the particular requirements implemented through software can be consistently
210 fulfilled. Software validation is a part of design validation of the finished device. It
211 involves checking for proper operation of the software in its actual or simulated use
212 environment, including integration into the final device where appropriate. Software
213 validation is highly dependent upon comprehensive software testing and other
214 verification tasks previously completed at each stage of the software development life
215 cycle. Planning, requirements, traceability, testing, risk assessment, design reviews,
216 change management, and many other aspects of good software engineering are important
217 activities that together help to support a conclusion that software is validated.
218
219 The above descriptions of software verification and software validation are consistent with
220 FDA’s thinking as described in the guidance General Principles of Software Validation. 33
221

222 V. Documentation Level

223 The recommended documentation for a premarket submission depends on the device’s risk to a
224 patient, a user of a device, or others in the environment of use. FDA intends to consider four
225 risk-based factors to help determine the device’s Documentation Level, which is either Basic or
226 Enhanced. The purpose of the Documentation Level is to help identify the minimum amount of
227 information that would support a premarket submission that includes device software functions.
228
229 The Documentation Level is based on the device’s intended use. 34 Evidence relevant to intended
230 use may include the design of the device. Notably, the Documentation Level is determined by
231 the intended use of the device as a whole—not the individual device function(s).
232
233 Basic Documentation should be provided for any premarket submission that includes device
234 software functions where Enhanced Documentation does not apply.
235
236 Enhanced Documentation should be provided for any premarket submission that includes
237 device software functions, where any of the following factors apply:

33
See “General Principles of Software Validation” Guidance, available at https://www.fda.gov/regulatory-
information/search-fda-guidance-documents/general-principles-software-validation.
34
See 21 CFR 801.4 (“…[I]ntended uses…refer to the objective intent of the persons legally responsible for the
labeling of an article. The intent may be shown by such persons’ expressions, the design or composition of the
article, or by the circumstances surrounding the distribution of the article.”).

7
 Contains Nonbinding Recommendations

Draft – Not for Implementation

238
239 1) The device is a constituent part of a combination product. 35
240
241 2) The device (a) is intended to test blood donations for transfusion-transmitted
242 infections; or (b) is used to determine donor and recipient compatibility; or (c) is a
243 Blood Establishment Computer Software. 36
244
245 3) The device is classified as class III. 37
246
247 4) A failure or latent flaw of the device software function(s) could present a probable
248 risk of death or serious injury 38, either to a patient, user of the device, or others in
249 the environment of use. These risk(s) should be assessed prior to implementation of
250 risk control measures. You should consider the risk(s) in the context of the device’s
251 intended use; the direct and indirect impacts to safety, treatment, and/or diagnosis;
252 and other relevant considerations.
253
254 The term ‘probable’ in factor #4 above is intended to capture reasonably foreseeable software
255 and hardware risks associated with the device, including those risks resulting from intentional or
256 reasonably foreseeable misuse of the device, prior to the implementation of risk control
257 measures. “Probable” risks also include the likelihood that device functionality is intentionally or
258 unintentionally compromised by inadequate device cybersecurity. The term “probable” is
259 intended to exclude the consideration of purely hypothetical risks, consistent with the use of
260 “probable” in other FDA guidances. 39 It is the sponsor’s responsibility to proactively and
261 comprehensively consider risks as part of the device’s risk assessment.
262
263 For additional information and examples on assessing the Documentation Level for a device,
264 please refer to Appendix A.
265

35
21 CFR 3.2(e).
36
Blood establishment computer software (BECS) is a device used in the manufacture of blood and blood
components to assist in the prevention of disease in humans by identifying ineligible donors, by preventing the
release of unsuitable blood and blood components for transfusion or for further manufacturing into products for
human treatment or diagnosis, by performing compatibility testing between donor and recipient, or by performing
positive identification of patients and blood components at the point of transfusion to prevent transfusion reactions.
This generic type of device may include a BECS accessory, a device intended for use with BECS to augment the
performance of the BECS or to expand or modify its indications for use (21 CFR 864.9165).
37
See 21 CFR 860.3(c)(3).
38
See 21 CFR 803.3(w).
39
Example guidances that distinguish between “probable risks” and “purely hypothetical risks” include, but are not
limited to: (1) Factors to Consider When Making Benefit-Risk Determinations for Medical Device Investigational
Device Exemptions - Guidance for Investigational Device Exemption Sponsors, Sponsor-Investigators and Food and
Drug Administration Staff available at: https://www.fda.gov/regulatory-information/search-fda-guidance-
documents/factors-consider-when-making-benefit-risk-determinations-medical-device-investigational-device; and
(2) Factors to Consider When Making Benefit-Risk Determinations in Medical Device Premarket Approval and De
Novo Classifications available at: https://www.fda.gov/regulatory-information/search-fda-guidance-
documents/factors-consider-when-making-benefit-risk-determinations-medical-device-premarket-approval-and-de

8
 Contains Nonbinding Recommendations

Draft – Not for Implementation

266 VI. Recommended Documentation

267 This section reflects FDA’s recommendations for information to be included in premarket
268 submissions for Basic and Enhanced Documentation Levels. This recommended information
269 should demonstrate that practices were employed resulting in traceability for device software
270 functions and demonstrate planning, requirements, risk assessment, design reviews, change
271 management, testing plans and results, and other aspects of good software engineering for device
272 software functions, to help inform a regulatory decision on whether the software is appropriately
273 designed, verified, and validated.
274
275 Table 1 below provides an outline of the recommended documentation for each software
276 documentation element and corresponding Documentation Level. Please refer to subsections A-J
277 in this section of the guidance (IV) for more detail.
278
279 Table 1. Outline of Recommended Documentation
280
Software
Documentation Basic Documentation Level Enhanced Documentation Level
Elements

Documentation A statement indicating the appropriate Documentation Level and a

Level Evaluation description of the rationale for that level.
(Section IV.A)

Software Software description, including overview of operationally significant

Description software features, analyses, inputs, and outputs.
(Section IV.B)

System and Detailed diagrams of the modules, layers, and interfaces that comprise the
Software device, their relationships, the data inputs/outputs and flow of data, and
Architecture how users or external products (including IT infrastructure and peripherals)
Design Chart interact with the system and software.
(Section IV.C)

Risk Risk management plan, risk assessment demonstrating that risks have been
Management File appropriately mitigated, and risk management report.
(Section IV.D)

Software The complete documentation, describing the needs or expectations for a

Requirements system or software, presented in an organized format and with sufficient
Specification information to understand the traceability of the information with respect to
(SRS) the other software documentation elements (e.g., risk management file,

9
 Contains Nonbinding Recommendations

Draft – Not for Implementation

(Section IV.E) software design specification, system and software architecture design
chart, software testing as part of verification and validation).

None. The complete documentation, including

sufficient information that would allow
FDA to understand the technical design
Software Design details of how the software functions,
Specification how the software design completely and
(SDS) correctly implements all the
(Section IV.F) requirements of the SRS and how the
software design traces to the SRS in
terms of intended use, functionality,
safety, and effectiveness.

A Declaration of Conformity to A Declaration of Conformity to IEC

IEC 62304 62304
Software
Development OR OR
and Maintenance a summary of the life cycle Basic Documentation Level PLUS
Practices development plan and a complete configuration management and
(Section IV.G) summary of configuration maintenance plan document(s).
management and maintenance
activities.

A summary description of the Basic Documentation Level PLUS unit

Software Testing testing activities at the unit, and integration level test protocols
as Part of integration and system levels. including expected results, observed
Verification and System level test protocol results, pass/fail determination, and unit
Validation including expected results, and integration level test reports.
observed results, pass/fail
(Section IV.H) determination, and system level
test report.

Revision Level Revision history tabulating the major changes to the software during the
History development cycle, including date, version number, a brief description of
the changes relative to the previous version, and indication of the version
(Section IV.I) on which testing was performed.

Unresolved List of remaining software anomalies (e.g., bugs, defects) annotated with an
Anomalies (e.g., explanation of the impact on safety or effectiveness, including operator
Bugs, Defects, or usage and human factors, work-arounds, and timeframe for correction.
Errors)

10
 Contains Nonbinding Recommendations

Draft – Not for Implementation

(Section IV.J)

281
282 Documentation Level Evaluation
283 A statement indicating the Documentation Level for the device and a description of the rationale
284 for such Documentation Level, as appropriate.
285
286 Software Description
287 An overview of operationally significant software features, including images, flow charts, and
288 state diagrams as needed to adequately explain the software functionality 40 should be provided.
289 If the premarket submission is for a modified device, provide the document number of the
290 previous submission and highlight pertinent software changes since the last FDA approval or
291 clearance.
292
293 Please consider and provide information to address the questions below when preparing the
294 software description. However, FDA recognizes that these questions and examples may not
295 capture all the unique aspects of a device software function and encourages the inclusion of
296 additional information that will streamline or further FDA’s understanding of the device’s
297 functionality to facilitate the review of a submission.
298
299 If the device is a multiple function device product and includes software function(s) that are
300 considered “other functions,” as that term is used in the guidance Multiple Function Device
301 Product: Policy and Considerations, the recommendations described in the aforementioned
302 guidance should be considered when preparing the software description information.
303
304 Software Specifics
305
306 • What programming languages and compiler versions are used?
307 • What hardware platforms are used?
308 • What operating systems are used (if applicable)?
309 • Does the device use Off-The-Shelf (OTS) software(s)? 41
310 • What is the intended release version? If the intended release version is different from the
311 documentation’s version, explain the differences.
312

40
FDA may request additional architecture charts to address the cybersecurity risks associated with a device. Refer
to the guidance document, Content of Premarket Submissions for Management of Cybersecurity in Medical
Devices, for more information.
41
If a device uses OTS software, FDA may request additional information in premarket submissions. Please refer to
section VII.B of this guidance and the guidance document, Guidance for Off-The-Shelf Software Use in Medical
Devices, for more information.

11
 Contains Nonbinding Recommendations

Draft – Not for Implementation

313 Software Operation

314
315 • Who operates the software (user)? The patient, a caregiver, a healthcare professional, or a
316 combination thereof?
317 • What is the intended patient population?
318 o Does the software function focus on a specific disease, condition, patient
319 characteristic or demographic?
320 o Does the software provide information that is directly applicable to a specific
321 disease or condition?
322 • If the software performs an analysis of data, what is the analysis methodology? What is
323 the evidence base used for this methodology? Examples: rule-based calculations, online
324 test administration, artificial intelligence (AI)/machine learning (ML), neural networks,
325 fixed or adaptive algorithms.
326 • Does the software impact or replace any otherwise manual or clinician performed
327 actions? What are the workflow steps and assumptions (from beginning to end state)?
328 Examples: automates steps, triages patients, provides a definite diagnosis or suggests
329 likely diagnosis for further confirmation by physician, performs or recommends
330 treatment, identifies a region of interest for further review.
331 • If the device is AI/ML-enabled, what populations or samples have informed the
332 model(s)? What steps were taken to identify and address potential biases and limitations
333 of the model(s)?
334
335 Software Inputs and Outputs
336
337 • What are the inputs and their format? Examples: data, images (specify modality),
338 measurements (specify units), sensor/attachments, report, questionnaire.
339 • Who or what provides the inputs? Examples: user, other medical devices, other non-
340 medical devices or software.
341 • Is the device designed to be interoperable? 42 In other words, does the device transmit,
342 exchange, and/or use information through an electronic interface with another
343 medical/nonmedical product, system, or device? If yes, what other products does the
344 device interface with, and what methods, standards, and specifications are used to
345 interact and/or communicate with other medical/nonmedical product, system, or device?
346 • What are the outputs and their format?
347 o Note: The performance testing of the outputs, including test setup, acceptance
348 criteria, and results should be included in the submission. Please clearly indicate
349 where in the submission this information is located. Examples: testing for
350 accuracy and repeatability of output measurements, parametric analyses, model
351 outputs, device generated segmentation contours, medical image enhancements.
352 • To whom are the outputs provided? Examples: patients, caregivers, healthcare
353 professionals, technicians, researchers, health records, interoperable systems.

42
More information on interoperable medical devices is available at: https://www.fda.gov/regulatory-
information/search-fda-guidance-documents/design-considerations-and-pre-market-submission-recommendations-
interoperable-medical-devices.

12
 Contains Nonbinding Recommendations

Draft – Not for Implementation

354 • What is the data or information flow of the software? Consider identifying the response
355 to this question in the system and software architecture diagram. Examples: inputs or
356 outputs transmitted locally, via cloud storage, by disk or drive, or wirelessly.
357 • Does the software interact with any networked devices? Does the software use cloud or
358 network storage?
359
360 If any of the information requested above is included in another document, such as the SRS, an
361 annotation and a reference to the document in the submission where this information is located
362 should be provided.
363
364 System and Software Architecture Diagram
365 The purpose of the system and software architecture diagram is to present a roadmap of the
366 device design to facilitate a clear understanding of 1) the modules 43 and layers that make up the
367 system and software, 2) the relationships among the modules and layers, 3) the data
368 inputs/outputs and flow of data among the modules and layers, and 4) how users or external
369 products, including IT infrastructure and peripherals (e.g., wirelessly connected medical devices)
370 interact with the system and software.
371
372 Sponsors should provide the appropriate level of detail in the system and software architecture
373 diagram to convey the information in a manner that can facilitate an efficient premarket review,
374 including descriptive text (in the diagram or in an accompanying document) to explain the
375 architecture diagram where appropriate. A system and software architecture diagram that is not
376 appropriately tailored (e.g., too high level, too detailed, or overly confusing) will likely increase
377 requests for additional information from the FDA review staff. To the extent appropriate, the
378 system and software architecture diagram can be communicated in one or more diagrams and in
379 one or more formats, and may convey different dimensions of the system and software (e.g.,
380 cybersecurity architecture, state diagram). If more than one diagram is used, the sponsor should
381 provide a high-level diagram that communicates the overview and points to the other diagrams
382 that provide additional detail. The relationship between diagrams should also be clearly
383 communicated. In general, the sponsor should take note of the following visual, language, and
384 reference considerations when developing an effective system and software architecture diagram:
385
386 Visual Considerations
387
388 • The diagram and the means for communicating information in the diagram should be
389 visually consistent (e.g., a solid arrow should convey a specific meaning as compared to a
390 dashed arrow; icons should be used consistently; lines that intersect should clearly

43
For purposes of the system and software architecture diagram, this guidance considers a module to be a discrete unit
or architectural item within the system or software. A module could represent, for example, a finished hardware device
within a system of hardware and software products, a hardware component within a finished hardware device, a
finished software product within a system of software products, or a software function within a finished software
product. A module is not specifically meant to describe code-level software functions, although such code-level
software functions could be considered modules if appropriate. The sponsor should determine what constitutes a
module in the context of its system and software.

13
 Contains Nonbinding Recommendations

Draft – Not for Implementation

391 communicate whether the intersection is a crossing or connection) and the meaning
392 ascribed should be clearly communicated (e.g., through the use of standard symbols and
393 notation).
394 • The level of detail provided in the diagram should be consistent throughout unless areas
395 of less detail are clearly explained (e.g., in the case of functions, within the system or
396 software, that are not under review).
397 • Modules should be grouped in a logical and obvious manner.
398 • Use of color or other visual means (e.g., dashed boxes within solid boxes) should be used
399 to convey layering within the system, software, or module.
400 • Visual clutter should be avoided, and the diagram should be scaled according to the
401 complexity and amount of information presented.
402
403 Language Considerations
404
405 • Annotations should be used to provide additional information about a particular module
406 or data element (e.g., a plain-language explanation of the module purpose or a pointer to
407 a document or requirement within the premarket submission).
408 • Use of terminology and naming conventions should be consistent within the diagram and
409 the remainder of the premarket submission materials.
410 • Use of acronyms, jargon, or terms that are not defined in the diagram itself should be
411 avoided.
412
413 References
414
415 • The diagram should reference other documents in the submission (e.g., System &
416 Software Description, Software Requirements Specification), as appropriate.
417 • For submissions related to modifications to a previously cleared or approved device, the
418 diagram should identify and reference those modules that are affected by the
419 modification.
420
421 The above considerations are intended to serve as a guide and may not apply in every case or
422 may apply differently for different diagrams. When developing the system and software
423 architecture diagram, manufacturers are encouraged to leverage industry best practices within
424 and outside the medical device industry.
425
426 For multiple function device products, the system and software architecture diagram should
427 clearly delineate between the device functions-under-review and the “other functions,” as that
428 term is used in the guidance Multiple Function Device Product: Policy and Considerations. The
429 system and software architecture diagram should include adequate detail to understand how or if
430 the “other function(s)” interact with or impact the device function-under-review.
431
432 An example system and software architecture diagram is provided in Appendix B of this
433 guidance, which illustrates one approach to effectively convey the recommended information to
434 facilitate an efficient premarket review of a software system with multiple modules. The example
435 demonstrates how the considerations described in this section can be implemented into a system
14
 Contains Nonbinding Recommendations

Draft – Not for Implementation

436 and software architecture diagram. The modules in the example are intended for illustration
437 purposes only and are not intended to document or represent a comprehensive or complete
438 system and software architecture diagram for a specific medical device or system. The approach
439 illustrated can be applied to any system and software architecture diagram, including standalone
440 SaMD.
441
442 Risk Management File
443 The risk management file should be provided as part of the premarket submission and include
444 the following documentation:
445
446 • Risk Management Plan
447 o Refer to the FDA recognized consensus standard ISO 14971 for
448 recommendations on the content of a risk management plan.
449
450 o Submit a risk management plan to support the effectiveness of the risk
451 management activities and processes for a particular medical device. In
452 FDA’s review of the risk management plan, the Agency intends to primarily
453 focus on:
454  Individual risk acceptability criteria including the need for risk
455 reduction (control).
456  Method to evaluate the acceptability of the overall residual risk for all
457 residual risks after all risk control measures have been implemented
458 and verified.
459
460 o The risk acceptability criteria should be based on the sponsor’s policy for
461 determining acceptable risk. The acceptability criteria should be documented
462 in the risk management plan before an initial risk evaluation is performed for
463 the medical device software under review.
464
465 o It should be clear in the risk management plan how the manufacturer’s plans
466 to evaluate the overall residual risk against the benefits of the intended use of
467 the device. For SiMD, if this information is covered in the overall device
468 hazard analysis, this should be noted in the software documentation and
469 reference that section of the submission.
470
471 • Risk Assessment
472 A risk assessment should be provided for all medical device software. For multiple
473 function device products, the risk assessment should include the results of a risk-
474 based analysis of any potential adverse impact or labeled positive impact of “other
475 function(s),” as that term is used in the guidance Multiple Function Device Product:
476 Policy and Considerations, to the safety or effectiveness of the device function-under-
477 review.
478

15
 Contains Nonbinding Recommendations

Draft – Not for Implementation

479 The International Medical Device Regulators Forum (IMDRF) document, Software as
480 a Medical Device: Possible Framework for Risk Categorization and Corresponding
481 Considerations, 44 may also be helpful in identifying probable risks. Specifically, it
482 may be helpful to consider the significance of information provided by the software
483 and the criticality of the medical situation or condition in which the software is
484 intended to function.
485
486 All reasonably foreseeable software and hardware hazards associated with the device
487 should be identified and documented in a tabular format, including those hazards
488 resulting from intentional or reasonably foreseeable misuse of the device. You should
489 consider the device’s intended use; the direct and indirect impacts to safety,
490 treatment, and/or diagnosis; among other relevant considerations. In a tabular format,
491 each identified hazard is captured in a singular line item which should include the
492 following items:
493
494 o Identification of the hazard
495
496 o Cause(s) of the hazard
497
498 o Severity of the hazard
499
500 o Initial risk evaluation of hazard
501  This includes assessment of acceptability (e.g., acceptable, not
502 acceptable) and need for risk reduction (control) measures as defined
503 in the risk management plan
504
505 o Risk Control Measures
506  This should include the following risk control measures listed in
507 descending order from highest to lowest priority:
508 • Design
509 • Protective measures (e.g., alarms)
510 • Information for safety (e.g., written warnings, on-screen
511 warnings, training)
512
513  There should be verification of the implementation of the risk control
514 measures and verification of the effectiveness of the implemented risk
515 control measures (i.e., the implemented risk control measure reduces
516 risk). This can be accomplished by tracing the identified hazard to the
517 verified specific risk control measures (e.g., a requirement ID in the
518 SRS and SDS, a test name and identifier in the testing documentation
519 that shows pass/fail results, a user manual name and identifier, a
520 training manual name and identifier). For example, given an identified

44
Available at http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-
categorization-141013.pdf.

16
 Contains Nonbinding Recommendations

Draft – Not for Implementation

521 hazard (e.g., HAZ-XXX 45), the following could be listed for
522 traceability: a design related risk control measure that is documented
523 in a software requirement specification (e.g., SRS-XXX) and software
524 design specification (e.g., SDS-XXX), and tested as part of a unit test
525 case (e.g., UT-XXX), integration test case (e.g., INT-XXX) and
526 system test case (e.g., SYS-XXX). FDA recognizes that there may be
527 instances where a specific hazard traces to several
528 requirements/specifications and tests, thereby making the presentation
529 of information cumbersome in the risk assessment document.
530 Therefore, sponsors may choose to present this traceability in a
531 separate table or document with line items to link together software
532 requirements specifications, software design specifications, testing and
533 identified hazards derived from the risk assessment.
534
535  There should be an assessment of whether risk control measures
536 introduce new hazards or hazardous situations or impact the initial risk
537 evaluation.
538
539  Document any risk control measures employed to mitigate increased
540 risk or adverse effect on performance due to the combination of “other
541 function(s),” as that term is used in the guidance Multiple Function
542 Device Product: Policy and Considerations, with the device function-
543 under review.
544
545 o Residual risk evaluation after implemented risk control measures.
546  This includes assessment of acceptability (e.g., acceptable, not
547 acceptable) as defined in the risk management plan.
548
549 o Benefit-Risk Analysis
550  If a residual risk is deemed not acceptable according to the
551 acceptability criteria in the risk management plan and further risk
552 control is not practicable, the manufacturer should provide
553 documented evidence to demonstrate that the benefits of the intended
554 use outweigh the residual risk.
555
556 • Risk Management Report
557 o A risk management report should be provided to:
558  Show how the risk management plan has been appropriately
559 implemented.
560  Demonstrate that the risk management file has been assessed by the
561 appropriate personnel and the overall residual risk is acceptable

45
XXX denotes a unique number identifier for a specific hazard, software requirement specification, software
design specification, unit test case, integration test case or system test case.

17
 Contains Nonbinding Recommendations

Draft – Not for Implementation

562  Demonstrate appropriate methods are established for the collection and
563 assessment of relevant production and post-production information
564
565 Software Requirements Specification (SRS)
566 The SRS documents the requirements 46 for the software which typically specifies inputs and
567 outputs, functions that the software will perform, hardware, 47 programming language, 48 compiler
568 version, performance, 49 interfaces, 50 user interaction, error definition and handling, response
569 times, intended operating environment, safety related requirements derived from a risk
570 assessment (Refer to Section VI.D Risk Management File) and all ranges, limits, defaults, and
571 specific values that the software will accept. For additional details on what should be included in
572 the software requirements specification, refer to the guidance, General Principles of Software
573 Validation. 51
574
575 The QSR requires “a mechanism for addressing incomplete, ambiguous, or conflicting
576 requirements.” 52 Each requirement (e.g., hardware, software, user, operator interface, and safety)
577 identified in the software requirements specification should be evaluated for accuracy,
578 completeness, consistency, testability, correctness, and clarity.
579
580 A complete SRS document should be provided. The documentation should include a description
581 of the software requirement identification and tracking methodology used to support the
582 traceability of the requirements.
583
584 FDA acknowledges that modern development practices may employ incremental or evolutionary
585 software development practices. Additional forms of software requirements might be included in

46
The term “requirements” is used in this section as part of the term “Software Requirements Specification”, and
does not refer to a regulatory requirement.
47
Hardware requirements generally include, but are not limited to, requirements related to: microprocessors,
memory devices, sensors, energy sources, safety features, and communications.
48
Programming language requirements generally include, but are not limited to, requirements related to program
size requirements or restrictions, and information on management of memory leaks.
49
Software performance and functional requirements generally include, but are not limited to, requirements related
to algorithms or control characteristics for therapy, diagnosis, monitoring, alarms, analysis, and interpretation with
full text references or supporting clinical data, if necessary. Software performance and functional requirements may
also include: device limitations due to software, internal software tests and checks, error and interrupt handling, fault
detection, tolerance, and recovery characteristics, safety requirements, and timing and memory requirements.
50
Interface requirements (e.g., external, user, internal) generally include, but are not limited to, both communication
between system components and communication with the user such as: printers, monitors, keyboard, mouse, cloud
servers, peripheral medical devices, mobile technology platforms.
51
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-
software-validation.
52
See 21 CFR 820.30(c) (“Design input. Each manufacturer shall establish and maintain procedures to ensure that
the design requirements relating to a device are appropriate and address the intended use of the device, including the
needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or
conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved
by a designated individual(s). The approval, including the date and signature of the individual(s) approving the
requirements, shall be documented.”).

18
 Contains Nonbinding Recommendations

Draft – Not for Implementation

586 the submission, such as well elaborated stories, use cases, textual descriptions, screen mockups,
587 and control flows. Executable requirements may be provided with additional clarification to
588 support readability.
589
590 In order to facilitate a timely premarket review, the following recommendations should be
591 considered in preparing SRS documentation:
592 • Format the SRS to be well-organized, easily navigable and readable with the labeling
593 and/or grouping of requirements by function.
594 • Note any relevant traceability between requirements listed in the SRS and information
595 related to those requirements in other software documentation (e.g., SDS, System and
596 Software Architecture Diagram, etc.).
597 • If the premarket submission involves a modification to an existing approved or cleared
598 device, highlight all pertinent differences in software requirements.
599 • The manufacturer may choose to identify the requirements the manufacturer believes are
600 most critical (i.e., could have the most significant impacts) to the device’s safety and
601 effectiveness. These requirements can be highlighted within the complete SRS document
602 and/or consolidated in a supplemental document that includes these requirements of
603 interest in a summarized format. This technique will help facilitate the presentation of
604 those requirements that most critically affect clinical functionality or performance
605 specifications that are directly associated with the intended use of the device.
606
607 Documentation of requirements included in the premarket submission for the device function-
608 under-review should include adequate detail to describe any expected relationship, utility,
609 reliance, or interoperability with any “other function,” as that term is used in the guidance
610 Multiple Function Device Product: Policy and Considerations.
611
612 Software Design Specification (SDS)
613 The Software Design Specification (SDS) may contain both a high level summary of the design
614 and detailed design information. In terms of the relationship between the Software Requirement
615 Specification (SRS) and the SDS, the SRS describes what the software function will do and the
616 SDS describes how the requirements in the SRS are implemented. The information presented in
617 the SDS should be sufficient to ensure that the work performed by the software engineers who
618 created the software device function was clear and unambiguous, with minimal ad hoc design
619 decisions. Documentation of specifications included in the premarket submission for the device
620 function-under-review should include adequate detail to describe any expected relationship,
621 utility, reliance, or interoperability with any “other function,” as that term is used in the guidance
622 Multiple Function Device Product: Policy and Considerations.
623
624 (1) Basic Documentation Level
625 No SDS documentation recommended in the premarket submission.
626

19
 Contains Nonbinding Recommendations

Draft – Not for Implementation

627 (2) Enhanced Documentation Level

628 A singular SDS document or set of SDS documents that provide the technical design details of
629 how the software functions, how the software design completely and correctly implements all the
630 requirements of the SRS and how the software design traces to the SRS in terms of intended use,
631 functionality, safety, and effectiveness. The software functional units or modules along with the
632 interfaces among them identified in the architectural (i.e., high level) design should be
633 documented with the corresponding detailed (i.e., low-level) design information in the SDS. The
634 information provided for review should be sufficient to ensure that the work performed in
635 developing the software functional units or modules and their interfaces was clear and
636 unambiguous, with minimal ad hoc design decisions. For example, the creation of the SDS is
637 expected to have occurred as a prospective activity where the SDS was used to guide the design,
638 development and testing of the software rather than documented retrospectively after the
639 software design has been implemented by ad hoc design methods.
640
641 For additional details on what should be included in the software design specification, refer to
642 the guidance, General Principles of Software Validation. 53
643
644 Software Development and Maintenance Practices
645 (1) Basic Documentation Level
646 For devices that the Basic Documentation Level is appropriate, a Declaration of Conformity to
647 the currently FDA-recognized version of ANSI/AAMI IEC 62304 Medical Device Software -
648 Software Life Cycle Processes may suffice.
649
650 Alternatively, a summary of the processes and procedures that are in place to manage the
651 software life cycle development, software configuration and change management and software
652 maintenance activities could be provided. This summary information should include an adequate
653 description of:
654
655 • Processes and procedures used in software development, verification and validation.
656 • Standards (e.g., coding), methods and tools used in software development.
657 • Main deliverables of the typical activities and tasks involved in software
658 development, verification and validation.
659 • Processes, procedures, and tools used to link user needs, system requirements,
660 software requirements, software design specifications, software testing and
661 implemented risk control measures (i.e., traceability).
662 • Processes and procedures used in software configuration and change management.
663 • Processes and procedures used in software maintenance that includes risk assessment
664 of software changes, initial testing that evaluates the correctness of the implemented
665 software change(s) and regression analysis and testing.

53
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-
software-validation.

20
 Contains Nonbinding Recommendations

Draft – Not for Implementation

666 o Note: Software maintenance typically includes the following types of software
667 changes:
668  Corrective: Changes made to correct errors and faults in the software
669  Perfective: Changes made to the software to improve the performance,
670 maintainability, or other attributes of the software system
671  Adaptive: Changes to make the software system usable in a changed
672 environment
673
674 (2) Enhanced Documentation Level
675 For devices that the Enhanced Documentation Level is appropriate, a Declaration of Conformity
676 to the currently FDA-recognized version of ANSI/AAMI IEC 62304 Medical Device Software -
677 Software Life Cycle Processes may suffice.
678
679 Alternatively, a complete configuration management and maintenance plan document could be
680 provided in addition to the summary documentation requested for the Basic Documentation
681 Level, as described above.
682
683 Software Testing as part of Verification and Validation
684 Refer to Section IV (Definitions) for important information pertaining to FDA’s thinking on
685 verification and validation, as it relates to this guidance. Additionally, please refer to guidance
686 General Principles of Software Validation 54 for additional details regarding FDA’s thinking
687 regarding software testing particularly unit level (module or component) testing, integration level
688 (internal and external interfaces) testing and system level (functional) testing.
689
690 Software testing may sometimes involve other device performance testing activities. If the
691 premarket submission leverages information from the performance testing section to address
692 software validation content, the manufacturer is encouraged to appropriately reference the
693 performance testing material to facilitate the navigation between submission sections, reduce
694 instances of duplication, and improve readability.
695
696 (1) Basic Documentation Level
697 The following software testing documentation should be provided:
698
699 • A summary description of the testing activities at the unit, integration, and system levels.
700 The summary description should include the software version tested and the overall
701 pass/fail test results for all test protocols (i.e., collection of test procedures for specific
702 software functionality) executed. If the device is a modified version of a previously
703 cleared or approved device, provide a summary of the modifications compared with the
704 previous cleared or approved version.

54
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-
software-validation.

21
 Contains Nonbinding Recommendations

Draft – Not for Implementation

705
706 • Any intentional changes made in response to failed tests and documentation of test results
707 demonstrating that the intentional changes were implemented correctly.
708
709 • A regression analysis and pass/fail test results to account for unintended effects of a
710 software change.
711
712 o Regression analysis is the determination of the impact of a change based on
713 review of the relevant documentation (e.g., software requirements specification,
714 software design specification, source code, test plans, test cases, test scripts, etc.)
715 in order to identify the necessary regression tests to be run. Regression testing is
716 the rerunning of test cases that a program has previously executed correctly and
717 comparing the current result to the previous result in order to detect unintended
718 effects of a software change.
719
720 • System level test protocol including expected results derived from software requirements,
721 actual results that are observed and recorded, objective pass/fail determination (i.e.,
722 actual results are acceptably equivalent to expected results) and a system level test report.
723 The system level test report should demonstrate that the protocol has been acceptably
724 executed with passing test results and any unresolved anomalies have been acceptably
725 deferred based on a risk assessment for the candidate release version.
726

727 (2) Enhanced Documentation Level

728 In addition to the documentation requested for the Basic Documentation Level, unit and
729 integration level test protocols and reports should be provided, including expected results derived
730 from software requirements and design, actual results that are observed and recorded, objective
731 pass/fail determination (i.e., actual results are acceptably equivalent to expected results) and unit
732 and integration test reports. The unit and integration level test reports should demonstrate that the
733 protocols have been acceptably executed with passing testing results and any unresolved
734 anomalies have been acceptably deferred based on a risk assessment for the candidate release
735 version.
736
737 Revision Level History
738 The documentation should include the history of software revisions generated during product
739 development.
740
741 This typically takes the form of a line-item tabulation of the major changes to the software
742 during the development cycle, including date, version number, a brief description of the changes
743 in the version relative to the previous version, and an indication of the version testing was
744 performed on, including bench testing, animal testing, and clinical testing, if applicable.
745

22
 Contains Nonbinding Recommendations

Draft – Not for Implementation

746 The last entry in the list should be the final version to be incorporated in the released device.
747 This entry should also include any differences between the tested version of software and the
748 released version, along with an assessment of the potential effect of the differences on the safety
749 and effectiveness of the device.
750
751 If a manufacturer’s development practices use an iterative methodology, information on any
752 changed software requirements and how they continue to meet the system requirements or design
753 inputs should be provided.
754
755 If the revision level history includes a version(s) that corresponds to a previously released
756 version of the software, please highlight in the revision level history document each prior
757 released version and (if applicable) the premarket submission number(s) associated with that
758 release.
759
760 Unresolved Anomalies (e.g., Bugs, Defects, or Errors)
761 An anomaly is any condition that deviates from the expected behavior based on requirements
762 specifications, design documents, standards, or from someone’s perceptions or experiences.
763
764 For each unresolved anomaly, indicate the:
765
766 • problem;
767 • impact on device performance; and
768 • any plans or timeframes for correcting the problem (where appropriate).
769
770 Each item should be annotated with an explanation of the impact of the anomaly on device safety
771 or effectiveness, including operator usage and human factors issues. Typically, this anomaly list
772 can be generated as an output of a change control board or similar mechanism for evaluation and
773 disposition of unresolved software anomalies. FDA suggests ranking anomalies based on risk to
774 patient and/or operator (user). Additionally, the Agency recommends including defect
775 classification for each anomaly using a defect taxonomy, such as ANSI/AAMI SW91’s
776 Classification of defects in health software.
777
778 If the resolution of any unresolved anomalies will be deferred, a risk-based rationale for why
779 each unresolved anomaly would not impact device safety or effectiveness should be provided.
780
781 A list of unresolved anomalies should be communicated to end user(s) as appropriate to assist in
782 the proper operation of the device. In all instances where it is practical to do so, any mitigations
783 or possible work-arounds for unresolved anomalies should be included in the premarket
784 submission.
785

786 VII. Additional Information

787 Regulatory Considerations for Software Functions
23
 Contains Nonbinding Recommendations

Draft – Not for Implementation

788 Section 3060(a) of the Cures Act amended section 520 of the FD&C Act on December 13, 2016,
789 removing certain software functions from the definition of device in section 201(h) of the FD&C
790 Act. To learn more about FDA’s regulatory considerations for software functions, please
791 consider the following reference materials:
792
793 • Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st
794 Century Cures Act 55
795 • General Wellness: Policy for Low Risk Devices 56
796 • Policy for Device Software Functions and Mobile Medical Applications 57
797 • Medical Device Data Systems, Medical Image Storage Devices, and Medical Image
798 Communications Devices 58
799 • How to Determine if Your Product is a Medical Device 59
800
801 Off-The-Shelf (OTS) Software Use in Medical Devices
802 FDA recognizes the Off-The-Shelf Software Use in Medical Devices (“OTS”) guidance uses
803 “Level of Concern” factors to determine the software content for OTS software. Therefore, after
804 finalization of this guidance, FDA intends to update the OTS guidance to be consistent with this
805 guidance. For example, Table 2 below is derived from “Table 1” in the OTS guidance. Table 2
806 incorporates the Documentation Levels described in this guidance to help explain how the
807 concepts in this guidance could be represented in a future update to the OTS guidance.
808
809 Table 2: Documentation Level for Off-The-Shelf Software
Basic Documentation Level Enhanced Documentation Level
Hazard Analysis Hazard Analysis
Basic Documentation Basic Documentation
Hazard Mitigations Hazard Mitigations
Describe and Justify Residual Risk Describe and Justify Residual Risk
Special Documentation
810
811 Please refer to the OTS guidance for additional information on what information is requested as
812 part of “hazard analysis,” “basic documentation,” 60 “hazard mitigations,” “describe and justify

55
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/changes-existing-
medical-software-policies-resulting-section-3060-21st-century-cures-act.
56
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-
policy-low-risk-devices.
57
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-
functions-and-mobile-medical-applications.
58
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/medical-device-data-
systems-medical-image-storage-devices-and-medical-image-communications-devices.
59
Available at https://www.fda.gov/medical-devices/classify-your-medical-device/how-determine-if-your-product-
medical-device.
60
Please note “Basic Documentation” is only applicable to the Off-The-Shelf Software Use in Medical Devices
(OTS) guidance and is NOT the same as “Basic Documentation Level.” “Basic Documentation” is described in the

24
 Contains Nonbinding Recommendations

Draft – Not for Implementation

813 residual risk,” and “special documentation” content. The OTS Guidance describes “Special
814 Documentation” in section V.E. The information requested as part of the “Special
815 Documentation” includes: (1) an assurance to FDA that the product development methodologies
816 used by the OTS software developer are appropriate and sufficient for the intended use of the
817 OTS software within the specific medical device, (2) the procedures and results of the
818 verification and validation activities performed for the OTS software are appropriate and
819 sufficient for the safety and effectiveness requirements of the medical device, and (3) the
820 existence of appropriate mechanisms for assuring the continued maintenance and support of the
821 OTS software should the original OTS software developer terminate their support.
822
823 When appropriate, the documentation described in this guidance can be leveraged to address the
824 content described in the OTS guidance. For example, the OTS Hazard Analysis information may
825 be captured as part of the Risk Assessment, as described in this guidance.
826
827 Please note, OTS software is typically an “other function,” as that term is used in the guidance
828 Multiple Function Device Product: Policy and Considerations. Therefore, please consider the
829 impact of the OTS software on the device function-under-review and provide information (as
830 recommend in the OTS guidance) about the impact on the device function from the OTS
831 software in a manner consistent with the policy described in the Multiple Function Device
832 Product: Policy and Considerations guidance.
833
834 Additionally, please note the term SOUP, Software of Unknown Pedigree, may also be used to
835 describe software from a third party. For additional information on the term SOUP, please refer
836 to the use of the term in the standard ANSI/AAMI/IEC 62304: Medical Device Software -
837 Software Life Cycle Processes.
838
839 Comparison of Guidance to IEC 62304 and
840 ANSI/AAMI/IEC 62304
841 FDA recognizes voluntary consensus standards to help facilitate meeting requirements under the
842 statute or regulations. The use of FDA-recognized consensus standards can increase
843 predictability, streamline premarket review, provide clearer regulatory expectations, facilitate
844 market entry for safe and effective medical products, and promote international harmonization
845 (see Recognition and Withdrawal of Voluntary Consensus Standards 61).
846
847 As of this draft guidance’s publication, both IEC 62304 Edition 1.1 and ANSI/AAMI/IEC
848 62304:2006/A1:2016 Medical device software — Software life cycle processes (henceforth “IEC
849 62304”), are FDA-recognized voluntary consensus standards. The scope of each standard
850 includes life cycle requirements for medical device software, including the set of processes,

OTS guidance as the answers to questions pertaining to the description of OTS software; whereas “Basic
Documentation Level” is described in this guidance as one of two levels of documentation recommendations used to
help identify the minimum amount of information that, based on FDA’s experience, would generally be needed to
support a premarket submission for a device that uses software.
61
Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/recognition-and-
withdrawal-voluntary-consensus-standards.

25
 Contains Nonbinding Recommendations

Draft – Not for Implementation

851 activities, and tasks that establish a common framework for medical device software life cycle
852 processes.
853
854 There are similarities and differences between the intents and information discussed in this
855 guidance and IEC 62304. Both this guidance and IEC 62304 discuss how to document and
856 communicate software development, maintenance, and risk management processes. However,
857 this guidance document focuses on documentation and communication only as it pertains to
858 facilitating FDA’s complete and efficient review of device software functions subject to
859 premarket submission, whereas the scope of IEC 62304 extends beyond the intent of this
860 guidance and discusses broader perspectives that may not result in documents that are easily
861 reviewed by FDA.
862
863 Therefore, this guidance document intends to leverage IEC 62304 in a very specific manner in
864 order to reduce the amount of documentation requested to support a premarket submission for a
865 device software function. Specifically, Section V.G: Software Development and Maintenance
866 Practices offers an alternate approach through which FDA intends to accept a Declaration of
867 Conformity to IEC 62304 in place of a detailed description of software development and
868 maintenance practices (formerly, “Software Development Environment Description”). Sponsors
869 may refer to the guidance document Appropriate Use of Voluntary Consensus Standards in
870 Premarket Submissions for Medical Devices 62 for more information on preparation of a
871 Declaration of Conformity. Conformity to this consensus standard is voluntary and, as such, an
872 alternate approach is offered. When assessing the appropriate Documentation Level for the
873 device and the overall recommended documentation for inclusion in a premarket submission,
874 please refer to Section V (Documentation Level) and Section VI (Recommended
875 Documentation) of this guidance.
876

Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/appropriate-use-
62

voluntary-consensus-standards-premarket-submissions-medical-devices.

26
 Contains Nonbinding Recommendations

Draft – Not for Implementation

877 Appendix A: Documentation Level Examples

878 The following are examples of devices that demonstrate the implementation of the
879 Documentation Level factors. Please note that these generalized examples do not necessarily
880 account for every possible detail, risk, or consideration a sponsor should evaluate, and should not
881 be taken to mean that the devices described definitely do or do not require a certain
882 Documentation Level. These examples do not define the appropriate Documentation Level for a
883 particular device type. As such, the Documentation Level should be uniquely considered for each
884 particular device or device modification and in consideration of the device’s intended use. When
885 addressing the recommendations in sections V and VI.A of this guidance, FDA encourages
886 sponsors to leverage their device’s risk assessment when providing a rationale for choosing a
887 Documentation Level.
888
889
890 1. A non-contact infrared thermometer intended for intermittent measurement of body
891 temperature from the forehead
892
# Factors Yes/No
1 The device is a constituent part of a combination product. No
2 The device (a) is intended to test blood donations for transfusion- No
transmitted infections; or (b) is used to determine donor and recipient
compatibility; or (c) is Blood Establishment Computer Software.
3 The device is classified as class III. No
4 A failure or latent flaw of the device software function(s) could No
present a probable risk of death or serious injury either to the patient,
user of the device, or others in the environment of use. These risk(s)
should be assessed prior to implementation of risk control measures.
You should consider the risk(s) in the context of the device’s intended
use; the direct and indirect impacts to safety, treatment, and/or
diagnosis; and other relevant considerations.
893
894 Outcome: The device is class II and is not a constituent part of a combination product,
895 not Blood Establishment Computer Software, and is not intended for use in testing blood
896 donations for transfusion-transmitted infections or determining donor and recipient
897 compatibility. A failure or latent flaw of the device software function(s) would not
898 present a probable risk of death or serious injury to either a patient, user of the device, or
899 others in the environment of use prior to the implementation of risk control measures.
900 Therefore, this device would fall under “Basic Documentation Level.”
901
902

27
 Contains Nonbinding Recommendations

Draft – Not for Implementation

903 2. An implantable cardiac pacemaker used to treat bradycardia.

904
# Factors Yes/No
1 The device is a constituent part of a combination product. No
2 The device (a) is intended to test blood donations for transfusion- No
transmitted infections; or (b) is used to determine donor and recipient
compatibility; or (c) is Blood Establishment Computer Software.
3 The device is classified as class III. Yes
4 A failure or latent flaw of the device software function(s) could Yes
present a probable risk of death or serious injury either to the patient,
user of the device, or others in the environment of use. These risk(s)
should be assessed prior to implementation of risk control measures.
You should consider the risk(s) in the context of the device’s intended
use; the direct and indirect impacts to safety, treatment, and/or
diagnosis; and other relevant considerations.
905
906 Outcome: The device is not a constituent part of a combination product, is not Blood
907 Establishment Computer Software, and is not intended for use in testing blood donations
908 for transfusion-transmitted infections or determining donor and recipient compatibility.
909 However, the device is classified as a class III device. Furthermore, a failure or latent
910 flaw of the device software function(s) (e.g., algorithm operates as designed but
911 incorrectly senses an ectopic beat) would present a probable risk of death or serious
912 injury to the patient prior to the implementation of risk control measures. Therefore, this
913 device would fall under “Enhanced Documentation Level.”
914
915 3. A facility use continuous ventilator
916
# Factors Yes/No
1 The device is a constituent part of a combination product. No
2 The device (a) is intended to test blood donations for transfusion- No
transmitted infections; or (b) is used to determine donor and recipient
compatibility; or (c) is Blood Establishment Computer Software.
3 The device is classified as class III. No
4 A failure or latent flaw of the device software function(s) could Yes
present a probable risk of death or serious injury either to the patient,
user of the device, or others in the environment of use. These risk(s)
should be assessed prior to implementation of risk control measures.
You should consider the risk(s) in the context of the device’s intended
use; the direct and indirect impacts to safety, treatment, and/or
diagnosis; and other relevant considerations.
917

28
 Contains Nonbinding Recommendations

Draft – Not for Implementation

918 Outcome: The device is not a constituent part of a combination product, is not Blood
919 Establishment Computer Software, and is not intended for use in testing blood donations
920 for transfusion-transmitted infections or determining donor and recipient compatibility.
921 The device is class II. However, a failure or latent flaw of the device software function(s)
922 (e.g., exploited cybersecurity vulnerability compromises device functionality) would
923 present a probable risk of death or serious injury to a patient (e.g., loss of life supporting
924 function) prior to the implementation of risk control measures. Therefore, this device
925 would fall under “Enhanced Documentation Level.”
926
927 4. A Blood Establishment Computer Software or BECS accessory.
928
# Factors Yes/No
1 The device is a constituent part of a combination product. No
2 The device (a) is intended to test blood donations for transfusion- Yes
transmitted infections; or (b) is used to determine donor and recipient
compatibility; or (c) is Blood Establishment Computer Software.
3 The device is classified as class III. No
4 A failure or latent flaw of the device software function(s) could Yes
present a probable risk of death or serious injury either to the patient,
user of the device, or others in the environment of use. These risk(s)
should be assessed prior to implementation of risk control measures.
You should consider the risk(s) in the context of the device’s intended
use; the direct and indirect impacts to safety, treatment, and/or
diagnosis; and other relevant considerations.
929
930 Outcome: The device is not a constituent part of a combination product. It is Blood
931 Establishment Computer Software. The device is class II. However, a failure or latent
932 flaw of the device software function(s) (e.g., exploited cybersecurity vulnerability
933 compromises device functionality) would present a probable risk of death or serious
934 injury to a patient (e.g., loss of life supporting function) prior to the implementation of
935 risk control measures. Therefore, this device would fall under “Enhanced Documentation
936 Level.”
937
938 5. A qualitative in vitro nucleic acid screening test for the direct detection of Babesia DNA
939 and RNA in whole blood samples from individual human donors.
940

29
 Contains Nonbinding Recommendations

Draft – Not for Implementation

# Factors Yes/No
1 The device is a constituent part of a combination product. No
2 The device (a) is intended to test blood donations for transfusion- Yes
transmitted infections; or (b) is used to determine donor and recipient
compatibility; or (c) is Blood Establishment Computer Software.
3 The device is classified as class III. No
4 A failure or latent flaw of the device software function(s) could Yes
present a probable risk of death or serious injury either to the patient,
user of the device, or others in the environment of use. These risk(s)
should be assessed prior to implementation of risk control measures.
You should consider the risk(s) in the context of the device’s intended
use; the direct and indirect impacts to safety, treatment, and/or
diagnosis; and other relevant considerations.
941
942 Outcome: The device is not a constituent part of a combination product and is not Blood
943 Establishment Computer Software. The device is licensed under a BLA and consequently
944 is not class III. However, the device is intended for use in testing blood donations for a
945 transfusion-transmitted infection where an inaccurate result could result in blood
946 recipient death or serious injury prior to the implementation of risk control measures.
947 Therefore, this device would fall under “Enhanced Documentation Level.”
948
949 6. A hardware-only hip prosthesis.
950
951 Outcome: This device would not have a Documentation Level because it does not
952 contain software.
953
954
955

30
 Contains Nonbinding Recommendations

Draft – Not for Implementation

956 Appendix B: System and Software Architecture Diagram

957 Chart Examples
958 The examples are intended for illustration purposes only and are not intended to document a
959 comprehensive system and software architecture diagram for a specific medical device or
960 system. The approach illustrated can be applied to any system and software architecture diagram,
961 including standalone SaMD. The examples demonstrate how the considerations described in
962 section VI.C (System and Software Architecture Design Chart) can be implemented into a
963 system and architecture diagram. The example is not intended to represent a complete system
964 and architecture diagram.
965

966
967 Figure 1: Example Architecture Design Chart – Overview of all modules
968

31
 Contains Nonbinding Recommendations

Draft – Not for Implementation

969
970 Figure 2: Example Architecture Design Chart – Detail view of example module #1
971

32
 Contains Nonbinding Recommendations

Draft – Not for Implementation

972
973 Figure 3: Example Architecture Design Chart – Detail view of example module #2
974

33
 Contains Nonbinding Recommendations

Draft – Not for Implementation

975
976 Figure 4: Example Architecture Design Chart – Detail view of example module #3
977
978

34
 Contains Nonbinding Recommendations

Draft – Not for Implementation

979
980 Figure 5: Example Architecture Design Chart – Detail view of example module #4
981

35
 Contains Nonbinding Recommendations

Draft – Not for Implementation

982
983 Figure 6: Example Architecture Design Chart – Detail view of example module #5
984
985
986

36