Contains Nonbinding Recommendations
Draft Not for Implementation
Computer Software Assurance for 
Production and Quality System 
Software
______________________________________________________________________________
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 September 13, 2022.
You should submit comments and suggestions regarding this draft document within 60 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 Compliance 
and Quality Staff at 301-796-5577 or by email at CaseforQuality@fda.hhs.gov. 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 
ocod@fda.hhs.gov. 
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-
Guidance@fda.hhs.gov to receive a copy of the guidance. Please include the document number 
17045 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, ocod@fda.hhs.gov 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 .......................................................................................................................................................... 4
II.  Background .......................................................................................................................................................... 5
III.  Scope .................................................................................................................................................................... 6
IV.  Computer Software Assurance ............................................................................................................................. 6
V.  Computer Software Assurance Risk Framework ................................................................................................. 7
Identifying the Intended Use........................................................................................................................7
Determining the Risk-Based Approach........................................................................................................9
Determining the Appropriate Assurance Activities...................................................................................13
Establishing the Appropriate Record.........................................................................................................16
Appendix A. Examples ................................................................................................................................................ 20
Example 1: Nonconformance Management System ............................................................................................... 20
Example 2: Learning Management System (LMS) ................................................................................................ 23
Example 3: Business Intelligence Applications ...................................................................................................... 24 Contains Nonbinding Recommendations
Draft Not for Implementation
Computer Software Assurance for 
1
Production and Quality System 
2
Software 
3 
4  ______________________________________________________________________________
Draft Guidance for Industry and
5
Food and Drug Administration Staff
6
7
8 This draft guidance, when finalized, will represent the current thinking of the Food and Drug 
9 Administration (FDA or Agency)on this topic.  It does not establish any rights for any person 
10 and is not binding on FDA or the public.  You can use an alternative approach if it satisfies
11 the requirements of the applicable statutes and regulations.  To discuss an alternative 
12 approach, contact the FDA staff or Office responsible for this guidanceas listed on the title 
13 page.
14
I. Introduction1
15
16 FDA is issuing this draft guidance to provide recommendations on computer software assurance 
17 for computers and automated data processing systems used as part of medical device production 
18 or the quality system. This draft guidance is intended to:
19
20  Describe computer software assurance as a risk-based approach to establish confidence 
21 in the automation used for production or quality systems,and identify where additional 
22 rigor may be appropriate; and
23
24  Describe various methods and testing activities that may be applied to establish computer 
25 software assurance and provide objective evidence to fulfill regulatory requirements, 
26 such as computer software validation requirements in21 CFR part 820 (Part 820).
27
28 When final, this guidance will supplement FDAs guidance, General Principles of Software 
29 Validation (Software Validation guidance)2 except this guidance will supersede Section 6 
30 (Validation of Automated Process Equipment and Quality System Software) of the Software 
31 Validation guidance.
32
1 This guidance has been prepared by the Center for Devices and Radiological Health (CDRH) and the Center for 
Biologics Evaluation and Research (CBER) in consultation with the Center for Drug Evaluation and Research 
(CDER), Office of Combination Products (OCP), and Office of Regulatory Affairs (ORA).
2 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-principles-
software-validation. 
4 Contains Nonbinding Recommendations
Draft Not for Implementation
33 For the current edition of the FDA-recognized consensus standard referenced in this document, 
34 see the FDA Recognized Consensus Standards Database.3
35
36 In general, FDAs guidance documents do not establish legally enforceable responsibilities. 
37 Instead, guidances describe the Agencys current thinking on a topic and should be viewed only 
38 as recommendations, unless specific regulatory or statutory requirements are cited. The use of 
39 the word should in Agency guidances means that something is suggested or recommended, but 
40 not required.
41
II. Background
42
43  FDAenvisions a future state where the medical device ecosystem is inherently focused on device 
44  features and manufacturing practices that promote product quality and patient safety. FDA has 
45  sought to identify and promote successful manufacturing practices and help device 
46  manufacturers raise their manufacturing quality level. In doing so, one goal is to help 
47  manufacturers produce high-quality medical devices that align with the laws and regulations 
48  implemented by FDA. Compliance with the Quality System regulation, Part 820, is required for 
49  manufacturers of finished medical devices to the extent they engage in operations to which Part 
50 820 applies. The Quality System regulation includes requirements for medical device 
51 manufacturers to develop, conduct, control, and monitor production processes to ensure that a 
52 device conforms to its specifications (21 CFR 820.70, Production and Process Controls), 
53 including requirements for manufacturers to validate computer software used as part of 
54 production or the quality system for its intended use (see 21 CFR 820.70(i)).4 Recommending
55 best practicesshould promoteproduct quality and patient safety, and correlateto higher-quality 
56 outcomes. This draft guidance addresses practices relating to computers and automated data 
57 processing systems used as part of production or the quality system.
58
59 In recent years, advances in manufacturing technologies, including the adoption of automation, 
60 robotics, simulation, and other digital capabilities,have allowedmanufacturers to reducesources 
61 of error, optimize resources, and reduce patient risk. FDA recognizes the potential for these 
62 technologies to provide significant benefits for enhancing the quality, availability, and safety of 
63 medical devices, and has undertaken several efforts to help foster the adoption and use of such
64 technologies. 
65
66 Specifically, FDA has engaged with stakeholders via the Medical Device Innovation Consortium 
67 (MDIC), site visits to medical device manufacturers, and benchmarking efforts with other 
68 industries (e.g., automotive, consumer electronics) to keep abreast of thelatest technologies and 
69 to better understand stakeholders challenges and opportunities for further advancement. As part 
70 of these ongoing efforts, medical device manufacturers have expressed a desire for greater clarity 
71 regarding the Agencys expectationsfor software validation for computers and automated data 
72 processing systems used as part of production or the quality system. Given the rapidly changing 
3 Available at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/search.cfm.
4 This guidance discusses the intended use of computer software used as part of production or the quality system 
(see 21 CFR 820.70(i)), which is different from the intended use of the device itself (see 21 CFR 801.4).
5 Contains Nonbinding Recommendations
Draft Not for Implementation
73  nature of software, manufacturers have also expressed a desire for a more iterative, agile 
74 approach for validation of computer software used as part of production or the quality system. 
75
76  Traditionally, software validation has often been accomplished via software testing and other 
77  verification activities conducted at each stage of the software development lifecycle.  However, 
78  as explained in FDAs Software Validation guidance, software testing alone is often insufficient 
79  to establish confidence that the software is fit for its intended use. Instead, the Software 
80  Validation guidance recommends that software quality assurance focus on preventing the 
81  introduction of defects into the software development process, and it encourages use of a risk-
82 based approach for establishing confidence that software is fit for its intended use.
83
84  FDA believes that applying a risk-based approach to computer software used as part of 
85  production or the quality system would better focus manufacturers assurance activities to help 
86  ensure product quality while helping to fulfill the validation requirements of 21 CFR 820.70(i). 
87  For these reasons, FDA is now providing recommendations on computer software assurance for 
88  computers and automated data processing systems used as part of medical device production or 
89  the quality system. FDA believes that these recommendations will help foster the adoption and 
90  use of innovative technologies that promote patient access to high-quality medical devices and 
91  help manufacturers to keep pace with the dynamic, rapidly changing technology landscape, while 
92 promoting compliance with laws and regulations implemented by FDA. 
93
III.  Scope
94
95  When final, this guidance is intended to provide recommendations regarding computer software 
96  assurance for computers or automated data processing systems used as part of production or the 
97 quality system. 
98
99  This guidance is not intended to provide a complete description of all software validation 
100  principles. FDA has previously outlined principles for software validation, including managing 
101  changes as part of the software lifecycle, in FDAs Software Validation guidance. This guidance 
102  applies the risk-based approach to software validation discussed in the Software Validation 
103  guidance to production or quality system software. This guidance additionally discusses specific 
104  risk considerations, acceptable testing methods, and efficient generation of objective evidence 
105 for production or quality system software. 
106
107  This guidance does not provide recommendations for the design verification or validation 
108  requirements specified in 21 CFR 820.30 when applied to software in a medical device (SiMD) 
109  or software as a medical device (SaMD). For more information regarding FDAs 
110  recommendations for design verification or validation of SiMD or SaMD, see the Software 
111 Validation guidance. 
112
IV.  Computer Software Assurance 
113
114  Computer software assurance is a risk-based approach for establishing and maintaining 
115 confidence that software is fit for its intended use. This approach considers the risk of 
6 Contains Nonbinding Recommendations
Draft Not for Implementation
116  compromised safety and/or quality of the device (should the software fail to perform as intended) 
117  to determine the level of assurance effort and activities appropriate to establish confidence in the 
118  software. Because the computer software assurance effort is risk-based, it follows a least-
119  burdensome approach, where the burden of validation is no more than necessary to address the 
120 risk. Such an approach supports the efficient use of resources, in turn promoting product quality.
121
122  In addition, computer software assurance establishes and maintains that the software used in 
123  production or the quality system is in a state of control throughout its lifecycle (validated 
124  state). This is important because manufacturers increasingly rely on computers and automated 
125  processing systems to monitor and operate production, alert responsible personnel, and transfer 
126  and analyze production data, among other uses.  By allowing manufacturers to leverage 
127  principles such as risk-based testing, unscripted testing, continuous performance monitoring, and 
128  data monitoring, as well as validation activities performed by other entities (e.g., developers, 
129  suppliers), the computer software assurance approach provides flexibility and agility in helping 
130 to assure that the software maintains a validated state consistent with 21 CFR 820.70(i).
131
132  Software that is fit for its intended use and that maintains a validated state should perform as 
133  intended, helping to ensure that finished devices will be safe and effective and in compliance 
134  with regulatory requirements (see 21 CFR 820.1(a)(1)). Section V below outlines a risk-based 
135 framework for computer software assurance.
136
V.  Computer Software Assurance Risk Framework 
137
138  The following approach is intended to help manufacturers establish a risk-based framework for 
139  computer software assurance throughout the softwares lifecycle. Examples of applying this risk 
140 framework to various computer software assurance situations are provided in Appendix A. 
Identifying the Intended Use 
141
142  The regulation requires manufacturers to validate software that is used as part of production or 
143  the quality system for its intended use (see 21 CFR 820.70(i)). To determine whether the 
144  requirement for validation applies, manufacturers must first determine whether the software is 
145 intended for use as part of production or the quality system. 
146
147  In general, software used as part of production or the quality system falls into one of two 
148  categories: software that is used directly as part of production or the quality system, and software 
149 that supports production or the quality system. 
150
151  Software with the following intended uses are considered to be used directly as part of 
152 production or the quality system:
153
154   Software intended for automating production processes, inspection, testing, or the 
155 collection and processing of production data; and
156   Software intended for automating quality system processes, collection and processing of 
157  quality system data, or maintaining a quality record established under the Quality System 
158 regulation.
7 Contains Nonbinding Recommendations
Draft Not for Implementation
159
160 Software with the following intended uses are considered to be used to supportproduction or 
161 the quality system: 
162
163    Software intended for use as development tools that test or monitor software systems or 
164  that automate testing activities for the software used as part of production or the quality 
165  system, such as those used for developing and running scripts; and 
166    Software intended for automating general record-keeping that is not part of the quality 
167  record. 
168   
169  Both kinds of software are used as part of production or the quality system and must be 
170  validated under 21 CFR 820.70(i). However, as further discussed below, supporting software 
171  often carries lower risk, such that under a risk-based computer software assurance approach, the 
172  effort of validation may be reduced accordingly without compromising safety.  
173   
174  On the other hand, software with the following intended uses generally are not considered to be 
175 used as part of production or the quality system, such that the requirement for validation in 21 
176 CFR 820.70(i) would not apply:  
177
178    Software intended for management of general business processes or operations, such as 
179  email or accounting applications; and 
180    Software intended for establishing or supporting infrastructure not specific to production 
181  or the quality system, such as networking or continuity of operations. 
182   
183  FDA recognizes that software used in production or the quality system is often complex and 
184  comprised of several features, functions, and operations;5 software may have one or more 
185  intended uses depending on the individual features, functions, and operations of that software. In 
186  cases where the individual features, functions, and operations have different roles within 
187 production or the quality system, they may present different risks with different levels of 
188 validation effort. FDA recommends that manufacturers examine the intended uses of the 
189 individual features, functions, and operations to facilitate development of a risk-based assurance 
190 strategy. Manufacturers may decide to conduct different assurance activities for individual 
191 features, functions, or operations.
192
193 For example, a commercial off-the-shelf (COTS) spreadsheet software may be comprised of 
194 various functions with different intended uses. When utilizing the basic input functions of the 
195 COTS spreadsheet software for an intended use of documenting the time and temperature 
196 readings for a curing process, a manufacturer may not need to perform additional assurance
197 activities beyond thoseconducted by the COTS software developer and initial installation and 
198 configuration. The intended use of the software, documenting readings, only supports
199 maintaining the quality system record and poses a low process risk. As such, initial activities 
5 That is, software is often an integration of features, that are used together to perform a function that provides a 
desired outcome. Several functions of the software may, in turn, be applied together in an operation to perform 
practical work in a process. For the purposes of this guidance, a function refers to a software function and is not 
to be confused with a device function.
8 Contains Nonbinding Recommendations
Draft Not for Implementation
200  such as the vendor assessment and software installation and configuration may be sufficient to 
201  establish that the software is fit for its intended use and maintains a validated state. However, if a 
202  manufacturer utilizes built-in functions of the COTS spreadsheet to create custom formulas that 
203  are directly used in production or the quality system, then additional risks may be present. For 
204  example, if a custom formula automatically calculates time and temperature statistics to monitor 
205  the performance and suitability of the curing process, then additional validation by the 
206 manufacturer might be necessary.
207
208  For the purposes of this guidance, we describe and recommend a computer software assurance 
209  framework by examining the intended uses of the individual features, functions, or operations of 
210  the software. However, in simple cases where software only has one intended use (e.g., if all of 
211  the features, functions, and operations within the software share the same intended use), 
212  manufacturers may not find it helpful to examine each feature, function, and operation 
213  individually. In such cases, manufacturers may develop a risk-based approach and consider 
214 assurance activities based on the intended use of the software overall.
215
216  FDA recommends that manufacturers document their decision-making process for determining 
217  whether a software feature, function, or operation is intended for use as part of production or the 
218 quality system in their Standard Operating Procedures (SOPs). 
219
Determining the RiskBased Approach  
220 
221  Once a manufacturer has determined that a software feature, function, or operation is intended 
222  for use as part of production or the quality system, FDA recommends using a risk-based analysis 
223  to determine appropriate assurance activities. Broadly, this risk-based approach entails 
224  systematically identifying reasonably foreseeable software failures, determining whether such a 
225  failure poses a high process risk, and systematically selecting and performing assurance activities 
226 commensurate with the medical device or process risk, as applicable.
227
228  Note that conducting a risk-based analysis for computer software assurance for production or 
229  quality system software is distinct from performing a risk analysis for a medical device as 
230  described in ISO 14971:2019  Medical devices  Application of risk management to medical 
231  devices. Unlike the risks contemplated in ISO 14971:2019 for analysis (medical device risks), 
232  failures of the production or the quality system software to perform as intended do not occur in a 
233  probabilistic manner where an assessment for the likelihood of occurrence for a particular risk 
234 could be estimated based on historical data or modeling.
235
236  Instead, the risk-based analysis for production or quality system software considers those factors 
237  that may impact or prevent the software from performing as intended, such as proper system 
238  configuration and management, security of the system, data storage, data transfer, or operation 
239  error. Thus, a risk-based analysis for production or quality system software should consider 
240  which failures are reasonably foreseeable (as opposed to likely) and the risks resulting from each 
241  such failure. This guidance discusses both process risks and medical device risks. A process risk 
242  refers to the potential to compromise production or the quality system. A medical device risk 
243 refers to the potential for a device to harm the patient or user. When discussing medical device 
9 Contains Nonbinding Recommendations
Draft Not for Implementation
244  risks, this guidance focuses on the medical device risk resulting from a quality problem that 
245 compromises safety. 
246
247  Specifically, FDA considers a software feature, function, or operation to pose a high process risk 
248  when its failure to perform as intended may result in a quality problem that foreseeably 
249  compromises safety, meaning an increased medical device risk. This process risk 
250  identification step focuses only on the process, as opposed to the medical device risk posed to the 
251  patient or user. Examples of software features, functions, or operations that are generally high 
252 process risk are those that: 
253
254   maintain process parameters (e.g., temperature, pressure, or humidity) that affect the 
255  physical properties of product or manufacturing processes that are identified as essential 
256 to device safety or quality;
257
258   measure, inspect, analyze and/or determine acceptability of product or process with 
259 limited or no additional human awareness or review;
260
261   perform process corrections or adjustments of process parameters based on data 
262  monitoring or automated feedback from other process steps without additional human 
263 awareness or review;
264
265   produce directions for use or other labeling provided to patients and users that are 
266 necessary for safe operation of the medical device; and/or
267
268   automate surveillance, trending, or tracking of data that the manufacturer identifies as 
269 essential to device safety and quality.
270
271  In contrast, FDA considers a software feature, function, or operation not to pose a high process 
272  risk when its failure to perform as intended would not result in a quality problem that 
273  foreseeably compromises safety. This includes situations where failure to perform as 
274  intended would not result in a quality problem, as well as situations where failure to 
275  perform as intended may result in a quality problem that does not foreseeably lead to 
276  compromised safety. Examples of software features, functions, or operations that generally are 
277 not high process risk include those that: 
278
279   collect and record data from the process for monitoring and review purposes that do not 
280 have a direct impact on production or process performance;
281
282   are used as part the quality system for Corrective and Preventive Actions (CAPA) 
283  routing, automated logging/tracking of complaints, automated change control 
284 management, or automated procedure management; 
285
286   are intended to manage data (process, store, and/or organize data), automate an existing 
287  calculation, increase process monitoring, or provide alerts when an exception occurs in an 
288 established process; and/or
10 Contains Nonbinding Recommendations
Draft Not for Implementation
289
290  are used to support production or the quality system, as explained in Section V.A. above.
291
292  FDA acknowledges that process risks associated with software used as part of production or the 
293  quality system are on a spectrum, ranging from high risk to low risk. Manufacturers should 
294  determine the risk of each software feature, function, or operation as the risk falls on that 
295  spectrum, depending on the intended use of the software. However, FDA is primarily concerned 
296  with the review and assurance for those software features, functions, and operations that are high 
297  process risk because a failure also poses a medical device risk. Therefore, for the purposes of this 
298  guidance, FDA is presenting the process risks in a binary manner, high process risk and not 
299  high process risk. A manufacturer may still determine that a process risk is, for example, 
300  moderate, intermediate, or even low for purposes of determining assurance activities; in 
301  such a case, the portions of this guidance concerning not high process risk would apply. As 
302  discussed in Section V.C. below, assurance activities should be conducted for software that is 
303 high process risk and not high process risk commensurate with the risk.
304
305  Example 1: An Enterprise Resource Planning (ERP) Management system contains a feature that 
306  automates manufacturing material restocking. This feature ensures that the right materials are 
307  ordered and delivered to appropriate production operations. However, a qualified person checks 
308  the materials before their use in production. The failure of this feature to perform as intended 
309  may result in a mix-up in restocking and delivery, which would be a quality problem because the 
310  wrong materials would be restocked and delivered. However, the delivery of the wrong materials 
311  to the qualified person should result in the rejection of those materials before use in production; 
312  as such, the quality problem should not foreseeably lead to compromised safety. The 
313  manufacturer identifies this as an intermediate (not high) process risk and determines assurance 
314  activities commensurate with the process risk. The manufacturer already undertakes some of 
315  those identified assurance activities so implements only the remaining identified assurance 
316 activities.
317
318  Example 2: A similar feature in another ERP management system performs the same tasks as in 
319  the previous example except that it also automates checking the materials before their use in 
320  production. A qualified person does not check the material first. The manufacturer identifies this 
321  as a high process risk because the failure of the feature to perform as intended may result in a 
322  quality problem that foreseeably compromises safety. As such, the manufacturer will determine 
323  assurance activities that are commensurate with the related medical device risk. The 
324  manufacturer already undertakes some of those identified assurance activities so implements 
325 only the remaining identified assurance activities.
326
327  Example 3: An ERP management system contains a feature to automate product delivery. The 
328  medical device risk depends upon, among other factors, the correct product being delivered to 
329  the device user. A failure of this feature to perform as intended may result in a delivery mix-up, 
330  which would be a quality problem that foreseeably compromises safety; as such, the 
331  manufacturer identifies this as a high process risk. Since the failure would compromise safety, 
332  the manufacturer will next determine the related increase in device risk and identify the 
333 assurance activities that are commensurate with the device risk. In this case, the manufacturer 
11 Contains Nonbinding Recommendations
Draft Not for Implementation
334 has not already implemented any of the identified assurance activities so implements all of the 
335 assurance activitiesidentified in the analysis.
336
337 Example 4: An automated graphical user interface (GUI) function in the production software is 
338 used for developing test scripts based on user interactions and to automate future testing of 
339 modifications to the user interface of a system used in production. A failure ofthis GUI function 
340 to perform as intended may result in implementation disruptions and delay updates to the 
341 production system, but in this case, these errors should not foreseeablylead to compromised 
342 safetybecausethe GUI function operates in a separate test environment. The manufacturer 
343 identifies this as a low (not high) process risk and determines assurance activitiesthat are 
344 commensurate with the process risk. The manufacturer already undertakes some of those 
345 identified assurance activities so implements only the remaining identified assurance activities.
346
347 As noted in FDAs guidance, 30-Day Notices, 135 Day Premarket Approval (PMA) 
348 Supplements and 75-Day Humanitarian Device Exemption (HDE) Supplements for 
349  Manufacturing Method or Process Changes,6 for devices subject to a PMA or HDE, changes to 
350  the manufacturing procedure or method of manufacturing that do not affect the safety or 
351  effectiveness of the device must be submitted in a periodic report (usually referred to as an 
352  annual report).7 In contrast, modifications to manufacturing procedures or methods of 
353  manufacture that affect the safety and effectiveness of the device must be submitted in a 30-day 
354  notice.8 Changes to the manufacturing procedure or method of manufacturing may include 
355  changes to software used in production or the quality system. For an addition or change to 
356  software used in production or the quality system of devices subject to a PMA or HDE, FDA 
357 recommends that manufacturers applythe principles outlined above in determining whether the 
358 change may affect the safety or effectiveness of the device. In general, if a change may result in a 
359  quality problem that foreseeably compromises safety, then it should be submitted in a 30-day 
360  notice. If a change would not result in a quality problem that foreseeably compromises safety, an 
361  annual report may be appropriate.  
362   
363  For example, a Manufacturing Execution System (MES) may be used to manage workflow, track 
364  progress, record data, and establish alerts or thresholds based on validated parameters, which are 
365  part of maintaining the quality system. Failure of such an MES to perform as intended may 
366  disrupt operations but not affect the process parameters established to produce a safe and 
367  effective device. Changes affecting these MES operations are generally considered annually 
368  reportable. In contrast, an MES used to automatically control and adjust established critical 
369 production parameters (e.g.,temperature, pressure, process time) may be a change to a 
370 manufacturing procedure that affects the safety or effectiveness of the device. If so, changes 
371 affecting this specific operation would require a 30-day notice.
372
6 Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/30-day-notices-135-day-
premarket-approval-pma-supplements-and-75-day-humanitarian-device-exemption. 
7 21 CFR 814.39(b), 814.126(b)(1), and https://www.fda.gov/regulatory-information/search-fda-guidance-
documents/annual-reports-approved-premarket-approval-applications-pma.
8 21 CFR 814.39(b), 814.126(b)(1).  Changes in manufacturing/sterilization site or to design or performance 
specifications do not qualify for a 30-day notice.  
12 Contains Nonbinding Recommendations
Draft Not for Implementation
Determining the Appropriate Assurance Activities 
373
374 Once the manufacturer has determined whether a software feature, function, or operation poses a 
375 high process risk (a quality problem that may foreseeably compromise safety),the manufacturer 
376 should identify theassurance activities commensurate with the medical device risk or the process 
377 risk. In cases where the quality problem may foreseeably compromise safety (high process risk), 
378 the level of assurance should be commensurate with the medical device risk.In cases where the 
379 quality problem may not foreseeably compromise safety(not high process risk), the level of 
380 assurance rigor should be commensurate with the process risk. In either case, heightened risks of 
381 software features, functions, or operations generally entail greaterrigor, i.e., a greater amount of 
382 objective evidence. Conversely, relatively less risk (i.e., not high process risk)of compromised 
383 safety and/or quality generallyentails less collection of objective evidence for the computer 
384 software assurance effort.
385
386 Afeature, function, or operation that could lead to severe harm to a patient or user would 
387 generally be high device risk. In contrast, a feature, function, or operation that would not 
388 foreseeably lead to severe harm would likely not be high device risk. In either case, the risk of 
389 the softwares failure to perform as intended is commensurate with the resulting medical device 
390 risk.
391
392 If the manufacturer instead determined that the software feature, function,or operation does not 
393 pose a high process risk (i.e., it would not lead to a quality problem that foreseeably 
394 compromises safety), the manufacturer should consider the risk relative to the process, i.e., 
395 production or the quality system. This is because the failure would not compromise safety, so the 
396 failure would not introduce additional medical device risk. For example, a function that collects 
397 and records process data for review would pose a lower process risk than a function that 
398 determines acceptability of product prior to human review.
399
400 Types of assurance activities commonly performed by manufacturers include, but are not limited 
401 to, the following:
402
403  Unscripted testingDynamic testing in which thetesters actions are not prescribed by 
404 written instructions in a test case.9 It includes:
405
406  Ad-hoc testingA concept derived from unscripted practice that focuses primarily 
407 on performing testing that does not rely on large amounts of documentation (e.g., test 
408 procedures) to execute.10
409
410  Error-guessing A test design technique in which test cases are derived on the basis 
411 of the testers knowledge of past failures or general knowledge of failure modes.11
412
9 IEC/IEEE/ISO 29119-1 First edition 2013-09-01: Software and systems engineering  Software testing - Part 1: 
Concepts and definitions, Section 4.94.
10 Ibid., Section 5.6.5.
11 Ibid., Section 4.14.
13 Contains Nonbinding Recommendations
Draft Not for Implementation
413  Exploratory testing  Experience-based testing in which the tester spontaneously 
414 designs and executes tests based on the testers existing relevant knowledge, prior 
415 exploration of the test item (including results from previous tests), and heuristic 
416 rules of thumb regarding common software behaviors and types of failure. 
417 Exploratory testing looks for hidden properties, including hidden, unanticipated user 
418 behaviors, or accidental use situations that could interfere with other software 
419 properties being tested and could pose a risk of software failure.12
420
421    Scripted testing  Dynamic testing in which the testers actions are prescribed by written 
422  instructions in a test case. Scripted testing includes both robust and limited scripted 
423  testing.13  
424   
425    Robust scripted testing  Scripted testing efforts in which the risk of the computer 
426  system or automation includes evidence of repeatability, traceability to requirements, 
427  and auditability. 
428   
429    Limited scripted testing  A hybrid approach of scripted and unscripted testing that 
430  is appropriately scaled according to the risk of the computer system or automation. 
431  This approach may apply scripted testing for high-risk features or operations and 
432  unscripted testing for low- to medium-risk items as part of the same assurance effort. 
433   
434 In general, FDA recommends that manufacturers apply principles of risk-based testing in which 
435 the management, selection, prioritization, and use of testing activities and resources are
436 consciously based on corresponding types and levels of analyzed risk to determine the 
437 appropriate activities.14 For high-risk software features, functions,and operations, manufacturers 
438 may choose to consider more rigorsuch as the use of scripted testing or limited scripted testing, 
439 as appropriate,when determining their assurance activities.In contrast, for software features, 
440 functions,and operations that are not high-risk, manufacturers may consider using unscripted 
441 testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a combination of 
442 methods that is suitablefor the risk of theintended use.
443
444  When deciding on the appropriate assurance activities, manufacturers should consider whether 
445  there are any additional controls or mechanisms in place throughout the quality system that may 
446  decrease the impact of compromised safety and/or quality if failure of the software feature, 
447  function or operation were to occur. For example, as part of a comprehensive assurance 
448  approach, manufacturers can leverage the following to reduce the effort of additional assurance 
449 activities:
450
451   Activities, people, and established processes that provide control in production. Such 
452  activities may include procedures to ensure integrity in the data supporting production or 
453 software quality assurance processes performed by other organizational units. 
454
12 Ibid., Section 4.16.
13 Ibid., Section 4.37. 
14 Ibid., Section 4.35.
14 Contains Nonbinding Recommendations
Draft Not for Implementation
455   Established purchasing control processes for selecting and monitoring software 
456  developers. For example, the manufacturer could incorporate the practices, validation 
457  work, and electronic information already performed by developers of the software as the 
458  starting point and determine what additional activities may be needed. For some lower-
459  risk software features, functions, and operations, this may be all the assurance that is 
460 needed by the manufacturer.
461
462   Additional process controls that have been incorporated throughout production. For 
463  example, if a process is fully understood, all critical process parameters are monitored, 
464  and/or all outputs of a process undergo verification testing, these controls can serve as 
465  additional mechanisms to detect and correct the occurrence of quality problems that may 
466  occur if a software feature, function, or operation were to fail to perform as intended. In 
467  this example, the presence of these controls can be leveraged to reduce the effort of 
468 assurance activities appropriate for the software. 
469
470   The data and information periodically or continuously collected by the software for the 
471  purposes of monitoring or detecting issues and anomalies in the software after 
472  implementation of the software. The capability to monitor and detect performance issues 
473  or deviations and system errors may reduce the risk associated with a failure of the 
474  software to perform as intended and may be considered when deciding on assurance 
475 activities.   
476
477   The use of Computer System Validation tools (e.g., bug tracker, automated testing) for 
478  the assurance of software used in production or as part of the quality system whenever 
479 possible.
480
481   The use of testing done in iterative cycles and continuously throughout the lifecycle of 
482 the software used in production or as part of the quality system.
483
484  For example, supporting software, as referenced in Section V.A., often carries lower risk, such 
485  that the assurance effort may generally be reduced accordingly. Because assurance activities 
486  used directly in production or the quality system often inherently cover the performance of 
487  supporting software, assurance that this supporting software performs as intended may be 
488  sufficiently established by leveraging vendor validation records, software installation, or 
489  software configuration, such that additional assurance activities (e.g., scripted or unscripted 
490 testing) may be unnecessary. 
491
492  Manufacturers are responsible for determining the appropriate assurance activities for ensuring 
493  the software features, functions, or operations maintain a validated state. The assurance activities 
494  and considerations noted above are some possible ways of providing assurance and are not 
495  intended to be prescriptive or exhaustive. Manufacturers may leverage any of the activities or a 
496 combination of activities that are most appropriate for risk associated with the intended use. 
497
15 Contains Nonbinding Recommendations
Draft Not for Implementation
Establishing the Appropriate Record
498
499 When establishing the record, the manufacturer should capture sufficient objective evidence to 
500 demonstrate that the software feature, function, or operation was assessed and performs as
501 intended. In general, the record should include the following: 
502
503  the intended use of the software feature, function, or operation;
504   the determination of risk of the software feature, function, or operation; 
505  documentation of the assurance activities conducted, including: 
506   description of the testing conducted based on the assurance activity; 
507  issues found (e.g., deviations, failures) and the disposition; 
508   conclusion statement declaring acceptability of the results;
509  the date of testing/assessment and the name of the person who conducted the 
510 testing/assessment;
511   established review and approval when appropriate (e.g., when necessary, a 
512 signature and date of an individual with signatory authority)
513
514 Documentation of assurance activities need not include moreevidence than necessary to show 
515 that the software feature, function, or operation performs as intended for the risk identified. FDA 
516 recommends the record retain sufficient details of the assurance activity to serve as a baseline for 
517 improvements or as a reference point if issues occur.15
518
519 Table 1 provides some examples of ways to implement and develop the record when using the 
520 risk-based testing approaches identified in Section V.C. above. Manufacturers may use 
521 alternative approaches and provide different documentation so long as their approach satisfies 
522 applicable legal documentation requirements.
523
524 Table 1Examples of Assurance Activities and Records
Assurance  Record  
Test Plan Test Results
Activity (Including Digital) 
Scripted    Test objectives    Pass/fail for test   Intended use
Testing:   Test cases  case   Risk determination
(step-by-step    Details regarding   Detailed report of testing performed
Robust procedure)  any   Pass/fail result for each test case 
  Expected  failures/deviations   Issues found and disposition
