Over the past decade, one the most innovative areas of software development has been in the field of medical device. 30 years ago, medical device software powered large complex machines inside hospitals and laboratories, but today teams can build software that runs on tablets, phones, or smart devices. However, even if you are building an app for an iPad, your software must meet the same regulations as programs that power MRI and EKG machines. In 2020, major regulatory changes are going to come into effect which will significantly impact how teams need to design their devices and document their development. Firms in the medical industry can’t take chances with their compliance, so it’s important they understand and prepare for these changes.
Regulatory Changes in the Medical Industry
In the EU, medical devices must meet stringent regulatory requirements in order to be certified with a „CE“ mark. This includes requirements relating to the creation, storage, and approval of documentation. In order to be released to the public, a medical device’s software documentation must pass regulatory audits to ensure it is complete and accurate.
In 2017 the EU announced significant changes to their regulatory requirements. The European Medical Devices Directives was replaced by a new set of rules called Medical Devices Regulation (MDR). There are two major consequences of the new requirements:
- Some medical hardware and software products that were previously certified have to re-apply to pass the more rigorous standards
- Devices that were previously exempt from the stringent rules are now included under the requirements
These two factors mean that suddenly a large number of teams need to have QMS systems that pass regulatory audits. The EU set a deadline of May 26th, 2020 for companies to certify their products. This has led to a number of teams searching for new documentation systems that can meet their needs, and it has also created a backlog with audit bodies.
What Must Developers Do?
The first step for developers is to find out whether your software requires a QMS audit. The new MDR regulations classify products into three categories; I, II, and III. Although Class I device developers must have a QMS, they will not be audited by a Notified Body; class I is considered „self-certified“, so their QMS does not require a formal audit.
If your product falls into the other categories, II or III, then it’s critical that you move forward building your documentation properly. You need to ensure that you are providing the right kind of documentation, that it is being stored correctly, and that it has been approved by the right people. This blog provides a step-by-step overview of the compliance process.
The process may seem daunting, but there is help available. Documentation systems like Atlassian Confluence can form the backbone for your QMS. A number of teams have combined Confluence with apps like eQMS and Comala Workflows, and several have already passed their QMS audits with these apps. And, a Solution Partner like Communardo can be there to answer any questions you might have and support you on the road to regulatory compliance.
Need more information? There are a variety of blogs online about this topic: