AI Startup Roadshow Encore Webinar - Scott...

1

Background Information

2

Agenda

Ways AI/ML could be used in medical devices

FDA classification and regulation of medical devices, including AI

AI/ML medical device paths to market

FDA Pre-Certification Pilot Program

FDA AI/ML discussion paper

3

AI/ML USE IN MEDICAL DEVICE SPACE

4

Ways AI could be used in or with medical devices

Product Development

• Design decisions

• In Silico testing

• Data curation (NLP)

• Algorithm development / training / optimization

Algorithm implementation into device (include SaMD)

• Static / locked (same output for same input)

• Dynamic / adaptive (changes over time based upon input)

Post-market

• Root-cause analysis

• Cybersecurity monitoring / response

4/16/2019

5

HOW DOES FDA CLASSIFY AND REGULATE AI/ML MEDICAL DEVICES?

6

Review: is my AI device a medical device?

7

Review: is my AI device a medical device?

We will focus here.

8

Overview: classification and regulatory oversight

REGULATORY OVERSIGHT

►General Controls

►Special Controls

►Performance Standards

REGULATORY PATHWAYS

►Registration & Listing

►Pre-market Notification

►De Novo Petition

►Pre-market Approval (PMA)

Class IIIPacemaker/Defibrillator, Neurostimulators, Artificial Pancreas, Computer-Aided Diagnostic/Therapy

Class IICardiac Monitors, Peripheral Nerve Stimulators, Blood Glucose Meters, Imaging Diagnostic Software

Class IMedical Device Data Systems, Wheelchair, Surgical Instruments, Orthotics, Liquid Bandages

Ris

k &

No

velt

y

Regu

latory O

versigh

t

► Prohibition against adulterated or misbranded devices

► Good Manufacturing Practices (GMPs)

► ….

9

What controls apply?

Recognized

Guidance

Recognized Standards

Guidance

Each device type has a specific regulation that describes the generic device and establishes the device's classification:

Example: Infusion Pumps are governed by regulation §21 CFR 880.5725

Regulation 880.5725 establishes infusion pumps as class II devices

Clinical Performance

*21 CFR Part 820.30 describes Design Controls

Quality Management

System

Product Codes:

MRZ (infusion pump accessories)FRN (infusion pump) LZF (analytical sampling infusion pump) MEB (elastomeric infusion pump) LZH (enteral infusion pump) MHD (gallstone dissolution infusion pump) MRH (ophthalmic infusion pump) MEA (PCA infusion pump)

10

GxPs

GMP = Good Manufacturing Practices

GLP = Good Laboratory Practices

GDP = Good Documentation Practices

GCP = Good Clinical Practices

GxP = Good “fill in blank” Practices

GxP is a general abbreviation for the "good practice" quality guidelines and regulations.

The "x" stands for the various fields, including the medical device, pharmaceutical and food industries.

A "c" or "C" is sometimes added to the front to designate “current”

11

Good manufacturing practices (GMP) are the practices required in order to conform to the guidelines and regulations overseen by agencies that control the authorization and licensing of the manufacture and sale of medical devices.

These guidelines and regulations provide minimumrequirements that a manufacturer must meet to assure that their products are consistently high in quality for their intended use.

A quality management system (QMS) is a collection of business processes expressed as the organizational goals and aspirations, policies, processes, documented information and resources needed to implement and maintain it.

For medical device manufacturers, a QMS is required; see 21 CFR Part 820 and ISO 13485: 2016.

GMPs and QMS

In US, satisfied through compliance to

12

QMS: FDA 21 CFR Part 820

Product Traceability

820.65

General(a)

Design & Develop-

ment Planning

(b)

Design Input(c)

Design Review

(e)

Design Verification

(f)

Design Validation

(g)

Design Transfer

(h)

Design Changes

(i)

Design History File

(DHF)(j)

DHR820.184

DMR820.181

Medical Device

Tracking Part 821

Inspection, Measuring &

Test Equipment

820.72

Process Validation

820.75

Receiving, in-process, &

finished device

acceptance820.80

Acceptance Status820.86

Non-conforming

Product 820.90

Purchasing Controls

820.50

Servicing820.200

Device Labeling820.120

LabelingPart 801

UDI

Risk Management - Foundational

Complaints820.198

Correct-ions /

RemovalsPart 806

Medical Device

