Integrating Agile Development with Regulatory Compliance: A Practical Framework for Standalone Medical Device Software

In recent years, as many traditional internet companies have actively entered the healthcare market, numerous AI healthcare firms have emerged in China, also participating actively in the sunrise industry of medical devices.

However, reality always presents both opportunities and challenges. Transitioning directly from traditional enterprises into the medical device industry inevitably leads to certain difficulties in adaptation. The author summarizes the main reasons as follows:

1. Due to a lack of background in the medical device industry, traditional industries often have an insufficient understanding of medical device industry standards and regulations. Applying past experience from conventional software development directly to medical device software development may lead to issues with regulatory and standard compliance;

2. AI has only begun to be applied to medical device software in recent years. Current industry guidelines and regulations for software development face the risk of being inapplicable or partially inapplicable when confronted with this emerging technology.

In short, there is currently no gold standard or established benchmark for reference. How to ensure the safety and efficacy of medical devices while applying AI technology remains an unresolved challenge for the entire industry, including regulatory authorities. Despite the difficulties, companies must rise to the occasion. Adapting traditional development models to meet the new requirements of the healthcare industry is a source of confusion for many enterprises. The author, in reading a previous article by VCBeat“AI Medical Device Innovation Cooperation Platform Conference Held in Boao: A Comprehensive Guide to Common Questions on the Review and Approval of AI Medical Devices”Subsequently, I will also share some practical experiences by using the adaptation of traditional agile software development methodologies to the development of medical device standalone software as an example.

Currently, the standards and regulations that can be referenced for domestic medical device software development include the "Appendix to Good Manufacturing Practice for Medical Devices: Standalone Software" (hereinafter uniformly referred to as: Software GMP) released by the National Medical Products Administration on July 12, and the IEC 62304:2015 standard titled "Medical Device Software – Software Life Cycle Processes." As AI-based standalone medical software is classified as a Class III medical device with a software safety classification of Class C, the Software GMP imposes stringent requirements on product traceability and change control.

Product requirements must be clearly defined at the project initiation stage. It is foreseeable that these requirements cannot be easily changed, and their implementation and verification must adhere to strict procedural requirements. However, this stands in contrast to the iterative nature of software development and agile methodologies. Of course, the agile development model is a mature framework with its own advantages:

(1) With the team adopting the agile development model, iteration cycles are well-aligned with collective goals. This approach enhances the team’s self-management capabilities, ensures timely information flow, and facilitates daily synchronization.

(2) In the agile development model, products are accepted on a per-iteration basis. The deliverables of each iteration must be demonstrated; any discrepancies identified during the demonstration can be promptly exposed and corrected. This approach features a higher frequency of testing submissions, thereby reducing wait times for both development and testing teams. The agile development model adopts a binary view of project progress (either 0 or 100 percent), emphasizing team commitment over individual capability. It focuses more on overall team performance and places significant importance on both external and internal commitments.

(3) Risk management in Agile focuses on project risks such as schedule, release quality, and personnel risks.

(4) In Agile, emphasis is placed on the continuous improvement of iterative processes, addressing issues such as inadequate requirements reviews and asynchronous communication.

In short, Agile focuses more on the project lifecycle. In contrast, software GMP requirements emphasize the product lifecycle, spanning from product initiation to market withdrawal, with a focus on controlling the entire product lifecycle.

Secondly, the Agile model is more suitable for development control of software products and less applicable to hardware development. This is because software can rapidly deliver usable features, whereas the nature of hardware dictates that functionality is achieved through integration. Merely producing individual components cannot realize specific functions or meet defined functional requirements. Furthermore, Agile requirements are progressively elaborated rather than being clearly defined from the outset, involving an iterative refinement process (see Chapter 3 for discussion). Regarding personnel, Agile does not support part-time assignments or parallel project work; tasks must be executed sequentially.

In summary, in accordance with GMP requirements, manufacturers must focus on the entire product lifecycle, emphasizing quality assurance in research and development, procurement quality management, production quality control, sales and after-sales services, and post-market quality tracking and assurance.

We can also examine the differences between traditional agile software development models and GMP requirements from a risk control perspective: risk management in agile focuses on project risks, such as schedule, release quality, and personnel risks, whereas risk management under GMP places greater emphasis on product-specific risks, with risk management integrated throughout the entire software lifecycle.

Given that most software development projects adopt agile development models, how can agile software development meet the requirements of software Good Manufacturing Practice (GMP)? The author believes that solutions can be found in the standard YY/T 0664 “Medical Device Software – Software Life Cycle Processes.” Specifically, this involves thoroughly understanding the project management philosophy of the V-Model and flexibly integrating each phase of the V-Model into the iterative development process. Strict control should be exercised over the deliverables at each phase (which enterprises may align with their own project development stages) to ensure compliance with software GMP requirements. To facilitate understanding for the majority of readers, a brief introduction to the V-Model is provided below.

(1) V-Model Acronyms and Model:

A. Vertical decomposition of requirements;

