Software is gaining relevancy in a broad range of medical devices, as it either enables the control or influence of their operation, or because Software as Medical Device (SaMD) itself has the potential for detection, diagnosis, treatment and alleviation of diverse diseases/disabilities.
General Safety and Performance Requirements (GSPR as per Annex I of the Medical Device Regulation MDR 2017/745 and In Vitro Diagnostics Regulation IVDR 2017/746) are applicable for all SaMD manufacturers. The regulation states in section 17, chapter II of Annex I that:
“17.2. For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation”
State of the Art
The IEC 62304:2006 – medical device software – software life cycle processes standard is considered the state-of-the-art for software development. Manufacturers shall leverage this standard to comply with the GSPR.
Although this standard is process-oriented and defines a set of specific requirements for manufacturers, Quality Management Systems (QMS), Standard Operational Procedures (SOPs) and lifecycle, it is not essentially different from other standards for software development.
Furthermore, it is not incompatible with Agile methodologies for software (SW) development. In fact, there is a Technical Information Report (TIR45:2012 – Guidance on the use of Agile practices in the development of medical device software) providing some insights and unification of terms for Agile development of SaMD.
In this post, we highlight some differences and correspondences in software development terms between Agile SW and SaMD development regulations, in order to help project teams work better together and channel their efforts in the right direction:
1. LIFECYCLE
The IEC 62304 requires manufacturers to define the lifecycle and detail the entire process from requirement collection (pre-market) to problem resolution (post-market). Three lifecycles are mentioned in the standard: waterfall, incremental and evolutionary.
Agile is considered incremental/evolutionary and is therefore recognized by the standard as an adequate methodology.
Manufacturers should make it clear, from the beginning, if and when they are using the Agile development methodology. They should always provide this information in the Technical Documentation to enable the software development team and regulatory bodies to understand their development process.
It’s important, however, that the methodology is aligned with the company’s QMS procedures for design and development and embeds the requirements of IEC 62304!
2. THE CONCEPT OF “DONE”
When Agile teams have completed an activity, this activity is considered finished and no further actions are expected once it is delivered.
Similarly, section 5.5 of IEC 62304 lists very similar requirements. However, the concept of “Done” should be expanded to include conditions such as:
- review of requirements,
- approvals, tester teams and testing conditions,
- expanded acceptance criteria
- documentation level required.
In other words, the concepts are similar and the “Done” concept and the underlying process can be widely leveraged to build compliance against IEC 62304, however, additional steps need to be checked before moving an activity to “Done”.
3. MOVING TO VERIFICATION & VALIDATION (V&V)
According to the regulatory requirements as per IEC 62304, integration, hardening and V&V activities need to be performed before the software becomes shippable (final release). However, this is quite difficult for each sprint outcome. To manage it, the Software Development Plan (and most particularly its Verification Plan subpart) must define a “Done is Done” criteria in order to collect a minimum set of increments/epics that could be considered adequate to undergo V&V testing.
Validation according to the regulation is a more complex concept including not only technical performance but also clinical association and clinical validation.
4. RELEASE
Before software is released, all Verification & Validation activities need to be completed and the results evaluated as per the IEC 62304 section 5.8.
Agile methodologies are aligned with these requirements. Indeed, the activities performed at increment level are documented using software development tools, and then at the end of the processes, Agile teams must ensure proper documentation of the consistency and acceptance criteria of all tests that have been performed.
Another requirement set in IEC 62304 is to document known residual anomalies. In Agile, this is created by conducting a review of each increment and searching for the potential known anomalies/bugs to be addressed.
Finally, manufacturers need to ensure that a new release is assessed against the criteria of significant or substantial change, as per Article 120 and Annexes related to Conformity Assessment procedures of the MDR and IVDR. Further details to determine whether an evolution (update/upgrade) might fall under the significant changes as per Article 120 under MDR are found in the MDCG 2020-3 guidance. No guidance related to the concept of substantial change has been published to date.
The examples provided above represent just a thin part of the parallelisms between the Agile development process and IEC 62304 requirements. Based on our experience, most of the software development processes that are IEC 62304 agnostic are very often just a few adjustments away from compliance with the regulatory requirements.
We have been working with numerous software development teams, helping them leverage their pre-existing tools, working practices and methodologies to build compliance against IEC 62304, and other related standards, in a pragmatic fashion. Contact Veranex today to accelerate your project!
This article was written by Dr. Gustavo Hernandez and Dr. Nuria Gresa.