A Regulatory Approach Manual for Device Software Functions

Understanding the policies for your Medical Device Software Functions

Manufacturers and authorities are often experiencing uncertainty when classifying their software under regulatory specifications. 

It is important for any company developing Software as a Medical Device (SaMD) to understand their device's required regulatory oversight based on FDA classifications. Regardless of the shape, size, or platform, this subset of devices is still taken with the same administering caution as any medical device out on the market.

Definitions to know

Understanding the terminology surrounding software functions in the regulated industry will give SaMD startups a head-start on defining a regulatory approach for your “device software functions”. 

• “Device software functions” - software functions that are device functions
  
  
• May include: Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD)
• To learn the difference between SaMD and SiMD, check out our blog “Medical Device Software & SaMDs: A Crash Course”

• “Manufacturer” - anyone who creates, designs, develops, labels, re-labels, remanufactures, modifies, or creates a mobile medical app software system from multiple components. 
  
  
• This same person is also in charge of the specifications or requirements for the device’s product development.

Policy for Device Software Functions and Mobile Medical Applications

Now that you know the terminology, you are ready to discover how as a manufacturer you can find the right regulatory approach for your medical device.

In 2019, the FDA’s updated its regulatory guidelines for device software functions into two categories:

• Subset of software functions under FDA’s regulatory oversight
• Subset of software functions under FDA’s enforcement discretion

Software functions under FDA’s regulatory oversight

Identifying specific regulatory requirements for your device becomes more straightforward when you can define the type of software functions your device contains.

Software functions may take a number of forms, but it is important to note that the FDA intends to apply its regulatory oversight to only the subset of software functions who may have a higher level of risk. These specific type of software functions can transform a general-purpose computing platform or mobile platform into a regulated medical device. They are listed below:

1. Extension Devices
   
   
• Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.
  
  
2. Attachment, Display Screen or Sensor Devices
   
   
• Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors or by including functionalities similar to those of currently regulated medical devices.
  
  
3. Sophisticated Analysis Devices
   
   
• Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations. Similar performing functions have been previously cleared or approved.

Because of the low-risk nature of the following devices, the FDA only intends to exercise "enforcement discretion" on this subset. In other words, the FDA will not expect manufacturers to submit premarket review applications or to register their software with the FDA. These device software functions are usually designed to:

1. Automate simple tasks
   
   
   • Help patients, or users, self-manage their disease or conditions without providing specific treatment or treatment suggestions
     
     
2. Facilitate supplemental clinical care
   
   
   • These are software functions that supplement professional clinical care by facilitating behavioral change or coaching patients with specific diseases or identifiable health conditions in their daily environment.
     
     
3. Grant access to health information
   
   
   • This includes software that provides contextually-relevant information to users by matching patient-specific information (diagnosis, treatments, allergies, signs, or symptoms) to reference information routinely used in clinical practice (e.g., practice guidelines) to facilitate a user’s assessment of a specific patient.
     
     
4. Provide patient communication
   
   
   • These products either pose little or no risk or are the sole responsibility of the health care providers who have experience with them in medical applications.
     
     
5. Perform simple calculations
   
   
   • These are software functions that are intended to provide a convenient way for clinicians to perform various simple medical calculations taught in medical schools and are routinely used in clinical practice.

Risk Classifications for Medical Devices

Now that you know if your device software function is considered a medical device under FDA’s regulatory policy, you will have to adhere to the rules of your device’s Risk Classification. 

Depending on the Risk Classification for the device software function, manufacturers are required to implement the proper controls to ensure a record-keeping of safety.

• Class I (general controls)
  
  
• Class I devices: General Controls, including:
• Establishment registration, and Medical Device listing (21 CFR Part 807)
• Quality System (QS) regulation (21 CFR Part 820)
• Labeling Requirements (21 CFR Part 801)
• Medical Device Reporting (21 CFR Part 803)
• Premarket Notification (21 CFR Part 807)
• Reporting Corrections and Removals (21 CFR Part 806)
• Investigational Device Exemption (IDE) requirements for clinical studies of investigational devices (21 CFR Part 812)
  
  
• Class II (special controls in addition to general controls)
  
  
• General Controls (as described for Class I), Special Controls, and (for most Class II devices) Premarket Notification.

• Class III (premarket approval): 
  
  
• General Controls (as described for Class I), and Premarket Approval (21 CFR Part 814)

Regulatory Requirements for Device Software Functions

Now that you know where your device software function(s) stand under the FDA’s classification, you are in charge of complying with the Quality System regulation, also known as QS. 

This regulation basically states that manufacturers of software functions that are considered medical devices are required to follow “good” manufacturing practice. In other words, the FDA wants manufacturers to be able to follow a set of regulations to prevent a user or patient harm or instill proper corrections when there is an inaccuracy.

The QS does not explain in detail how a manufacturer must produce a specific device but instead provides a framework for all manufacturers to develop applicable requirements and specifications for the design, production, and distribution of the device.

How to get your device on the right regulatory path

Deciding the correct regulatory approach for your medical device can be a hectic process mainly because it requires a high level of documentation. Manual documentation can further lag development processes.

Here at Sierra Labs, we developed an out-of-the-box QMS for medical device startups with built-in document automation tools to streamline compliance processes. Sierra Quality Management System (QMS) offers you a robust start to identifying relevant regulatory requirements pertaining to your SaMD's risk classification.

Sierra QMS is designed for SaMD startups looking to market their solutions in a global regulated environment. Our solutions allow you to easily integrate risk management into your production process and operate with your own preferred tool-sets.

Want to see how Sierra QMS can automate your documentation processes?

Contact us for a free demo below!

Easy compliance starts here.