[PDF] Content of Premarket Submissions for Device Software Functions

View - Download Content of Premarket Submissions for Device Software Functions

Previous PDF

Next PDF

Contains Nonbinding Recommendations

Content of Premarket Submissions for

Device Software Functions

Guidance for Industry and

Food and Drug Administration Staff

Document issued on June 14, 2023.

The draft of this document was issued on November 4, 2021. This document supersedes Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, May 2005. For questions about this document regarding CDRH-regulated devices, contact the Digital Health Center of Excellence at digitalhealth@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

Center for Drug Evaluation and Research

Office of Combination Products in the Office of the

Commissioner

Contains Nonbinding Recommendations

Preface

Public Comment

You may submit electronic comments and suggestions at any time for Agency consideration 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 FDA-2021-D-0775. Comments may not be acted upon by the Agency until the document is next revised or updated.

Additional Copies

CDRH Additional copies are available from the Internet. You may also send an email request to CDRH- Guidance@fda.hhs.govto receive a copy of the guidance. Please include the document number GUI00000337 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.govor from the Internet at

biologics/biologics-guidances. CDER Additional copies are available from the Center for Drug Evaluation and Research (CDER), Office of Communication, Division of Drug Information, 10001 New Hampshire Ave., Hillandale Bldg., 4th Floor, Silver Spring, MD 20993-0002, or by calling 855-543-3784 or 301-

796-3400, or by email, druginfo@fda.hhs.gov, or from the Internet at

Contains Nonbinding Recommendations

Table of Contents

I. Introduction ............................................................................................................................. 1

II. Background ............................................................................................................................. 2

III. Scope ....................................................................................................................................... 4

IV. Definitions............................................................................................................................... 6

V. Documentation Level .............................................................................................................. 8

VI. Recommended Documentation ............................................................................................... 9

Documentation Level Evaluation ................................................................................... 12

Software Description ...................................................................................................... 12

Risk Management File ................................................................................................... 15

Software Requirements Specification (SRS) ................................................................. 18

System and Software Architecture Diagram .................................................................. 20

Software Design Specification (SDS) ............................................................................ 22

(1)Basic Documentation Level ........................................................................................ 23

(2)Enhanced Documentation Level ................................................................................. 23

Software Development, Configuration Management, and Maintenance Practices ........ 23

(1)Basic Documentation Level ........................................................................................ 24

(2)Enhanced Documentation Level ................................................................................. 24

Software Testing as part of Verification and Validation................................................ 25

(1)Basic Documentation Level ........................................................................................ 25

(2)Enhanced Documentation Level ................................................................................. 26

Software Version History ............................................................................................... 26

Unresolved Software Anomalies .................................................................................... 27

VII. Additional Information - Regulatory Considerations for Software Functions ..................... 28

Appendix A: Documentation Level Examples ............................................................................. 28

Appendix B: System and Software Architecture Diagram Examples .......................................... 39

Contains Nonbinding Recommendations

1

Content of Premarket Submissions for

Device Software Functions

Guidance for Industry and

Food and Drug Administration Staff

This guidance represents the current thinking of the Food and Drug Administration (FDA or Agency) on this topic. It does not establish any rights for any person and is not binding on FDA or the public. You can use an alternative approach if it satisfies the requirements of the applicable statutes and regulations. To discuss an alternative approach, contact the FDA staff or Office responsible for this guidance as listed on the title page. I. This guidance document is intended to provide information regarding the recommended documentation for premarket submissions for FDA"s evaluation of the safety and effectiveness of device software functions, which are software functions that meet the definition of a device under section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act).1This document replaces FDA"s Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices issued on May 11, 2005, and updates FDA"s thinking related to the documentation FDA recommends sponsors include for the review of device software functions in premarket submissions. The recommendations in this guidance are intended to facilitate FDA"s premarket review. This guidance describes information that would be typically generated and documented2during software development, verification, and validation. The least burdensome approach was applied to identify the minimum amount of information that, based on our experience, would generally be needed to support a premarket submission for a device that uses software. During premarket review, FDA may request additional information that is needed to evaluate the submission. For example, in order to demonstrate a reasonable assurance of safety and effectiveness for devices

1The term “device" is defined in 201(h)(1) 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.

2As 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).

Contains Nonbinding Recommendations

