Medical Device Software: Update on IMDRF WorkNancy ShadeedInternational Programs Division, Health Canada
FROM A TIME WHERE SOFTWARE HAD …
• Standalone software
• Medical software• Embedded
software• Software “part of
medical device”• Mobile apps• Cloud software• ….. etc
Many Names Different Application of Controls Many Interpretations
• Of risk and impact to patients
• On philosophy and practice
– Inherently does not harm patients
• By country regulators
• By medical device industry
• By software industry
2
MANY INDIVIDUAL EFFORTS
3
IMDRF Establishes SaMD Working Group and Plan for ConvergenceGoals• International convergence and common understanding of
Software as a Medical Device (SaMD):– Generic types of SaMD– Generic risks of SaMD that affect public health– Expectations of controls required to minimize generic
risk
• Establish a framework for regulators to incorporate converged approach into their own regulatory paths or regulations.
4
Approach
• Define Key terms?
Phase I
• What factors affect public health risk?
• What generic types of exists?
• What are the generic risks for the types?
Phase II •What are the controls/expectations needed to minimize generic risk for the types?
•Who, when and where is best suited to assure that the risks to be adequately managed?
Phase III
5
WG proposes key definitions
Proposed Definition• Standalone medical device
software• Medical purpose for
software• Software Changes• Standalone Medical Device
Software manufacturer• Intended use / intended
purpose
Public feedback• Provide clarity to definition
and scope– Related to software that is
part of – Mobile apps
• Provide context of IMDRF SaMD effort
• Provide how key definitions relate to existing vocabulary (GHTF, standards, etc.,)
6
Final Key Definitions Document• Vocabulary that reflects the
scope – Software as a Medical
Device” (SaMD) – “Standalone Medical Device
Software”
• Adoption & alignment to relevant GHTF definitions
• Introduction includes description of future activities
• Software as a Medical Device
• Medical purpose– Medical Device– In Vitro Diagnostic (IVD)
medical device– Additional considerations for
SaMD• SaMD Changes• SaMD Manufacturer• Intended use / intended
purpose– Additional considerations for
SaMD
http://www.imdrf.org/docs/imdrf/final/technical/imdrf‐tech‐131209‐samd‐key‐definitions‐140901.docx
7Japan, March 2015
SaMD DefinitionSoftware intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device
NOTES: • SaMD is a medical device and includes in‐vitro diagnostic (IVD) medical device.• SaMD is capable of running on general purpose (non‐medical purpose)
computing platforms • “without being part of”means software not necessary for a hardware medical
device to achieve its intended medical purpose;• Software does not meet the definition of SaMD if its intended purpose is to
drive a hardware medical device. • SaMD may be used in combination (e.g., as a module) with other products
including medical devices; • SaMD may be interfaced with other medical devices, including hardware
medical devices and other SaMD software, as well as general purpose software• Mobile apps that meet the definition above are considered SaMD.
8
WHAT ABOUT HARDWARE …
SaMD definition is platform‐agnostic
SaMD can run on • dedicated platforms,• medical devices, • general‐purpose PCs,• mobile platforms, • cloud services, • etc.
WHAT it does is more important than WHERE it is
Intended Purpose.Intended Purpose.Intended Purpose.
9Japan, March 2015
Phase II ‐ Possible Framework for Risk Categorization and Corresponding Considerations
Phase II Phase III• SaMD Key definitions • What factors of SaMD affect
public health risk?• What generic types of SaMD exists?
• What are the generic risks for the types of SaMD?
•What are the controls/expectations
Combined effort for N12/R10
SaMD FrameworkIMDRF/N12/PD1‐R5
Proposed Final: 8/2014IMDRF WG (PF)/N12/R10
Final: 12/2013 IMDRF/N10/R2
Phase I
Informal input from stakeholders
Public Consultation
Framework Overview
SaMD definition statement:• Significance of recommendation• Context of use
9 criteria based on definition
statement
4 Categories based on similarity of impact
Risk Categorization
Type
IV
III
II
I Common
process
expe
ctation
Level of Risk
General and Special Controls Considerations
SaMD Categorization Principles• SaMD impact and resultant category relies on an accurate
and complete SaMD definition statement provided by the manufacturer
• Categories are a result of combination of significance of the information provided by the SaMD to the healthcare decision and the healthcare situation or condition
• Categories are based on the levels of impact on the patient or public health
• Categories are in relative significance to each other. Category IV has the highest level of impact, Category I the lowest.
• SaMD functionality that span across multiple healthcare situations or conditions or provide information of varying significance are categorized at the highest level of impact when can be used
• SaMD has its own category even when interfaced with other SaMD, other hardware medical devices, or used as a module in a larger system
Definition Statement
Significance
Impact
Relativity
Highest Denominator
Independency
SaMD Definition Statement: A Common vocabulary
A C O M M O N V O C A B U L A R Y T H A T E N A B L E S T H E I D E N T I F I C A T I O N O F T H E S A M D C A T E G O R Y .
treat or diagnose, drive clinical management; inform clinical management
who is it for, how used, patient condition, target population, target disease, limitations of SaMD output
what features/functions are essential to the intended medical purpose and context of use that will determine considerations for managing changes
1. The significance of information provided by SaMD
2. The criticality ofcontext of use of the SaMD
3. A description of the SaMD’s core functionality
SaMD Categorization
State of Healthcare Situation or Condition
Significance of Information Provided by SaMD to Healthcare Decision
Treat or Diagnose
Drive Clinical Management
Inform Clinical Management
Critical IV III II
Serious III II I
Non-Serious II I I
Increasing significance
Increasing
criticality
14
S i g n i f i c a n c e o f i n f o rma t i o n
• To treat or to diagnose– To provide therapy to a human body; – To diagnose/screen/detect a disease or
condition
• To drive clinical management – To aid in treatment by providing enhanced
support to safe and effective use of medicinal products or a medical device.
– To aid in making a definitive diagnosis.– To triage or identify early signs of a disease
or conditions.
• To Inform clinical management– To inform of options – To provide clinical information by
aggregating relevant information
C r i t i c a l i t y o f con tex t
• Critical situation or condition– where accurate and/or timely diagnosis
or treatment action is vital to avoid death, long‐term disability or other serious deterioration of health of an individual patient or to mitigating impact to public health.
• Serious situation or condition– where accurate diagnosis or treatment is
of vital importance to avoid unnecessary interventions
• Non‐Serious situation or condition– where an inaccurate diagnosis and
treatment is important but not critical for interventions
15
Categorization Criteria
Not SaMDNot SaMD
SaMD Types Landscape/Scope
Retrieves information
Organizes Data
Informs serious
Informs non-serious
Closed Loop Interventions No Clinical
Intermediary
Optimizes Process
Cat
astr
ophi
cH
igh
Med
ium
Low
Non
e
Imp
ac
t
Not SaMD(Part of MD
/ Embedded in MD)
Not SaMD(Part of MD
/ Embedded in MD)
i
i
i
i
F u n c t i o n a l i t y
Informs critical
Drives non-serious
Drives serious
Treat/ Diagnoses
non serious
Drives critical
Treat/ Diagnoses
serious
Treats/ diagnoses
critical
iiiii
iiiii
ii
Very
Hig
h
Type I
Type II
Type III
Type IV
16
A NEED FOR CONVERGENCE ON APPLICATION OF CONTROLS
A C O M M O N
A P P L I C A T I O N
A N D
P H I L O S O P H Y -
D R I V E S C O M M O N
P R A C T I C E S
• Quality Management System (QMS) principles is one of the key controls
• QMS as written applies to everything including software
• Translation of to the uniqueness of software practices not always transparent
17
Application of QMS to SaMD ‐ N23“overview of scope and approach”
• Not a new QMS
• Not in conflict with current QMS requirements
• Assumes developers are using good s/w engineering practices
• Not a tutorial for software practices or QMS
• Uses common software quality terminology ad practices
• Groups QMS principles from a software perspective
• Reinforces medical device quality principles that should be appropriately incorporated for an effective SaMD QMS
• Highlight clinical and technological considerations of Medical device QMS in elements of s/w practices
• Link to IMDRF SaMD risk framework document (SaMD types and general and special considerations of SaMD)
18
Software specifics in standards fragmented/missing… need convergence/alignment efforts to address uniqueness of s/w in standards
Clinical
Pre & Post Market
Privacy & Security
User Configurability
Non‐Physical Nature• CLOUD• Open Source• Interoperability
NEW• Data • Ease of Iterations• Systems• Responsibilities
Guidance needed for
SaMD
Highlighted other aspects (comments analysis)
19
Survey Goal
SaMD Working Group Survey Results
NWIE Proposal ‐ Software as a Medical Device (SaMD): Clinical Evaluation
Purpose: To give detailed guidance on when clinical data may be needed for an original SaMD and for a modification to a SaMD based on the risk classification for SaMD (SaMD N12) adopted by IMDRF to support market authorization.
Rationale: Though current clinical guidance are intended to be relevant across a broad spectrum of technology, SaMD operates in a complex socio‐technical environment heavily influenced by the inherent nature of software that enables a highly interactive and iterative technological environment. A majority of the respondents (from the IMDRF survey) either believe current clinical guidance needs to be revised with criteria specific for SaMD, or don’t know whether it applies to SaMD.
Alignment with goals/objectives: A common understanding on the application of clinical evaluation and clinical evidence processes as they relate to SaMD and the need for clinical data to support market authorization will lead to increased transparency and promoting a converged thinking on this topic.
20
Goal
21
‐‐ Based on “SaMD type” (level of impact on public health) and unique aspects of software
Which clinical evaluation methods and processes should/can be appropriately used for SaMD to generate evidence of clinical effectiveness?
How much and what level of evidence is adequate to show clinical effectiveness?
Which SaMD types are important /not important to independently verify‐ Clinical evidence ‐ Adherence to methods and processes