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.


Incident reporting EUDAMED Vigilance Module

[ARTICLE] Incident reporting until release of the EUDAMED Vigilance module

The EUDAMED Vigilance module will serve notably for the reporting of serious incidents involving medical devices. Until the EUDAMED Vigilance module is operational, manufacturers shall continue to report incidents directly to the relevant National Competent Authority(ies).

 

In December 2018, the European Commission published the new Manufacturer Incident Report (MIR) form for manufacturers to use in this process. The form introduced novel information requirements under the MDR 2017/745/EU / IVDR 2017/746/EU such as trending data based on relevant similar incidents, and also integrates the use of harmonized adverse event terminology and codes recommended by the International Medical Device Regulators Forum (IMDRF).

The information requirements for Incident reporting using the new MIR form are announced to be highly similar to those for the upcoming EUDAMED Vigilance module, and the latter will also integrate the use of IMDRF terminology to describe adverse events, their causes, and their consequences on users/patients.

 

The new MIR form has since been updated twice. The latest version, MIR version 7.2.1, became applicable from January 1st, 2020, for the reporting of Incidents under both the EU Directives and the Regulations for both medical devices and IVDs. These comprise incidents reportable under the AIMDD 90/385/EEC / MDD 93/42/EEC / IVDD 98/79/EC as defined in MEDDEV 2.12/1 Guidelines on a medical device vigilance system, and Serious Incidents under the MDR / IVDR. Accordingly, wherever the form refers to “incidents”, one should read “serious incident”, in other words reportable event, when the form is used to report under the MDR/IVDR.

 

A clarification has to be made regarding the difference between an Incident under the AIMDD/MDD/IVDD and a Serious Incident under the MDR/IVDR. These two terms mean the same thing, there is just a slight modification of the wording for the definition of Serious Incident as per the MDR/IVDR:
 
"Serious incident means any incident that directly or indirectly led, might have led or might lead to any of the following: the death of a patient, user or other person; the temporary or permanent serious deterioration of a patient's, user's or other person's state of health; a serious public health threat".
 
Hence, events that were reported as Incidents under the AIMDD/MDD/IVDD, are now considered as Serious Incidents under the MDR/IVDR. It shall be noted that the MDR/IVDR also define Incidents. However, under the Regulations, Incidents refers to degradation of the characteristics and performance of the device, including use error to ergonomic features as well as any inadequacy in the information supplied by the manufacturer and any undesirable side-effect, which only require to be reported if they also qualify a Serious Incidents.

It shall be emphasized that completing the different fields of the new MIR form is a complex and time-consuming task, particularly in comparison with what was previously required for incident reporting under the AIMDD/MDD/IVDD

 

The use of the new MIR form to report Incidents is mandatory since January 2020. It shall be emphasized that completing the different fields of the new MIR form is a complex and time-consuming task, particularly in comparison with what was previously required for incident reporting under the AIMDD/MDD/IVDD. Indeed, the main purpose of this new form is to have more complete information of the incidents and to be able to collect the data in a harmonized way.
 
The IMDRF terms and codes to be employed for filling in the MIR form can be found in the IMDRF Adverse Event Terminology web browser. The main tool provided by the EC to support manufacturers in the implementation of the MIR form is the New manufacturer incident report help text.
 
This living document clarifies which fields are mandatory or voluntary to complete in function of the different types of reports (initial, update, final, etc.) pertaining to the main Incident reporting stages, and moreover provides practical guidance on how to fill certain fields of the MIR form. It shall furthermore be noted that new MIR XSD and XSL files are available for implementation in manufacturers' databases.

 

Medidee can offer support to manufacturers in completing and submitting the new MIR form, and, for manufacturers wishing to implement the MIR XSD and XSL files within their own databases, support in validation of the solution.
Contact us now!

 

This article was written by Dr Jérôme Randall.


Control of outsourced design & development activities

[ARTICLE] Control of outsourced Design & Development activities

