Welcome To Today’s Webinar

Thanks for joining us!

We’ll get started in a few minutes

Today’s Topic: 

Content of Premarket Submissions for Device Software Functions, 

Final Guidance 

July 20, 2023
Content of Premarket Submissions for Device Software 

Functions, Final Guidance 

Sonja Fulmer, PhD

Acting Deputy Director

Digital Health Center of Excellence

Office of Strategic Partnerships and 

Technology Innovation

Jessica Paulsen

Digital Health Associate Director

Office of Product Evaluation and Quality

Aneesh Deoras

Assistant Director

Cardiac Ablation, Mapping, and Imaging 

Devices Team 

Office of Cardiovascular Devices

Office of Product Evaluation and Quality

Center for Devices and Radiological Health

U.S. Food and Drug Administration
Sonja Fulmer, PhD

Acting Deputy Director

Digital Health Center of Excellence

Office of Strategic Partnerships and 

Technology Innovation

3
Final Guidance

• Content of Premarket Submissions for Device Software Functions, 

Guidance for Industry and Food and Drug Administrative Staff, 

issued on June 14, 2023

– www.fda.gov/regulatory-information/search-fda-guidancedocuments/content-premarket-submissions-device-software-functions

– www.federalregister.gov/documents/2021/11/04/2021-24061/contentof-premarket-submissions-for-device-software-functions-draft-guidancefor-industry-and-food

4
Learning 

Objectives

 Explain what is covered in guidance and why 

updates were made

 Describe purpose and scope of final guidance 

 Describe Software Documentation Levels

 Describe Software Documentation Elements

 Discuss other regulatory considerations and 

updates

5
Background

6
Questions addressed by the guidance:

7

• What software documentation is recommended for a 

marketing submission?

• What should the documentation demonstrate?
What is not covered by the guidance?

8

• Doesn’t provide recommendations on how device 

software should be developed, verified, and validated

• Doesn’t recommend use of any specific software life 

cycle model or development methodology (such as 

waterfall model or other variations thereof, spiral 

model, agile model, etc.)
Why is there an update to the guidance?

• Replaces FDA’s Guidance for Content of Premarket Submissions for Software 

Contained in Medical Devices issued on May 11, 2005

• Updates FDA’s thinking related to documentation FDA recommends sponsors include 

for review of device software functions in premarket submissions

• Completes a MDUFA V Commitment

9

Updates intended to:

 Foster timely access to safe and effective software devices

 Promote Least Burdensome Principles

 Provide clarity and simplicity 

 Align with changes resulting from Section 3060 of the 21st Century Cures 

Act

 Harmonize with FDA-recognized voluntary consensus standards
Comments from Draft Guidance

• Sought clarification on application of Documentation 

Levels for certain premarket submissions and 

requested more examples 

• Suggested more flexibility in Documentation Level 

factors to reduce documentation burden

• Highlighted opportunity to apply recommendations to 

device constituent parts of combination products 

10
Comments from Draft Guidance

• Emphasized ways to further align with IEC 62304

• Raised questions about appropriate software 

development methodology 

• Observed few recommendations for artificial 

intelligence and machine learning (AI/ML)

• Noted general clarifications, editorial changes, and 

corrections

11
Notable Updates Since Draft Publication

• Simplified Documentation Level considerations and application

• Added more examples on how to apply Documentation Level

– Increased from 5 to 27 examples

• Revised recommendations to address device constituent parts 

of a combination product and added CDER and OCP to the 

guidance

CDER = Center for Drug Evaluation and Research

OCP = Office of Combination Products

12
Notable Updates Since Draft Publication

• Harmonized risk terminology with ISO 14971

• Clarified leveraging of IEC 62304 to reduce burden 

while maintaining differences where appropriate

• Provided fully revised system and software 

architecture diagram examples

• Included general updates, corrections, and 

clarifications

13
Updated Software References to Help Prepare a 

Premarket Submission

The guidance complements other existing guidance documents, and aligns with current 