results  found   Conclusion statement
  Independent   Record of who performed testing and 
review and  date
approval of test   Established review andapproval when 
cases   appropriate
15 For the Quality System regulations general requirements for records, including record retention period, see 21 
CFR 820.180.
  
16 Contains Nonbinding Recommendations
Draft Not for Implementation
Assurance  Record 
Test Plan Test Results
Activity (Including Digital)
Scripted   Limited test   Pass/fail for test   Intended use
Testing: cases (step-by- case identified  Risk determination
step procedure)   Details regarding   Summary description of testing 
Limited identified any  performed
 Expected  failures/deviations   Pass/fail test result for each test case 
results for the  found   Issues found and disposition
test cases  Conclusion statement
 Identify   Record of who performed testing and 
unscripted  date
testing applied
  Established review and approval when 
 Independent  appropriate
review and 
approval of test 
plan 
Unscripted    Testing of    Details regarding   Intended use
Testing: features and  any   Risk determination
functions with  failures/deviations   Summary description of features and 
Ad-hoc  no test plan found functions tested and testing performed
 Issues found and disposition
 Conclusion statement
 Record of who performed testing and 
date of testing
 Established review and approval when 
appropriate
Unscripted    Testing of    Details regarding   Intended use
Testing: failure-modes  any failures/   Risk determination
with no test  deviations found  Summary description of failure-modes 
Error guessing plan tested and testing performed
 Issues found and disposition
 Conclusion statement
 Record of who performed testing and 
