ai startup roadshow encore webinar - scott...
TRANSCRIPT
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
Submission Content: specific for AI/ML Medical Device
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
Submission Content: specific for AI/ML Medical Device
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
A Working Model: v1.0 – January 2019
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
A Working Model: v1.0 – January 2019
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
A Working Model: v1.0 – January 2019
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]