Home

Blog

Case Studies

Services

Contact

We're all thankful for the arrival of digital technologies that bring convenience to our fingertips. Applications such as Uber or AirBnB, for example, 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, then our respect level goes up a significant notch.

Who of us hasn't heard of or known someone personally 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 approved and compliant software is no small undertaking. IT practitioners and application developers must be prepared for the long and oftentimes difficult process of attaining FDA compliance and approval to ensure their software/device meets federal guidelines for the consumer market.

In this article, we aim to provide a set of guidelines, strategies, and best practices on how to navigate the complexities of building FDA compliant 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 come away better equipped to successfully launch your medical device or application into the competitive and highly regulated marketplace of digital health.

1. Navigating the Digital Health Ecosystem: What You Need to Know
2. Don't Write a Line of Code Until You Nail Requirements Engineering
3. Testing, Testing & More Testing
4. Submitting Your Software for FDA Approval
5. What's Next/Trending

The area of digital health has experienced immense growth in recent years. Broadly speaking, digital health includes categories such as 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 (SaMD)

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 a 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)

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

When it comes to health and compliance of these applications and devices, the primary agency that monitors these transformations in the United States is, of course, the Food and Drug Administration. A big question that often comes up is how to know whether a medical device or app needs FDA approval. A good rule of thumb is provided by the following paragraph, which touches on how FDA classifies these various devices.

Approval depends on the risk classification of the device. Class I devices, such as dental floss and bandages, are subject to the least regulation. Catheters and wheelchairs are examples of Class II devices that require FDA "clearance" prior to 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.

Devices that have already been medically approved or cleared by the FDA are being continually updated to add new digital features and remain in compliance. This should be taken into consideration when looking at the approval process. For example, the category of MMDS was reclassified in 2015 from Class III (subject to premarket approval) to Class I (subject to general controls). However, SaMDs and MMAs still do require FDA approval, since they are classified as "medical devices" (though some categories of MMAs are not devices, such as medical dictionaries).

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

If you compare the changes that have hit the retail and consumer sectors in recent years, and apply that to the FDA, then the level of compliance and complexity involved in approvals, regulations, and the various stakeholders required to oversee these changes is significantly different than the mainstream consumer apps that we interact with on a daily basis.

Kicking off the build of your FDA medical device and/or compliant 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.

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 compliant 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. Essentially, the audit trail provides a historical electronic record to show that all transactions are meeting the full standards of FDA compliance and operational integrity.

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

Take the case of when a patient is admitted to an emergency room, the    on-duty doctor would have access to the patient information, but upon transfer to 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.

Today, more and more applications are requiring two-step verification for an extra layer of security. Likewise, any type of FDA compliant 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.

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

In the same way that security protocols surround the storage and transmission of live data, so 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 of the fact that the device is no longer in use, has been explanted, returned to the manufacturer, or the patient has died."

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

Additionally, users must be trained on the proper use and upkeep of that software system. In order to ensure the system works and functions as planned, it is critical to draw up a proper set of requirements and specifications from the outset of the project. In addition, all change requests (CRs) for the requirements must be appropriately tracked throughout the verification and validation stage.

• Below are some of the major specifications that are important to ensuring your FDA compliant software is planned, built, and delivered efficiently and without enormous cost overruns and delays.

• This document essentially describes what the 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.

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

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

• The purpose of the traceability analysis is to ensure that all requirements for the FDA compliant system are properly tested during the test protocols. This document serves as a tool for two groups: 1) the validation team, who are responsible for ensuring that requirements are not lost during the validation phase, and 2) auditors, who will be thoroughly reviewing the validation documentation.

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

Achieving full FDA compliance requires a rigorous level of 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 be applicable 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 in order to ensure that your FDA compliance 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 in place a proper source control platform means that developers will be able to 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. It's not uncommon that a test case ID becomes 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. Following the peer review, any comments are documented in the validation and verification document. This process ensures that the test case design and execution is 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 properly documented. Code freezes should be completed against a full test cycle to ensure that already executed test cases work as expected.

5. Perform execution cycles

This is a critical part of the testing process. During this stage, we run 100% of the test cases 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, called 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

In order 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, as well as 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. In the event a test case fails, the standard process is to document the bug 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 against these particular cases.

Finally, after many weeks, months, and even years of planning and testing, your software is now ready to be submitted for FDA approval. The process for 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 primary by the level of risk the devices pose to the patient.

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

There's never been a more exciting time to be involved in the area of digital health innovation. With the rapid advance of AI, Internet of Medical Things, and telemedicine, there is no end of the possibilities in sight for improving 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.

For its part, the FDA is committed to supporting this dramatic market shift and streamlining the process of regulatory oversight. For example, the Software Precertification Program test plan was rolled out in January 2019 and is committed to rewarding "manufacturers who have demonstrated a robust culture of quality and organizational excellence, and who are committed to monitoring 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 else an existing enterprise, the area of digital health is a fast-moving target that's constantly changing. Perhaps you've 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 else perhaps 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 the planning, testing, or build phases of your software, we know exactly what it takes to develop and test FDA compliant/approved software. Contact us today to find out more!

Company

Contact

Follow US

About Us

Address: 16870 W Bernardo Dr, Suite 250

San Diego, CA 92127

Email: info@integrant.com
Phone: +1 858.731.8700

Privacy Policy

© 2021 Integrant, Inc. All Rights Reserved