ReportingPart 803

Quality Audit820.22

Personnel820.25

Document Controls

820.40

Records820.180

Statistical Techniques

820.250

QS Record820.186

CAPA (820.100)

Identification820.60

Handling820.140

Distribution820.160

Storage820.150

Installation820.170

Device Packaging

820.130

13

AI MEDICAL DEVICE PATH TO MARKET -FDA

14

FDA Paths to Market available for AI Medical Devices

No premarket submission

Most need to comply with QMS & companies must register and list

Must comply with QMS and Special Controls

510(k) pre-market clearance required (substantial equivalence)

Must comply with QMS and any applicable special controls

PMA approval required

Device without predicate or assigned classification (de facto Class III)

Manufacturer files petition for down classification if believe device risk is lower than Class III

Must comply with QMS

Class I

Class II

Class III

De Novo

15

Class I Path to Market

QMS

Design History Management Approval

Register & List

$4,884

16

Pre-Market Notification [510(k)] Path

Special Controls

QMS

Management Approval

Register & List

$4,884

$10,953($2,738)

Cleared

Submission

Design History

Predicate

120 – 180 days

17

Pre-Market Approval [PMA] Path

Special Controls

QMS

Management Approval

Register & List

$4,884

$322,147($80,537)

Approved

Submission

Design History 210 – 280 days

18

WHAT IS A DE NOVO PETITION?

Low-risk products that have been classified as Class III because there are no identifiable predicate devices or assigned classification.

Low-risk products that have been classified as Class III because there are no identifiable predicate devices or assigned classification.

Novel products often do not have a predicate.Novel products often do not have a predicate.

A company can file the petition to down-classify the product. If granted, then a new regulation and set of special controls is established.

A company can file the petition to down-classify the product. If granted, then a new regulation and set of special controls is established.

The effort and complexity falls somewhere between a 510(k) and a PMA. The effort and complexity falls somewhere between a 510(k) and a PMA.

19

De Novo Path

Special Controls

QMS

Management Approval

Register & List

$4,884

$96,644($24,161)

Granted

Petition

Design History

Predicate

Proposed Special Controls

250 – 300 days

20

AI MEDICAL DEVICE CONSIDERATIONS

21

Intended Use

• What should it be used for / does the problem require AI to solve?

• Does the use support intended use?

• How to quantify benefit

Risks

• User reliance (automation bias, automation complacency)

• Mitigating perpetuating bias (distributional shift, sample selection bias)

• Algorithms unable to “err on the side of caution”

Data

• Quality / usability of the data (real-world data, different nomenclature, semantics)

• Identifying training and retraining data sets

• Data could reinforce outmoded practice (may not be able to adjust to radical shifts)

• Can optimize to the wrong or unrelated task

Testing

• Explainability of the result and algorithm

• How to verify and validate, especially if AI changes based upon data ingested (dynamic)

• How / when to assess changes in application

• Development speed / processes

Considerations for AI Medical Devices

22

EXAMPLE:

For a cleared Class II medical device software, the current requirement is:

• A new 510(k) is needed if a modification significantly changes the clinical functionality or performance specifications related to the intended use of the software, or

• If the intent of the modification is to significantly improve the safety or effectiveness of the software.

Static algorithms – the manufacturer controls the software changes.

Adaptive algorithms – the software changes significantly based upon data it is exposed to.

For both types of algorithms:

Has the problem being addressed changed in some way?

Often, an algorithm is part of an overall software system meant to change behavior of the user(s). If the software system is successful, then the training data or algorithm may need to be changed to accommodate for the new behavior environment.

Testing considerations for changes to AI

23

Verification & Validation: a brief explanation

ValidationDid I make the right thing?

Does the thing meet user expectations and is it safe and effective?

VerificationDid I make the thing right?

Does the thing meet requirements?

Validation

Verification

Usability test

Testing- Regression test- System test- Beta test

Modelling

Prototyping

Goal analysis

Inspection

Code Inspection

Proof of correctness

Data analysis

24

Verification

Requirements

Design Specifications

Product

Verification Test Protocol with criteria

Traceability Matrix

25

Validation

Product Design Intend to Launch

Validation Test Protocol with criteria

Traceability Matrix

26

WHAT INFORMATION IS SUBMITTED?

27

Submission Content: General

Design History File

Submissions dossier Administrative