2 that use software, documentation related to the requirements of the Quality System Regulation (QSR) (21 CFR Part 820) is often a necessary part of the premarket submission. As part of QSR design controls, a manufacturer must “establish and maintain procedures for validating the device design," which “shall include software validation and risk analysis, where appropriate" (21 CFR 820.30(g)). The documentation recommended in this guidance is based on FDA"s experience evaluating the safety and effectiveness of device software. However, sponsors may use alternative approaches and provide different documentation so long as their approach and documentation satisfy premarket submission requirements in applicable statutory provisions and regulations. For the current edition(s) of the FDA-recognized consensus standard(s) referenced in this document, see the FDA Recognized Consensus Standards Database.3For more information regarding use of consensus standards in regulatory submissions, please refer to the FDA guidance titled Appropriate Use of Voluntary Consensus Standards in Premarket Submissions for Medical Devices4and Standards Development and the Use of Standards in Regulatory Submissions Reviewed in the Center for Biologics Evaluation and Research.5 As stated above, this guidance identifies the software information FDA considers to generally be necessary to support a premarket submission. The recommendations in this guidance are also intended to facilitate FDA"s premarket review. FDA anticipates that the Agency and industry will need up to 60 days after the publication of this guidance to operationalize the recommendations discussed. However, CDRH intends to review any such information if submitted at any time. In general, FDA"s guidance documents do not establish legally enforceable responsibilities. Instead, guidances describe the Agency"s current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The use of the word should in Agency guidances means that something is suggested or recommended, but not required. II. The purpose of this guidance is to describe FDA"s thinking on the recommended documentation sponsors should include in premarket submissions for FDA"s evaluation of the safety and effectiveness of device software functions. This thinking recognizes recent changes to the FD&C Act made by the 21st Century Cures Act (Cures Act), which amended section 520 of the FD&C Act and excludes certain software functions from the device definition. It also considers the rapidly evolving nature of digital health and recent FDA-recognized consensus standards related to software. This guidance, as described in Section III (Scope), is intended to complement other existing guidance documents that provide recommendations related to software, including the

3Available at https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfStandards/search.cfm.

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

5Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/standards-development-

Contains Nonbinding Recommendations

3 guidance documents listed below. The following guidance documents represent a subset of FDA guidances with digital health content6relevant to premarket software documentation activities. Please note the list is not exhaustive and is subject to change: Multiple Function Device Products: Policy and Considerations7

Off-The-Shelf Software Use in Medical Devices8

Design Considerations and Premarket Submission Recommendations for Interoperable

Medical Devices9

General Principles of Software Validation10

Content of Premarket Submissions for Management of Cybersecurity in Medical

Devices11

Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS)

Software12

Applying Human Factors and Usability Engineering to Medical Devices13 FDA encourages the consideration of these guidances when developing device software functions and preparing premarket software documentation. The emergence of consensus standards related to software has helped to improve the consistency and quality of software development and documentation, particularly with respect to activities such as risk assessment and management. When possible, FDA harmonized the terminology and recommendations in this guidance with software-related consensus standards, such as the following examples. The following standards are not intended to represent an exhaustive list and are subject to change:14 ANSI/AAMI/ISO 14971: Medical devices - Applications of risk management to medical devices ANSI/AAMI/IEC 62304: Medical Device Software - Software Life Cycle Processes ANSI/AAMI SW91: Classification of defects in health software

6Available at https://www.fda.gov/medical-devices/digital-health-center-excellence/guidances-digital-health-

content.

7Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/multiple-function-

8Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/shelf-software-use-

medical-devices.

9Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-considerations-

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

software-validation.

11Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-

12Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-

13Available at https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-

14The most up-to-date list of voluntary FDA-recognized consensus standards is available at

Contains Nonbinding Recommendations

