CE Certification of Medical Software in UK

Medical Software – An Overview

The MDCG defines software as a medical device as a collection of instructions that processes input data (data given by a human data-input device) and produces output data (data created by software) and is thus considered an active device under the MDR and IVDR standards.

Medical device software (MDSW) is designed to control or affect (hardware) medical equipment usage, either alone or in combination, for a specific purpose as defined in the guideline document.

Medical Software meets the requirements of EU Article 2 (1) of Regulation (EU) 2017/745 – MDR should be considered Medical Software (MD MDSW). The following considerations should be applied to software that provides information on:

(a) illness detection, prevention, monitoring, prediction, prognosis, therapy, or relief
(b) an injury or disability’s diagnosis, monitoring, treatment, alleviation, or recompense,
(c) anatomical or physiological or pathological process or state study, replacement, or alteration
(d) conception control or encouragement;
(e) goods designed particularly for the cleaning, disinfection, or sterilization of devices, as defined in Article 1(4), and Annex XVI products

REQUEST FOR PROPOSAL - FILL THE FORM

IVD medical software that delivers information under Article 2(2) (a) to (f) of Regulation (EU) 2017/746 – IVDR should be considered In Vitro Diagnostic Medical Device Software.

(a) illness detection, prevention, monitoring, prediction, prognosis, therapy, or relief
(b) an injury or disability’s diagnosis, monitoring, treatment, alleviation, or compensation,
(c) anatomical or physiological or pathological process or state study, replacement, or alteration
(d) conception control or encouragement;

Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR >> MDCG 2019-11 Guidance Document

CE Certification of Medical Software in UK

What you mean by Software as a Medical Device?

Medical software is sometimes referred to as a medical device or an in vitro diagnostic device. An instruction set that analyses input data and generates output data is called “software”.

Input data is any information supplied to software to receive output data after being computed. Examples of input data (not exhaustive):

Information entered via a human data entry device such as a keyboard, mouse, pen, or touch screen;
Information gleaned through voice recognition;
Digital document: prepared for general use (Word, pdf, or jpeg picture), formatted for medical use (DICOM, ECG records, or Electronic Health Record). It’s important to distinguish between digital documents and software that can read them.
Data received from/transmitted by devices.

Is your software a Medical Device? Should we apply for CE Certification according to (EU) 2017/745 or (EU) 2017/746? Check the Software Classification

What Is Artificial Intelligence and Machine Learning?

Artificial Intelligence

Artificial Intelligence is a technology to simulate human behaviour. The goal is to create an intelligent system to solve complex problems. Machine Learning and Deep Learning are the two subsets of AI. AI works on Structured, Semi-structured and Unstructured Data. AI has a wide range of scope. However, AI is mainly focused on maximizing the chances of success.

AI includes Learning, reasoning and self-correction. AI is divided into Weak AI, General AI, and Strong AI based on capabilities. The main applications of AI are Siri, Expert Systems, Online playing games, Intelligent Humanoid robots, Customer support using catboats, Natural Language Processing etc.

Artificial Intelligence deals with Structured, Semi-Structured and Unstructured data.

Machine Learning

Machine Learning is the subset of AI that allows machines to automatically learn from past data without programming. The goal is to allow machines to learn from data to achieve accuracy.

Deep Learning is the subset of Machine Learning. Machine Learning (ML) has limited scope. ML works to create a machine to perform only the tasks for which it has been trained. ML is mainly concerned with accuracy and patterns.

ML includes Learning and self-correction when fed with new data. ML is divided into Supervised Learning, Unsupervised Learning, Reinforcement Learning. The main application of ML is Facebook auto friend tagging suggestions, online recommender system, Google search algorithms etc.

Machine Learning deals with Structured and Semi-Structured Data.

When a 510(k) required for a Medical Software?

For New Software Device entering in to market

Step 1 : Medical Device Rationale for the software analyzed
Step 2 : Product Code and Regulation number has been identified
Step 3 : Classification identification
Step 4 : When the device do not require a Pre-Market Approval (PMA) and the predicate device is identified.

For a Software device already entered into the market and New 510(k) required as a result of change

According to the guidance, manufacturers are required to submit a new 510(k) when a change (or changes) exceed the 21 CFR 807.81(a)(3) threshold.

e.g., it “could significantly affect the safety or effectiveness of the device,” or constitutes a “major change or modification in the intended use of the device.”

How IEC 62304 Is Related To ISO 13485?

ISO 13485 is the standard that defines the requirement for the establishment of a Quality Management System in the Medical Device Industry.
IEC 62304 is the standard that defines the requirements for the medical device software development life cycle.
ISO 62304 is related to ISO 13485 in various phases of the software development life cycle, as discussed below.

	ISO 62304 : 2006 Clause & Procedure	ISO 13485 : 2016 Clause & Procedure
