Digital therapeutics — software-based interventions that deliver evidence-based therapeutic content to patients as a treatment for medical conditions — occupy a distinct regulatory category from wellness apps, clinical decision support tools, and general telemedicine platforms. When a DTx product makes a treatment claim, it is a medical device under FDA law. The engineering obligations that follow from that classification are substantial and non-negotiable.
The FDA-authorised DTx market has grown significantly since the 2017 authorisation of reSET for substance use disorder. But the failure rate among DTx development programmes remains high — not primarily because the interventions lack clinical efficacy, but because the regulatory submission packages are incomplete. Building a DTx platform correctly from the start requires treating regulatory documentation as a first-class engineering output.
FDA Regulatory Pathway for DTx Products
Most FDA-authorised DTx products have received authorisation through the De Novo pathway — appropriate for novel, low-to-moderate risk devices without a predicate. Once a De Novo classification order is granted, the product establishes a new device classification and serves as a predicate for subsequent 510(k) submissions in the same category. DTx developers entering a category with an existing De Novo classification can use the 510(k) pathway, which is faster and less burdensome.
The Pre-Submission programme is strongly recommended for DTx products entering the De Novo pathway. FDA reviewers of DTx products evaluate clinical evidence standards, software documentation requirements, and labelling claims in ways that differ from traditional medical device review. Pre-Sub feedback from FDA's Digital Health Center of Excellence before clinical validation study design prevents misaligned endpoint selection that produces a complete response letter rather than authorisation.
IEC 62304 Software Lifecycle Requirements for DTx
IEC 62304 is the international standard for medical device software lifecycle processes. FDA references IEC 62304 conformance in its software documentation guidance and expects premarket submissions to include evidence of IEC 62304-compliant development processes. The standard classifies software units as Safety Class A, B, or C based on the potential severity of injury if the software fails. Most DTx application components are Class B or Class C, requiring the most rigorous documentation tier.
IEC 62304 documentation includes a software development plan, software requirements specification, software architecture design, unit implementation and testing records, integration testing records, system testing records, and software maintenance plan. Producing these documents as post-hoc descriptions of an already-built system generates documentation that does not reflect actual system behaviour — and that FDA reviewers can identify during submission review.
The correct approach is to produce IEC 62304 artefacts as by-products of the development process: requirements specifications are written before coding begins, architectural decisions are documented as they are made, and test records capture actual test execution results. Development teams using Agile methodologies must map IEC 62304 deliverables to their sprint cadence, not treat compliance documentation as a separate waterfall phase.
Usability Engineering: IEC 62366 Compliance
FDA requires evidence of usability engineering for DTx products under IEC 62366. The standard requires a usability engineering file that documents the intended use, user interface design, formative usability studies conducted during development, and summative validation testing with representative users. Summative validation must demonstrate that representative users can use the DTx software safely and effectively without undue use errors.
For DTx products targeting populations with chronic conditions, low health literacy, or limited technology experience, summative usability validation is demanding. Recruiting representative users, conducting validated usability sessions, and documenting the results to FDA's standards requires usability engineering expertise that most software development teams do not have in-house.
Clinical Evidence Standards for DTx Authorisation
FDA's expectation for clinical evidence to support DTx authorisation depends on the device classification and the nature of the treatment claims. For a De Novo submission making efficacy claims, FDA typically expects at least one randomised controlled trial demonstrating statistically significant improvement on a clinically meaningful endpoint. The study protocol and statistical analysis plan must be agreed with FDA through the Pre-Sub process before study initiation.
The version of the DTx software studied in the pivotal clinical trial must be the version submitted for authorisation — or changes between study completion and submission must be documented and evaluated for their potential to invalidate the clinical evidence. Software that receives significant updates between study completion and authorisation may require bridging studies.
Post-Authorisation Obligations: PCCP and Real-World Evidence
A Predetermined Change Control Plan submitted with the initial DTx authorisation allows the manufacturer to update the software within defined parameters without a new submission. FDA expects DTx manufacturers to maintain real-world performance data and to report serious adverse events through MedWatch. The post-authorisation compliance programme must be designed before launch, not after the first adverse event.
The Algorithm Approach: DTx Engineering for Regulatory Success
The Algorithm builds DTx development programmes with regulatory engineering embedded from sprint zero. We establish the IEC 62304 documentation framework before development begins, conduct Pre-Sub engagement with FDA DHCoE before pivotal study design, and manage the usability engineering programme in parallel with software development. Our regulatory and engineering teams collaborate on the PCCP strategy, defining the algorithm update parameters that allow post-launch optimisation within the authorised scope.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.