BSI Md Software Regulated

7/23/2019 BSI Md Software Regulated

http://slidepdf.com/reader/full/bsi-md-software-regulated 1/28

Copyright © 2015 BSI. All rights reserved.

Medical Device Software – Do YouUnderstand How Software is Regulated?

By Gregory Martin



2 Copyright © 2015 BSI. All rights reserved.

Agenda

• Relevant directives, standards, and guidance documentsrecommended to develop, maintain, and validate medicalsoftware according to the state of the art.

• Determine if software is covered by an EU medical directivefor 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.

26/11/2015




Directives, Standards, and Guidance Documents

* Harmonized standards provide a presumption of conformity with the essentialrequirements 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 uniformapplication of relevant directive provisions → Legally not binding

Directives -Mandatory

HarmonizedStandards*

Non-harmonizedStandards**

GuidanceDocuments***

• 93/42/EEC(MDD)

• 90/385/EEC

(AIMDD)• 98/79/EC

(IVDD)

• EN ISO 14971

• EN ISO 13485

• EN 62304

• EN 60601-1• EN 62366

• ISO/IEC 12207 • MEDDEV 2.1/6

• IEC/TR 80002-1

• NB-MED/

2.2/Rec4




Definition of Active Medical Device

• Active Medical Device - Any medical device relying for itsfunctioning on a source of electrical energy or any source ofpower other than that directly generated by the human body orgravity.

• Note: Medical Device Directive states that a ‘medicaldevice’ can be software.

26/11/2015




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

1. Article 1: Change of Definition of Medical device - ‘medical device’ means any instrument, apparatus,appliance, software, material or other article…

2. 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 ofthe art taking into account the principles of developmentlifecycle, risk management, validation and verification.”

3. Annex IX – Active Medical Device definition in theclassification criteria added – “Stand alone software isconsidered to be an active medical device.”




Definition of Accessory

• Accessory - An article which whilst not being a device isintended specifically by its manufacturer to be usedtogether with a device to enable it to be used in accordancewith the use of the device intended by the manufacturer of

the device.

26/11/2015




CE Mark Process

Conform withDirectives

Issue a Declarationof Conformity(DoC)

Place a CE Mark onthe Product

Determineclassification of thedeviceMDD – 4 classes

AIMDD – 1 ClassIVDD – 4 Classes

Conformity AssessmentProcedures (CAP)available arebased onClassification

Use 1 or acombination of 2

Annexes to formthe CAP route forMDD and AIMDD

A notified body does not issue a CE Mark; they assess andissue certificates for the annexes the manufacturer uses.

It is the manufacturer’s responsibility to draw up and signthe DoC and place the CE Mark on the product. Thatsignifies the manufacturer claims the product conformswith the provisions of the directive which applies to them.




Medical Device Classification

Directive Classification Accessory

AIMD Directive All AIMDs are one classification(considered high risk)

All AIMD accessories aregiven same high riskclassification

MD Directive Rule-based Accessories are classifiedin their own right

IVD Directive List, not rule-based(List A - high-or-

List B - moderate risk devices)

Accessories are classifiedin their own right

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




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 tomedical devices (Note: Normative reference in EN62304)

EN 60601-1:2006/ AC:2010 or

EN 60601-1:2006/ A1:2013

Medical electrical equipment – General requirements forbasic safety and essential performance – Section 14:Programmable electrical medical systems (PEMS) (Note:

Not harmonized to IVD Directive)

EN 62366:2008 Application of usability engineering to medical devices




International Guidance

Guidance Topic

MEDDEV 2.1/6 (2012) Guidelines for the qualification andclassification of standalone SW usedwithin healthcare within the regulatoryframework of medical devices

IEC/TR 80002-1:2009 Medical device SW - Part 1: Guidance onthe application of ISO 14971 to medicaldevice SW

NB-MED/2.2/Rec4 SW and Medical Devices (2001)

