Here’s What FDA Compliance Means to You

When it comes to medical software development, businesses can fall into one of two traps:

1. They are unaware that the product they want to create has features that are subject to the FDA’s scrutiny.
2. They overcompensate in their documentation efforts for fear of the FDA’s ability to condemn the project with little notice.

While a thumbs up from the FDA is indeed the gold standard for pharmaceutical development or some cases of medical software development, product owners may be surprised to learn that their digital health solutions do not always fall under the purview of the FDA.

Even when they do, understanding the FDA’s regulatory nuances allows product owners of medical software development projects to control their budgets more easily.

Exploring Medical Software Development? Tread Carefully.

While leaders of startups who look to break into digital health might underestimate the FDA’s purview, enterprise leaders with legacy knowledge of medical device or pharmaceutical development might have the exact opposite issue. They can be overly cautious as they weigh whether FDA clearance is required for medical software development to proceed.

Whatever the business perspective, properly aligning solution development with related industry regulations is no joke — the FDA has every right to shut down a business’s operations at any hint of non-compliance.

How Does the FDA Choose to Regulate Medical Software Development?

The FDA now has language to define its oversight of solutions advertising various health benefits on app stores.

In a recent document, the US government clarified the FDA’s regulation of mobile medical apps. It defines a mobile application as software that can be run on a mobile platform, or a web-based software application that is tailored to a mobile platform but executed on a server. The FDA names iPhones, iPads, and other personal devices as examples of what it calls a “mobile platform.”

Is Your Medical Software Development Project Subject to FDA Review?

While the FDA has final say over whether a solutions falls under its purview based on the benefits it claims to provide users, some simple prompts can help to determine whether your digital solution will require review from the Agency.

Medical Software Development: Subject to FDA review when:

• The app controls another connected medical device. As an “accessory” to the connected device, it is subject to the same regulatory treatment as the connected device.
• The solution performs patient-specific analysis and diagnosis or recommends treatments. The app uses patient-specific information to measure dosage or design a dosage plan for radiation therapy, for example.

Medical Software Development: Not subject to FDA review when:

• The app helps users self-manage their disease without providing specific treatment suggestions.
• It gives users simple tools to organize and track their health information.
• It allows patients to access information relating to health conditions or treatments.
• It helps patients document, show, or share potential medical conditions to healthcare professionals.
• The app simplifies clerical tasks for healthcare providers.
• It enables patients and providers to access personal health records or electronic health record systems.

If a digital health product doesn’t make disease-specific claims in its marketing materials or general description, then it is free from requirements demanded by the FDA for more condition-specific solutions.

Does Agile Work in the World of Medical Software Development?

When auditing medical software development projects, the FDA wants to know:

• Is the product safe?
• Does it work?
• Will it keep working?

For product owners who understand the importance of responding to these questions, documentation is everything, and Waterfall is the logical way to leave enough bread crumbs for FDA auditors.

Savvy Product Owners Say “Yes!”

Technical teams that have successfully built digital solutions for the healthcare industry know how to adapt Agile to the Waterfall mindset that defines healthcare. When the two are balanced, products in need of FDA certification receive the green light faster, and those that don’t can relieve themselves of the documentation headaches altogether.

The sooner product owners see the potential for Agile in medical software development, the sooner they will see their barriers to success begin to reduce in size.

How Do You Make Agile Work in Healthcare’s Waterfall World?

• Identify and isolate critical solution components that must be FDA-approved (the FDA’s approval metrics for components like two-factor authentication and password reset overlap with many of those outlined in HIPAA’s guidelines).
• Build out documentation of development for only those particular functionalities.
  Make written specifications, test plans, and test results of each release deployed to the production environment available for review by the auditor.
• Repurpose and submit Scrum boards as documentation for review by the FDA.
• Seek technical partnerships with vendors that have demonstrated success in prior engagements with healthcare businesses.
• Make sure everyone on the team understands the principle of “least privilege” as a guiding nonfunctional requirement in all of their work. This means that every user role within a solution or a system of solutions where highly sensitive data is processed can access only the information and resources that are critical to his or her role.

Is Working With Pre-certified Tech Partners Worth it?

Between the FDA’s nascent precertification program for development firms and ISO 9000 certified companies, working with a “pre-approved” partner can, at first glance, seem like the path of least resistance when it comes to medical software development.

The International Organization for Standardization (ISO) helps companies formalize approaches in their respective fields that focus on quality, risk-based thinking, and accountability. The helps organizations meet the needs of customers conforming to strict regulatory requirements.

ISO 9001 does not describe a specific quality tool. Instead, it specifies the types of components a quality system must have in order to improve processes and increase value.

Why a Pre-certified Firm Can’t Guarantee Success in Medical Software Development

While more formalized processes are thought to guarantee a thumbs up from the FDA at the end of rigorous software development cycles, any FDA- or ISO-vetted development process is going to be longer, more rigid, and highly cumbersome since it has been designed to include a surplus of documentation for every step.

Documentation itself is by no means a bad thing — particularly when a product’s FDA approval is a factor in a business’s success — but too much of it flies in the face of a team’s Agile philosophy as it pushes release dates further into the future.

A Pre-certified Firm isn’t an Excuse to Slack Off on Compliance

Pre-certified firms introduce the temptation of offloading the burden of maintaining regulatory compliance onto the partner. Even when that partner specializes in HIPAA-compliant SaaS, companies in the business of medical software development should consider any and all necessary certifications for their product a core competency.

After all, if the FDA ever happens to condemn a product for non-compliance, it will be the company that pays the price — not its technical partners.

How Businesses Can Speed Medical Software Development With Selective Documentation

Digital partners without such certifications can still achieve success in medical software development. Free from the burden of documenting each step of each development engagement, they can allocate their resources more efficiently from project to project, documenting the builds of essential features whose security and privacy measures must pass audits from third party organizations.

Partnering with Agile technology vendors reduces wait time and narrows in on necessary requirements, tailoring FDA requirements and process to work for — and not against — the business’s time to market.

Image Source: Unsplash, Nino Liverani

Original post can be found here.

Innovate with us. Click here to access all of our free resources.
Authored by Stanislas Walden.

Stan loves to make the obscure more apparent, the complicated more human and approachable. He strives to communicate the complex themes inherent in software development trends in a way that sparks curiosity and invites exploration.When he’s not researching or publishing a new article, Stan enjoys running around a few of Minnesota’s many lakes and looking for new recipes.