date of testing
 Established review and approval when 
appropriate
Unscripted    Establish high   Pass/fail for each   Intended use
Testing: level test plan  test plan objective   Risk determination
objectives (no   Details regarding   Summary description of the objectives 
Exploratory  step-by-step  any  tested and testing performed
Testing procedure is  failures/deviations   Pass/fail test result for each objective
necessary) found  Issues found and disposition
 Conclusion statement
 Record of who performed testing and 
date of testing
 Established review and approval when 
appropriate
525
526
527
528
17 Contains Nonbinding Recommendations
Draft Not for Implementation
529  The following is an example of a record of assurance in a scenario where a manufacturer has 
530  developed a spreadsheet with the intended use of collecting and graphing nonconformance data 
531  stored in a controlled system for monitoring purposes. In this example, the manufacturer has 
532  established additional process controls and inspections that ensure non-conforming product is not 
533  released. In this case, failure of the spreadsheet to perform as intended would not result in a 
534  quality problem that foreseeably leads to compromised safety, so the spreadsheet would not pose 
535  a high process risk. The manufacturer conducted rapid exploratory testing of specific functions 
536  used in the spreadsheet to ensure that analyses can be created, read, updated, and/or deleted. 
537  During exploratory testing, all calculated fields updated correctly except for one deviation that 
538 occurred during update testing. In this scenario, the record would be documented as follows:  
539
540   Intended Use: The spreadsheet is intended for use in collecting and graphing 
541  nonconformance data stored in a controlled system for monitoring purposes; as such, it is 
542  used as part of production or the quality system. Because of this use, the spreadsheet is 
543 different from similar software used for business operations such as for accounting.
544
545   Risk-Based Analysis: In this case, the software is only used to collect and display data 
546  for monitoring nonconformances, and the manufacturer has established additional process 
547  controls and inspections to ensure that nonconforming product is not released. Therefore, 
548  failure of the spreadsheet to perform as intended should not result in a quality problem 
549  that foreseeably leads to compromised safety. As such, the software does not pose a high 
550 process risk, and the assurance activities should be commensurate with the process risk.
551
552  Tested: Spreadsheet X, Version 1.2
553
554  Test type: Unscripted testing  exploratory testing
555
556  Goal:  Ensure that analyses can be correctly created, read, updated, and deleted 
557
558  Testing objectives and activities: 
559
560 o  Create new analysis  Passed
561 o  Read data from the required source  Passed
562 o  Update data in the analysis  Failed due to input error, then passed
563 o  Delete data  Passed
564  o  Verify through observation that all calculated fields correctly update with changes 
565  Passed with noted deviation  
566
567   Deviation: During update testing, when the user inadvertently input text into an 
568 updatable field requiring numeric data, the associated row showed an immediate error.
569
570   Conclusion: No errors were observed in the spreadsheet functions beyond the deviation.  
571  Incorrectly inputting text into the field is immediately visible and does not impact the risk 
572  of the intended use. In addition, a validation rule was placed on the field to permit only 
573 numeric data inputs.
18 Contains Nonbinding Recommendations
Draft Not for Implementation
574
575    When/Who: July 9, 2019, by Jane Smith 
576   
577  Advances in digital technology may allow for manufacturers to leverage automated traceability, 
578  testing, and the electronic capture of work performed to document the results, reducing the need 
579  for manual or paper-based documentation. As a least burdensome method, FDA recommends the 
580  use of electronic records, such as system logs, audit trails, and other data generated by the 
581  software, as opposed to paper documentation and screenshots, in establishing the record 
582  associated with the assurance activities. 
583   
584  Manufacturers have expressed confusion and concern regarding the application of Part 11, 
585 Electronic Records; Electronic Signatures, to computers or automated data processing systems 
586 used as part of production or the quality system. As described in the Part 11, Electronic 
587  Records; Electronic Signatures  Scope and Application guidance,16 the Agency intends to 
588  exercise enforcement discretion regarding Part 11 requirements for validation of computerized 
589  systems used to create, modify, maintain, or transmit electronic records (see 21 CFR 11.10(a) 
590  and 11.30). In general, Part 11 applies to records in electronic form that are created, modified, 
591  maintained, archived, retrieved, or transmitted under any records requirements set forth in 
592 Agency regulations (see 21 CFR 11.1(b)). Part 11 also applies to electronic records submitted to 
593 the Agency under requirements of the Federal Food, Drug, and Cosmetic Act (FD&C Act) and 
594 the Public Health Service Act (PHS Act), even if such records are not specifically identified in 
595 Agency regulations (see 21 CFR 11.1(b)). 
596
597 In the context of computer or automated data processing systems, for computer softwareused as 
598 part of production or the quality system, a document required under Part 820 and maintained in 
599 electronic form would generally be an electronic record within the meaning of Part 11 (see 21 
600 CFR 11.3(b)(6)). For example, if a document requires a signature under Part 820 and is 
601 maintained in electronic form, then Part 11 applies (see, e.g., 21 CFR 820.40 (requiring 
602 signatures for control of required documents)).
16 https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-
electronic-signatures-scope-and-application.
19 Contains Nonbinding Recommendations
Draft Not for Implementation
Appendix A. Examples
603
604  The examples in this section outline possible application of the principles in this draft guidance to various software assurance 
605 situations cases.
Example 1: Nonconformance Management System
606
607  A manufacturer has purchased COTS software for automating their nonconformance process and is applying a risk-based approach for 
608  computer software assurance in its implementation.  The software is intended to manage the nonconformance process electronically. 
609 The following features, functions, or operations were considered by the manufacturer in developing a risk-based assurance strategy:
610
611 Table 2. Computer Software Assurance Example for a Nonconformance Management System
Features, Functions, or  Intended Use of the  Risk-Based Analysis Assurance Activities Establishing the appropriate 
Operations Features, Functions or  record 
Operations
Nonconformance (NC) Initiation  The intended uses of the  Failure of the NC initiation  The manufacturer has  The manufacturer documents: 
Operations: operations are to manage the  operation to perform as intended  performed an assessment of the   the intended use
 A nonconforming event  workflow of the  may delay the initiation  system capability, supplier   risk determination,