B. Horizontal Verification and Validation of Requirements;

C. Risk-related requirements shall be traceable to the source code;

(2) Integration of Rules During Development:

A. The product architecture is divided into three layers: system, subsystem, and unit module.

B. Design Specifications and Unit Testing: Agile development with rapid sprint iterations may be adopted for individual module components. When software development procedures undergo changes or updates affecting more than one-third of the content, or as otherwise self-defined, the revision and release of Design History File (DHF) documents—including corresponding design specifications, unit testing specifications, and unit testing reports (self-testing)—for the respective module components shall be initiated.

C. Integration Testing: This focuses on functional-level testing of integrated unit modules. Integration testing is categorized into three types: full testing, partial testing, and defect testing. For each iteration, the testing team is responsible for updating and releasing the test specifications and test reports.

D. System Testing: System testing focuses on comprehensive evaluation of product functionality, performance, and security. For each iteration, the testing team is responsible for updating the release test specifications and test reports.

(3) Rule integration during testing, as illustrated below:

Having introduced the V-Model, readers may ask: What is its relationship with agile development? This is illustrated using examples of iterative requirements and iterative detailed design:

(1) For the definition of requirements, we can certainly apply the principles of agile development (iterative approach).

During the early stages of project development, product managers typically define basic product requirements based on customer needs, which we can preliminarily refer to as market requirements. Based on these, User Requirements Specifications (RS) are decomposed into Functional Specifications (FS) (RS→FS), establishing the initial requirements baseline (visually represented by the first version of the Design History File [DHF] requirements document). As the project progresses, team members contribute to enriching these requirements. For instance, Regulatory Affairs (RA) specialists add regulatory and standards-related requirements; clinical experts/physicians contribute clinical requirements; service engineers provide service-related requirements; and R&D engineers supply development requirements. These inputs are iteratively integrated, continuously expanding both the RS and FS. This process continues until the RS-to-FS mapping is fully defined, resulting in the final requirements baseline and the final version.

Some companies continue to iterate on requirements during the detailed design phase. The author believes that, provided appropriate change control and software configuration management (e.g., control of requirements baselines and software version baselines) are properly implemented, this approach remains compliant with software GMP and IEC 62304 requirements. Due to space limitations, further elaboration will not be provided.

Introducing an Iterative Management Model for Requirements:

Flowchart for Iterative Change Management of Requirements

Job Responsibilities:

The Requirements Management Team shall include, at a minimum, representatives from the following functions:

· Systems Engineer

· Project Manager

·Clinical Experts/Physicians

· Design Quality Assurance (QA)

· R&D Engineer

· Regulatory Affairs Engineer (RA)

A. As can be seen from the figure above, iterative changes in requirements constitute a form of change control. The iterative process involves a cyclical sequence: defining requirements (planning) → stakeholder input on requirements → establishment of a requirements traceability matrix → formation of a requirements baseline → changes (iteration) → defining requirements (planning) → ……

B. During the requirements iteration process, members of the Requirements Management Team must conduct thorough requirements reviews to ensure that valid requirements are incorporated and ambiguous ones are clarified in a timely manner.

(2) Iterative Control of Detailed Design

Once the requirements are clearly defined, the project can advance to the next phase: the detailed design phase. The author briefly introduces two iterative processes:

A. Iteration of Software Features

Software engineers can adopt an agile development model, first implementing the functionality of core modules and then gradually expanding features until all requirements specified in the Design Specification (DS) are fulfilled. Engineers may carry this agile approach to its fullest extent, provided that software version iteration and baseline control are properly managed (refer to IEC 62304, Section 8: Software Configuration Management Process), thereby meeting the requirements of the V-Model and software Good Manufacturing Practice (GMP). For instance, requirements in the Functional Specification (FS) must be fully translated into the DS and remain traceable, while the DS must be traceable to the source code, and vice versa.

B. Iterative Process of Bug Fixes and Patch Releases

The resolution process can follow the workflow shown below:

(3) Iteration of Software Testing:

A prime example in IEC 62304 that directly embodies the concept of iteration is regression testing (IEC 62304 – Section 5.6). When software code is recompiled or a software version is upgraded, conducting partial or full regression testing becomes essential to demonstrate that original functionalities remain intact and no new defects have been introduced.

In summary, as long as the regulatory requirements for medical devices are truly understood—namely, that manufacturers must ensure the safety and effectiveness of their devices—agile development methodologies can be flexibly integrated into the V-model during actual development. In this way, agile models can also thrive and be effectively applied in medical device software development. It can be stated that regulations and standards do not oppose the use of agile iterations or any specific fixed development model by enterprises; any approach is considered acceptable provided that manufacturers can exercise reasonable control over it to meet the relevant standards and regulatory requirements.

By |

Peng Chuanbo (Quality Lead at a leading AI healthcare company in China; WeChat: pengchuanbo52)

Cheng Jiangong (Head of Software Quality at a well-known foreign medical company, WeChat: jekingcheng88)