NB-MED EN 62304:2006 -Frequently Asked Questions(2013)

Frequently Asked Questions related tothe Implementation of EN 62304:2006with respect to MDD 93/42/EEC




MEDDEV 2.1/6

• Scope is stand alone software (no embeddedsoftware)

• Defines criteria for software being a stand alonemedical device (qualification criteria)

• Potential risk arising from the use of stand alonesoftware is not enough to qualify the software as amedical device

• Explains application of classification rules for standalone software

26/11/2015




Software is a Medical Device if...

26/11/2015

(A) Software is a computer program

(B) Software is not incorporated in a medical device

(D) Software has benefit for individuals

Software fallsunder medicaldirectiveregulations

(E) Intended purpose is acc. to medical directives or SWis an accessory acc. to medical directive‘s definition

(C) Software “action” is more than “basic data processing”




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

Not a medical device:

• DICOM files

• ECG recordings

•Data in electronic patient record




MEDDEV 2.1/6: Criterion (B) – Software is not Part of aMedical Device

Software as integral part of amedical device

→ Not a device on its own

Software program used withgeneral purpose hardware




MEDDEV 2.1/6: Criterion (C) – Software “Action” More ThanBasic Data Processing

"more than”…

•Storing, archiving,lossless compression




Criterion (C) – Software “Performance” More Than BasicData Processing

"more than” …• Data transfer (communication)

• Presentation of information for “embellishment purposes”

Location A Location B

Before After




Criterion (C) – Software “Performance” More Than BasicData Processing

"more than” …

• Performing “simple search”

Examples of “simple search” :• Searching for blood glucose valuesmeasured within January 2015

• Number of digital X-ray images taken within March 2015




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

• Software which processespopulation data for scientificpurposes

• Digitized medical literature

Anonymized Test Population

Patient Benefit Not a medical device:




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

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




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

•Definition: Stand alone software is an active device

Applicable active device rules

Noninvasive

devices

Rules 1

to 4

Invasive

devices

Rules 5

to 8

Additional rules applicable to active devices

Rule 9 Rule 10 Rule 11 Rule 12

Special

rules

Rules 13to 18




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

Rule # Summary Classification9 All active therapeutic devices

intended to administer or exchangeenergy

Class IIa unlesspotentially hazardousway 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, orother substances

Class IIa unlesspotentially hazardousway 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 adevice, falls automatically in the same device class *




EN 62304

• Software can contribute to hazards

• 62304 expects you to risk classify software as A, B, or C based onpossible effects on the patient, operator, or other people. The higherthe class, the more requirements need to meet in 62304.

26/11/2015

SW - safety class ANo INJURY or damage to health is possible

SW - safety class BNon-SERIOUS INJURY is possible

SW - safety class CDeath or SERIOUS INJURY is possible




EN 62304

•Must consider hazards that couldbe 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

26/11/2015

ShockPatient




Safety Classification of Software Components

Software system

C

Softwarecomponent X

Softwarecomponent Y

Software-component Z

Software-component W

A

C

B

C

Documented rationale thatsegregation is effective isrequired





Reducing the Software Safety Classification

software system

C softwarecomponent X

softwarecomponent Y

software

component Y

A

C

B


Hardware risk controlmeasure




•

Reduction not possible fromC (initial) to A (final)

• Reduction only B A or C B

• Reduction only if hardware mitigationmeasures are implemented

• User is not (explicitly) defined ashardware mitigation

• Reduction not possible if softwarecontrols software (e.g. C software component is controlled by another Csoftware component as mitigation)

• The probability of a failure of software system to behave as specifiedthat can cause a hazard shall be assumed to be 100 percent whenassigning safety classification.

Reducing the SW Safety Classification Acc. To EN 62304




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 isallowed to reduce the risk (including probability) of harmand 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 downto A unlike 2006 version.

26/11/2015



Date post:	17-Feb-2018
Category:	Documents
Upload:	luis-garcia
View:	220 times
Download:	0 times