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