/ FDA Forms

Intended Use and

DescriptionDesign Input

Design OutputVerification &

ValidationLabeling

Risk Management

28

Submission Content: 510(k)

Typical Table of Contents for 510(k)• Medical Device User Fee Cover Sheet• CDRH Premarket Review Submission Cover Sheet• 510(k) Cover Letter• Indications for Use Statement• 510(k) Summary• Truthful and Accuracy Statement• Class III Summary and Certification• Financial Certification or Disclosure Statement• Declarations of Conformity and Summary Reports• Executive Summary• Device Description• Substantial Equivalence Discussion• Risk Analysis• Proposed Labeling• Sterilization/Shelf Life• Biocompatibility• Software• Cybersecurity (design & internal programs)• Electromagnetic Compatibility/Electrical Safety• Performance Testing – Bench• Performance Testing – Animal• Performance Testing – Clinical• System level validation (including usability)

Typical Table of Contents for Software Section• Level of Concern• Software Description• Device Hazards Analysis (per ISO 14971)• Software Requirements Specification• Architecture Design Chart• Software Design Specifications• Traceability Analysis• Software Development Environment Description• Verification and Validation Documentation• Revision Level History• Unresolved Anomalies

29

Submission Content: De Novo Petition

Core Topics to Address• The device should appear to meet the statutory standards for

classification into class I or class II; • General and/or special controls would provide reasonable

assurance of the safety and effectiveness; and • You should sufficiently understand and be able to:

• explain all of the probable risks to health and probable benefits of the device,

• explain the measures needed to effectively mitigate all probable risks,

• explain how device safety and effectiveness can be assured through general and/or special controls, and

• describe or recommend special controls, if needed.

Pre-Submission – not required, but recommended

Typical Table of Contents • Regulatory History• Device Information and Summary• Change Summary• Classification Summary• Classification Recommendation• Proposed Special Controls (for Class II devices only)• Supporting Protocols and/or Data• Summary of Benefits• Summary of Known and Potential Risks to Health• Risk and Mitigation Information• Benefit-Risk Considerations• Financial Certification or Disclosure Statement• Declarations of Conformity and Summary Reports• Executive Summary• Risk Analysis• Proposed Labeling• Sterilization/Shelf Life• Biocompatibility• Software (see details on 510(k) slide)• Cybersecurity (design & internal programs)• Electromagnetic Compatibility/Electrical Safety• Performance Testing – Bench• Performance Testing – Animal• Performance Testing – Clinical• System level validation (including usability)

30

Is

Described in FDA guidance*.

A mechanism to obtain written feedback from and/or a meeting with FDA on a variety of topics within 75 calendar days of submission.

Currently free.

Limited to the information and questions included in the pre-submission.

Voluntary on the part of industry.

Is Not

A mechanism for legally marketing your product.

The only mechanism for obtaining feedback from FDA.

A way to get FDA guarantee on an opinion (fact and circumstance specific and new information can alter FDA opinion).

Required.

What is a pre-submission?

*“Requests for Feedback on Medical Device Submissions: The Pre-Submission Program and Meetings with Food and Drug Administration Staff”

31

Submission Content: Cybersecurity

FDA Cybersecurity Expectations

• Impossible to completely mitigate risks through premarket controls alone

• Cybersecurity Risk Management

o Emphasize addressing vulnerabilities in a timely fashion

o Critical components include:

‒ Monitoring cybersecurity information sources

‒ Maintaining robust software lifecycle processes

‒ Understanding, assessing, and detecting presence and impact of a vulnerability or incident

‒ Establishing and communicating processes for vulnerability intake and incident handling

‒ Deploying methods to analyze, detect, and assess threat sources

‒ Using threat modeling to clearly define how to maintain safety and essential performance

‒ Adopting a coordinated vulnerability disclosure policy and practice

‒ Deploying mitigations that address cybersecurity risk early and prior to exploitation

32

Submission Content: specific for AI/ML Medical Device

Technological Characteristics

• Algorithm design and function• Flowchart describing processing, features, models and classifiers• How parameters are selected and weighted

• Features and limitations

• Models and classifiers, training paradigm, reference standard

• Impact to true positives and false negatives

33


Testing Assessment / DOE

• Match testing to the intended use, subject population (e.g., patient), and intended user population (e.g., clinician)