results in the creation of an  nonconformance and to  workflow, but would not result  evaluation, and installation 
 summary description of the 
NC record. error-proof the workflow to  in a quality problem that  activities. In addition, the 
features, functions, 
 The necessary data for  facilitate the work and a  foreseeably compromises safety,  manufacturer supplements these 
operations tested
initiation are recorded prior to  complete quality record.  as the manufacturer has  activities with exploratory 
 the testing objectives and 
completion of an NC  These operations are  additional processes in place for  testing of the operations. High 
if they passed or failed
initiation task. intended to supplement  containment of non-conforming  level objectives for testing are 
 An NC Owner is assigned  processes established by the  product. As such, the  established to meet the intended   any issues found and their 
prior to completion of the NC  manufacturer for  manufacturer determined the NC  use and no unanticipated  disposition
initiation task. containment of non- initiation operations did not pose  failures occur.  a concluding statement 
conforming product. a high process risk.  noting that the 
performance of the 
operation is acceptable
 the date testing was 
performed, and who 
performed the testing.
20 Contains Nonbinding Recommendations
Draft Not for Implementation
Features, Functions, or  Intended Use of the  Risk-Based Analysis Assurance Activities Establishing the appropriate 
Operations Features, Functions or  record 
Operations
Electronic Signature Function: The intended use of the  If the electronic signature  The manufacturer has  The manufacturer documents: 
 The electronic signature  electronic signature function  function were to fail to perform  performed an assessment of the   the intended use
