How to Manage the Med Device Software Development Process in Your eQMS

Managing the medical device software development process is a big undertaking. Software as a device is regulated like any other medical device, but the process is not the same for device manufacturers and manufacturers creating medical software applications.

If you don't manage these requirements effectively, at best, you'll slow the time to market. At worst, there are significant liability concerns.

Your enterprise quality management system software (eQMS) should play a significant role in the process of managing deliverables required by the Quality System Regulation (Part 820) and ISO 13485.

The right eQMS integration can make it a lot easier to meet unique requirements for managing quality processes in the manufacture of software as a device. We’ll show you the unique considerations for companies in your vertical so you can confidently move forward and get to market quickly.

Managing the Medical Device Software Development Process in Your eQMS

Software as a Medical Device (SaMD) is one of the fastest-growing trends in medical devices. However, this category is subject to strict definitions from the US FDA. The FDA has clarified that SaMD is limited to “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device." The SaMD category does not include firmware or embedded software which is used to power a device.

SaMD is a unique classification category created by the FDA to bridge emerging regulatory gaps. Some examples of SaMD include:

• Applications used to view medical imaging on a mobile device
• Treatment planning applications which include AI or cognitive intelligence
• Software used to regulate implanted devices, like pacemakers or insulin monitors
• Software used to calculate BMI, body fat, or heart rate
• Applications which use AI to process images to diagnose cancer or other conditions

FDA guidance for SaMD states clinical evaluations are needed for SaMD applications, and specific guidance for development processes within the quality management system (QMS). During the software development of a SaMD app, developers are expected to prepare for premarket approval (PMA) by collecting and analyzing clinical data to develop a benefit/risk profile and provide evidence of the application's effectiveness.

The FDA’s draft guidance document describes the need for clinical evaluations of all SaMD applications, describing the same as a process activity that is conducted during a product’s lifecycle as part of the quality management system. Developers who code software for medical applications will be expected to assess and analyze clinical data and verify its safety, effectiveness, and performance. The right enterprise quality management system software (eQMS) can significantly streamline compliance and market approval.

Pick the Right eQMS

Trying to fit a generic eQMS into the highly specific requirements for medical device software is challenging. Customizing and configuring a broad quality management system to meet the unique requirements of ISO 13485, FDA 820, and SaMD guidance can be time-consuming and costly. It can also lead to regulatory gaps if you fail to incorporate any requirements.

Extensive configuration can increase the cost of required system validation each time you perform a significant update, which is something to keep in mind in fast-evolving, emerging fields like SaMD.

Your eQMS should be built specifically for organizations in the life sciences field, with special provisions for medical device manufacturers. Your SaMD organization needs a cloud-based eQMS, which is cost-effective and fast to implement and can begin delivering value quickly. Prioritize cloud-based eQMS applications which are built for compliance with ISO 13485 and FDA CFR Part 820, including design control and risk management.

The eQMS should offer a high degree of scalability with real-time features for global collaboration. It should provide automated workflows, and customized workflows to meet the requirements of clinical association and evaluation for SaMD products. It should also scale to accommodate new processes and capabilities as your SaMD product exits the development process and enters clinical trials for market approval.

Plan Ahead

In the realm of SaMD, a medical device manufacturer is never "just working on product development." Rigorous requirements for market approval require organizations to continually look ahead and create a sufficient trail of data for clinical validation of an application.

Some of the requirements for SaMD, according to the FDA, include:

Valid Clinical Association

Also known as “scientific validity,” a quantitative measure of the extent to which a software application is clinically acceptable and relevant to a real-world healthcare situation or medical condition.

Analytical Validation

Manufacturers are expected to provide "objective evidence" of sound software development processes. This includes effective software design for data processing. Analytical validation is also needed to verify the safety, performance, and effectiveness of the application.

Clinical Validation

To gain market approval, manufacturers must demonstrate "clinically meaningful" performance of a SaMD application. This can be shown with an application which has a measurably positive impact on the individual or public health, including clinical outcomes, diagnostics, prediction of risk, or prediction of treatment response.

Clinical validation may be gathered through clinical studies, but FDA guidelines also provide support for:

• Existing data from relevant studies for the same use
• Existing data from related studies for a different use
• Generating new clinical data

If your organization opts to use existing data sets, extrapolating results from this data must be fully justified.

SaMD manufacturers are expected to provide evidence of more than just real-world results. They're also required to integrate compliance into the product development lifecycle. Clinical validation should be built into the organization's lifecycle activities, according to the FDA. Documentation, data collection, and data analysis are a critical component of the product development lifecycle.

Educate Your Team

