A Regulatory Approach Manual for Device Software Functions

Posted by Sierra Labs on May 7, 2020 9:09:00 AM

How to effortlessly define a Regulatory Approach for your Medical Device Software Function

Hero-4

Manufacturers and authorities are often experiencing uncertainty surrounding whether a software is classified as a medical product or not. 

Although the FDA has not issued an overarching software policy, software applications may still fall under the regulatory oversight of the FDA based on their 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 you a head-start on defining a regulatory approach for your “device software functions”. 

  • “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:

Info (1)

  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:

Under FDA's Enforcement Discretion

  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. Throughout the device's production stage, your team must also compile supporting documentation to help you verify your device's classifications before any submission. Manually documenting these processes can further complicate your device's journey to market!

Here at Sierra Labs, we help organizations like yours automate their processes and reduce risk by providing tools to stay within FDA's regulatory standards. Sierra Document Automation is a valuable tool that integrates with your current systems, ensuring an automated documentation process to support your device's regulatory path.

Sierra Document Automation allows you to generate audit ready documents, upload personalized SOP templates, and sign documents electronically with e-signature capabilities.

Want to see how Sierra Document Automation can automate your compliance processes?

Contact us for a free demo below!

Sierra Document Automation

Easy compliance starts here.

Topics: SaMD, Medical Devices, Medical Device Company, Manufacturing, Device Software Functions, SiMD, Risk Classification, Enforcement Discretion, Regulatory Approach, QS, Quality System Regulation, 21 CFR, General Controls, Documentation, Compliance Process

Recent Posts

Topics

See all

Subscribe Here