execution record is stored as  is to capture and store an  as intended, then production or  system capability, supplier   risk determination
part of the audit trail. electronic signature where a  quality system records may not  evaluation, and installation 
 testing performed
 The electronic signature  signature is required and  reflect appropriate approval or  activities. To provide assurance 
 any issues found and their 
employs two distinct  such that it meets  be sufficiently auditable, or may  that the function complies with 
disposition
identification components of  requirements for electronic  fail to meet other regulatory  applicable requirements, the 
 a concluding statement 
a login and password. signatures. requirements. However, such a  manufacturer performs ad-hoc 
 When an electronic signature  failure would not foreseeably  testing of this function with  noting that the 
is executed, the following  lead to compromised safety. As  users to demonstrate the  performance of the 
information is part of the  such, the manufacturer  function meets the intended use.  function is acceptable
execution record: determined that this function   the date testing was 
o  The name of the person  does not pose high process risk.  performed and who 
who signs the record performed the testing.
o  The date (DD-MM-
YYYY) and time 
(hh:mm) the signature 
was executed.
o  The meaning associated 
with the signature (such 
as review, approval, 
responsibility, or 
authorship).
21 Contains Nonbinding Recommendations
Draft Not for Implementation
Features, Functions, or  Intended Use of the  Risk-Based Analysis Assurance Activities Establishing the appropriate 
Operations Features, Functions or  record 
Operations
Product Containment Function: This function is intended to  Failure of the function to  The manufacturer has  The manufacturer documents: 
  When a nonconformance is  trigger the necessary  perform as intended would  performed an assessment of the   the intended use
