Implementing software development practices to get MDR certified: A case study

The EU Medical Device Regulation (MDR) comprises a comprehensive set of rules governing the manufacture and distribution of medical devices within the European Union. Its primary objective is to safeguard human health by ensuring that medical devices meet stringent safety and efficacy standards. The EU MDR replacing the former Medical Device Directive (MDD), represents an updated framework for ensuring the quality and safety of medical devices in the EU.

<<Work with our agile & tech experts to get successful business outcomes>>

Who needs to comply with the MDR?

If you are:

• A manufacturer, authorized representative, importer, or distributor of medical devices in the EU.
• A regulatory affairs or quality management professional involved with medical devices.

A case study

For our client, a promising healthcare provider, obtaining MDR certification was imperative to access the lucrative German market. They were in search of a partner to create a solution ready for production for their proof of concept (PoC) application. They had already made a PoC focusing on remote treatment but aimed to construct a reliable and scalable solution from scratch, which will include:

• the development of an Android mobile app and supporting backend API in line with GDPR standards, eligible for MDR certification;
• certified Bluetooth-connected medical device;
• ensure secure transfer and storage of data due to the classification of the gathered data as PHI.

However, navigating the complex regulatory landscape posed significant challenges, prompting the client to seek our assistance.

Key challenges

• Understanding regulatory requirements: The client grappled with deciphering the intricate provisions of the MDR and aligning their existing processes with the new regulatory framework.
• Documentation and data management: Organizing vast amounts of documentation and ensuring data accuracy presented formidable obstacles for the client.
• Time sensitivity: With impending deadlines for MDR compliance, time was of the essence, necessitating swift and efficient execution of compliance measures.

The MDR lifecycle

A primary and essential requirement for MDR is the establishment of a Quality Management System.?We aid in the process of setting up and implementing a Quality Management System (one of the key elements for MDR certification) by participating in the following activities:

• Defining quality objectives

• Documenting procedures and processes

• Conducting training and facilitating communication within the team

• Implementing document control

• Performing monitoring and measurement

The next step was to establish a process following IEC 62304, which is a standard providing a framework for the software life cycle processes of medical device software.?Key activities and contributions include:

• ?Definition and application of SOPs:

We initiated the process by defining and applying Standard Operating Procedures (SOPs) throughout the software development lifecycle. These SOPs provided clear guidelines for each stage of development, ensuring consistency, traceability, and compliance with the updated MDR standards.

• Versioning management:

To facilitate effective version control, we established procedures for versioning management, including a robust branching strategy. This ensured that the development team could work concurrently on different features while maintaining a stable and reliable codebase, aligning with MDR documentation requirements.

• Build Management:

We implemented procedures for build management, streamlining the process of compiling, testing, and packaging software. This not only enhanced the efficiency of development but also contributed to the reliability and repeatability of the build process, meeting the MDR's emphasis on software reliability and performance.

• Change Management:

A dedicated change management procedure was defined to handle modifications to the software during development. This allowed for systematic evaluation of changes, their impact on the system, and documentation of any necessary updates to maintain compliance with the dynamic MDR landscape.

In parallel, we actively contributed to the preparation of the technical documentation.?

• System components?overview:

Detailed documentation of system components, including responsibilities, interfaces, performance requirements, and responsible developers, was created. This information facilitated effective collaboration among development teams and ensured accountability, meeting MDR expectations for robust system documentation.

• Database schema documentation:

We documented the database schema, providing a clear representation of data structures and relationships within the system. This documentation was vital for regulatory authorities to assess data integrity and security, aligning with MDR requirements for data protection.

• Dynamic/Runtime view and UML diagrams:

Dynamic/runtime views of the system, supported by UML diagrams and runtime scenarios, were documented. This visualization aided in understanding the system's behavior under different conditions, contributing to both development and certification processes as per MDR expectations.

• Documentation of software architecture constraints:

We meticulously documented software architecture constraints, including specifications for the runtime environment, coding guidelines, and tools. This documentation served as a reference for developers, ensuring that the software adhered to predefined safety and quality standards following MDR requirements.

• Software architecture overview:

A comprehensive software architecture overview, featuring a context delimitation diagram and top-level component overviews, was created. This document provided stakeholders with a clear understanding of the system's structure and functionality, aligning with MDR expectations for transparent documentation.

• Identification of components and SOUPs:

We documented self-developed components and third-party Software of Unknown Provenance (SOUPs) with versions and safety class information. This transparency was crucial for MDR compliance, enabling traceability and risk assessment as mandated by the new regulations.

• Distribution view documentation:

We documented the distribution view of the system, illustrating how components interact in a distributed environment. This information was valuable for assessing system scalability, reliability, and performance, aligning with MDR's emphasis on comprehensive system understanding.

• Testing process?documentation:

Our team thoroughly documented the testing process, focusing on integration testing. This documentation outlined test scenarios, coverage, and results, demonstrating the effectiveness of our quality assurance practices in line with MDR requirements.

• Cross-cutting concerns documentation:

We identified and documented cross-cutting concerns, such as security, logging, and error handling. This documentation ensured that these concerns were consistently addressed throughout the development process, meeting MDR expectations for robust and secure software.

• Design decisions with ADRs:

All design decisions were documented using Architecture Decision Records (ADRs). This traceability provided insights into the rationale behind architectural choices, aiding in future modifications and updates, and aligning with MDR expectations for transparent decision-making processes.

• Documentation according to ard42 guidelines:

The entire documentation process adhered to ard42 guidelines, ensuring consistency, clarity, and completeness. This approach facilitated communication among team members and stakeholders, aligning with best practices in software architecture documentation as recommended by MDR.

• Software release procedure documentation:

We established a comprehensive software release procedure, complete with checklists for each release, test results, release assets, and documents. This streamlined the deployment process and provided a basis for auditing and compliance verification following MDR documentation standards.

<<Discover how you can build your product with ready-to-go teams>>

Key outcomes

Through the implementation of these meticulous software development practices, our team successfully assisted our client in achieving compliance with the Medical Device Regulation and also resulted in:

• Timely compliance: Our efficient implementation of compliance measures enabled the client to meet regulatory deadlines without undue delay.
• Enhanced efficiency: Automation of regulatory processes resulted in significant time and cost savings for the client, optimizing resource allocation and improving operational efficiency.

• Improved competitiveness: MDR certification bolstered the client's credibility and market reputation, enhancing their competitiveness and fostering customer trust and loyalty.

The takeaway

In imposing stronger rules on medical devices, the MDR seeks to establish a modern and more robust regulatory framework to protect public health and patient safety.

Specifically, the MDR aims to improve the quality, safety and reliability of medical devices, with tighter controls on certification; strengthen transparency and information for patients, so that vital information is easy to find; and enhance vigilance and market surveillance – once devices are available on the market, manufacturers must collect data about the devices' performance.

Intertec as a tech partner was directly involved in the development process and the design of the client's solution but also in the defining, documenting, and practicing development process. This collaboration underscores the importance of integrating best practices in software development to meet the stringent requirements of the medical device industry under the updated regulatory framework.

If you or someone you know is keen to explore how Intertec can support your healthcare digital transformation journey, feel free to pass this along. Don't hesitate to subscribe for more updates!