IndustryDoctors ClubNewsProfessionals ClubTechnology

Top 3 Questions to Ask Your Team Before Developing Software As A Medical Device (SaMD)

The questions you ask before you pull the trigger on a new software as a medical device represent an extremely important investment of time.

Health and life science organizations are constantly striving to improve patient centricity and to optimize their product development lifecycle in order to deliver new products to market quickly and to remain competitive. COVID-19 has accelerated many trends across the sector, including organizations adopting digital technologies such as Software as a Medical Device (SaMD) to complement and enhance their therapeutic portfolios.

Well-known examples of SaMD include the electrocardiogram (ECG) of the new Apple Watch (see its De Novo classification request here) or an automated insulin adjustment software by Tandem Diabetes Care (see FDA’s evaluation of automatic Class III designation for control-IQ technology here).

Whether your organization is interested in software adoption to build in continuous data acquisition, offer remote care capabilities, improve patient engagement, or simplify routine clinical tasks, SaMD is at the center of it.

Before getting started on your project, answer these three questions:

  1. What updates does my team need to make to our quality management system?
  2. How can we leverage an agile methodology for this project?
  3. What regulations apply to commercializing our SaMD?

1. What Updates Does My Team Need To Make To Our Quality Management System?

Start by updating your existing quality management system (QMS). You’ll need a QMS compliant with ISO 13485 that is risk-based per ISO 14971. A QMS allows for a robust set of processes that ensure a systematic approach to developing, commercializing, and monitoring medical devices, which includes implementation of appropriate controls based on the evaluation of identified risks.

If your company is new to medical device manufacturing, this is a big ask because you’ll need to thoroughly review your business processes against the requirements in order to identify gaps and resolve them. More specific to software, you can find further guidance regarding risk’s application to medical device software in ISO 80002-1.

In addition to a QMS and risk management, you will also need to embed the medical device software lifecycle process per IEC 62304, which will enable you to have the required deliverables specific to software. The implementation of this standard will vary based on the software safety classification derived from the software’s risk profile described in the standard.

As the software safety classification increases from A to C, more requirements for processes and outputs outlined in the standard will apply. Fortunately, the standard clearly links each requirement to the applicable software safety classification(s) for easy mapping.

Compliance with this standard will enable your organization to have credibility with regulatory bodies, acting as an endorsement that the proper activities and tasks were completed to ensure the safe design and maintenance of your medical device software.

2. How Can We Leverage An Agile Methodology For This Project?

An agile methodology is an iterative product development approach that brings high-quality products quickly to market by working collaboratively in self-organized teams.

Using this approach will enable your organization to work dynamically and efficiently throughout the development process using tools to promote transparency and cooperation rather than operating within like-minded silos. After receiving leadership buy-in, the initial step is to create an agile team composed of key internal stakeholders across business functions.

It is important to allow team members to establish their time commitment to the project — the agile principle of capacity allocation — to ensure everyone is committed and available to achieve project goals. In addition, the team must align with an agile business sponsor responsible for communication across the organization on a regular basis.

Software as a Medical Device is defined by the International Medical Device Regulators Forum (IMDRF) as "software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device."
As per FDA’s website the term Software as a Medical Device is defined by the International Medical Device Regulators Forum (IMDRF) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”

Throughout the development process and across the agile team, regular touchpoints are necessary to reduce hurdles that often show up later in the process, when working in silos. One recurring method is implementing daily stand-ups, which can be done virtually using online meeting tools, followed by shared action items.

Another project management method is to share each person’s responsibilities and the overall project status using visual tools such as Kanban boards (a way to visually depict work at various stages of a process using columns to represent each stage of the process and cards to represent work items) and Jira (a software management tool to track issues and bugs related to your software).

This will allow for project-wide transparency with clear delineation of responsibilities and will ultimately enhance speed to market.

3. What Regulations Apply To Commercializing Our SaMD?

After implementing QMS and agile processes, it is essential to properly evaluate your device’s final intended use to determine the regulatory pathways. Although we are talking about SaMD solutions, your organization will want to verify that the device you want to build is, in fact, a medical device. For guidance, health authorities have tools available such as:

Make sure to capture all the region-specific requirements where you intend to commercialize your device, such as U.S. regulation and EU regulation, into a comprehensive list that can be used to map out your device development planning.

In addition to country-specific regulations, you will also need to incorporate the EU’s Global Data Protection Regulation (GDPR) as well as U.S. requirements related to the Health Insurance Portability and Accountability Act of 1996 (HIPAA), interoperability, and cybersecurity as design inputs to ensure the device communicates and stores data securely and integrates properly with other key technologies.

SaMD is a growing space in which you’re competing with other health and life science companies to deliver on patient centricity and offer innovative ways to engage patients. The impact of COVID-19 has fueled the need for devices that accommodate urgent challenges afforded to patients and healthcare systems worldwide looking at solutions such as SaMD as the future.

Health authorities, such as the FDA, are often viewed as gatekeepers in medical device development; however, they should be viewed as a collaborative partner as they too are incentivized to promote innovation and streamline device approval to benefit patients.

If a cutting-edge technology doesn’t fit into an existing regulatory framework, the FDA will collaborate with an organization to identify an acceptable path to device approval. Although there are challenges that arise with implementation of SaMD development, you’ll now be in a good position to tackle those challenges and make your SaMD a reality.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button