MedTech companies producing medical devices, while remaining the legal manufacturer from a regulatory standpoint, traditionally outsource the production of their medical devices to contract manufacturers. It is now also becoming increasingly common to see legal manufacturers outsource significant parts of their design and development (D&D) activities, in particular those related to the development of software and electronics. Similarly to a subcontracted manufacturer, it is essential for the legal manufacturer to ensure a suitable level of control over the entity the outsourced development has been entrusted with, hereafter referred to as the “contract designer”.
 
This article aims to present the different possible approaches that may be applied and the associated risks incurred, as well as at presenting Medidee’s recommendations for MedTech companies considering to outsource Design & Development activities (D&D).
 
 

The different type of schemes for subcontracting Design & Development activities

 
We have observed different types of schemes for subcontracting Design & Development activities, ranging from “high-end contract design and development with a reputable ISO 13485-certified contractor” to “my engineer has a friend handling the software design in his spare time”.
 
The downside to the first scenario is of course the associated costs. The clear risk with the second extreme scheme is that although such an option may initially appear attractive from a financial standpoint, the probability that the contract designers performs the Design & Development activities following a process that does not fulfill the expected quality requirements (ISO 13485, and other applicable standards such as ISO 62304) is very high.
 
In this case, the D&D process would have to be reviewed – or in the worst-case scenario entirely restarted with an alternative, more reliable contract designer – implying additional costs that could add up to well more than what was saved in the first place, in addition to potentially incurring considerable delays.
 
Thus, opting for an initially cheaper solution may easily result in “real” costs well above what would have been the case if a known, trustworthy contract designer would have been chosen.
 
We also observe that when design activities are contracted to a high-end certified company, the probability of compliance is also sometimes challenged because of a lack of clarity from the legal manufacturer on what he actually expects, especially in terms of risk management.
 
