Tackling Medical Device Software Under the New IVDR Requirements (Part 2)

In part 1 of tackling medical device software under the new IVDR requirements, I provided a summary of the first document published by the Medical Device Co-ordination group. As a follow up, I’d like to help identify the key things to focus on for meeting the General Safety & Performance Requirements of Annex Ifor MDSW, as well as providing a summary of the second guidance document published by the MDCG, specifically with software.

General Requirements

‘Interoperability’

This is one of the new definitions in the regulation. It stresses the ability of the device to exchange information and to operate correctly in combination with another device. It concerns protocols, in particular those used to provide interoperability with a LIMS system.

Among the general requirements, some are dedicated to embedded systems and standalone software: consider reliability, reducing risks, development cycle, etc. So really, all requirements that need harmonised standard EN ISO 14971 (“Medical devices – application of risk management to medical devices” for risk management and standard IEC62304 “Medical device software. Software life-cycle processes”) for their software.

Standard EN ISO 14971 is well-known to manufacturers, but EN 62304 can retain a few surprises. It is extremely thorough, with more than 300 requirements for the most critical software. A true “software mini-QMS”.

Performance Evaluation of IVD Medical Device Software

Article 61 Article 56 (1) of the IVDR states the following:

‘The manufacturer shall specify and justify the level of CLINICAL EVIDENCE necessary to demonstrate conformity with the relevant general safety and performance requirements. That level of CLINICAL EVIDENCE shall be appropriate in view of the characteristics of the device and its intended purpose.’

Article 2 (36) of the IVDR defines ‘CLINICAL EVIDENCE’ as:

‘clinical data and PERFORMANCE EVALUATION (IVDR) results pertaining to a device of a sufficient amount and quality to allow a qualified assessment of whether the device is safe and achieves the intended CLINICAL BENEFIT(S), when used as intended by the manufacturer.’

Performance evaluation is an ongoing, structured, transparent, and iterative process, which continues throughout the life cycle of a MDSW. It forms an integral part of the quality management system for a device. Software that qualifies as an IVD is subject to the same general performance evaluation principles. These principles are laid down in the applicable guidelines and regulatory documents, as other IVDs:

• PLANNING – establishing and maintaining a performance evaluation and criteria applied to generate the necessary clinical evidence based on the characteristics of the device;
• DATA – Identification of the relevant data pertaining to performance and/or safety of the device and any remaining unaddressed issues or gaps in the data;
• APPRAISAL – of the relevant data in terms of quality and its contribution to the performance evaluation
• ANALYSIS – of the available data and its relevance with regard to demonstrating conformity with the relevant General Safety and Performance Requirements (GSPRs);
• DOCUMENTING – the relevant data, their assessment and the clinical evidence derived therefrom, in performance evaluation report;
• Updating the PERFORMANCE EVALUATION and the documentation throughout the life cycle of the MDSW concerned with data obtained from implementation of the manufacturer’s Post Market Clinical Follow-up / Post Market Performance Follow-up (PMCF /PMPF) plan.

Annex II of MDCG-2020-1 provides a high-level example on how to develop a performance evaluation strategy, applied to a MDSW IVD: (However, this is not a confirmation of the pathway for a performance evaluation of the type of device, as other factors need to be considered).

Example;

MDSW intended to detect inflammatory bowel diseases (IBD)

Self-testing independent MDSW intended for the semi-quantitative detection of calprotectin from a faecal sample. Reagents are added to the sample resulting in a colour change. The sample is then photographed on a smartphone. The image is evaluated by an MDSW application (app) running on the phone. The MDSW app detects the colour change in the sample and interprets the concentration of calprotectin. The test is intended as an aid in monitoring and staging of patients with inflammatory bowel disease (IBD).

Manufacturer’s claim that the MDSW app;

The following types of data ( Clinical Evidence ) would need to be collected to support the claims;

Scientific Validity

To establish scientific validity, review literature.

• The scientific validity could address how the calprotectin level corresponds to the IBD level and stages. Furthermore, it should address, whether calprotectin levels are suitable to differentiate between IBD and functional bowel disorders.
• Calprotectin concentration in faecal matter can be reliably measured in test strips by change of colour.
• The colour intensity is directly representative of the concentration of calprotectin.

Analytical Performance

• Confirm the MDSW app can detect reliably and accurately the colour of the test strip compared to human observation, taking into account environmental factors.

Clinical Performance

• The manufacturer should assess the initial performance and feasibility by creating clinical performance metrics, taking into account sensitivity, specificity and confidence intervals.
• Any claims regarding clinical benefit should be supported by sufficient clinical performance data.
• Usability should be confirmed by the manufacturer.

Conclusion

Performance evaluation is a real focal point of the IVDR. Done properly, it provides sufficient clinical evidence for your IVD device.  As MDSW is now firmly established in the scope and definition of IVDs, manufacturers of MDSW, who may have little clinical evidence for these, are now advised to heed the new requirements.  Following this, it is recommended that a gap assessment of existing data and technical documentation is performed against relevant parts of the regulation (Article 56 and Annex III), then followed up by remediation to address any findings.

How IMed Can Help With Tackling Medical Device Software Under the New IVDR Requirements

The MDCG guidance documents on MDSW & the IVDR are really helpful. Utilising these will help bring devices into compliance as part of your IVDR transition plans. IMed are here to help guide you through each stage.

For any questions on tackling medical device software regulations or for IVD regulation in general, get in touch with IMed Consultancy today.