CE Certification of Medical Software

Medical Software – An Overview

Software is defined by the MDCG as a set of instructions that processes input data (data provided by a human data-input device) and creates output data (data generated by software), making it an active device under the MDR and IVDR standards.

Medical device software (MDSW) is software that is meant to regulate or influence the use of medical equipment (hardware) for a specific purpose as stated in the guideline document, either alone or in combination.

Medical Software: MDSW that complies with EU Article 2 (1) of Regulation (EU) 2017/745 – MDR is deemed Medical Device Software (MD MDSW). The following points should be taken into account when developing software that delivers data 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

In Vitro Diagnostic Medical Device Software (IVD MDSW) that gives information in line with Article 2(2) (a) to (f) of Regulation (EU) 2017/746 – IVDR should be evaluated.

  • (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;

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

A medical device or an in vitro diagnostic device are terms used to describe medical software. The term "software" refers to a collection of instructions that analyses input data and creates output data.

Data Input

Any information sent to software in order to get output data after it has been computed is referred to as input data. Input data examples (not exhaustive):

  • Information input via a keyboard, mouse, pen, or touch screen as a human data entry device;
  • Information acquired through speech recognition
  • Digital document: structured for medical use (Word, pdf, or jpeg image) and prepared for general use (Word, pdf, or jpeg picture) (DICOM, ECG records, or Electronic Health Record). It's critical to distinguish between digital documents and document-reading software.
  • Device data is received and sent.

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

AI stands for Artificial Intelligence.


Artificial intelligence (AI) is a technology that can mimic human behaviour. The objective is to develop an intelligent system that can tackle difficult issues. AI is divided into two subsets: machine learning and deep learning. Structured, semi-structured, and unstructured data are all used by AI. AI offers a wide variety of applications. AI is primarily concerned with increasing the likelihood of success.

Learning, reasoning, and self-correction are all aspects of AI. Weak AI, General AI, and Strong AI are the three types of AI based on their capabilities. Siri, Expert Systems, Online Playing Games, Intelligent Humanoid Robots, Customer Support through Catboats, Natural Language Processing, and other AI applications are among of the most common.


Structured, semi-structured, and unstructured data are all dealt with by Artificial Intelligence.


Machine Learning


Machine Learning is a branch of AI that allows machines to learn from prior data without having to train them directly. The objective is for the machine to be able to learn from data in order to attain accuracy.

Machine Learning is a subset of Deep Learning. The scope of machine learning (ML) is limited. Machine learning aims to construct a machine that only performs the tasks for which it has been educated. The fundamental concerns of machine learning are accuracy and patterns.

When supplied with new data, ML incorporates learning and self-correction. Supervised Learning, Unsupervised Learning, and Reinforcement Learning are the three types of machine learning. Facebook auto friend tagging recommendations, online recommender systems, and Google search algorithms are some of the most common uses of machine learning.

Machine Learning deals with Structured and Semi-Structured data.

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.”

  • 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 & ProcedureISO 13485 : 2016 Clause & Procedure
1.5.1 Software Development Planning7.3.2 Design and Development Planning
2.5.2 Software Requirement Analysis7.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 Testing7.3.6 Design and Development Verification
7.5.7 Software System Testing7.3.7 Design and Development Validation
8.5.8 Software Release7.3.8 Design and Development Transfer
9.6.1 Establish Software Maintenance Plan7.3.9 Control of Design and Development Changes. Document and Evaluate Feedback8.2.1 Feedback Use Software Problem resolution process8.2.2 Complaint Handling Analyse Change Request Change Request Approval Communicate to users and Regulators8.2.3 Reporting to regulatory authorities
15.6.3 Modification Implementation8.3.4 Rework
16.7. Software Risk Management ProcessRisk Management Process
17.8.1 Software Configuration Identification7.5.8 Identification &


7.5.9 Traceability

18.9.Software Problem Resolution Process8.5.2 Corrective Action &


8.5.3 Preventive Action

Software DocumentationClass A (Low Risk)Class B (Medium Risk)Class C (High Risk)
Risk Classification or Safety ClassificationA statement indicating the software safety classification and the description of MD or IVD rationale and its risk classification. Also indicating that the software meets all customer requirements, regulatory requirements and Quality Management System needs.
Software DescriptionA summary of software and its overview, Software Operating Environment.
Risk AnalysisTabular Description of the hardware and software hazard, its severity assessment and its mitigation types.
Software Requirement Specification (SRS)Summary on all the requirementsThe complete SRS documents.
Design  ArchitectureNo documents needed on Architectural DesignArchitecture Design on Software, Interface, Include Functional & Performance requirements, System Hardware & Software Requirements of SOUP itemsAlong 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 DesignArchitecture refined to Software Units documents are needed.With Class B documents, Detailed design of Software Units and interfaces should be documented and verified. 
Software DevelopmentSummary of Software Development Life cycle plan, with summary 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 in the development of the software shall be documented. 
Verification and Validation DocumentationSoftware Functional Test Plan,  Acceptance criteria, Results.Describe V&V activities at 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 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 AnalysisTracebility among Requirements, Specifications, Identified Harzards and Mitigation, Verification and Validation Testing. 
Revision HistoryRevision History log, including release version number and date. 
Bugs or Defects (Unresolved Anamolies)No documents requiredList of remaining unresolved anamolies, annotated with explanation of the impact on safety and effectiveness, including operator usage and human factors. 
Problem and Modification AnalysisSummary of Maintenance Plan & Protocol, Change Request, Problem Resolution Procedure including Feedback and Problem Evaluation Procedure. 
Risk ManagementChange request and Problem Report analysis for additional potential cause for hazardous situation and Additional Risk control measure for 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 ManagementDescription on Configuration Management Plan and Procdure (including SOUP). History of Configuration items that are retrievable (including system configuration) 
Problem Resolution ProcessProcedure for Problem Resolution, Trend Chart, Problem Report, Analysis, Evaluation and Verification with test document. 

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.


As per IEC 62304 : 2006 standard Software safety classes are assigned based on severity, resulting from an Hazard on 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.


As per EU MDR 2017/745, Article 2, Software which is intended specifically for any of the medical purpose 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)


a device is “ an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other 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 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, as well as general purpose software.
• Mobile apps that meet the definition of above are considered as SaMD.


Office 54, No:58, Peregrine Road, Hainault, Ilford, Essex, England. IG6 3SZ

Call Us

+44 75 8147 1399

Email Us