The MDR requires legal manufacturers of medical devices other than investigational devices to integrate amongst others the D&D of the device within a quality management system (QMS) (MDR Article 10(9)(g). The IVDR contains a near identical requirement for legal manufactures of IVD devices other than devices for performance evaluation (IVDR Article 10(8)(g)).
 
ISO 13485:2016, the reference standard for medical device QMS, states in clause 4.1.5:
 
When the organization chooses to outsource any process that affects product conformity to requirements, it shall monitor and ensure control over such processes. The organization shall retain responsibility of conformity to this International Standard and to customer and applicable regulatory requirements for outsourced processes. The controls shall be proportionate to the risk involved and the ability of the external party to meet the requirements in accordance with 7.4 (i.e. Purchasing process). The controls shall include written quality agreements.
 
The process of D&D is by essence a process that affects product conformity, and thus legal manufacturers outsourcing development activities should view contract designers as critical service providers on which a risk-proportionate level of control must be ensured. This implies a risk analysis and risk management activities in relation to the outsourcing of design activities.
 
 

THE IMPORTANCE OF A QUALITY AGREEMENT

It is essential that a robust quality agreement be established between the two parties

Importantly, the legal manufacturer remains responsible in case of non-conformities with applicable standards and regulatory requirements. As a consequence, it is essential that a robust quality agreement be established between the two parties. Depending on the external party’s perceived ability to meet applicable requirements, additional controls may be necessary.
 
It therefore essential to properly qualify the contract designer as a critical service provider as per section 7.4 of ISO 13485. The maturity of both the legal manufacturer’s and the contract designer’s QMS is a key consideration in these processes.
 
The main schemes for establishing a quality agreement are either that the legal manufacturer accepts some specific provisions of the QMS of the contract designer; or that the legal manufacturer’s QMS is extended to the contract designer. It can also go both ways, with certain Design & Development activities addressed by the contract designer’s QMS, and others by that of the legal manufacturer.
 
In any event, a thorough and robust quality planning should be performed. Where the contract designer is responsible for establishing the design and development and/or the verification and validation plans, these must be approved by the legal manufacturer. The dispositions for design review and the authorities therein should also be made clear from the beginning.
 
Furthermore, it is important to clearly define which of the legal manufacturer’s or contract designer’s procedures will be used for each specific design and/or development process.
 
For instance, it could be agreed that the design verification activities will be performed according to the contract designer’s SOP for design control, whereas the design validation activities are to be performed as per the legal manufacturer’s SOP. Such an approach may require an in-depth integrative analysis of the two QMS’s to ensure compatibility of the processes.
 
The legal manufacturer’s risk management activities must account for the risks incurred by the outsourcing of Design & Development activities and the control measures implemented to mitigate them. These will be heavily influenced by the degree of maturity of the contract designer’s QMS. Indeed, a legal manufacturer with a mature and approved QMS may lean more on its own QMS if a contract designer were to present an immature QMS, and vice-versa. A situation where both actors present young, immature QMS’s should in all cases certainly be avoided.
 
The quality agreement between the two parties should therefore provide a detailed description of the arrangements, responsibilities, and authorities listed above. It shall moreover account for the control measures determined to be necessary to ensure the subcontracted D&D activities are performed as per the requirements.
 
It shall be noted that MDR holds provisions for the inspection of the premises of subcontractors by competent authorities in the context of their market surveillance activities(MDR Article 93(3)(b)). Furthermore, for medical devices for which the assessment of conformity requires the involvement of a Notified Body, the Notified Body may proceed, where applicable, to audit the contract designer during the conformity assessment procedure (MDR Article Annex IX(2.3) or during periodic surveillance audits (MDR Article (3.3); (3.4)).

Legal manufacturers should carefully consider the levels of controls that will be necessary and their implications in terms of costs in time and money – i.e. the “real” costs - before selecting a partner who will be entrusted with the Design & Development activities of their device

Medidee’s recommendation is that legal manufacturers should carefully consider the levels of controls that will be necessary and their implications in terms of costs in time and money – i.e. the “real” costs - before selecting a partner who will be entrusted with the D&D activities of their device. We would also strongly advise legal manufacturers against carrying out their first MedTech development with a novice contract designer.
 
Still, it is to be noted that a small contract designer may also decide in good faith to invest the actual effort to upgrade its practices, to train its personal and obtain an ISO 13485 certification. Simply, this type of decision belongs to major strategic moves and cannot be half implemented. Should a small contract designer decide to go this way, he/she should do it completely and correctly plan the future cost that this move will induce.
 
Are you a legal manufacturer seeking to outsource part or all of your design and development activities? Medidee will assist you in identifying and qualifying an appropriate partner for this process, in setting up the quality planning to ensure the requirements of ISO 13485 and the MDR are met, and in the establishing a robust quality agreement suitable to your specific needs.
 
We also help contract designers to build and implement a plan towards the new market of MedTech.
Contact us now !
 
This article was written by Dr Jérôme Randall.


PRRC function & liabilities

[ARTICLE] PRRC responsibilities, qualification requirements & legal liability

The MDR and IVDR introduce the requirement for device manufacturers and authorized representatives to appoint a Person Responsible for Regulatory Compliance (PRRC). The PRRC responsibilities, functions, and required qualifications are defined in Article 15 of the MDR and IVDR. Nonetheless, the question of the legal liability of the PRRC is not formally addressed.
 
PRRC candidates are often reluctant to accept the function due to the fear of the consequences this potential liability could incur. This article aims to discuss PRRC qualification requirements and PRRC function, as well as to clarify the legal liability of PRRCs.
 
 

PRRC responsibilities

 
As per MDR/IVDR Article 15, the PRRC is responsible for ensuring that the conformity of the devices is appropriately checked, in accordance with the manufacturer’s quality management system, before a device is released. He/she must also make sure the technical documentation and the EU declaration of conformity are drawn up and kept up-to-date.
 
Moreover, the PRRC shall ensure the post-market surveillance obligations are complied with in accordance with Article 10(10) and that the reporting obligations referred to in Articles 87 to 91 are fulfilled. Finally, in the case of investigational devices, the PRRC is responsible for ensuring the statement referred to in Section 4.1 of Chapter II of MDR Annex XV, or section 4.1 of Chapter I of IVDR Annex XIV, is issued (MDR/IVDR Article 15(3)(a-e)).

the responsibilities of the PRRC and clear rules in case of diverging opinion with the managing entity should be explicitly defined, for example in the PRRC job description, as to prevent any potential conflict of interest and ensure the PRRC is enabled with the required authority to carry out his/her function in accordance with the applicable Regulations

 

PRRC qualification requirements

 
The required expertise for one to be eligible for a PRRC role is detailed in Article 15(1).
 
The PRRC must either hold a university diploma or a certificate recognized as equivalent by the Member State concerned in the field of law, medicine, pharmacy, engineering or another relevant scientific discipline, in addition to at least one year of professional experience in the area of regulatory affairs or in quality management systems relating to medical devices; or alternatively possess at least four years of professional experience in regulatory affairs or in quality management systems related to medical devices.
 
In the case of custom-made devices, the PRRC may demonstrate the requisite expertise by having at least 2 years of experience in the relevant field of manufacturing.
 
 

PRRC in micro and small enterprises

 
Manufacturers are required to have a PRRC within their organization.
 
An exception is nonetheless made for micro and small enterprises, in which case the PRRC may be part of an external organization provided the permanent and continuous availability of that party is ensured through a contract.
 
Micro and small enterprises are defined as organizations that employ fewer than 50 persons and have an annual turnover and/or annual balance sheet does not exceed EUR 10 million (Commission Recommendation 2003/361/EC Article 2(2-3)).
 
The responsibilities of the PRRC may be distributed between two or more individuals within the organization, or, in the case of micro and small enterprises, shared between internal and outsourced resources. The MDCG 2019-7 guidance on Article 15 nevertheless clarifies that in all cases a close linkage between the PRRC and the product realization activities is incurred. Thus, the PRRC is expected to be located in close geographic proximity with the product realization site.
 
 

What about PRRC liability?

 
The question of PRRC liability is however much less clearly defined in the MDR. Generally speaking, an employee may not be held liable for ordinary negligence. The liability stands with the economic operator, and should be covered by the organization’s liability insurance.
 
Nonetheless, in the event of gross negligence or when intent can be demonstrated, the organization may resort to recourse, including legal action, against the employee. Resort to recourse may also come from other parties such as patients, association of patients or healthcare professionals if the device has led to a serious injury or death of the patient (Directive 85/374/EEC).
 
Personal coverage for the PRRC may be provided by including the PRRC in the organization’s Directors’ and Officers’ (D&O) liability insurance policy. In all cases, the responsibilities of the PRRC and clear rules in case of diverging opinion with the managing entity should be explicitly defined, for example in the PRRC job description, as to prevent any potential conflict of interest and ensure the PRRC has the required authority to carry out his/her function in accordance with the applicable Regulations.

In Belgium for instance (...) economic operators whom fail to comply with their obligations under MDR Article 15 shall face a criminal fine of up to EUR 50’000 and/or imprisonment of one month to one year.

 
The MDR and IVDR stipulate that the Member States shall law down the rules on penalties applicable for the infringement of the provisions of the Regulation, and thus on a national level fines and/or penal provisions are to be expected for organizations who do not meet the PRRC requirements. In Belgium for instance, the Act on Medical devices defines in Articles 71(6) and 68 that economic operators whom fail to comply with their obligations under MDR Article 15 shall face a criminal fine of up to EUR 50’000 and/or imprisonment of one month to one year.
 
This article was written by Dr Jérôme Randall.

How Medidee can help

 
Whether you are an organization seeking to complete an employee’s training to reach the minimal PRRC qualifications defined in the MDR, or a micro or small enterprise seeking to outsource PRRC functions, Medidee will support you through our recognized CARAQA training network or in providing external qualified regulatory affairs experts to fulfil this role. Contact us now!