software practices and FDA-recognized voluntary consensus standards

Guidance Documents FDA-Recognized Voluntary Consensus Standards

• Multiple Function Device Products: Policy and 

Considerations 

• Off-The-Shelf Software Use in Medical Devices

• Design Considerations and Premarket Submission 

Recommendations for Interoperable Medical Devices

• General Principles of Software Validation

• Content of Premarket Submissions for Management of 

Cybersecurity in Medical Devices

• Cybersecurity for Networked Medical Devices 

Containing Off-The-Shelf (OTS) Software

• Applying Human Factors and Usability Engineering to 

Medical Devices

• 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

14
Purpose and Scope

15
Purpose

• Least burdensome approach was applied to identify minimum amount of 

information generally needed to support a premarket submission for a device 

that uses software.

• Guidance describes information typically generated and documented during 

software development, verification, and design validation.

• FDA may request additional information needed to evaluate the submission 

during a premarket review.

16

The guidance identifies software information considered to be generally 

necessary to evaluate safety and effectiveness of device software functions in 

a premarket submission. 
Scope

• Generally, apply to device constituent part of a combination product when device 

constituent part includes a device software function.

• This guidance does not apply to:

o automated manufacturing and Quality System software or software that is not a device

o software-related documentation that may be needed to evaluate postmarket software 

device issues

• Other guidance documents may recommend additional software-related 

documentation for premarket submissions; e.g., cybersecurity

17

The guidance applies to all types of premarket submissions that include 

one or more device software function(s).
Definitions

18

Function: a distinct purpose of the product, which could be the intended use, or subset of 

the intended use, of the product

Device Software Function: software function that meets definition of a device under 

section 201(h) of the Federal Food, Drug, and Cosmetic Act (FD&C Act)

• Recommendations pertain to device software functions

• Recommendations reflect function-based approach described in 

guidance documents Policy for Device Software Functions and 

Mobile Medical Applications and Multiple Function Device 

Products: Policy and Considerations
Definitions, continued

Software verification: confirmation by objective evidence that the output of a particular 

phase of development meets all the input requirements for that phase. 

• Software verification involves evaluating the consistency, completeness, and 

correctness of the software and its supporting documentation, as it is being 

developed, and provides support for a subsequent conclusion that software is 

validated.

Software validation: refers to establishing, by objective evidence, that the software 

specifications conform to user needs and intended uses, and that the particular 

requirements implemented through software can be consistently fulfilled. 

• Software validation is a part of design validation of the finished device. It involves 

checking for proper operation of the software in its actual or simulated use 

environment, including integration into the final device where appropriate. 

19
Jessica Paulsen

Digital Health Associate Director

Office of Product Evaluation and Quality

20
Documentation Level

21
Documentation Level

Simplified Documentation Level in this guidance replaces Level of Concern 

(LoC) from 2005 Guidance

• Two Documentation Levels Defined for Devices: 

– Basic

– Enhanced

22
Purpose of Documentation Level

Documentation Level helps to identify minimum amount of 

software information that would support a premarket submission

• Depends on device’s risk to a patient, a user of a device, or 

others in the environment of use.

• Based on the risks of the device software function(s) in the 

context of the device’s intended use

• Reflects the device as a whole

23
Enhanced Documentation

24

• Should be provided for any premarket submission that includes device 

software function(s)

― where failure or flaw of any device software function(s) could present a 

hazardous situation with a probable risk of death or serious injury, either to 

a patient, user of the device, or others in the environment of use

• Risks should be assessed prior to implementing risk control measures

• Sponsor should consider risks in context of device intended use, for 

example, impacts to safety, treatment, or diagnosis, and other relevant 

considerations
Basic Documentation

25

• Should be provided for any premarket submission that 

includes device software functions where Enhanced 

Documentation does not apply
Considerations for Documentation Level 

• Sponsor should consider all known or foreseeable software hazards 

and hazardous situations associated with device

― including those resulting from reasonably foreseeable misuse, whether 

intentional or unintentional, prior to the implementation of risk control measures 

