NEWS

Agile vs. Regulatory

Agile vs. Regulatory: How the two coexist and contribute to successful Medical Device Software Development

Agile vs. Regulatory: How the two coexist and contribute to successful Medical Device Software Development

 

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.

 

Agile vs. Regulatory

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:

 

1) review of requirements,

2) approvals, tester teams and testing conditions,

3) expanded acceptance criteria

4) 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”.

 

 

Techletter | Medical Device Software incorporating Artificial Intelligence: Techletter

 

Medical Device Software Incorporating Artificial Intelligence

Generating Sufficient Evidence under the MDR

 

Click to read

 

 

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. For further details on Clinical Validation of Medical Device Software, check our dedicated webpage.

 

 

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.

 

At Medidee, now part of Veranex, 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.

 

If this is something you are currently working on, do not hesitate to check our full offering of Digital Health Services, or to reach out directly for expert support: https://www.medidee.com/contacts/

 

 

This article was written by Dr. Gustavo Hernandez and Dr. Nuria Gresa.

[UPDATE] Resolution of the German Bundesrat – Urgent need for action in the implementation of the European Medical Devices Regulation (MDR)

The German Länder urge the Federal Government of Germany to take action at the EU level regarding the imminent problems with the implementation of EU Medical Device Regulations.

 

The Decision 445/22 published on 07.10.2022 summarizes the concerns of the German Länder. See the official publication in German here, and Medidee's tentative translation to English below:

 

2022-10-09 Summary and tentative translation – Bundesratsbeschluss Oct07-2022

 

To make sure that your transition to MDR is as quick and smooth as possible, contact Medidee today: www.medidee.com/contacts

Natural Cycles - Medidee

[Business Case] Achieving MDR conformity for legacy MDD class I medical software

This Business Case introduces the collaboration between Natural Cycles, a Swedish woman's healthcare company, and Medidee, a global regulatory service provider active in the fields of Medical Devices and IVD products.

 

When embarking on our journey through evolving regulatory frameworks, Medidee was a stable, informative resource. The experienced team explained detailed guidelines and closely coached us to the point of submission, where the outcome was positive.

 

Dr Jack Pearson, Medical Affairs Manager at Natural Cycles

 

Read more about the  Quality-Regulatory-Clinical challenges faced by Natural Cycles and how Medidee supported overcoming them:

 

Business Case – MDR Conformity – Natural Cycles & Medidee

 

Contact Medidee's experts to discover how we can support you

Business Case Fabrinal Medidee - Eye

[Business Case] How the long-term collaboration between Fabrinal and Medidee supports the competitiveness of the Swiss Manufacturer

This Business Case introduces the collaboration between Fabrinal, an SME focused on medical technology applied to studying the eye, and Medidee, a global regulatory service provider active in the fields of Medical Devices and IVD products.

 

Fabrinal has been supported closely for almost 10 years by Medidee. For an SME of our size, this change is so critical from a timing and economic point of view, that it is crucial to be advised by rational and experienced experts. I am extremely confident about their advice and application of the MDR and can navigate through this challenging change a bit less worried.

 

Cloé Houriet, CEO of Fabrinal

 

Read more about the Regulatory challenges faced by Fabrinal and how Medidee supported overcoming them:

 

Business Case – MDR Transition – Fabrinal & Medidee

 

Click to contact our experts and get support with your MDR Transition

Cybersecurity Medical Devices

Artificial Intelligence (AI), General Data Protection Regulation (GDPR) and Cybersecurity: 10 Misconceptions about Medical Device Software

Artificial Intelligence (AI), General Data Protection Regulation (GDPR) and Cybersecurity: 10 Misconceptions about Medical Device Software

 

Medical Device Software (MDSW) is a growing, fast-evolving industry. However, manufacturers often must face a regulatory framework which does not evolve at the same speed. Regulation for medical devices is restrictive, since it needs to guarantee the safety of users (e.g. Health Care Professionals) and the target population (e.g. patients). Moreover, it has experienced a significant increase in requirements with the approval of the new regulation MDR 2017/745. Manufacturers of MDSW who have never placed a medical device on the market, or who did it under the former Medical Device Directive (93/42/EEC MDD) might have some misconceptions about the process. The purpose of this article is to address some of the most common (and not always right) assumptions and provide useful and truthful information about the process of reaching the conformity assessment under MDR, for successfully placing an MDSW on the market. 

 

Cybersecurity Medical Devices

Here are 10 common misconceptions about Medical Device Software, and their respective clarification:

 

1. MDSW is classified as low risk under the MDR 2017/745. 

False! On the contrary, only a small portion of MDSW is classified with the lowest risk class (class I) according to the new regulation (MDR2017/745 annex VIII) and related guideline (MDCG 2019-11). To classify a Medical Device Software, two main aspects must be taken into account: 1) the severity of the state of the healthcare situation or patient condition and 2) the significance of the information provided by the software to the healthcare situation related to diagnosis/therapy. After taking these factors into consideration, most MDSW is classified in higher classes, from Class IIa to Class III, which entails increased regulatory requirements. 

 

2. Agile development practice and IEC 62304 requirements cannot co-exist because they rely on fundamentally conflicting principles. 