1.	5.1 Software Development Planning	7.3.2 Design and Development Planning
2.	5.2 Software Requirement Analysis	7.3.3 Design and Development Inputs
3.	5.3 Software Architectural Design
4.	5.4 Software Detailed Design
5.	5.5 Software Unit Implementation and Verification
6.	5.6 Software Integration and Integration Testing	7.3.6 Design and Development Verification
7.	5.7 Software System Testing	7.3.7 Design and Development Validation
8.	5.8 Software Release	7.3.8 Design and Development Transfer
9.	6.1 Establish Software Maintenance Plan	7.3.9 Control of Design and Development Changes.
10.	6.2.1 Document and Evaluate Feedback	8.2.1 Feedback
11.	6.2.2 Use Software Problem resolution process	8.2.2 Complaint Handling
12.	6.2.3 Analyse Change Request
13.	6.2.4 Change Request Approval
14.	6.2.5 Communicate to users and Regulators	8.2.3 Reporting to regulatory authorities
15.	6.3 Modification Implementation	8.3.4 Rework
16.	7. Software Risk Management Process	Risk Management Process
17.	8.1 Software Configuration Identification	7.5.8 Identification & 7.5.9 Traceability
18.	9. Software Problem Resolution Process	8.5.2 Corrective Action & 8.5.3 Preventive Action

IEC 62304 Software Classification and Documentation

Software Documentation	Class A (Low Risk)	Class B (Medium Risk)				Class C (High Risk)
Risk Classification or Safety Classification	A statement indicating the software safety classification and the Description of MD or IVD rationale and risk classification. It also means that the software meets all customer requirements, regulatory requirements, and Quality Management System needs.
Software Description	A summary of software and its overview, Software Operating Environment.
Risk Analysis	Tabular Description of the hardware and software hazard, its severity assessment and its mitigation types.
Software Requirement Specification (SRS)	Summary of all the requirements	The complete SRS documents.
Design Architecture	No documents needed on Architectural Design	Architecture Design on Software, Interface, Include Functional & Performance requirements, System Hardware & Software Requirements of SOUP items.			Along with Class B documents, segregation b/w s/w items for Risk controls to be maintained.
Software Design Specification (SDS)	No documents needed on Detailed Design	Architecture refined to Software Units documents is needed.			With Class B documents, the Detailed design of Software Units and interfaces should be documented and verified.
Software Development	Summary of Software Development Life cycle plan, with an overview on Risk Management Plan, Configuration Management, Maintenance activities.	Along with Class A documents, Controls and the control documents over supporting items and Configuration items should be documented.			Along with Class B documents, Standards, Methods and Tools associated with the development of the software shall be documented.
Verification and Validation Documentation	Software Functional Test Plan, Acceptance criteria, Results.	Describe V&V activities at the Unit, Integration and System level. Verify Unit, Integration and System Tests by evaluating with established strategies, methods and procedures. Acceptance Criteria and Document or record Test Result.			Describe V&V activities at the Unit, Integration and System level. Verify Unit, Integration and System Tests by evaluating with established strategies, methods and procedures. Acceptance Criteria and Document or record Test Result.
Traceability Analysis	Traceability among Requirements, Specifications, Identified Hazards and Mitigation, Verification and Validation Testing.
Revision History	Revision History log, including release version number and date.
Bugs or Defects (Unresolved Anomalies)	No documents required		List of remaining unresolved anomalies, annotated with an explanation of the impact on safety and effectiveness, including operator usage and human factors.
Problem and Modification Analysis	Summary of Maintenance Plan & Protocol, Change Request, Problem Resolution Procedure including Feedback and Problem Evaluation Procedure.
Risk Management	Change request and Problem Report analysis for additional potential cause for the hazardous situation and Additional Risk control measures for a safety check.			Summary on Risk Management Plan, Risk Analysis Protocol and Reports, Implementation and verification of Risk Control measure protocol and its documents (including SOUP), including Risk Management in effect to changes with software
Configuration Management	The Description of Configuration Management Plan and Procedure (including SOUP). History of Configuration items that are retrievable (including system configuration)
Problem Resolution Process	Procedure for Problem Resolution, Trend Chart, Problem Report, Analysis, Evaluation and Verification with test document.

Medical Software and CE Certification

Latest 62304 Standard accepted by FDA and EU.

Latest version accepted by EU and US FDA - IEC 62304: 2006 / AMD 1:2015 Published Date: 06-2015
Will be replaced by IEC/DIS 62304.3 which is under development.

Medical Software Classification

As per IEC 62304: 2006 standard Software safety classes are assigned based on severity, resulting from a Hazard on the patient, operator or other people.
The Software Safety classes are assigned 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.

Definition of Medical Software as per MDR 2017/745

As per EU MDR 2017/745, Article 2, Software which is intended specifically for any of the medical purposes like
• diagnosis,
• prevention,
• monitoring,
• treatment or alleviation of disease,
• prediction,
• prognosis,
• investigation
• and provide information are considered as Medical Device.

This software could be
I. incorporated or integrated into any Medical Device (Software in a Medical Device)
II. designed to manufacture or maintain a Medical Device (Software in a Medical Device)
III. used as a Medical Device (Software as a Medical Device)

Definition of Medical Software as per (IMDRF/SaMD WG/N10FINAL:2013)

a device is “ an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or another similar or related article, including a component part, or accessory which is :
1. recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them,
2. intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or
3. intended to affect the structure or any function of the body of man or animal or which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and
which is not dependent upon being metabolized for the achievement of its primary intended purposes.

The term “device” does not include software functions excluded pursuant to section 520(o).

As referred by US FDA, IMDRF (IMDRF/SaMD WG/N10FINAL:2013) defines the Software as a Medical Device as “Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Purposes :
• SaMD is a medical device and includes an 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 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 and general-purpose Software.
• Mobile apps that meet the definition the above are considered SaMD.

REQUEST FOR PROPOSAL - FILL THE FORM