• Includes likelihood that device functionality is intentionally or 

unintentionally compromised by inadequate device cybersecurity

• Sponsor is responsible for proactively and comprehensively 

considering risks as part of device’s risk assessment

26
Considerations for Documentation Level 

Individually assess devices within scope of guidance

to determine appropriate Documentation levels.

• Guidance recommends Enhanced Documentation be provided in a premarket submission 

for devices intended to:

• test blood donations for transfusion-transmitted infections;

• determine blood donor and recipient compatibility;

• automate blood cell separator devices intended for collection of blood components for 

transfusion or further manufacturing use;

• blood establishment computer software (BECS).

• Guidance generally recommends Enhanced Documentation be provided in a premarket 

submission for Class III devices and device constituent parts of a combination product; 

however, a sponsor may determine that an Enhanced Documentation level does not 

apply in certain cases, for which the sponsor should provide a detailed rationale as to 

why Basic Documentation is appropriate for the premarket submission. 27
Example: Documentation Level (Appendix A)

A non-contact infrared thermometer intended for intermittent 

measurement of body temperature from the forehead. 

Description

• Device is intended to measure body temperature from 

forehead using an infrared sensor.

• Device is a hand-held, battery powered, reusable device for 

home and professional healthcare facility use.

Rationale

In general, a failure or latent flaw of the device software 

function(s) would not present a hazardous situation with a 

probable risk of death or serious injury to either a patient, user of 

the device, or others in the environment of use, prior to the 

implementation of risk control measures. 

Outcome

Basic Documentation Level

28
Example: Documentation Level (Appendix A)

A facility-use continuous ventilator.

Description

• Device is intended to provide continuous ventilation for adult, 

pediatric, and neonatal patients who require invasive or noninvasive 

respiratory support.

• Allows clinicians to set ventilator control parameters, set alarm limits, 

and view monitored values and waveforms for patient management.

• Includes respiratory monitoring as well as both mandatory and 

spontaneous ventilation modes.

• Intended for use in professional healthcare facilities. 

Rationale

A failure or latent flaw of the device software function(s), such as failure to 

provide appropriately timed ventilation, would present a hazardous 

situation with a probable risk of death or serious injury to a patient, prior to 

the implementation of risk control measures.

Outcome

Enhanced Documentation Level

29
Aneesh Deoras

Assistant Director

Cardiac Ablation, Mapping, and Imaging 

Devices Team 

Office of Cardiovascular Devices

Office of Product Evaluation and Quality

30
Software Documentation Elements

31
Overview of Software

Documentation Elements

• Documentation Level Evaluation

• Software Description

• Risk Management File

• Software Requirements Specification (SRS)

• System and Software Architecture Design 

• Software Design Specification (SDS)

• Software Development, Configuration Management, and Maintenance 

Practices

• Software Testing as Part of Verification and Validation

• Software Version History

• Unresolved Software Anomalies (e.g., Bugs, Defects, or Errors)

32
Documentation Level Evaluation

For Basic and Enhanced Documentation Levels:

• Guidance encourages sponsors to account for their device’s intended use and to 

leverage their device’s risk assessment when preparing the rationale for choosing a 

Documentation Level.

• Examples in Appendix A are provided to demonstrate how to implement the 

Documentation Level.

• During premarket review, FDA may request additional information that is needed to 

evaluate the submission. 

Provide statement indicating the Documentation Level and a description of the 

rationale for that level.

33
For Basic and Enhanced Documentation Levels:

• Guidance provides a curated set of questions to help readers prepare focused device 

description information.

• Encourages inclusion of additional information, if needed, to further FDA’s 

understanding of the device’s functionality, such as images, flow charts, and state 

diagrams.

• For a modified device, guidance encourages description of software changes from 

previous premarket submission, which may include providing document number for 

previous submission and highlighting pertinent software changes (e.g., changes that 

affect safety and effectiveness) since last authorization. 

Software Description

Provide comprehensive software description, including overview of significant software 

