The ABCs of Medical Device Software Compliance under EU Regulations 2017/745 and 2017/746 – April Komplin’s Presentation – Part 2

April Komplin is a valuable member of the Celegence team due to her expertise and highly successful career in Quality Management Systems and Regulatory Affairs. At her previous position at a medical device start up, she built their QMS from the ground up and the company is now ISO 13485:2016 certified and will achieve CE Marks for seven medical devices in 2021. Additionally, she covered compliance for 21 locations across North America for an In Vitro Diagnostic device manufacturer.

During our Medical Device Virtual Summit – 2021, April Komplin presented a feature presentation titled “The ABCs of Medical Device Software Compliance under EU Regulations 2017/745 and 2017/746.” Check out part one of her presentation here.

Why should you watch this video/read the transcript?

• To review the medical device software (MDSW) verification and validation process and requirements
• To understand the Clinical Evaluation Report (CER) and Performance Evaluation Report (PER) requirements as they relate to MDSW

A full transcript of April Komplin’s presentation is available to download (and to read below) and just press play to watch the clip now. 

Software verification is confirmation through objective evidence that specified requirements have been met. It confirms that design outputs have met the design input requirements. It is typically conducted at particular phases. Software verification and validation planning is essential in the early stages of software development.

While not required. It is very beneficial to use a third-party software validation service. This provides independence of review of the validation reports, and the ability to perhaps detect anomalies.

Software validation by the FDA is defined as testing and subsequent objective evidence that specifications conformed to the user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled. Validation is not covered by IEC 62304. It only covers software release in section 5.8. Manufacturers should validate the installation operation and performance of their medical device software.

The IVDR’s general safety and performance requirements 6.4 reads “the documentation shall contain evidence of the validation of the software, as it is used in the finished device. Such information shall typically include the summary results of all verification, validation, and testing performed in-house and applicable in an actual user environment prior to final release. It shall also address all of the different hardware configurations and, where applicable, operating systems identified in the labeling”.

The FDA advises that software validation should be increased in rigor as compared to hardware:

“Because of its complexity, the development process for software should be even more tightly controlled than for hardware, in order to prevent problems that cannot easily be detected later in the development process”. 

User site testing, for example, also known as installation qualification, is essential for your medical device software.

The software validation process cannot be completed of course, without an established SRS (software requirements specification) and you can find some definitions and other requirements for software validation in 21 CFR 820 cited here. Your testing can be differentiated into 7 separate units. We have the unit level, the integration level, and then we move on to the system level. The system level validation should address functional concerns, including performance issues, response to stress conditions, operation of security features, effectiveness of recovery procedures, usability, compatibility with other software products, behavior in each of the defined hardware configurations, and accuracy of documentation.

Let’s move on to some technical file documentation requirements as they relate to medical device software. So here’s a list of key software technical file requirements.

• Interoperability – discussing that in your technical file, especially for those softwares in a medical device
• Describe your security controls
• Describer your architecture
• The Performance Evaluation, which is applicable to the IVDR
• The Clinical Evaluation, which is applicable to the MDR
• Software validation documentation
• You want to provide an overview of design, including the design stages
• Your usability and human factors testing
• If applicable, your GSPR analysis
• Risk management

Annex two in the IVDR paragraph 6.4 – which reads that the documentation shall contain evidence of the validation of the software, as it is used in the finished device. It includes the summary results of all verification, validation, and testing performed in-house and in an actual user environment prior to release. Address, if applicable hardware configurations and operating systems identified in the labelling.

Note: IVDR essential requirements are now termed as GSPR 16.2 also cites the requirement for software validation and verification.

Performance evaluation is defined by the IVDR as “an assessment and analysis of data to establish or verify the scientific validity, the analytical and, where applicable, the clinical performance of a device.”

Clinical performance is defined by the IVDR as “the ability of a device to yield results that are correlated with a particular clinical condition or a physiological or pathological process or state in accordance with the target population and intended user.”

Clinical evidence is defined by the IVDR as “clinical data and performance evaluation 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 report or PER is a critical element of the technical file. It is the outcome of the performance evaluation plan. All devices require a PER. The IVDR states – The performance evaluation shall follow a design and methodologically sound procedure. Particular contents can be justified as not applicable, only as appropriate. IVDR also reads the clinical evidence shall support the intended use of the device.

Refer to article 56 of the IVDR for more information on your performance evaluation, and then refer to part A of Annex 13 for all of the requirements of PERs.

Performance evaluation, of course, is not just pre- or post-CE, it is continuous.

The clinical evaluation will be very comprehensive and will include at least this list of items:

• Combination of various studies and analysis conducted
• Any usability or human factors studies you conducted under IEC 62366
• Software (bench) testing
• Literature evaluation
• Clinical testing
• Your substantial equivalent analysis as applicable.

The term clinical evaluation appears 145 times in the MDR, which of course again shows the regulatory emphasis.

I like to look at the schematic from the IMDRF guidance document listed down here below:

• Valid clinical association: Manufacturers should ask, is there a valid association between your software as a medical device output and your SaMD’s targeted clinical condition?
• Analytical validation: Manufacturers should ask, does your SaMD correctly process input data to generate accurate, reliable, and precise output data?
• Clinical validation: Does use of your SaMD’s accurate, reliable, and precise output data achieve your intended purpose in your target population in the context of clinical care?

Software medical device manufacturers should complete and maintain an IEC 62304 gap analysis. This gap assessment or gap analysis should be created against the device’s safety class. As there are different requirements throughout the standard based on whether the device is safety class A, B or C.

IEC 62304 section 4 requires a gap analysis and follow up activities. The 2015 amendment has added this requirement for legacy devices. For example here, section 4.4 of the standard reads taking the perform gap analysis into account, the manufacturer will evaluate the potential reduction in risk resulting from the generation of missing deliverables and associated activities and create a plan to perform activities and generate deliverables to close these gaps.

With that. I would like to thank everybody for joining my presentation. I hope you were able to learn a little bit from my presentation today. If you have any questions, comments, concerns, or need any help with projects, feel free to reach out to Celegence.