IEC 62304 scope and what it means for you
The scope of the IEC 62304 standard requires following a development process based on users’ needs and is essentially made of 3 major activities:
- the implementation of an actual, defined development process,
- which, in turn, is associated both to a software configuration management system,
- and to a system for requirements management, risk management and associated risk mitigating management.
In parallel, the whole process is encompassed within a broader release and test management system as to cover and ensure all the activities related to bug tracking and change requests. The ultimate purpose is building a system that can ensure both 100% traceability – from the very first customers’ needs to its satisfaction – and compliance with the industry standards.
It is important to note that the IEC 62304 norm does not require the implementation of precise verification and testing techniques, or any standardized process to be applied to all types of organizations. However, it does require that each enterprise in scope adopts and sticks to a rigorous method throughout the entire lifecycle of its medical device software in order to prove requirements compliance, which is actually mandatory for audit purposes. This is why it is crucial to set a Software Quality Assurance Plan (SQAP) to outline all the project specifications upstream, as to ensure delivered products’ conformity and ultimately reduce the risks to an “acceptable” level.
[obflink-image link=”https://content.tuleap.org/webinar-iso-13485-iec-62304-keep-processes-under-control” id=”229151″ alt”ALT” class=”my-image” target=”_blank” size=”large”]
What are the consequences of non-compliance?
Audits and defects
Manufacturing organizations of medical device software are subject to several compliance audits. They are conducted by external auditors of a Notified Body and can last one or more days either on-premises or remotely, depending on their type and scope. In a nutshell, it can be:
- CE marking audits for new product(s) launch
- Renewal audits every 3 years
- Follow-up audits once a year
- Unannounced audits at least once every 3 years, in addition to the traditional three-year certification cycle
In the case of defects detected during audits, there are two types of non-conformities:
- minor non-conformity: the organization has to fix it before the next upcoming audit, so that it won’t become a critical one (aka a major non-conformity)
- major non-conformity: the organization must fix it within 3 months before it is re-audited. It this defect is not properly addressed, the company will no longer be authorized to sell the product concerned as long as it is not corrected
Overall risks of a non-optimized software project management system
Risking not to comply with standards
- Prohibition to sell products on the market
- Increase of time-to-market
- Loss of marketshare
Failing to meet demand expectations
- Bad corporate image
- Decrease in customers and suppliers propensity to trust the enterprise
- Increased need of quick defects monitoring and resolution
In short, being able to organize, adapt, and – above all – rapidly react are now crucial factors not only to prove software and product compliance to auditors but also to efficiently cope with changes within a fast-moving environment, including changes in (market) standards that are becoming increasingly demanding.
Why relying on an ALM tool is so important?
Application Lifecycle Management is a key success lever for companies developing embedded software products. The implementation of a good ALM tool is hence fundamental for both the development and the quality control of software in the medical industry. In fact, it makes it possible to better manage the entire application lifecycle, facilitating both on-site and remote audits since all data and processes are centralized under one roof, on a single platform.
Track every item, automatically
Proving traceability throughout the whole software development process is a major concern.
As soon as possible
Is it possible to check and adapt the process to meet the IEC 62304 standards even for developments that have already started? Well… the earlier it’s done, the smaller the risks of identifying last minute issues which would lead to mandatory adaptations, likely to delay the compliance process and ultimately the software release. This is why we suggest that you build good habits as soon as possible, from the start.
Embrace a more iterative, agile approach
Waterfall development approaches are widely used in the medical field, however, it is important to bear in mind that the IEC 62304 standard does not impose the implementation of any precise development methodology. In fact, a more incremental approach is possible too, as long as all changes are tracked. And for this, agile methods are full of good practices that can definitely create a lot of value for medical device software projects.
