Medical Software CE Marking

Software CE Marking  – Medical Software means software or system used in medical settings that collect data on patients’ health and helps healthcare providers in their medical practices. Software used in the medical environment plays a vital role in diagnosing, treating, and testing various medical conditions. The software can be fitted into a device to enhance its functioning or drive it to perform its function accurately. However, there is another category of medical software called “Software as a medical device (SaMD)”.

SaMD is software that performs one or more medical functions without interfacing with other medical devices and works as standalone software. These are the medical software to be used for medical purposes without being integrated into an actual device. Hence, it is clear that SaMD is not software that supports the functioning of medical device hardware.

A few examples are listed below to make a clear understanding of SaMD:

  • Software to determine a fixed drug dose for a patient based on personalized patient data.
  • Software that can analyze medical reports to diagnose a specific medical condition. e.g., diagnosing a stroke by analyzing MRI images.
  • Software that can detect cancer through image processing. e.g., tracking a mole’s size and determining the risk for melanoma.
  • Software that uses data from other digital devices and determines risk factors associated with epileptic seizures.
  • A Software application that calculates insulin dosage based on the glucose level.
  • A Software that calculates breathing rate during sleep with the help of a smartphone.

A Medical Device Software is defined as a “SOFTWARE SYSTEM that has been developed to be incorporated into the MEDICAL DEVICE being developed, or that is intended for use as a MEDICAL DEVICE in its own right” according to clause 3.12 of IEC 62304:2015. Organizations must establish documented procedures for the validation of computer software used in production, according to ISO 13485.

Before initial use, MUST must confirm the intended application of computer software in monitoring and measuring devices. IEC 62304:2015 or ISO 62304 is the new Medical Device software validation method (life cycle process model) developed. The new standard addresses software development and maintenance, ISO 14971 risk management, software partitioning, safety classification, and software process management.

Stricter rules under new MDR for SaMD

Mobile apps that monitor health conditions such as diabetes, heart disease, depression, etc., are increasing. Worldwide manufacturers of such digital health equipment must carefully consider the new rules and regulatory requirements set forth within the Medical Devices Regulation (MDR), adopted by the European Parliament and Council in May 2017.

With a mandatory compliance date of 26 May 2020, the new EU MDR replaces the former Medical Device Directive (MDD) and introduces new concepts, definitions, classification rules, and procedural requirements for medical device software. Many digital health care products will now fall into the scope of the new European MDR. Manufacturers of digital products must carefully examine new MDR requirements for CE Marking before any commercial distribution to determine where they fall into the following definition of a ‘medical device’ under the new MDR.

Article (1) states that general-purpose software without a medical purpose and fitness and wellness apps are regulated as medical devices. In addition, all software developers must consider the implications of the General Data Protection Regulation (GDPR), which will apply in the EU from 25 May 2018 and replace the current EU Data Protection Directive. The GDPR will introduce new EU data protection requirements with increasing responsibility and liability of entities processing personal health data collected via software of individuals in the EU.

Software CE Marking – Role of Consultants

Medical Software developers for digital health applications must carefully examine new MDR requirements before commercial distribution to determine where their software falls into the definition of ‘medical device’ within the new EU regulation. This is critical to be meet the mandatory compliance date of 26 May 2020 for software products.

I3CGlobal Regulatory Experts welcome the opportunity to discuss the EU’s MDR’s potential impact on your medical device digital software technology, and more importantly, the steps your organization can take to streamline preparedness activities.

Standalone software shall be classed as an AIMD/ IVD or an accessory to an AIMD/ IVD provided that it meets the definition contained in the relevant Directive.

Software Classification

The manufacturer must assign a software safety class (A, B, or C) to each software system based on the potential effects on the patient, operator, or other people due to a hazard to which the software system can contribute.

The software CE Marking is determined by the type and risk class of the software in question. The software safety classes will be assigned in the following order based on severity:

  • 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

The software must be classified in accordance with the Medical Device Regulations. If medical software is used in conjunction with other medical equipment, can easily determine the class can choose the category if it is used as a stand-alone piece of equipment based on the risk analysis and indented application.

Integrating ISO 13485 with ISO 62304

Below is the list of ISO 13485 mandatory procedures and explains how it is to be integrated with ISO 62304

Sl.No

Cl. 13485

Title of the Procedure

Cl. 62304

Title of the Procedure

01

4.1.5

Outsourced Process

02

4.1.6

Validation of the application of software used in QMS

03

4.2.4

Control of Documents

04

4.2.5

Control of Records

05

5.6

Management Review

06

6.2

Human Resources

07

6.3

Infrastructure

08

6.3

Maintenance Activities

09

6.4.1

Control of  Work Environment

10

6.4.1 a

Health, Cleanliness, and Clothing

11

6.4.2

Control of Contaminated or Potentially Contaminated Product

12

6.4.2

Contamination Control for Sterile Medical Devices

13

7.1

Risk Management

7

Software Risk management process

14

7.3

Design and Development

5.1

Software Development Planning

5.2

Software requirements analysis

5.3

Software architectural design

5.4

Software detailed design

5.5

Software unit implementation and verification

5.6

Software integration and integration testing

6

Software maintenance process

6.3

Modification implementation

15

7.3.7

Clinical Evaluation

16

7.3.8

Design & Development Transfer

5.8

Software Release

17

7.3.9

Design & Development Changes

6.2.3
6.2.4
6.2.5

Analyze change requests
Change request approval
Communicate to users and regulators

5.7.1

Establish tests for software requirements

