We're all thankful for the arrival of digital technologies that bring convenience to our fingertips. For example, applications such as Uber or Airbnb make finding transportation and a vacation home much easier and more efficient. 

But when it comes to medical devices that prevent sickness and improve the quality of life for millions, our respect level goes up significantly.

Who has yet to hear of or know someone whose quality of life has been changed by 3-D printed prosthetics, smart watches that monitor vital signs, and personalized medicines? These are just some of the many breakthroughs that have emerged in recent years under the general umbrella of digital health.

Building an app for the consumer and retail space is one thing. Negotiating the complex world of healthcare and FDA regulations and protocols is another. Building a piece of FDA compliance software is no small undertaking. 

IT practitioners and application developers must be prepared for the long and frequently difficult process of attaining FDA compliance and approval to ensure their software/device meets federal guidelines for the consumer market.

This article aims to provide guidelines, strategies, and best practices for navigating the complexities of building FDA compliance software. 

In the process, we want to provide awareness to the "gotchas" to watch out for, areas of regulation vs. non-regulation in digital health, and other levels of compliance that may not be so apparent at the start of the project.

Our goal is that you will be better equipped to successfully launch your medical device, application, or FDA software into the competitive and highly regulated digital health marketplace.

Navigating the Digital Health Ecosystem with FDA Regulatory Compliance Software

The area of digital health has experienced immense growth in recent years. Digital health includes mobile health (mHealth), health information technology (IT), wearable devices, telehealth and telemedicine, and personalized medicine.

Some of the prominent terms to be aware of in this growing market are:

Software as a Medical Device

SaMDs are defined by the 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." An example of this could be software that allows a smartphone to view images obtained from magnetic resonance imaging (MRI). 

Mobile Medical Applications (MMA)

According to the FDA definition, "Mobile medical apps are medical devices that are mobile apps, meet the definition of a medical device, and are an accessory to a regulated medical device or transform a mobile platform into a regulated medical device." Examples of MMAs are apps designed to provide antibiotic recommendations for the treatment of pneumonia or else to measure a patient's blood glucose levels. 

Medical Device Data Systems (MDDS)

This medical device provides the electronic transfer, exchange, storage/retrieval, and display of medical device data without altering the function or parameters of connected devices. An example is software that stores historical blood pressure or electrocardiogram information for later review by a healthcare provider.

When it comes to the health and compliance of these applications and devices, the primary agency that monitors these transformations in the United States is the Food and Drug Administration (FDA). A big question that often arises is how to know whether a medical device or app needs FDA approval.

Approval depends on the risk classification of the device. Class I devices like dental floss and bandages are subject to the most minor regulation. Catheters and wheelchairs are examples of Class II devices requiring FDA "clearance" before marketing. These products are under regulatory controls that reasonably assure their safety and effectiveness. Implants and life-sustaining devices such as heart valves are examples of Class III devices, which require premarket approval by the FDA and are subject to the highest levels of regulation.

FDA Regulatory Compliance Software can help mobile application developers and other digital health stakeholders navigate the complex and ever-changing landscape of FDA regulations. This FDA approved software can help ensure that digital health products are developed and marketed in a compliant manner and meet the high standards of safety and efficacy that the FDA expects.

Aside from the changing status and nature of the devices and apps, the entities and players in the field of digital health are rapidly expanding. It has moved beyond the realm of patient and healthcare practitioners to include private researchers, traditional medical device industry firms, and firms new to FDA regulatory requirements, such as mobile application developers.

Suppose you compare the changes that have hit the retail and consumer sectors in recent years and apply that to the FDA. In that case, the level of compliance and complexity involved in approvals, regulations, and the various stakeholders required to oversee these changes significantly differ from the mainstream consumer apps we interact with daily.

Don't Write a Line of Code Until You Nail FDA Software Requirements Engineering

 

Kicking off the build of your FDA medical device or FDA compliance software requires several components to be in place before you write the first line of code. These specific areas require strong oversight and relate to the "requirements engineering" phases that must be accomplished in order to ensure the full security and operational integrity of your FDA software system.

