Digital Health Regulations — the big picture

The medical technology industry in the United States began to lean into digital health a few years ago (FDA’s first guidance document on “Software As A Medical Device” was published on December 20, 2017) and there is a massive spread of technology and devices which are linked to this growth. Digital health products can range from a web app reading radiology data, to robots positioning diagnostic probes, all the way to AI-driven mobile apps that identify clinical trial participants.

I’ve seen this regulatory environment grow and change substantially since I made my start in compliance over ten years ago. I’ve had the opportunity to enhance quality processes at F100 medical device powerhouses, create QMS from the ground up at venture-backed startups, and advise founders on compliance strategies for companies still in the “back of the napkin business plan” phase.

The single most important thing I’ve learned about digital health regulation is that it sits at the center of every other medical device concentration, and you need to understand how all the pieces fit together to be successful. Seemingly minor product changes like a wellness app startup deciding to expand from “fitness tracker” to “care management platform” could have major impacts on the time and cost to bring the product to market. A related (but opposite) problem happens for more established, traditional medical device manufacturers hoping to expand into digital health. A product development process that produced catheters and bone screws will create piles of unnecessary paperwork and delays if applied to a consumer-facing mobile application.

This confluence of products, industries, and technology has led to a regulatory environment in which compliance professionals truly must understand the breadth of requirements and systems in order to be effective. It’s easy to make strategic mistakes that could lead to delays in regulatory approvals or compliance risks after commercializing a device: at first it might seem wise to fast-track a mobile application that summarizes biometric data and does not require a 510(k), but what if you want to start providing insights or predicting health outcomes? Or maybe your app users aren’t willing to pay out-of-pocket, and you need to generate health economic data to unlock reimbursement? You need to ensure that your design process can satisfy the data quality requirements necessary to create submission-quality documents at any time. At the same time, an early-stage startup may not have the time or resources to plan out design activities months in advance or review each and every test report with a fine-tooth comb.

The approach I advocate to address this challenge is to be humble and learn from as many people as possible. I listen to software engineers and understand what levels of test coverage are really critical for product quality. I speak to companies in adjacent disease areas with similar product profiles to understand how their users react to new features. I actually read FDA’s guidance documents and participate in town halls and workshops. There may not be a “right answer” every time, but by understanding the big picture of digital health regulation and keeping an open mind for new ideas you can put yourself in the position to make the best decision when the time comes.