features, analyses, inputs, outputs, and hardware platforms.

34
For Basic and Enhanced Documentation Levels:

• FDA recommends sponsors refer to FDA-recognized version of ISO 14971 and account 

for the recommendations provided in the guidance “Multiple Function Device 

Products: Policy and Considerations”

Risk Management File

Should include documentation demonstrating following three components:

1. Risk Management Plan: demonstrates how a manufacturer plans to approach a risk assessment for their 

device and evaluate the overall residual risk against the benefits of the intended use of the device. 

2. Risk Assessment: documents (e.g., in a tabular format) known or foreseeable hazards and resulting hazardous 

situations, initial risk evaluation of the hazardous situation, risk control measures, residual risk evaluation 

after implemented risk control measures and traceability of risk control measures.

3. Risk Management Report: shows how the risk management plan has been appropriately implemented.

35
Software Requirements Specification (SRS)

For Basic and Enhanced Documentation Levels:

• Recommendations acknowledge modern development practices and allow for additional forms 

of software requirements to be included in submission, such as well-elaborated stories, use 

cases, textual descriptions, screen mockups, and control flows.

• Section includes considerations for use when preparing SRS documentation to help facilitate a 

timely premarket review, such as:

‒ Tips for formatting and labeling ‒ Inclusion of traceability information ‒ A manufacturer may highlight requirements they believe are most critical to the device’s safety and 

effectiveness, and/or those that were modified since a previous clearance or approval. 

• For additional details on what should be included in the software requirements specification, 

refer to the guidance, General Principles of Software Validation. 36

Includes complete documentation, describing the needs or expectations for a system or software, 

presented in an organized format and with sufficient information to understand the traceability of 

the information with respect to the other software documentation elements.
System and Software Architecture Diagram

For Basic and Enhanced Documentation Levels:

• Recommends that sponsors provide the appropriate level of detail to convey 

information in a manner that facilitates an efficient premarket review.

• Includes visual, language, and reference considerations that can be leveraged when 

developing the diagrams for a premarket submission.

• Appendix B of the guidance includes example system and software architecture 

diagrams. 

37

Provide detailed diagrams of the modules, layers, and interfaces that comprise the device, the 

data inputs, outputs, and flow, and how users or external products (including IT infrastructure 

and peripherals) interact with the system and software.
Appendix B: 

System and 

Software

Architecture 

Diagram 

Examples 

• Examples demonstrate how considerations described 

in System and Software Architecture Diagram section 

can be implemented into a system and software 

architecture diagram. 

• Examples are intended for illustration purposes only 

and are not intended to document a comprehensive 

system and software architecture diagram for a 

specific device or system. 

• Approaches illustrated can be applied to any system 

and software architecture diagram. 

• Examples do not preclude the use of off-the-shelf 

architectural modeling languages or platforms.

38
Appendix B: 

System and 

Software 

Architecture 

Diagram Example -

Figure 2

39
Software Design Specification (SDS)

Basic Documentation Level Enhanced Documentation Level

FDA is not recommending the SDS as part of 

the premarket submission.

Sponsor should document this information 

on the design via the design history file for 

the device. During premarket review, FDA 

may request additional information, if 

needed, to evaluate the safety and 

effectiveness of the device. 

Includes:

• singular SDS document or set of SDS 

documents that provide the technical 

design details of how the software 

functions, 

• how the software design completely and 

correctly implements all the 

requirements of the SRS, and 

• how the software design traces to the 

SRS in terms of intended use, 

functionality, safety, and effectiveness.

40
Software Development, Configuration 

Management, and Maintenance Practices

May provide a Declaration of Conformity to the currently FDA-recognized 

version of ANSI/AAMI IEC 62304 Medical Device Software - Software Life 

Cycle Processes

For Basic Documentation Level

Alternatively, recommends 

providing a summary of the 

processes and procedures that are 

in place to manage the software 

life cycle development, software 

configuration and change 

management and software 

maintenance activities.

OR

For Enhanced Documentation Level