Authentication/Authorization

When building compliant FDA software, data integrity, and security are critical components. This means that every function in the system must be constructed to ensure that only authorized people can access the data they need.

 

When a patient is admitted to an emergency room, the on-duty doctor can access the patient's information. Still, upon transfer to the ICU, that patient's data will need to be released by another doctor with access rights. 

 

The medical records software must be designed with the appropriate authentication channels in mind to ensure that all patient data and privacy are protected each step of the way.

Audit Trail

An integral part of access rights is the audit trail. This is an electronic log of who has access to data, which data they can access, and (from a historical perspective) the time and date when they accessed it. 

 

Since security is critical to FDA compliance software, an audit trail provides a way for system fault tracking in case of a breach or system failure. For example, if someone downloaded records they were not supposed to, the audit trail will disclose who exported this report and when. 

 

The audit trail provides a historical electronic record to show that all transactions meet the full standards of FDA compliance and operational integrity.

E-Signature/Digital Signature

Today, more applications require two-step verification for an extra layer of security. Likewise, any FDA compliance software must also require a digital signature. 

 

This means users must supply their e-signature whenever accessing a report; the signature provides a historical record of who accessed, verified, processed, and approved a particular report at a given time.

Data Encryption

Another integral part of the FDA compliance software stage is data encryption. This ensures that all information is fully protected and preserved against unauthorized entry or tampering, whether in the database (when an electronic key is required for access) or transferred over the web. In cases of data transfer, complete SSL connections must be ensured between the web app, the database, and the end user.

Data Retirement

In the same way that security protocols surround the storage and transmission of live data, compliance standards follow on how that data is retired. According to the FDA CFR regulations 21, data is maintained until "the person maintaining the record becomes aware that the device is no longer in use, has been explanted, returned to the manufacturer, or the patient has died."

Verification, Validation & Functional Requirements Documentation

 

Developing an FDA compliance software designed according to customer specifications involves a rigorous process of gathering information, validation, identifying between assumptions, constraints, and requirements (functional, performance, and non-functional), and testing against the criteria to verify that everything meets those specifications.

 

Additionally, users must be trained on the proper use and upkeep of that FDA software system. To ensure the system works and functions as planned, drawing up an appropriate set of requirements and specifications from the project's outset is critical. 

 

In addition, all change requests (CRs) for the requirements must be appropriately tracked throughout the verification and validation stage.

Engineering Requirement Musts

• Below are some major specifications crucial to ensuring your FDA compliance software is planned, built, and delivered efficiently and without enormous cost overruns and delays.

 

Software Requirements Specification (SRS)

• This document essentially describes what the FDA software will do and how it will be expected to perform. It serves as a critical source of information for ensuring that your teams (development, quality assurance, operations, and maintenance) are all on the same page throughout the software build lifecycle.

 

Architecture Design Chart

• Software developers need clear system architecture diagrams to understand, clarify, and communicate ideas about the FDA software-compliant system structure and the user requirements that the system must support. This basic framework can be used during the system planning phase to help the partners and stakeholders understand the architecture, discuss changes, and communicate intentions clearly.

 

Software Design Specification (SDS)

• This is a written description of the FDA-compliant product, which provides the software development team with overall guidance on the system's architecture. An SDS usually accompanies an architecture diagram and offers pointers to more detailed feature specifications of smaller design pieces.

 

Traceability Analysis

The traceability analysis aims to ensure that all requirements for the FDA compliance software system are properly tested during the test protocols. This document serves as a tool for two groups:

1. the validation team, responsible for ensuring that requirements are recovered during the validation phase, and
2. auditors, who will thoroughly review the validation 

Impact Analysis

• This process should be performed for any Change Requests (CRs) using a Requirement Traceability Matrix (RTM). RTM allows developers to measure test coverage and map system requirements and CRs.

Test Early, Test Often for a Good Performing FDA Approved Software