initiated for product outside  evaluation and decision- result in a necessary correction  system capability, supplier   risk determination
of the manufacturers control,  making on whether a product  or removal not being initiated,  evaluation, and installation   detailed test protocol 
then the system prompts the  correction or removal is  resulting in a quality problem  activities. Since the  developed
user to identify if a product  needed when the  that foreseeably compromises  manufacturer determined the   detailed report of the 
correction or removal is  nonconformance occurred in  safety. The manufacturer  function to pose high process  testing performed
needed. product that has been  therefore determined that this  risk, the manufacturer   pass/fail results for each 
distributed. function poses high process risk. determined assurance activities 
test case
commensurate with the medical 
 any issues found and their 
device risk: established a 
disposition
detailed scripted test protocol 
 a concluding statement 
that exercises the possible 
noting that the 
interactions and potential ways 
performance of the 
the function could fail. The 
operation is acceptable
testing also included 
 the date testing was 
appropriate repeatability testing 
performed and who 
in various scenarios to provide 
performed the testing 
assurance that the function 
 the signature and date of 
works reliably.
the appropriate signatory 
authority.
612
613
614
615
616
22 Contains Nonbinding Recommendations
Draft Not for Implementation
Example 2: Learning Management System (LMS)
617
618  A manufacturer is implementing a COTS LMS and is applying a risk-based approach for computer software assurance in its 
619  implementation. The software is intended to manage, record, track, and report on training. The following features, functions, or 
620 operations were considered by the manufacturer in developing a risk-based assurance strategy: 
621
622 Table 3. Computer Software Assurance Example for an LMS
Features, Functions, or Operations Intended Use of the Features,  Risk-Based Analysis Assurance Activities Establishing the 
Functions or Operations appropriate record 
 The system provides user log-on  All of the features, functions,  Failure of these features,  The manufacturer has  The manufacturer 