• How is the clinical attribute presence/absence determined?• Another device, biopsy, follow-up exam, interpretation by clinicians, etc.

• Types of data used and where sourced• Simulated, phantom, actual patient• Test dataset reuse, if done, and how not part of training

• Predetermined acceptance criteria; statistical and clinical justification; randomization methodology; plan for multiple hypothesis testing; plan for handling missing data

• Prospective or retrospective; scoring methodology, including scientific and clinical justification; supporting literature

34


Change Control

From April 2, 2019 FDA AI/ML Discussion paper

35

Submission Content: How it fits together

Intended useIntended usersIntended use environment

Product Requirements

Business requirements

Mechanical Design Specifications

Electrical Design Specifications

Software Design Specifications

Mechanical verification

Electrical verification

Unit VerificationIntegration Verification

System Design Verification

System Design Validation

Formative Usability Testing

Summative Usability

Risk management

36

WHAT IS THE PRE-CERTIFICATION PILOT PROGRAM?

37

FDA’s new Software Precertification Pilot ProgramIntroduction and Overview

The Software Precertification (Pre-Cert) Pilot Program aims to develop a new regulatory paradigm for SaMD and related digital health technologies that are not believed to be sufficiently addressed via the conventional FDA premarket review process.

In January 2019, FDA issued updates to the Software Pre-Cert Pilot Program. Three documents were issued by FDA.

Pre-Cert Working Model Version 1.0

• Describes major program components and how they interact.

•Pre-Cert 2019 Test Plan• Explains how FDA will confirm assurances of safety and effectiveness for

software products evaluated under the program.

•Pre-Cert Regulatory Framework

• Describes the Agency’s plans to implement the pilot program.

38

The new Software Precertification Pilot ProgramA Working Model: v1.0 – January 2019

The program should allow patients and healthcare providers to have confidence in precertified companies and the devices they produce because precertified organizations leverage real-world performance to continuously monitor and improve upon the safety and effectiveness of marketed SaMD products.

Vision: to be available for organizations of any size that are currently developing medical devices.

39

The latest Pre-Cert Working Model: What’s new?A Working Model: v1.0 – January 2019

FDA’s Working Model v1.0 continues the voluntary pathway theme with a goal of maintaining safety and effectiveness of software technologies, without inhibiting patient access to these novel technologies.

Goals of the Pre-Cert Program

Establish trust (that companies have a culture of quality).

Leverage transparency of organizational excellence/product performance.

Use a tailored streamlined premarket review.

Leverage postmarket opportunities to verify continued safety, effectiveness, and performance.

40

The program scope has been limited to SaMD for Version 1.0A Working Model: v1.0 – January 2019

Data TypesLab results, medical images,

symptoms, genomic data, Environmental signals, Pictures, activity data, phenotype data, IVD instrument results, patient

demographic information, progress notes, vital signs,

medications, diagnosis, immunization dates…

Algorithm, inference engine color equations,

analysis engine color model based logic,

AI/machine learning

Reference data, knowledge base,

rules, criteria

Intended Use for Medical Purpose (Inform, Drive,

Diagnose, Treat)

SaMD Algorithm SaMD Output

SaMD Inputs

Laboratory, medical devices, medical imaging devices,

physiological monitors, IVD test instruments,

patient-report outcomes medical purposes

screens, patient records, non-medical devices,

etc.

Data Sources

Description of SaMD, including possible data sources from which inputs are derived and that may be used for one or more medical purposes

Adopted by FDA from IMDRF SaMD definition in “Software as a Medical Device (SaMD): Key Definitions”; IMDRF/SaMD WG/N10FINAL:2013

41

Meant to cover the Total Product Lifecycle

The program is divided into four key components:

1. Excellence Appraisal2. Review Determination3. Streamlined Review4. Real-World Performance

Components are interdependent and part of a comprehensive Pre-Cert Program—covering a “total product lifecycle” approach.

Software Pre-Cert Program’s Four KEY ComponentsA Working Model: v1.0 – January 2019

42

Software Pre-Cert Program Overview: (1) Excellence AppraisalA Working Model: v1.0 – January 2019

FDA would evaluate organizational excellence based on five culture of quality and organizational “Excellence Principles.”

• Product Quality – Demonstration of excellence in the development, testing, and maintenance.

• Patient Safety – Demonstration of excellence in providing a safe patient experience and emphasizing patient safety as a critical factor in all decision-making processes.