4 The Agency encourages the consideration of these FDA-recognized consensus standards when developing device software functions and preparing premarket software documentation. When assessing the appropriate Documentation Level for the device and the overall recommended documentation for inclusion in a premarket submission, please refer to Section V (Documentation Level) and Section VI (Recommended Documentation) of this guidance. Section 3308 of the Food and Drug Omnibus Reform Act of 2022, Title III of Division FF of the Consolidated Appropriations Act, 2023, Pub. L. No. 117-328 (“FDORA"), enacted on December

29, 2022, added section 515C “Predetermined Change Control Plans for Devices" to the FD&C

Act (section 515C). Under section 515C, FDA can approve or clear a predetermined change control plan (PCCP) for a device that describes planned changes that may be made to the device and that would otherwise require a supplemental premarket approval application or premarket notification. For example, section 515C provides that a supplemental premarket approval application (section 515C(a)) or a premarket notification (section 515C(b)) is not required for a change to a device if the change is consistent with a PCCP that is approved or cleared by FDA. Section 515C also provides that FDA may require that a PCCP include labeling for safe and effective use of a device as such device changes pursuant to such plan, notification requirements if the device does not function as intended pursuant to such plan, and performance requirements for changes made under the plan. If you are interested in proposing a PCCP in your marketing submission, we encourage you to submit a Pre-Submission to engage in further discussion with CDRH. See FDA"s guidance “Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program" available at https://www.fda.gov/regulatory- submissions-q-submission-program. III. For the purposes of this document, FDA refers to a software function that meets the definition of a device as a device software function. For any given product, the term “function" is a distinct purpose of the product, which could be the intended use or a subset of the intended use of the product.15For example, a product with an intended use to analyze data has one function: analysis. A product with an intended use to store, transfer, and analyze data has three functions: (1) storage, (2) transfer, and (3) analysis. As this example illustrates, a product may contain multiple functions. This guidance is intended to cover device software functions. Examples include, but are not limited to, firmware and other means for software-based control of medical devices, software accessories to medical devices, and software only16function(s) that meet the definition of a device.

15For details, see “Multiple Function Device Products: Policy and Considerations," available at

policy-and-considerations.

16“Software only" functions include device software functions intended to be operated on commercial OTS

computing platforms.

Contains Nonbinding Recommendations

5 This guidance recommends the information to provide in a premarket submission that includes a device software function(s). For the purposes of this guidance, the term premarket submission includes, but is not limited to, premarket notification (510(k)) submission, De Novo classification request, Premarket Approval (PMA) application, Investigational Device Exemption (IDE), Humanitarian Device Exemption (HDE), or Biologics License Application (BLA). Certain devices are subject to premarket review through a BLA under section 351 of the Public

Health Service Act.

This guidance does not apply to automated manufacturing and Quality System software17or software that is not a device. For further information or to clarify the documentation expectations, please contact the responsible FDA review division. Generally, the recommendations in this guidance apply to the device constituent part of a combination product18(such as drug-device and biologic-device combination products) when the device constituent part19includes a device software function, including combination products assigned to CDER and CBER regulated under drug or biological product market submission types. For more information, contact the FDA review Division that will have the lead review for the combination product.20 Other FDA guidance documents may recommend additional software-related documentation for inclusion in a premarket submission. For example, recommendations regarding cybersecurity information to include in a device premarket submission can be found in the guidances “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices" and “Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software."21 Section II (Background) references other relevant guidance documents that supplement the recommendations contained in this guidance.

17As 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."

1821 CFR 3.2(e).

1921 CFR 4.2.

20Sponsors may request in writing the participation of representatives of the Office of Combination Products (OCP)

in meetings regarding their combination products, or to have OCP otherwise engage on regulatory matters

concerning the product (section 503(g)(1)(A) of the FD&C Act). In addition, if you are uncertain whether your

product is a combination product or a constituent part of a combination product, or which center has primary

jurisdiction, you may request engagement by the Office of Combination Products. For more information on

requesting engagement on regulation of combination products, please see FDA"s guidance “Requesting FDA

Feedback on Combination Products," available at https://www.fda.gov/regulatory-information/search-fda-guidance-

21For example, 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 risk management process that encompasses the total product

lifecycle in order to address cybersecurity risks and emerging vulnerabilities.

Contains Nonbinding Recommendations

6 Device software functions subject to specific special controls22may require additional software- related documentation in a premarket submission. As applicable, please refer to the relevant special controls for the device. This guidance does not apply to the software-related documentation that may be needed to evaluate postmarket software device issues, including corrections and removals.23 While this guidance identifies the documentation sponsors should include in premarket submissions, this guidance is not meant to provide recommendations regarding how device software should be developed, verified, and validated. This guidance does not recommend the use of any specific software life cycle model or development methodology (such as waterfall model or other variations thereof, spiral model, Agile model, etc.). Sponsors should establish a software life cycle model that is appropriate for their product and organization, and meets the applicable regulatory requirements. The software life cycle model that is selected should cover the software throughout its total product life cycle. Regardless of the software lifecycle model being utilized, sponsors should ensure that the establishment of their design history file (DHF)24 documentation is synchronized with their software development, verification, and validation efforts. DHF documentation that is created retrospectively or following a prolonged period of time after actual software development, verification, and validation efforts could raise concerns regarding whether a developer has adequate control of their design process. For recommendations on device software development, verification, and validation, please consult software-related FDA-recognized voluntary consensus standards and other software-related FDA guidance documents referenced in this guidance (e.g., “General Principles of Software

Validation"25).

IV. The following terms are used for the purposes of this guidance: Device Software Function - Software function that meets the device definition in section 201(h) of the FD&C Act. As discussed above, the term “function" is a distinct purpose of the product, which could be the intended use or a subset of the intended use of the product.

22For more information regarding special controls, please see FDA"s Regulatory Controls webpage, available at

23See 21 CFR Part 806.

24Each manufacturer shall establish and maintain a DHF for each type of device. 21 CFR 820.30(j). A DHF is a

compilation of records which describes the design history of a finished device. The DHF shall contain or reference

the records necessary to demonstrate that the design was developed in accordance with the approved design plan and

the requirements of 21 CFR 820. See 21 CFR 820.30(j).

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

software-validation.

Contains Nonbinding Recommendations

7 Off-the-Shelf (OTS) Software26- A generally available software component used by a device manufacturer for which the manufacturer cannot claim complete software life cycle control (e.g., operating system, printer/display libraries).

Serious Injury27- An injury or illness that:

1)Is life threatening,

quotesdbs_dbs21.pdfusesText_27

[PDF] software architecture diagram tutorial

[PDF] software architecture diagrams

[PDF] software architecture document example pdf

[PDF] software architecture document template

[PDF] software architecture exam questions and answers

[PDF] software being updated

[PDF] software design document example pdf

[PDF] software design document for android application

[PDF] software design document slideshare

[PDF] software design document template

[PDF] software design document template example

[PDF] software design documentation tools

[PDF] software design pattern final exam

[PDF] software development organizational structure

[PDF] software engineering applications