features (e.g., username and  and operations have the same  functions, or operations to  performed an assessment  documents:
password) intended use, that is, to manage,  perform as intended would  of the system capability,   the intended use
 The system assigns trainings to users  record, track and report on  impact the integrity of the  supplier evaluation, and   risk determination
per the curriculum assigned by  training. They are intended to  quality system record but  installation activities. In   a summary description 
management automate processes to comply  would not foreseeably  addition, the manufacturer  of the failure modes 
 The system captures evidence of  with 21 CFR 820.25  compromise safety.  As such,  supplements these  tested
users training completion  (Personnel), and to establish the  the manufacturer determined  activities with unscripted   any issues found and 
 The system notifies users of training  necessary records. that the features, functions,  testing, applying error- their disposition
curriculum assignments, completion  and operations do not pose  guessing to attempt to   a concluding statement 
of trainings, and outstanding  high process risk.  circumvent process flow  noting that the 
trainings and break the system  performance of the 
(e.g. try to delete the audit 
 The system notifies users  operation is acceptable
trail).
management of outstanding trainings  the date testing was 
 The system generates reports on  performed, and who 
training curriculum assignments,  performed the testing.
completion of training, and 
outstanding trainings
623
624
23 Contains Nonbinding Recommendations
Draft Not for Implementation
Example 3: Business Intelligence Applications
625
626  A medical device manufacturer has decided to implement a commercial business intelligence solution for data mining, trending, and 
627  reporting. The software is intended to better understand product and process performance over time, in order to provide identification 
628  of improvement opportunities. The following features, functions, or operations were considered by the manufacturer in developing a 
629 risk-based assurance strategy: 
630
631 Table 4. Computer Software Assurance Example for a Business Intelligence Application
Features, Functions, or  Intended Use of the  Risk-Based Analysis Assurance Activities Establishing the appropriate 
Operations Features, Functions or  record 
Operations
Connectivity Functions: These functions are  Failure of these functions to  The manufacturer determined  The manufacturer documents: 
 The software allows for  intended to ensure a secure  perform as intended would result  assurance activities   the intended use
