Anda di halaman 1dari 28

Medical Device Software Do You

Understand How Software is Regulated?


By Gregory Martin

Copyright 2015 BSI. All rights reserved.

Agenda

Relevant directives, standards, and guidance documents

recommended to develop, maintain, and validate medical


software according to the state of the art.

Determine if software is covered by an EU medical directive


for CE Marking, and if so how you classify the software.

Overview of basic concepts from the key software standard


EN 62304 and guidance document MEDDEV 2.1/6.

Copyright 2015 BSI. All rights reserved.

26/11/2015

Directives, Standards, and Guidance Documents

Directives Mandatory
93/42/EEC
(MDD)
90/385/EEC
(AIMDD)
98/79/EC
(IVDD)

Harmonized
Standards*
EN
EN
EN
EN
EN

ISO 14971
ISO 13485
62304
60601-1
62366

Nonharmonized
Standards**

Guidance
Documents***

ISO/IEC 12207

MEDDEV 2.1/6
IEC/TR 80002-1
NB-MED/
2.2/Rec4

* Harmonized standards provide a presumption of conformity with the essential


requirements of the directives.
** Use of non-harmonized standards can help provide compliance with directives.
*** Guidance documents are agreed upon (by Competent Authorities, Notified
Bodies, Industry, etc.) directive interpretations and if followed, ensure uniform
application of relevant directive provisions Legally not binding

Copyright 2015 BSI. All rights reserved.

Definition of Active Medical Device

Active Medical Device - Any medical device relying for its

functioning on a source of electrical energy or any source of


power other than that directly generated by the human body or
gravity.

Note: Medical Device Directive states that a medical


device can be software.

Copyright 2015 BSI. All rights reserved.

26/11/2015

MDD 93/42/EEC M5 (2007/47) Changes

1. Article 1: Change of Definition of Medical device 2.

3.

medical device means any instrument, apparatus,


appliance, software, material or other article
New sub-clause ER 12.1a: For devices which incorporate
software or which are medical software in themselves,
the software must be validated according to the state of
the art taking into account the principles of development
lifecycle, risk management, validation and verification.
Annex IX Active Medical Device definition in the
classification criteria added Stand alone software is
considered to be an active medical device.

Copyright 2015 BSI. All rights reserved.

Definition of Accessory

Accessory - An article which whilst not being a device is

intended specifically by its manufacturer to be used


together with a device to enable it to be used in accordance
with the use of the device intended by the manufacturer of
the device.

Copyright 2015 BSI. All rights reserved.

26/11/2015

CE Mark Process

Conform with
Directives

Issue a Declaration
of Conformity
(DoC)

Place a CE Mark on
the Product

Determine
classification of the
device
MDD 4 classes
AIMDD 1 Class
IVDD 4 Classes

Conformity
Assessment
Procedures (CAP)
available are
based on
Classification

Use 1 or a
combination of 2
Annexes to form
the CAP route for
MDD and AIMDD

A notified body does not issue a CE Mark; they assess and


issue certificates for the annexes the manufacturer uses.
It is the manufacturers responsibility to draw up and sign
the DoC and place the CE Mark on the product. That
signifies the manufacturer claims the product conforms
with the provisions of the directive which applies to them.

Copyright 2015 BSI. All rights reserved.

Medical Device Classification


Directive

Classification

Accessory

AIMD Directive All AIMDs are one classification


(considered high risk)

All AIMD accessories are


given same high risk
classification

MD Directive

Rule-based

Accessories are classified


in their own right

IVD Directive

List, not rule-based


(List A - high
-orList B - moderate risk devices)

Accessories are classified


in their own right

* If SW is embedded in a medical device, it takes on the


classification of the medical device *
Copyright 2015 BSI. All rights reserved.

European Harmonized Standards (for MDD)


Standard

Topic

EN 62304:2006 /
AC:2008

Medical device SW SW lifecycle processes

EN ISO 13485:2012/
AC:2012

Medical devices - Quality management systems


Requirements for regulatory purposes

EN ISO 14971:2012

Medical devices Application of risk management to


medical devices (Note: Normative reference in EN
62304)

EN 60601-1:2006/
AC:2010 or

Medical electrical equipment General requirements for


basic safety and essential performance Section 14:
Programmable electrical medical systems (PEMS) (Note:
Not harmonized to IVD Directive)

EN 60601-1:2006/
A1:2013
EN 62366:2008

Copyright 2015 BSI. All rights reserved.

Application of usability engineering to medical devices

International Guidance
Guidance

Topic

MEDDEV 2.1/6 (2012)

Guidelines for the qualification and


classification of standalone SW used
within healthcare within the regulatory
framework of medical devices

IEC/TR 80002-1:2009

Medical device SW - Part 1: Guidance on


the application of ISO 14971 to medical
device SW

NB-MED/2.2/Rec4

SW and Medical Devices (2001)

NB-MED EN 62304:2006 Frequently Asked Questions


(2013)

Frequently Asked Questions related to


the Implementation of EN 62304:2006
with respect to MDD 93/42/EEC

Copyright 2015 BSI. All rights reserved.

10

MEDDEV 2.1/6

Scope is stand alone software (no embedded

software)
Defines criteria for software being a stand alone
medical device (qualification criteria)
Potential risk arising from the use of stand alone
software is not enough to qualify the software as a
medical device
Explains application of classification rules for stand
alone software

Copyright 2015 BSI. All rights reserved.

26/11/2015

11

Software is a Medical Device if...

(A) Software is a computer program

(B) Software is not incorporated in a medical device

(C) Software action is more than basic data processing