Alternatively, recommends providing 

a complete configuration 

management and maintenance plan 

document in addition to the 

summary documentation requested 

for the Basic Documentation Level.

41
Software Testing as part of

Verification and Validation

Basic Documentation Level

Recommends providing a summary 

description of the testing activities at 

the unit, integration and system 

levels. System level test protocol 

including expected results, observed 

results, pass/fail determination, and 

system level test report.

Enhanced Documentation Level

Recommends providing the Basic 

Documentation Level PLUS unit and 

integration level test protocols 

including expected results, observed 

results, pass/fail determination, and 

unit and integration level test reports.

• Definition section of guidance includes important information pertaining to FDA’s 

thinking on verification and validation, as it relates to this guidance.

• Sponsor is encouraged to appropriately reference performance testing material in 

the submission to facilitate navigation between submission sections, reduce 

instances of duplication, and improve readability 42
Software Version History

For Basic and Enhanced Documentation Levels:

• FDA recommends beginning with version that became subject to design controls, as described in 

21 CFR 820.30. 

• Version history typically takes form of a line-item tabulation including the date, version number that 

was tested (including, if applicable, bench, animal and clinical testing) and a brief description of all 

changes in the version relative to the previously tested version. 

• Last entry in a line-item tabulation should be the final version to be incorporated in the released 

device. This entry should also include any differences between the tested version of software and the 

released version, along with an assessment of the potential effect of the differences on the safety and 

effectiveness of the device. 

43

Recommends a history of tested software versions including the date, version number, 

and a brief description of all changes relative to the previously tested software 

version.
Unresolved Software Anomalies

For Basic and Enhanced Documentation Levels:

• This section recommends the following information (e.g., in tabular format) is provided for each 

unresolved anomaly:

– A description of problem;

– Identification of how anomaly was discovered and, where possible, identification of its root cause(s);

– Evaluation of impact of anomaly on device’s safety and effectiveness, including operator usage and human 

factors considerations;

– Outcome of evaluation; and

– Risk-based rationale for not correcting or fixing anomaly in alignment with sponsor’s risk management plan or 

procedure(s).

• Encourages communication of unresolved anomalies to end user(s) as appropriate to assist in proper 

device operation

• Reference to ANSI/AAMI SW91 Classification of defects in health software is provided 44

Recommends to provide a list of remaining unresolved software anomalies with an evaluation of 

the impact of each unresolved software anomaly on the device’s safety and effectiveness. 
Sonja Fulmer, PhD

Acting Deputy Director

Digital Health Center of Excellence

Office of Strategic Partnerships and 

Technology Innovation

45
Other Regulatory Considerations 

and Updates

46
Regulatory Considerations for Software Functions

• You may consider following reference materials to learn more 

about FDA’s regulatory considerations for software functions: 

– Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st

Century Cures Act – General Wellness: Policy for Low Risk Devices – Policy for Device Software Functions and Mobile Medical Applications – Medical Device Data Systems, Medical Image Storage Devices, and Medical Image 

Communications Devices – How to Determine if Your Product is a Medical Device – Clinical Decision Support Software

• We encourage you to also explore the Digital Health Policy Navigator, which 

can help orient you to potential policy considerations for a given software 

function.

47
Level 2 Guidance Updates

• The “Off-The-Shelf Software Use in Medical Devices: Guidance for 

Industry and Food and Drug Administration Staff” will be revised with 

a Level 2-update to reflect finalization of this guidance

48
Additional Guidance Updates

The following device-specific guidances will be updated with a cover sheet:

49

• Blood Glucose Monitoring Test Systems for

Prescription Point-of-Care Use

• Submission of Premarket Notifications for Magnetic 

Resonance Diagnostic Devices

• The Content of Investigational Device Exemption (IDE) 

and Premarket Approval (PMA) Applications for 

Artificial Pancreas Device Systems

• Implanted Brain-Computer Interface (BCI) Devices for

Patients with Paralysis or Amputation - Non-clinical 

Testing and Clinical Considerations

