Interna<onal overview on risk classifica<on of SaMD Introduc<on of IEC 62304 and IEC 82304-­‐1 Dr. Peter Linders DITTA Standardiza.on Working Group Chair With the help of Frans Jacobs and Daniel Chen DITTA Workshop on Medical So:ware Brasília, 7 March 2016 ABOUT PETER LINDERS … •
•
•
•
•
•
•
•
Over 25 years involvement in IEC and ISO Involved in regulatory affairs since 1998 Chair of CENELEC TC 62, and ABHS COCIR Board member & chair of TRAC DITTA member Board of Directors Co-­‐project leader of future IEC 82304-­‐1 Member in AHWP TC WG1 for soYware Chair of ISO TC 210 T: +31 6 5182 6428 E: peter.linders@philips.com AGENDA Ø  Interna<onal Risk Classifica<on Ø  Introduc<on of IEC 62304 and IEC 82304-­‐1 Ø  But first … qualifica<on First: qualificaaon, or when is soYware an SaMD? (SOURCE IMDRF) Medical purpose (as defined in GHTF/SG/N71: 2012) •  diagnosis, preven.on, monitoring, treatment or allevia.on of disease, •  diagnosis, monitoring, treatment, allevia.on of or compensa.on for an injury, •  inves.ga.on, replacement, modifica.on, or support of the anatomy or of a physiological process, •  suppor.ng or sustaining life, •  control of concep.on, •  etcetera…………. SaMD defini<on: SoYware intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device First: qualificaaon, or when is soYware an SaMD? (SOURCE IMDRF) SaMD defini<on: SoYware intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device SaMD adds to medical purposes: •  provide means and suggesaons for miagaaon of a disease •  provide informaaon for determining compaability, detecang, diagnosing, monitoring or treaang physiological condiaons, states of health, illnesses or congenital deformiaes •  be an aid to diagnosis, screening, monitoring, determinaaon of predisposiaon; prognosis, predicaon, determinaaon of physiological status First: qualificaaon, or when is soYware an SaMD? Now look at this fancy gear … Medical devices? What about their soYware? First: qualificaaon, or when is soYware an SaMD? And what about this ? Remember: prevenaon is in the definiaon … Medical devices? What about soYware in fitness equipment? So, what is SaMD? “SoYware intended to be used for one or more medical purposes that perform these purposes without being part of a medical device” (Source: IMDRF 2013) “SoYware which is not incorporated in a medical device at the ame of its placing on the market or its making available” (source: European MEDDEV 2.1/6 2012) “SoYware intended to run on general purpose computers” (source: FDA Murray 2010)) “SoYware that is intended for use as a MEDICAL DEVICE” NOTE This includes a MEDICAL DEVICE soYware product, which then is a MEDICAL DEVICE in its own right. (source: IEC 62304 Ed.1.1 2015) INTERNATIONAL RISK CLASSIFICATION “STANDALONE SOFTWARE” Classificaaon Risk Based; FDA 2005, FDA defines a Major, Moderate or Minor “Level of Concern” An esamate of the severity of injury that a device could permit or inflict, either directly or indirectly, on a paaent or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use. •
Major –  if a failure or latent flaw could directly result in death or serious injury to the paaent or operator –  if a failure or latent flaw could indirectly result in death or serious injury of the paaent or operator through incorrect or delayed informaaon or through the acaon of a care provider. •
Moderate –  if a failure or latent design flaw could directly result in minor injury to the paaent or operator. –  if a failure or latent flaw could indirectly result in minor injury to the paaent or operator through incorrect or delayed informaaon or through the acaon of a care provider. •
Minor –  if failures or latent design flaws are unlikely to cause any injury to the paaent or operator. (Source: FDA Guidance 337 2005) “STANDALONE SOFTWARE” Classificaaon Risk Based; EU MDD 2007, EU Medical Device Direc<ve 93/42/EEC introduces So:ware 2012, MEDDEV 2.1/6 provides guidance Stand alone soYware that meets the definiaon of a medical device shall be considered as an ac<ve medical device. This means that rules 9, 10, 11 and 12 of Annex IX to Direcave 93/42/EEC may apply. Active device type
Rule
Rule 9
Active therapeutic devices are in IIa or IIb
Active diagnostic devices are in IIa or IIb and, Active devices intended to emit
Rule 10
ionizing radiation and intended for diagnostic and therapeutic interventional
radiology are in IIb
Rule 11
Active devices intended to administer and/or remove medicines are in IIa or IIb
All other active devices are in Class I
Rule 12
But … almost all SaMD ends up in class I (source: MEDDEV 2.1/6 2012) “STANDALONE SOFTWARE” Classificaaon Risk Based; IMDRF IMDRF defines principles for “Categoriza<on” in 4 levels (I, II, III, IV) The four categories (I, II, III, IV) are based on the levels of impact on the paaent or public health where accurate informaaon provided by the SaMD to treat or diagnose, drive or inform clinical management is vital to avoid death, long-­‐term disability or other serious deterioraaon of health, miagaang public health. Significance of information provided by SaMD to healthcare
decision
State of Healthcare situation
or condition
Treat or diagnose
Drive clinical
management
Inform clinical
management
Critical
IV
III
II
Serious
III
II
I
Non-serious
II
I
I
(Source: IMDRF 2013) “STANDALONE SOFTWARE” SaMD Landscape/Scope Very
High Catastrophic
None Low Medium High
Impact
Classificaaon Risk Based; IMDRF Not
SaMD
Not SaMD
Type
I
Retrieves
information
Optimizes
Process
Organizes
Data
Type
I
Informs
serious
Decisions
Informs nonserious
Decision
Type
II
Type
I
Type
II
Informs
critical
Decisions
Drives nonserious
Decisions
Functionality
Type
III
Type
II
Treat/
Diagnoses
non serious
Drives
serious
Decisions
Type
IV
Type
III
Treat/
Diagnoses
serious
Drives
critical
Decisions
(Part of
MD /
Embedded
in MD)
Closed Loop
Interventions
No Clinical
Intermediary
Treats/
diagnoses
critical
“STANDALONE SOFTWARE” Classificaaon Risk Based, IEC 62304 Ed 1.0 2006, IEC 62304 Ed. 1.0 defines So:ware Safety Classes A, B and C The MANUFACTURER shall assign to each SOFTWARE SYSTEM a soYware safety class (A, B, or C) according to the possible effects on the paaent, operator, or other people resulang from a HAZARD to which the SOFTWARE SYSTEM can contribute. The soYware safety classes shall iniaally be assigned based on severity as follows: •  Class A: No injury or damage to health is possible •  Class B: Non-­‐SERIOUS INJURY is possible •  Class C: Death or SERIOUS INJURY is possible Class can be reduced form C to B or B to A by a hardware risk control measure (source: IEC 62304 Ed. 1.0 2006) “STANDALONE SOFTWARE” Classificaaon Risk Based; IEC 62304 Ed 1.1 2015, IEC 62304 Ed. 1.1 introduces RISK of HARM and a flowchart approach The MANUFACTURER shall assign to each SOFTWARE SYSTEM a soYware safety class (A, B, or C) according to the RISK of HARM to the paaent, operator, or other people resulang from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-­‐
case scenario (source: IEC 62304 Ed.1.1 2015) For B and C classified systems, classifica.on can be reduced by applying risk control measures external to the so3ware system So, it does not have to be a hardware mi9ga9on “STANDALONE SOFTWARE” Classificaaon Risk Based General overview of IMDRF, FDA, EU and IEC 62304 State of
Healthcare
situation or
condition
Significance of information provided by
SaMD to healthcare decision
Classification
Treat or
diagnose
Drive clinical
management
Inform clinical
management
FDA
EU*
IEC
62304
Critical
IV
III
II
Major
IIb
Class C
Serious
III
II
I
Major
IIa
Class C
Non-serious
II
I
I
Moderate
I-IIa
Class B
No risk
?
?
?
Minor
I
Class A
* On the basis of classification rules 9-12; effectively almost all SaMD end up in class I
“STANDALONE SOFTWARE” Classificaaon Risk Based Conclusions •  IMDRF classificaaon is missing “zero-­‐risk” class •  Some effort sall needed to achieve coherence in regulatory classificaaon of SaMD •  Unal then: complicated standards development Introduc<on of IEC 62304 and IEC 82304-­‐1 IEC 62304 & IEC 82304-­‐1 IEC 62304: This standard defines the life cycle requirements for MEDICAL DEVICE SOFTWARE. The set of PROCESSES, ACTIVITIES, and TASKS described in this standard establishes a common framework for MEDICAL DEVICE SOFTWARE life cycle PROCESSES. IEC 82304-­‐1: This Internaaonal Standard applies to the SAFETY of HEALTH SOFTWARE PRODUCTS designed to operate on general compuang platorms and intended to be placed on the market without dedicated hardware, and its primary focus is on the requirements for MANUFACTURERS. IEC 62304 -­‐ IEC 82304-­‐1
Figure$A.1$Health$soPware$applicaJon$domains$and$scope$of$related$standards$
Scope$of$$
IEC$62304$
For$specific$$
hardware$
For$general$
compuJng$
plaTorm$
SoPware$as$
part$of$a$
medical$$
device$
SoPware;
only$
medical$
device$
SoPware$as$
part$of$
specific$
health$
hardware$
SoPware;only$
product$for$
other$$
health$use$
Health$$
soPware$
Scope$of$$
IEC$82304;1$
!
Medical$device$use$$
Other$health$use$$
2
Figure$A.1$Health$soPware$applicaJon$domains$and$scope$of$related$standards$
Scope$of$$
Health$$
IEC 62304 -­‐ IEC 82304-­‐1 (SOURCE IEC 82304-­‐1 – DRAFT FDIS) So, what is health so:ware? IEC 82304-­‐1 defini<on: HEALTH SOFTWARE soYware intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care Now this calls for a definiaon of “health” … IEC 62304 -­‐ IEC 82304-­‐1 (SOURCE IEC 82304-­‐1 – DRAFT FDIS) So, then what is health? Previous IEC 82304-­‐1 defini<on: HEALTH state of complete physical, mental and social well-­‐being and not merely the absence of disease or infirmity [SOURCE: WHO definiaon (WHO 1946)] Removed from the document because too broad a defini.on IEC 82304-­‐1 & IEC 62304 Health Software
software intended to be used specifically
for managing or improving health of
individual persons, or the delivery of care
Health Software
fully incorporates
Medical Software
without a clear
dividing line.
Medical Software
no single definition for all jurisdiction
No clear boundary
CONCEPT EXPANDED MEDICAL SOFTWARE à HEALTH SOFTWARE IEC 62304 -­‐ IEC 82304-­‐1 (SOURCE IEC 82304-­‐1 – DRAFT FDIS) Two other key defini<ons: HARM injury or damage to the HEALTH of people, or damage to property or the environment [SOURCE: ISO/IEC Guide 51:2014, 3.1] HAZARD potenaal source of HARM Note 1 to entry: Potenaal sources of HARM include breach of SECURITY and reducaon of effecaveness. [SOURCE: ISO/IEC Guide 51:2014, 3.2, modified — Note 1 to entry has been added.] IEC 82304-­‐1 & IEC 62304 (SOURCE IEC 82304-­‐1 – DRAFT FDIS) Figure$A.3$;$IEC$82304;1:$HEALTH$SOFTWARE$PRODUCT$processes$;$schemaJc$
USER$needs$
USER$needs$met$
Establish$INTENDED$USE;$
perform$iniJal$RISK$ASSESSMENT$
Post;market$
communicaJon$
Create$VALIDATION$report$
Decide$on$
SOFTWARE$
Establish$use$
requirements$$
Validate$HEALTH$
SOFTWARE$PRODUCT*$
Establish$
VALIDATION$plan$
Establish$system$requirements$
MAINTENANCE$
and/or$other$
post;market$
acJviJes$
Finalize$ACCOMPANYING$
DOCUMENTS$
Develop$and$release$verified$HEALTH$SOFTWARE$
Maintain$$
HEALTH$SOFTWARE$
SoPware$life$cycle$processes$as$detailed$in$IEC$62304$
*$HEALTH$SOFTWARE$PRODUCT:$HEALTH$SOFTWARE$plus$ACCOMPANYING$DOCUMENTS$
3
Figure$A.2$;$IEC$82304;1:$HEALTH$SOFTWARE$PRODUCT$processes$;$schemaJc$
USER$needs$
USER$needs$met$
Post;market$
communicaJon$
IEC 62304 -­‐ IEC 82304-­‐1 (SOURCE IEC 82304-­‐1 – DRAFT FDIS) Conclusions •  Health so:ware includes medical SW yet it is broader •  IEC 82304-­‐1 includes the medical SW grey zone (but …) •  IEC 82304-­‐1 does NOT replace IEC 62304, rather uses it as a “plug-­‐in standard”, like IEC 60601-­‐1 does •  IEC 82304-­‐1 does recognize security issues as hazards •  No coverage for specific hardware for “other health use” •  Should scope for IEC 60601-­‐1 change? •  No other parts in IEC 82304-­‐series scheduled yet •  Thoughts: TRs on valida.on and on security IEC 62304 -­‐ IEC 82304-­‐1 Note that IEC 62304 is currently in revision: •  Scope broadening, to match with IEC 82304-­‐1 •  Revised classifica<on scheme ? •  Risk management issue •  Cyber security Schedule somewhat unclear, because … IEC 62304 -­‐ IEC 82304-­‐1 ISO/TC 215 is elabora<ng a framework for health so:ware Some level of conten<ousness Planning is unclear May have impact on future of IEC 82304-­‐1 and IEC 62304 Ed.2 and IEC 80001-­‐series IEC 62304 -­‐ IEC 82304-­‐1 ISO/TC 215 is elabora<ng a framework for health so:ware Some level of conten<ousness Planning is unclear May have impact on future of IEC 82304-­‐1 and IEC 62304 Ed.2 and IEC 80001-­‐series IEC 80001-­‐SERIES (OVERVIEW) IEC 80001-1:2010 Application of risk management for IT-networks
incorporating medical devices – Part 1: Roles, responsibilities and
activities
•  Part 2-1: Step by Step Risk Management of Medical IT-Networks; Practical
Applications and Examples
•  Part 2-2: Guidance for the communication of medical device security needs,
risks and controls
•  Part 2-3: Guidance for wireless networks
•  Part 2-4: General implementation guidance for Healthcare Delivery
Organizations
•  Part 2-5: Guidance for distributed alarm systems
•  Part 2-6: Guidance for responsibility agreements
•  Part 2-7: Guidance for Healthcare Delivery Organizations (HDOs) on how to
self-assess their conformance with IEC 80001-1
•  Part 2-8: Guidance on standards for establishing the security capabilities
identified in IEC 80001-2-2 [DTR]
•  Part 2-9: Guidance for use of security assurance cases to demonstrate
confidence in IEC/TR 80001-2-2 security capabilities [NP]
OBRIGADO!
THANK YOU!