Achieving full FDA software compliance requires rigorous testing to ensure the software meets full standards for the consumer market. The FDA has identified a set of published standards that it "considers to apply to the validation of medical device software or the validation of software used to design, develop, or manufacture medical devices."

The following list provides an additional set of best practices that should be followed to ensure that your FDA compliance software testing strategy stays on track.

1. Source Control

Tracking and managing all changes to your code before and during the test process is integral to the success of your FDA compliance software. Having a proper source control platform means that developers can trace each test run on a certain date against the specific software requirements for those test cases.

2. Link All Test Case IDs with Requirement IDs

Every software requirement is assigned a unique ID, but when it comes to the testing phase, that ID may become linked to multiple test cases. A test case ID is not uncommon to become linked to more than one requirement.

3. Formal Test Case Review

A formal test case review must be conducted and documented during the validation and verification stage; this is a peer-reviewed process. Any comments are documented in the validation and verification document following the peer review. This process ensures that the test case design and execution are undertaken with the highest level of quality and oversight.

4. Code Freeze Before Starting the Test Cycle

Code freezes are meant to place a hold on code changes during the test cycle to ensure that everything is documented correctly. Code freezes should be completed against an entire test cycle to ensure that already executed test cases work as expected.

5. Performance Execution Cycles

This is a critical part of the FDA software testing process. We run 100% of the test cases during this stage in one cycle. Any bugs are corrected from this initial cycle, and then for cycle 2, only the test cases affected by bugs are run; usually, this is about 70%. The third cycle, the regression cycle, is where we only select the critical and high-priority scenarios for testing (on average, about 30% of test cases).

6. Log the Results of Each Test Case

To document the results of your test case, log into your source control system. After that, you will need to print and sign each test case and identify who verified and who approved the result. 

Taking screenshots at each stage of the logging process is an additional best practice to preserve a record of all transactions. It's important to note at this stage that bug reporting and the linkage of the bug to the test case must be completely traceable. If a test case fails, the standard process is to document the bug and then link the bug to the test case.

7. Sign Off on Each Test/Test Result

Ensure that each test is documented so you can go back and show that a test was run on this date against this version of the requirements and these particular cases.

Submitting Your FDA Software for FDA Approval

Finally, after many weeks, months, and even years of planning and testing, your software is ready to be submitted for FDA approval. 

The process for FDA software approval depends on how your device or application falls into the FDA regulatory hierarchy of Class I, II, and III. Determination of classification is determined primarily by the level of risk the devices pose to the patient.

Most Class I devices can be self-registered for approval, but most Class II devices require a 510(k) submission. For Class III devices, a Pre-Market (PMA) submission is needed. A helpful outline for registering a medical device with the FDA is provided here.

What's Next/Trending

There's never been a more exciting time to be involved in digital health innovation. With the rapid advance of AI, the Internet of Medical Things, and telemedicine, there is no end to the possibilities for improving a patient's overall quality of life. 

Many new players are entering the market and spinning up new devices and applications that promise to dramatically shift the relationship between patients, doctors, and healthcare providers for decades to come.

The FDA is committed to supporting this dramatic market shift and streamlining the regulatory oversight process. For example, the Software Precertification Program test plan was rolled out in January 2019. It rewards "manufacturers who have demonstrated a robust culture of quality and organizational excellence and are committed to monitoring the real-world performance of their products once they reach the U.S. market."

Whether you're a new medical device startup seeking to build and release a new SaMD or MMA or an existing enterprise, digital health is a fast-moving target that's constantly changing. You may have started down this road but are stuck on the process and the choice of what strategy you need to bring your software to market. Or you've already created the software but are having trouble with the FDA approval process.

Whatever the case may be, Integrant can help! We have a longstanding track record of partnering with organizations just like yours to scale and reach their strategic business goals in the digital health marketplace. 

Whether you're in your software's planning, testing, or build phases, we know what it takes to develop and test an approved FDA compliance software. Contact us today to find out more!