Agile methodologies (i.e. SCRUM) are compatible with the standard for the development of Medical Device Software. Actually, there exists a Technical Information Report providing guidance on the use of Agile practices in the development of medical device software (AAMI TIR45:2012). It is up to the manufacturer to decide the Software Development Lifecycle (SDLC) of the product. However, there are multiple challenges that a manufacturer must face, especially in terms of procedures (alignment with the Quality Management System), validation of tools and documentation.

 

3. I have developed a Machine Learning model that underwent thorough testing and showed excellent technical performance, so I should be able to access the market in a few months. 

All MDSW embedding AI must comply with applicable MDR 2017/745 requirements prior to being placed on the market. This means that the processes and the timing to access the market are not accelerated compared to other medical devices. In addition to the general regulation, there are some relevant specific considerations for the Clinical Evaluation of Medical Device Software as per MDCG 2020-1: For any MDSW (including AI-based MDSW), Clinical Evaluation should demonstrate the valid clinical association/scientific validity, technical performance, and clinical performance. This guidance on clinical evaluation of MDSW provides a framework for the determination of the appropriate level of clinical evidence required for MDSW. The provisions of this guidance document should be taken into consideration from the early stages of software development.

 

4. I can place my AI-based Software Medical device on the market if I have trained, tested and validated it with datasets coming from open access repositories.  

It depends. It is important to verify that sufficient information is available on the origin of the clinical data. Multiple requirements might be fulfilled to ensure the validity of the protocol used to collect the data as well as the compliance of the data collection methods with GDPR: Was the study run according to the Good Clinical Practices and standards? Was GDPR followed? Was the data collection performed by certified professionals? It is also important to adopt good machine learning practices during model training, testing and validation, e.g., that training and testing datasets should be independent. For more information, check these guiding principles for Good Machine Learning Practices. 

 

5. If my MDSW fails to ensure personal data protection, it is not considered as harm. 

According to the MDR 2017/745, all parties involved in its application shall respect the confidentiality of information and data obtained. Even if the failure of the software does not result in a lesion or physical injury, disclosure of personal yields infringement penalties according to MDR2017/745 and GDPR Regulation (EU) 2016/679. Therefore, data processing, involving transmission over a network or storage needs to be properly tackled by design strategies (e.g. minimum data collection, pseudo anonymisation) and complemented with ICT techniques (encryption, Secure layers, etc.). To conduct Risk management is a “must”, and any residual risk must be mitigated as much as possible.

6. If my device is not storing data, I do not need to comply with GDPR.

Even if the device does not store data, it still might be, for instance, linked to a website that collects some personal information related to the user or the practitioner. It is important to conduct an analysis of the whole lifecycle of the product and identify which processes need special attention as per the GDPR requirements. 

 

7. If I am working with anonymised data, I do not need to comply with GDPR. 

That is true if data is completely anonymised. However, most manufacturers rather work with pseudo-anonymised data, meaning that there is a “key” that can be used to link back the clinical data with the personal information of the patient. In this case, the manufacturer needs to be compliant with GDPR regulations. 

 

8. I can keep the collected data for as long as I want. 

Similarly, that depends on whether the collected data is fully anonymised. If that is the case, there are no time restrictions for its storage, but if the data is pseudo-anonymised, there are restrictions. GDPR regulation does not establish specific time windows within which the storage is allowed, instead, it mentions that “personal data must be kept in a form that makes it possible to identify data subjects for no longer than is necessary for the purposes of the processing”. 

 

9. If I use a cloud server, I do not need to worry about cybersecurity because the service provider takes care of it. 

Be careful, most cloud servers are not specifically designed to host confidential data or clinical data. When choosing a cloud server for such purposes, it is good to select an ISO 27001 certified provider. That means that the provider has a model for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an information security management system. However, be proactive! Use all relevant information sources (Common Vulnerabilities and Exposures (CVE) for vulnerability monitoring, testing tools such as Trivy, Shodan, OWASP, etc.), and monitor all processes concerning maintenance and infrastructure via health checks.  

 

10. If the Software Medical Device is a standalone software intended to be used in a host, I do not need to take precautions on cybersecurity. 

False! MDR 2017/745 requires manufacturers to foresee possible threats caused by misuse of their device and to take actions to prevent it. Besides, MDR also requires reducing as far as possible the risk associated with the possible negative interaction between software and the IT environment the MDSW operates and interacts with. So, it is important to take cybersecurity preventive measures to identify possible threats, vulnerabilities, assets and impacts. A manufacturer needs to consider security in a holistic approach as the nature of assets is diverse: Hardware (including the infrastructure), Software (protection against most common threats such as ransomware, malware, legacy software, Software of Unknown Provenance, etc), Data (Personal Identifiable Information PII, Health Records, Systems configuration, etc), and Users (considering misuse, unauthorised users, protection of sensitive functionalities, etc). 

 

 

Placing MDSW on the market requires knowledge of a broad variety of topics, including regulation and related guidelines for clinical validation, GDPR, cybersecurity, risk management and quality control. 

 

With an extensive track record working on similar problematics, Medidee can support you with services ranging from training courses and coaching, up to completing the strategy to successfully bring your product to the market.

 

Contact us today to discuss your project! 

 

 

This article was written by Dr Nuria Gresa, Dr Stamatia Pagoulatou and Dr Gustavo Hernandez.