(D) Software has benefit for individuals


(E) Intended purpose is acc. to medical directives or SW
is an accessory acc. to medical directives definition

Copyright 2015 BSI. All rights reserved.

26/11/2015

Software falls
under medical
directive
regulations

12

MEDDEV 2.1/6: Criterion (A) Software is a Computer


Program
Not a medical device:

DICOM files
ECG recordings
Data in electronic patient record

Copyright 2015 BSI. All rights reserved.

13

MEDDEV 2.1/6: Criterion (B) Software is not Part of a


Medical Device
Software as integral part of a
medical device
Not a device on its own

Copyright 2015 BSI. All rights reserved.

Software program used with


general purpose hardware

14

MEDDEV 2.1/6: Criterion (C) Software Action More Than


Basic Data Processing

"more than
Storing, archiving,
lossless compression

Copyright 2015 BSI. All rights reserved.

15

Criterion (C) Software Performance More Than Basic


Data Processing
"more than
Data transfer (communication)

Location A

Location B

Presentation of information for embellishment purposes


After

Before

Copyright 2015 BSI. All rights reserved.

16

Criterion (C) Software Performance More Than Basic


Data Processing
"more than
Performing simple search
Examples of simple search :
Searching for blood glucose values
measured within January 2015
Number of digital X-ray images taken within March 2015

Copyright 2015 BSI. All rights reserved.

17

MEDDEV 2.1/6: Criterion (D) Benefit for Individuals


Patient Benefit

Not a medical device:

Software which processes

population data for scientific


purposes
Digitized medical literature

Anonymized Test Population


Copyright 2015 BSI. All rights reserved.

18

MEDDEV 2.1/6: Criterion (E) Purpose of the Software is


Medical
Medical intended purpose according to 93/42/EEC

MEDDEV 2.1/6: If the manufacturer specifically intends the software to be


used for any of the purposes listed in Article 1(2)a of Directive 93/42/EEC,
then the software shall be qualified as a medical device.
We have learned:
Software is a medical device if:

Intended use is medical

Software is not a medical device if:

only basic data processing is performed

Copyright 2015 BSI. All rights reserved.

19

Certification of Stand Alone Software (Annex IX 93/42/EEC)


Definition: Stand alone software is an active device

Non
invasive
devices

Invasive
devices

Additional rules applicable to active devices

Special
rules

Rules 1
to 4

Rules 5
to 8

Rule 9

Rules 13
to 18

Rule 10

Rule 11

Rule 12

Applicable active device rules


Copyright 2015 BSI. All rights reserved.

20

Classification of Stand Alone Software (Annex IX 93/42/EEC)


Rule #

Summary

Classification

All active therapeutic devices


intended to administer or exchange
energy

Class IIa unless


potentially hazardous
way then Class IIb

10

Active devices intended for


diagnosis

Class IIa or Class IIb


(e.g. ionizing radiation)

11

Active devices to administer or


remove medicines, body liquids, or
other substances

Class IIa unless


potentially hazardous
way then Class IIb

12

All other Active Devices (fall


through rule)

Class I

* Annex IX, 2.3: SW which drives a device or influences the use of a


device, falls automatically in the same device class *

Copyright 2015 BSI. All rights reserved.

21

EN 62304
Software can contribute to hazards
62304 expects you to risk classify software as A, B, or C based on

possible effects on the patient, operator, or other people. The higher


the class, the more requirements need to meet in 62304.

SW - safety class A
No INJURY or damage to health is possible

SW - safety class B
Non-SERIOUS INJURY is possible

SW - safety class C
Death or SERIOUS INJURY is possible

Copyright 2015 BSI. All rights reserved.

26/11/2015

22

EN 62304
Shock
Patient

Must consider hazards that could

be indirectly caused by software


Framework of lifecycle processes:
Software Development Process
Software Maintenance Process
Software Risk Management Process
Software Configuration Management Process
Software Problem Resolution Process
Does not prescribe a specific lifecycle model

Copyright 2015 BSI. All rights reserved.

26/11/2015

23

Safety Classification of Software Components

Documented rationale that


segregation is effective is
required

A
C
Software
component X

Softwarecomponent W
C

Software system
Software
component Y

B
Softwarecomponent Z

Documented rationale that


segregation is effective is
required

Copyright 2015 BSI. All rights reserved.

24

Reducing the Software Safety Classification

Documented rationale that


segregation is effective is
required

B
software
component Y

software
component X

software system
C
software
component Y

Copyright 2015 BSI. All rights reserved.

Hardware risk control


measure

25

Reducing the SW Safety Classification Acc. To EN 62304


Reduction not possible from

C (initial) to A (final)
Reduction only B A or C B
Reduction only if hardware mitigation
measures are implemented
User is not (explicitly) defined as
hardware mitigation
Reduction not possible if software
controls software (e.g. C software component is controlled by another C
software component as mitigation)
The probability of a failure of software system to behave as specified
that can cause a hazard shall be assumed to be 100 percent when
assigning safety classification.

Copyright 2015 BSI. All rights reserved.

26

IEC 62304 Amd. 1:2015

Two of the main amendments/clarifications are:


Making it clear how to apply IEC 62304 to legacy software
(not developed in compliance with IEC 62304).
Alternative methods that may apply.
Consideration of factors external to the software is
allowed to reduce the risk (including probability) of harm
and could lower the safety classification.
2006 version used to state only hardware risk control measures
Now allowed to reduce safety classification from C all the way down
to A unlike 2006 version.

Copyright 2015 BSI. All rights reserved.

26/11/2015

27