• Peripheral Vascular Atherectomy Devices - Premarket

Notification [510(k)] Submissions

• Self-Monitoring Blood Glucose Test Systems for Overthe-Counter Use

• Premarket Notification (510(k)) Submissions for

Electrosurgical Devices for General Surgery

• Display Devices for Diagnostic Radiology

• Infusion Pumps Total Product Life Cycle

• Investigational Device Exemptions (IDEs) for Devices

Indicated for Nocturnal Home Hemodialysis

• Policy Clarification and Premarket Notification

[510(k)] Submissions for Ultrasonic Diathermy

Devices

• Computer-Assisted Detection Devices Applied to

Radiology Images and Radiology Device Data -

Premarket Notification [510(k)] Submissions
60-Day Transition Period

• FDA anticipates that Agency and industry will need up 

to 60 days after publication of this guidance to 

operationalize the recommendations discussed

– CDRH intends to review any such information if submitted at 

any time

– FDA’s eSTAR may accommodate either recommendations 

during this period

50
Guidance Summary

• Simplifies organization and content of software documentation 

elements as well as the documentation categorization levels

• Makes recommendations to aid in the preparation of the software 

documentation, consistent with Least Burdensome Principles

• Complements other existing guidance documents that provide 

recommendations related to software (e.g., “Multiple Function 

Device Products: Policy and Considerations”)

51
Guidance Summary

• Harmonizes with software-related consensus standards

• Reflects changes to FD&C Act made by 21st Century Cures 

Act

• Supersedes “Guidance for the Content of Premarket 

Submissions for Software Contained in Medical Devices”, 

May 2005

52

Additional Panelists

Samantha Collado, JD, MPH

Regulatory Policy Analyst

Office of Policy

Jason Ryans, PhD

Policy Analyst

Regulation, Policy and Guidance Staff

Office of Product Evaluation and Quality

Justin Post

Policy Analyst

Office of Health Technology 7

Office of Product Evaluation and Quality

Center for Devices and Radiological Health

U.S. Food and Drug Administration

54
Let’s Take Your Questions

• To Ask a Question:

1. Raise your hand in Zoom

2. Moderator will announce your name and invite you to ask your question

3. Unmute yourself when prompted in Zoom to ask your question

• When Asking a Question:

• Ask one question only

• Keep question short

• No questions about specific submissions

• After Question is Answered:

• Mute yourself and lower your hand

• If you have more questions - raise your hand again

55
Thanks for Joining Today!

• Presentation and Transcript will be 

available at CDRH Learn

• www.fda.gov/Training/CDRHLearn

• Upcoming Webinars

• www.fda.gov/CDRHWebinar

• Additional questions about today’s 

webinar

• Email: DICE@fda.hhs.gov
Resources

Slide 

Number

Cited Resource URL

18, 47 Policy for Device Software 

Functions and Mobile Medical 

Applications

www.fda.gov/regulatory-information/search-fda-guidancedocuments/policy-device-software-functions-and-mobilemedical-applications

18 Multiple Function Device 

Products: Policy and 

Considerations

www.fda.gov/regulatory-information/search-fda-guidancedocuments/multiple-function-device-products-policy-andconsiderations

36 General Principles of Software 

Validation

www.fda.gov/regulatory-information/search-fda-guidancedocuments/general-principles-software-validation

47 Changes to Existing Medical 

Software Policies Resulting from 

Section 3060 of the 21st Century 

Cures Act

www.fda.gov/regulatory-information/search-fda-guidancedocuments/changes-existing-medical-software-policiesresulting-section-3060-21st-century-cures-act

57
Resources

Slide 

Number

Cited Resource URL

47 General Wellness: Policy for Low 

Risk Devices

www.fda.gov/regulatory-information/search-fda-guidancedocuments/general-wellness-policy-low-risk-devices

47 Medical Device Data Systems, 

Medical Image Storage Devices, 

and Medical Image 

Communications Devices

www.fda.gov/regulatory-information/search-fda-guidancedocuments/medical-device-data-systems-medical-imagestorage-devices-and-medical-image-communications-devices

47 How to Determine if Your Product 

is a Medical Device

www.fda.gov/medical-devices/classify-your-medicaldevice/how-determine-if-your-product-medical-device

47 Clinical Decision Support Software www.fda.gov/regulatory-information/search-fda-guidancedocuments/clinical-decision-support-software

47 Digital Health Policy Navigator www.fda.gov/medical-devices/digital-health-centerexcellence/digital-health-policy-navigator

58
Resources

Slide 

Number

Cited Resource URL

48 Off-The-Shelf Software Use in 

Medical Devices

www.fda.gov/regulatory-information/search-fda-guidancedocuments/shelf-software-use-medical-devices

49 Blood Glucose Monitoring Test 

Systems for Prescription Point-ofCare Use

www.fda.gov/regulatory-information/search-fda-guidancedocuments/blood-glucose-monitoring-test-systemsprescription-point-care-use

49 Submission of Premarket 

Notifications for Magnetic 

Resonance Diagnostic Devices

www.fda.gov/regulatory-information/search-fda-guidancedocuments/submission-premarket-notifications-magneticresonance-diagnostic-devices

49 The Content of Investigational 

Device Exemption (IDE) and 

Premarket Approval (PMA) 

Applications for Artificial Pancreas 

Device Systems

www.fda.gov/regulatory-information/search-fda-guidancedocuments/content-investigational-device-exemption-ide-andpremarket-approval-pma-applications-artificial

59
Resources

Slide 

Number

Cited Resource URL

49 Implanted Brain-Computer 

Interface (BCI) Devices for Patients 

with Paralysis or Amputation -

Non-clinical Testing and Clinical 

Considerations

www.fda.gov/regulatory-information/search-fda-guidancedocuments/implanted-brain-computer-interface-bci-devicespatients-paralysis-or-amputation-non-clinical-testing

49 Peripheral Vascular Atherectomy 

Devices - Premarket Notification 

[510(k)] Submissions

www.fda.gov/regulatory-information/search-fda-guidancedocuments/peripheral-vascular-atherectomy-devicespremarket-notification-510k-submissions

49 Self-Monitoring Blood Glucose 

Test Systems for Over-the-Counter 

Use

www.fda.gov/regulatory-information/search-fda-guidancedocuments/self-monitoring-blood-glucose-test-systems-overcounter-use

49 Premarket Notification (510(k)) 

Submissions for Electrosurgical 

Devices for General Surgery

www.fda.gov/regulatory-information/search-fda-guidancedocuments/premarket-notification-510k-submissionselectrosurgical-devices-general-surgery

60
Resources

Slide 

Number

Cited Resource URL

49 Display Devices for Diagnostic 

Radiology

www.fda.gov/regulatory-information/search-fda-guidancedocuments/display-devices-diagnostic-radiology

49 Infusion Pumps Total Product Life 

Cycle

www.fda.gov/regulatory-information/search-fda-guidancedocuments/infusion-pumps-total-product-life-cycle

49 Investigational Device Exemptions 

(IDEs) for Devices Indicated for 

Nocturnal Home Hemodialysis

www.fda.gov/regulatory-information/search-fda-guidancedocuments/investigational-device-exemptions-ides-devicesindicated-nocturnal-home-hemodialysis

49 Policy Clarification and Premarket 

Notification [510(k)] Submissions 

for Ultrasonic Diathermy Devices

www.fda.gov/regulatory-information/search-fda-guidancedocuments/policy-clarification-and-premarket-notification510k-submissions-ultrasonic-diathermy-devices

61
Resources

Slide 

Number

Cited Resource URL

49 Computer-Assisted Detection 

Devices Applied to Radiology 

Images and Radiology Device Data 

- Premarket Notification [510(k)] 

Submissions

www.fda.gov/regulatory-information/search-fda-guidancedocuments/computer-assisted-detection-devices-appliedradiology-images-and-radiology-device-data-premarket

62