5.7.3

Retest after changes

18

7.4

Purchase Process

19

7.5.2

Cleanliness of the Product

20

7.5.3

Installation and Acceptance Criteria

21

7.5.4

Servicing Activities

22

7.5.6

Validation of processes for production and service provision

23

7.5.6

Validation of the software used in production.

24

7.5.7

Validation of processes for sterilization and sterile barrier systems

25

7.5.8

Product Identification

8

Software configuration management process

26

7.5.8

Identification of returned medical device

27

7.5.9

Traceability

8

Software configuration management process

28

7.5.11

Product Preservation

29

7.6

Monitoring and measuring

30

7.6

Calibration

31

7.6

Validation of Software used for Monitoring and Measurement

32

8.2.1

Feedback process

6.2

Problem and modification analysis

33

8.2.1

Post Market Surveillance

34

8.2.1

Post Market Clinical Follow up

35

8.2.2

Handling of Customer Complaints

36

8.2.3

Notifying the regulatory authorities

37

8.2.4

Internal audit

38

8.2.6

Monitoring & Measurement of Product

39

8.3

Nonconforming product

40

8.3.3

 Advisory Notice

41

8.3.4

Rework

42

8.4

Analysis of Data

43

8.5.2

Corrective and Preventive Action

9

Software Problem Resolution Process

ISO 62304 Mandatory Procedures

No

CL#

Procedure Name

Requirement

Class

1

5.1

Software Development Planning

The MANUFACTURER shall establish a software development plan (or plans) for conducting the ACTIVITIES of the software development PROCESS appropriate to the scope, magnitude, and software safety classifications of the SOFTWARE SYSTEM developed.

A+B+C

*

2

5.2

Software Requirements Analysis

For each SOFTWARE SYSTEM of the MEDICAL DEVICE, the MANUFACTURER shall define and document SOFTWARE SYSTEM requirements from the SYSTEM level requirements.

A+B+C

3

5.3

Software Architectural Design

Transform software requirements into an ARCHITECTURE
Develop an ARCHITECTURE for the interfaces of SOFTWARE ITEMS
Specify functional and performance requirements of SOUP item
Specify SYSTEM hardware and software required by SOUP item
Identify segregation necessary for RISK CONTROL
Verify software ARCHITECTURE

B+C

*

4

5.4

Software Detailed Design

The MANUFACTURER shall refine the software ARCHITECTURE
The MANUFACTURER shall develop and document a detailed design
Develop detailed design for interfaces
Verify detailed design
B+C

***

5

5.5

Verification of Software Unit

The MANUFACTURER shall establish strategies, methods, and procedures for verifying each SOFTWARE UNIT. A+B+C

****

6

5.6

Verification & Testin of Integrated Software

The MANUFACTURER shall verify and record the following aspects of the software integration.
The MANUFACTURER shall test the integrated SOFTWARE ITEMS in accordance with the integration plan.
B+C
7

5.7.1

Establishing  tests for software System Testing

The MANUFACTURER shall establish and perform a set of tests, expressed as input stimuli, expected outcomes, pass/fail criteria, and procedures, for conducting SOFTWARE SYSTEM testing, such that all
software requirements are covered.
B+C
8

5.7.3

Retest after changes

When changes are made during SOFTWARE SYSTEM testing, the MANUFACTURER B+C
9

5.8

Software Release

The MANUFACTURER shall ensure that all ACTIVITIES and TASKS are complete, along with all the associated documentation. A+B+C

*****

10

6.1

Establishing Software Maintenance Plan

The MANUFACTURER shall establish a software maintenance plan (or plans) for conducting the ACTIVITIES and TASKS of the maintenance PROCESS. A+B+C
11

6.2.1

Feed Back

The MANUFACTURER shall monitor feedback on released SOFTWARE PRODUCT from both inside its own organization and from users. A+B+C
12

6.2.3
6.2.4
6.2.5

Analysis, Approval of Change Requests & Communication of Changes

Analyse CHANGE REQUESTS
CHANGE REQUEST approval
Communicate to users and regulators
A+B+C

******

13

6.5

Implementation of Approved Modifications

The MANUFACTURER shall use the software development PROCESS (see Clause ___H5) or an established maintenance PROCESS to implement the modifications. A+B+C
14

7

Risk Management Process

(All Clauses). The same will be done as a part of ISO 13485 A+B+C

*******

15

8

Configuration Management

The MANUFACTURER shall establish a scheme for the unique identification of CONFIGURATION ITEMS and their VERSIONS to be controlled for the project. A+B+C
16

9

Software Problem Resolution

Prepare PROBLEM REPORTS
Investigate the problem
Advise relevant parties
Use change control process
Maintain records
Analyse problems for trends
Verify software problem resolution
Test documentation contents
A+B+C

Note:-

* Clause 5.1.4 is applicable only for Class C and 5.1.5, 5.1.10 & 5.1.11 applicable only for Class B & C

** Clause 5.3.5 is applicable only for Class C

*** Clause 5.4.2, 5.4.3 & 5.4.4 are applicable only for Class C

**** Clause 5.5.2, 5.5.3 & 5.5.5 applicable only for Class B & C and 5.5.4 applicable only for Class C

***** Clause 5.8.1, 5.8.2, 5.8.3, 5.8.5, 5.8.6, 5.8.7 & 5.8.8 are applicable only for Class B & C

****** Clause 6.2.3 is applicable only for Class B & C

******* Clause applicable for Class A in Sec 7 is 7.4.1

Enquire Now