• Clinical Responsibility – Demonstration of excellence in responsibly conducting clinical evaluation and ensuring that patient-centric issues, including labeling and human factors, are appropriately addressed.

• Cybersecurity Responsibility – Demonstration of excellence in protecting cybersecurity and proactively addressing cybersecurity issues through active engagement with stakeholders and peers.

• Proactive Culture – Demonstration of excellence in a proactive approach to surveillance, assessment of user needs, and continuous learning.

43

Software Pre-Cert Program Overview: (2) SaMD Review Pathway Determination

A Working Model: v1.0 – January 2019

SaMD Review Pathway Determination

The principal objective: develop a risk-based framework so precertified organizations developing SaMD can determine the premarket review

pathway (e.g., flow chart) for their products.

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

• FDA envisions leveraging the risk category framework for SaMD developed by the International Medical Device Regulators Forum (IMDRF)* to inform the risk category.

• FDA also identified SaMD product-level elements (e.g., the core functionality of the product, device description and performance, intended use, etc.) to be considered to determine SaMD risk categories and Pre-Cert review pathways.

44

Software Pre-Cert Program Overview: (2) SaMD Review Pathway Determination


This table describes a potential future model for a premarket review pathway for SaMD from precertified companies based on:

1. The IMDRF risk category of SaMD

2. Level of precertification of the organization

Table describes a proposal for when the precertification of organizations and commitment to leverage real-world performance might allow for no premarket review (“No Review” in table above) or streamlined premarket review (“SR” in table above), according to the IMDRF type of the SaMD and the Pre-Cert Level of the organization (Level 1 or Level 2).

45

Software Pre-Cert Program Overview: (3) Streamlined Premarket Review Process


Products that are considered for Streamlined Review are from organizations that have successfully gone through the Excellence Appraisal (Covered in Step 1: excellence in developing, testing, maintaining, and improving software products).

FDA envisions reviewing the risk management for the device’s intended use and the SaMD’s clinical evaluation results.

FDA intends to conduct an interactive review supported by automated analysis and then will provide a decision on the marketing of the precertified orgs. SaMD product within a shorter timeframe than traditional premarket review processes.

At a high level, the Streamlined Review

process would include:

• Understanding the product: FDA would use information from a Review Determination Pre-Sub to facilitate a better understanding of the product

• Premarket review: FDA envisions evaluating the SaMD’s analytical performance, clinical performance, and safety measures.

• Marketing authorization: FDA would make a premarket decision.

46

Software Pre-Cert Program Overview: (3) Streamlined Premarket Review Process


NOTE: The FDA expects to implement a process where repeated unsuccessful streamlined reviews of a precertified organization’s SaMD trigger a reassessment of the organization’s precertification determination.

Elements necessary for Streamlined Premarket review include examples such as clinical algorithms, cybersecurity-related info (including threat models), software architecture, etc.

Streamlined Review Elements

Administrative Elements

Cover letter

Financial Certification and Disclosure Form

Truthful and Accuracy Statement

Product-Specific Elements

Clinical algorithm

Clinical Data Analysis and Interpretation

Cybersecurity product-specific information including threat model

Declaration of Conformity and Summary Reports for Vertical Standards

Hazard Analysis (product-specific)

Instructions for use

Labeling review

Regulatory Pathway Specific Items (e.g., 510(k) substantial equivalence comparison)

Requirements (product-specific)

Revision history

SaMD product demo

Software architecture

Validation (product performance)

Elements Leveraged from other components

Excellence Appraisal Assessment

Review Determination information (Indications for Use, Device Description, etc.)

Real-world Performance Plan

47

Software Pre-Cert Program Overview: (4) Real-World Performance A Working Model: v1.0 – January 2019

The real-world performance analytics component of Version 1.0 of the Software Pre-Cert Program is designed to assess:

Real-World Health Analytics: analyses of real-world clinical outputs and outcomes related to the intended use of the SaMD product.

User Experience Analytics: analyses of user experience outputs related to the real-world use of a SaMD product.

Product Performance Analytics: analyses of outputs and outcomes demonstrating the real-world accuracy, reliability, and security of a SaMD product.

During the Excellence Appraisal, all organizations would demonstrate the capability to collect and analyze post-launch Real-World Performance (RWP) data. FDA expects that these organizations will consistently collect and analyze readily available post-launch data related to the safety, effectiveness, and performance of their products.

