[vc_row type=”1″][vc_column][vc_single_image image=”16716″ img_size=”full” alignment=”center”][vc_column_text]About the author: Yervant Chijian is Director, Team Lead Medical Devices / IVD, Australia, PharmaLex
Software as a medical device (SaMD) and software in a medical device (SiMD) have changed the face of the Med Tech industry. While these solutions bring innovation to the medical devices space, they do create complications with regards to ensuring the developments are compliant with regulations in various global markets. Med Tech companies must ensure they understand and adhere to specific processes and standards as they develop their SaMDs and other software devices.
The first key consideration is the software lifecycle process standard, IEC 62304, which not only provides the requirements of the deliverables and documentation that need to be generated, but also defines the processes, the activities and the tasks at various stages of the software development lifecycle for developing either SiMD or SaMD. As an international standard, IEC 62304 establishes a best practice framework for software development.
The activities involved include software development planning, defining software requirements, software design, software testing, configuration management, issue management and maintenance once the software is released. Since the standard doesn’t prescribe particular software development methodologies or techniques, developers can apply iterative design, such as the Agile Method, which allows for tweaks and changes and can accelerate development while meeting regulatory standards.
Verification and validation
Since testing must be specific to an operating system, there are inevitably verification and validation activities that are unique to software. Although the platform itself is not part of the medical device, manufacturers must still demonstrate that the software does operate on the specified operating system or platform. That means identifying the target platform and specifying that in the labelling instructions for use and defining a validation envelope for the product to be tested. Those verification and validation activities must comply with the ISO 13485 design control processes and be integrated with the manufacturer’s quality management system.
With post-market activities, there are a few specific considerations that must be incorporated within the software design and the QMS, such as issue management, vendor reporting, complaint handling, recurring problem resolution, quality assurance, customer feedback, and performance and quality metrics. It’s accepted that there will be bugs, patches and updates. The important thing is to do a risk and impact assessment of the various changes that are identified during the life of the software, incorporate them within the QMS and demonstrate that any issues are dealt with adequately.
Information security risks also must be addressed by monitoring your vulnerability and threats, especially when you have third-party software incorporated in your software build.
Clearly the QMS is key to managing product oversight and demonstrating compliance with the regulations. Again, there are standards to adhere to with building the QMS, specifically ISO 13485, which apply to medical devices organizations of all sizes and types. In addition, companies looking to supply to multiple territories need to understand the QMS requirements in all of those markets.
The regulations in Europe and Australia expect manufacturers to have established a QMS, however, it depends on the class of device whether the system needs to be certified. Class I devices aren’t required to be certified, but any manufacturer that has software that’s Class IIa and above needs to have a certified QMS.
Preparing QMS in advance
QMS considerations need to be defined upfront for the software design process, since it’s very difficult once you have developed software to retrospectively create design documents. Having a QMS established upfront ensures that all the required design documents will be developed during the design and development phases.
While some sub-systems within a QMS like inventory, warehousing and physical transport to manufacturing, don’t apply to software, issues like supply management do if, for example, you’re using subcontractors for software development or purchasing third-party code.
An advantage with standalone software is you can more easily manage change controls for post- market surveillance through automation. So, some parts of your QMS will be easier to achieve than with a hardware device, such as including device quality or performance metrics within your software for tracking and trending of quality issues.
With many safety and performance issues, such as risk management, clinical evaluation, cybersecurity and post-market surveillance, having a QMS in place will be key to demonstrating that all required steps have been handled effectively and that the company has a way to gather information once the product is released.
[vc_empty_space][vc_column_text]
Get in touch with our MedTech experts
Contact now[vc_row_inner css=”.vc_custom_1653895516815{margin-top: 30px !important;padding-top: 20px !important;background-color: #e2e2e2 !important;}”][vc_column_inner][vc_column_text]
Related Links:
[/vc_column_inner][/vc_row_inner][vc_row_inner css=”.vc_custom_1653895555344{padding-bottom: 20px !important;background-color: #e2e2e2 !important;}”][vc_column_inner width=”1/2″][vc_column_text]
Webinar
[vc_column_text]Watch our webinar: Considerations for Regulatory Compliance Success[vc_empty_space]Watch Webinar[/vc_column_inner][vc_column_inner width=”1/2″][vc_column_text]
Podcast
[vc_column_text]Listen to our Podcast: How software is changing the use of and types of medical devices[vc_empty_space]Listen Podcast[/vc_column_inner][/vc_row_inner]