connecting to various  and robust capability for the  in inaccurate or inconsistent  commensurate with the medical   risk determination
databases in the  system to connect to the  trending or analysis. This would  device risk and has performed   detailed test protocol
organization and external  appropriate data sources,  result in failure to identify  an assessment of the system   a detailed report of the testing 
data sources. ensure integrity of the data,  potential quality trends, issues or  capability, supplier evaluation,  performed
 The software maintains  prevent data corruption,  opportunities for improvement,  and installation activities.   pass/fail results for each test 
the integrity of the data  modify, and store the data  which in some cases, may result in  Additionally, the manufacturer  case
from the original sources  appropriately. a quality problem that foreseeably   establishes a detailed scripted   any issues found and their 
and is able to determine if  compromises safety. As such, the  test protocol that exercises the  disposition
there is an issue with the  manufacturer determined that these  possible interactions and 
 a concluding statement 
integrity of the data,  functions posed high process risk,  potential ways the functions 
noting that the performance 
corruption, or problems  necessitating more-rigorous  could fail. The testing also 
of the operation is acceptable
in data transfer. assurance activities, commensurate  includes appropriate 
 the date testing was 
with the related medical device  repeatability testing in various 
performed, and who 
risk.  scenarios to provide assurance 
performed the testing
that the functions work reliably.
 the signature and date of the 
appropriate signatory 
authority.
24 Contains Nonbinding Recommendations
Draft Not for Implementation
Features, Functions, or  Intended Use of the  Risk-Based Analysis Assurance Activities Establishing the appropriate 
Operations Features, Functions or  record 
Operations
Usability Feature: This feature is intended to  The failure of the feature to  The feature does not necessitate  The manufacturer documents:
  The software provides the  facilitate the interaction of  perform as intended is unlikely to  any additional assurance effort   the intended use
user a help menu for the  the user with the system and  result in a quality problem that  beyond what the manufacturer   risk determination
application. provide assistance on use of  would lead to compromised safety.  has already performed in   the date of assessment and 
all the system features. Therefore, the manufacturer  assessing the system capability,  who performed the 
determined that the feature does  supplier evaluation, and  assessment
not pose high process risk. installation activities.  a concluding statement 
noting that the performance 
is acceptable given the 
intended use and risk.
Reporting Functions: These functions are  Failure of these functions to  The supplier of the reporting  The manufacturer documents:
 The software is able to  intended to allow the user to  perform as intended may result in a  software has validated the   the intended use
create and perform  query the data sources, join  quality problem (e.g., incomplete  ability of the software to create   risk determination
queries and join data  data from various sources,  or inadequate reports) but, in this  and perform queries, join data   the date of assessment and 
from various sources to  perform analysis, and  example, would not foreseeably  from various sources to  who performed the 
perform data mining. generate visuals and  lead to compromised safety  perform data mining, perform  assessment
 The software allows for  summaries. These functions  because these functions are  statistical analysis and data   a concluding statement 
various statistical analysis  are intended for collection  intended for collection and  summarization, create graphs  noting that the performance 
and data summarization. and recording data for  recording data for monitoring and  and generate reports. Beyond  is acceptable given the 
 The software is able to  monitoring and review  review purposes that do not have a  this, the manufacturer has  intended use and risk. 
create graphs from the  purposes that do not have a  direct impact on production or  assessed the system capability 
data. direct impact on production  process performance. Therefore,  and performed supplier 
 The software provides the  or process performance. In  the manufacturer determined that  evaluation and installation 
capability to generate  this example, the software is  these functions do not pose high  activities. As such, the 
reports of the analysis. not intended to inform  process risk. manufacturer determined that 
quality decisions. the reporting functions of the 
software do not necessitate any 
additional assurance effort 
beyond these activities. 
632
25