Software as a medical device – safety integrity level

Medical devices IEC-62304 is the med industry-specific adaptation of the larger IEC-61508 standard regarding functional safety.

IEC-62304 applies to the development and maintenance of medical device software when:

• The software is itself a medical device.
• Or the software is an embedded or integral part of the final medical device.

While safety integrity level (SIL) refers mostly to electrical, electronic or programmable electronic safety systems, we will try to determine how, in the era of big data, AI or machine learning, a pure software medical device is to be considered behind the umbrella of both standards.

Determining if the medical application has safety-critical related functions to try to establish the SIL and his relative level of risk reduction provided by a safety function.

SIL ratings correlate to the frequency and severity of hazards. They determine the performance required to maintain and achieve safety — and the probability of failure.

The higher the SIL, the greater the risk of failure and the stricter the safety requirements to be satisfied.



Medical devices classification in class I, IIa, IIb or III according the patient-device contact/time ratio has been reviewed in the new EU MDR medical devices regulation.

Following MDR classification rule 11, any medical software application that supplies information aimed to support a clinical decision (Clinical decision support or CDS) in terms of therapeutic or diagnosis actions, is to be considered as a class-II or class-III medical device depending on the impact on the patient health.

As an example, cancer disease diagnosis software based on analysis of patient genotype records from genomic tests, is to be considered as a class-III medical device as it uses patient data to establish the correct medical treatment.

The cause of an inaccurate diagnosis could lead to a wrong therapy and to a serious injury but the medical software itself still can be classified as Class A, B or C (as a whole or in different parts) depending on the software architecture.

A requirements traceability matrix (RTM) is the easiest way to go from each functional or user requirement of the software as a medical device to the software design specification or description (SDD) and its associated hazards.

A series of unitary and integration test are to be implemented as to prove the correct mitigation of the effects of the related hazards.

The factorization of the code in software units, aimed to facilitate the unitary and integration tests, are the key point as it defines the software architecture itself.

Some guides for the medical device software management and classification are:

EN 62304:2006 Software for medical devices. Software life cycle processes
EN-ISO 13485:2016 Medical devices. Quality management systems.
IEC/TR 80002-1:2009 Medical device software – part I
EU – MEDDEV 2.1/6 Qualification and classification of stand-alone software
FDA – General principles of software validation.