NOTE: FDA intends to focus its post-launch product monitoring efforts on trends and summary analytics, rather than on raw data.

48

Proposed for 2019A Working Model: v1.0 – January 2019

Excellence Principles

Excellence Appraisal(FDA will do this in 2019)

Master File

Review Determination Pre-Sub(optional)

“Pre-Cert De Novo Request”

Pre-Sub Information De Novo Petition

Pre-Cert Level Assigned

Master File

Pre-Sub Information

Pathway for De Novo-eligible SaMD Product FDA intends to utilize the De Novo classification process (section 513(f)(2) of the FD&C Act) for the next phase of the Software Pre-Cert Pilot Program under its current authorities.

49

Proposed for 2019A Working Model: v1.0 – January 2019

Real World Performance

De Novo AuthorizationNew Device and Special Controls

Available as predicateFor 510(k)

Excellence Appraisal

Design Change Does Change need new

submission?

Non-Pre-Cert Competitor

“Normal” 510(k) Review

“Pre-Cert 510(k)” Review

FDA Pre-Cert Competitor

ORExample: Class II decision

through De Novo

50

FDA AI/ML DISCUSSION PAPER

51

Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) – Discussion Paper and Request for Feedback

The 20-page document was issued April 2, 2019.

Summarizes FDA thinking and questions regarding how to regulate AI/ML-based medical devices.

Includes 18 questions FDA is asking for input on.

Provides three (3) example scenarios, each with varying modifications.

52

Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning (AI/ML)-Based Software as a Medical Device (SaMD) – Discussion Paper and Request for Feedback

Discusses “locked” and “adaptive” algorithms, however most of the document presumes manufacturer knowing (being able to intervene) when the algorithm changes.

Expands / builds upon use of SaMD Pre-Certification Framework to show how fits with AI/ML-based systems.

Continues to expand the role of pre-submission program – may eventually lead to fees for the pre-submission program. We saw this with the de novo pathway.

Outlines concept of a pre-determined change control plan. Discussion paper includes high-level content proposal for a change control plan.

“We [FDA] define a “locked” algorithm as an algorithm that provides the same result each time the same input is applied to it and does not change with use.”

53

Good Machine Learning Practices

1. Establish clear expectations on quality systems and Good Machine Learning Practices (GMLP);

2. Conduct premarket review for those SaMD that require premarket submission to demonstrate reasonable assurance of safety and effectiveness and establish clear expectations for manufacturers of AI/ML-based SaMD to continually manage patient risks throughout the lifecycle;

3. Expect manufacturers to monitor the AI/ML device and incorporate a risk management approach and other approaches outlined in “Deciding When to Submit a 510(k) for a Software Change to an Existing Device” Guidance in development, validation, and execution of the algorithm changes (SaMD Pre-Specifications and Algorithm Change Protocol); and

4. Enable increased transparency to users and FDA using postmarket real-world performance reporting for maintaining continued assurance of safety and effectiveness.

54

FDA Expectations regarding quality

The FDA expects every medical device manufacturer to have an established quality system that is geared towards developing, delivering, and maintaining high-quality products throughout the lifecycle that conforms to the appropriate standards and regulations.

Similarly, for AI/ML-based SaMD, we expect that SaMD developers embrace the excellence principles of culture of quality and organizational excellence.

55

New concepts from FDA

• SaMD Pre-Specifications (SPS): A SaMD manufacturer’s anticipated modifications to “performance” or “inputs,” or changes related to the “intended use” of AI/ML-based SaMD. These are the types of changes the manufacturer plans to achieve when the SaMD is in use. The SPS draws a “region of potential changes” around the initial specifications and labeling of the original device. This is "what" the manufacturer intends the algorithm to become as it learns. [presumes the manufacturer can know this]

• Algorithm Change Protocol (ACP): Specific methods that a manufacturer has in place to achieve and appropriately control the risks of the anticipated types of modifications delineated in the SPS. The ACP is a step-by-step delineation of the data and procedures to be followed so that the modification achieves its goals and the device remains safe and effective after the modification.

56

Scott ThielDirectorNavigant [email protected]

AI Startup Roadshow Encore Webinar - Scott...

Documents

Transcript of AI Startup Roadshow Encore Webinar - Scott...