During the product development lifecycle, SaMD teams are expected to function with knowledge of future regulatory requirements. To pass regulatory audits, the team needs to operate with full knowledge of data collection, validation, and the strict FDA definitions of SaMD applications. Team education is critical to success in any highly regulated environment, but it's especially vital when teams are expected to validate a product during the development lifecycle.

Educate on Compliance

It's common for SaMD organizations to hire highly skilled development professionals with a background in writing code, artificial intelligence, analytics, algorithms, data science, or project management. While these individuals can bring the technical aspects of a product to market, they may lack knowledge of emerging requirements for SaMD approval. Compliance education is critical for every member of the workforce, especially when it comes to educating developers on SOPs, which may be very different than expectations in previous jobs.

RELATED READING: The 5 Best Medical Device Quality Assurance Training Options

Provide Technical Education

You can't transfer processes which are built for "normal" medical devices to a SaMD organization. Stakeholders who have a background in FDA-regulated industries but lack direct experience with software should undergo education on software best practices. This includes software updates, security, the agile development framework, and continuous deployment. This education should enhance cross-functional teams in the organization, which is built to combine technical and industry expertise.

RELATED READING: 4 Reasons You Need An Agile QMS (And The Easiest Way to Get One)

Support Continuous Integration

Continuous integration (CI) is a software development practice where developers frequently provide code updates, generally by uploading code to a shared repository. In a CI environment in which developers and QA operate separately, these frequent uploads allow for code to be tested in real-time. Provide education to your team members on CI and create clear SOPs to support the practice of continual testing for SaMD validation. The practice of CI can provide strong data of your organization’s efforts to collect and analyze data for clinical validation.

Set a Review Schedule

Your software should be continuously evaluated and tested by members of the development team, QA team, or other stakeholders in the organization assigned to validation analytics. A designated project manager or business analyst should always validate results against the project timeline and requirements to ensure development effort isn't wasted.

FDA guidance on software precertification designates several forms of product review which should take place during the product development lifecycle:

• Leadership and organizational review
• Infrastructure and work elements review
• Risk management review
• Configuration management and change control
• Measurement, analysis, and continuous improvement of process
• Design and development
• Verification and validation
• Deployment and maintenance

SaMD organizations are generally best served by frequently scheduled reviews which exceed standards or compliance requirements. ISO 13485 requires management review at planned intervals and clear documentation of these sessions. In a SaMD product development environment, a more iterative approach is necessary. Controls should be put into place to trigger real-time changes, and leadership should be actively involved in the review of the product development processes and collection of required data for market approval.

Document Everything

As the saying goes, "If it’s not documented, it didn’t happen."

In a SaMD environment, the developers are vital drivers for product realization. They're expected to play an integral role in documenting product development and data collection. For developers who lack a background in SaMD, steep documentation requirements can be new and challenging.

Many developers prefer to work closely to the code and find documentation projects challenging or boring. It's critical to communicate documentation expectations and ensure that your teams have a person dedicated to constant review and quality assurance of software documentation. This is a role typically handled by the project manager or business analyst.

FDA guidance on required documentation for the approval of software as a device is clear that the following forms of software documentation from the development phase are necessary:

• Level of concern statement
• Software description
• Device hazard analysis
• Software requirement specifications
• Software architecture design charts
• Software design specifications
• Traceability analysis
• Software development environment description
• Verification and validation documentation
• Revision level histories
• Unresolved bugs and defects

The level of documentation required in each of these categories depends on the level of concern associated with your SaMD application. An application could be classified as "Major concern" if the failure could result in serious injury or death to either the patient or the person operating the device. Minor concern occurs when failure is unlikely to cause any severe harm.

It's essential to use FDA guidance to classify the probable level of concern for your SaMD application early in the process to guide adequate documentation. Minor concern applications are not required to submit a report of unresolved bugs and defects or an architecture design chart, for example. Documenting everything regardless of concern level is a best practice, especially if you are unsure of whether your application will be classed as minor, moderate, or major concern.

Manage the Medical Device Software Development Process Wisely

Medical device manufacturers who are working to bring a SaMD product to market are subject to stricter regulatory requirements than manufacturers working on a traditional medical device. The requirements include rigorous guidance from the FDA on the real-time collection of data, constant product validation, and comprehensive documentation for each submission.

The right time to start thinking about regulatory requirements isn't after you've begun developing. It's during the product design phase before any code is written.

SaMD startups and scale-ups need an eQMS which is built to scale and makes compliant documentation easy. Fast-track the acquisition of a QMS which is built specifically to meet FDA 820 and ISO 13485 standards, and create strong internal education and awareness of constant documentation.

An eQMS should be right-sized to your organization's needs and begin providing value quickly after implementation with global collaboration features and strong document management.

Qualio is an eQMS built for small and growing life sciences companies. Get a demo of our software today.