How to Build a Digital Therapeutics App with FDA Compliance

Digital therapeutics (DTx) are not wellness apps. They are not meditation timers with a clinical wrapper. A true DTx product delivers evidence-based therapeutic interventions to patients, driven by software, and often prescribed by a clinician. The FDA treats these products as Software as a Medical Device (SaMD), which means they go through the same regulatory scrutiny as a physical medical device. That distinction changes everything about how you build, test, and ship.

The DTx market hit $6.5 billion in 2028 and is growing at roughly 25% year-over-year. Pear Therapeutics blazed the trail with reSET for substance use disorders (the first FDA-authorized prescription DTx), and companies like Akili Interactive (EndeavorRx for ADHD), Freespira (PTSD and panic disorder), and Happify Health have followed. But Pear's bankruptcy in 2023 also showed that FDA clearance alone does not guarantee commercial success. You need a product that clinicians actually prescribe, patients actually complete, and payers actually reimburse.

Before writing any code, you need to answer a few fundamental questions:

• What condition are you treating? Chronic pain, substance use disorder, insomnia, ADHD, depression, diabetes management, and respiratory conditions all have active DTx products or pipeline candidates. Your therapeutic area dictates the clinical evidence bar, the regulatory pathway, and the reimbursement landscape.
• Is this a prescription product or an over-the-counter product? Prescription DTx (PDTs) require a clinician order and typically go through more rigorous FDA review, but they also unlock higher reimbursement rates and formulary placement. OTC DTx products can reach patients directly but face tougher consumer acquisition economics.
• Who pays? Payer strategy shapes your entire product. If you are targeting commercial insurance reimbursement, you need CPT codes, clinical evidence that payers accept, and often health technology assessment (HTA) submissions. If you are selling to employers or health systems directly, the sales cycle and integration requirements are completely different.

Get these answers locked before you hire a single engineer. The wrong assumptions here waste millions and years. If you are new to building a healthcare app, start with the regulatory and reimbursement strategy, not the feature list.

The protocol engine is the clinical brain of your DTx product. It determines what therapeutic content a patient receives, when they receive it, and how the treatment adapts based on their responses and progress. This is not a content management system. It is a rules-based clinical intervention engine, and the FDA will scrutinize it closely.

Start with the clinical protocol document. Your clinical team (you absolutely need one) should produce a detailed treatment protocol that specifies every intervention, every decision branch, and every escalation trigger. For a cognitive behavioral therapy (CBT) based DTx, this might include 12 weekly modules with branching logic based on PHQ-9 depression scores, homework completion rates, and patient-reported symptom severity. For a chronic pain DTx, you might use acceptance and commitment therapy (ACT) protocols with adaptive pacing based on pain diary entries and functional activity levels.

The protocol document becomes your software specification. Every clinical decision in the engine must trace back to a defined rule in this document. The FDA expects this traceability. Your quality management system (QMS) must maintain a requirements traceability matrix linking clinical protocol requirements to software requirements to test cases to verification results.

Architecture of the Protocol Engine

Build the engine as a deterministic state machine. Each patient session exists in a defined state (module 3, lesson 2, exercise 1), and transitions between states are governed by explicit rules. Avoid black-box logic. The FDA wants to understand exactly why your software recommended a specific intervention to a specific patient. If you cannot explain the decision path, you will not clear regulatory review.

A practical architecture looks like this:

• Protocol definition layer: Store treatment protocols as versioned, structured data (JSON or a domain-specific schema). Each protocol version gets its own identifier, and patients are locked to the protocol version they started on unless explicitly migrated. This prevents mid-treatment changes from corrupting clinical data.
• Patient state manager: Tracks each patient's current position in the protocol, their accumulated responses, computed scores, and any clinician overrides. Store this as an append-only event log so you have a complete audit trail. Never mutate patient state in place.
• Decision engine: Evaluates transition rules against current patient state. Rules should be declarative ("if PHQ-9 score > 15 AND module completion < 50%, then flag for clinician review") rather than buried in procedural code. This makes the rules auditable and testable independently of the surrounding application logic.
• Content delivery service: Serves the correct therapeutic content (text, audio, video, interactive exercises) based on the decision engine's output. Content should be tagged with protocol version, therapeutic modality, and difficulty level.

Versioning is critical. When you update a treatment protocol (which you will, based on clinical evidence and post-market surveillance), you need to manage the transition carefully. Patients mid-treatment should not suddenly receive a different intervention sequence unless clinically appropriate. Your system needs to support running multiple protocol versions simultaneously and tracking which patients are on which version.

Expect to spend 8 to 12 weeks on protocol engine development alone, assuming a moderately complex treatment protocol with 10 to 15 decision branches. Budget $80,000 to $150,000 for this component if you are working with an experienced development team.

The FDA regulates digital therapeutics as Software as a Medical Device under 21 CFR Part 820 (Quality System Regulation). Your regulatory pathway determines your timeline, your evidence requirements, and your cost. Choosing the wrong pathway wastes six to eighteen months. Here is how each one works.

510(k) Premarket Notification

The 510(k) pathway requires you to demonstrate that your product is "substantially equivalent" to a legally marketed predicate device. This is the fastest route if a suitable predicate exists. For DTx products targeting conditions like substance use disorder or insomnia, you may find predicates from Pear Therapeutics (reSET, Somryst) or other cleared products.

What you need: a predicate device comparison, performance testing data, software documentation per FDA guidance on software validation, biocompatibility testing (if applicable), and labeling. The FDA's review clock is 90 days, but the actual process (including pre-submission meetings and information requests) typically takes 6 to 12 months. Budget $150,000 to $400,000 for the 510(k) submission process, including regulatory consulting, testing, and FDA fees.

De Novo Classification

If no suitable predicate exists (which is common for novel DTx mechanisms), you will use the De Novo pathway. This creates a new device classification and establishes your product as a predicate for future applicants. De Novo requires more robust clinical evidence than a 510(k) because you are defining the safety and effectiveness standard for a new category.

Akili Interactive used De Novo for EndeavorRx, the first FDA-authorized game-based DTx for ADHD. The process took years from initial clinical trials to authorization. Expect 12 to 24 months for the De Novo process, with costs ranging from $500,000 to $1.5 million including clinical studies, regulatory consulting, and FDA fees.

Breakthrough Device Designation

If your DTx treats a life-threatening or irreversibly debilitating condition and offers a significant advantage over existing treatments, apply for Breakthrough Device Designation. This does not change your regulatory pathway (you still go through 510(k) or De Novo), but it gives you priority review, more frequent FDA interaction, and potentially faster clearance. Pear Therapeutics received Breakthrough Device Designation for several products, and it materially shortened their review timelines.

Apply for Breakthrough Designation early, ideally before you start your pivotal clinical study. The FDA decides within 60 days, and the downside of rejection is minimal.

Pre-Submission Meetings Are Not Optional

File a Q-Submission (pre-submission meeting request) with the FDA before you begin your pivotal study. This meeting lets you present your intended use, your proposed regulatory pathway, your clinical study design, and your software architecture. The FDA will give you written feedback. This feedback is not binding, but ignoring it is reckless. Teams that skip pre-submission meetings frequently face major information requests during review that add 6+ months to their timeline.

Quality Management System (QMS). You must implement a QMS compliant with 21 CFR Part 820 before development begins. This includes design controls (design inputs, outputs, reviews, verification, validation), document control, corrective and preventive action (CAPA) procedures, complaint handling, and risk management per ISO 14971. Tools like Greenlight Guru, MasterControl, or Qualio provide cloud-based QMS platforms designed for medical device companies. Budget $20,000 to $50,000 per year for QMS tooling and management.

The FDA requires clinical evidence that your digital therapeutic is safe and effective. "We ran a user survey and people liked it" does not count. You need rigorous clinical studies, and the study design must match your regulatory pathway and intended claims.

Study Design for DTx Products

Most DTx pivotal studies use a randomized controlled trial (RCT) design. The gold standard is a double-blind RCT comparing your DTx intervention against a sham/control app. The sham app should look and feel similar to the active product but deliver non-therapeutic content. This controls for placebo effects and the Hawthorne effect (people improving simply because they know they are being observed).

For a CBT-based DTx targeting insomnia, your RCT might randomize 300 participants to either the active DTx (structured CBT-I modules with sleep restriction, stimulus control, and cognitive restructuring) or a sham app (sleep hygiene education only). Primary endpoint: change in Insomnia Severity Index (ISI) score at 12 weeks. Secondary endpoints: sleep diary metrics, PHQ-9 depression scores, work productivity measures.

Sample size matters. Underpowered studies waste everyone's time and money. Work with a biostatistician to calculate the required sample size based on your expected effect size, your chosen significance level (typically 0.05), and your desired power (typically 80% or 90%). For most DTx RCTs, expect 200 to 500 participants. Recruitment and data collection for a study this size typically costs $500,000 to $1.5 million and takes 12 to 18 months.

Real-World Evidence and Post-Market Studies

The FDA increasingly accepts real-world evidence (RWE) to supplement RCT data, especially for post-market surveillance and label expansion. Design your app to collect structured outcome data from every patient interaction. This means standardized assessments (PHQ-9, GAD-7, ISI, NRS pain scales) administered at protocol-defined intervals, with data stored in a research-grade format.

Your protocol engine should separate clinical outcome data from operational data. Clinical data needs to meet FDA requirements for electronic records under 21 CFR Part 11, which mandates audit trails, electronic signatures, and data integrity controls. Build these requirements into your data model from day one. Retrofitting Part 11 compliance is expensive and error-prone.

Building for Clinical Credibility

Publish your clinical results in peer-reviewed journals. Present at conferences like the Digital Therapeutics Alliance (DTA) Summit, American Psychiatric Association (APA) Annual Meeting, or the relevant specialty conference for your therapeutic area. Clinicians prescribe products they trust, and trust comes from transparent, published evidence. Budget $30,000 to $80,000 for manuscript preparation, open-access publication fees, and conference presentations.

One more thing: your clinical advisory board is not decoration. Recruit 3 to 5 key opinion leaders (KOLs) in your therapeutic area who will co-design your protocol, advise on study design, co-author publications, and advocate for your product at their institutions. Compensate them fairly ($5,000 to $15,000 per year for advisory roles). Their clinical credibility becomes your product's credibility.

A DTx product serves two audiences simultaneously: the patient completing the therapeutic program and the clinician monitoring their progress. Both experiences need to be excellent. Nail the patient experience and clinicians will not prescribe it. Nail the clinician dashboard and patients will not complete the program. You need both.

Patient-Facing Outcome Tracking

Patients need to see their own progress. This is not just a nice UX touch; it is a therapeutic mechanism. Showing patients their PHQ-9 scores trending downward over 8 weeks reinforces treatment engagement and self-efficacy. Design your outcome tracking to be visually clear, clinically accurate, and motivating without being misleading.

Key features for the patient experience:

• Validated assessment instruments: Administer standardized measures (PHQ-9, GAD-7, ISI, NRS, AUDIT-C, etc.) at clinically appropriate intervals. Present them as conversational check-ins, not clinical questionnaires. Score them automatically and store results with timestamps and protocol version identifiers.
• Progress visualization: Show trends over time using simple line charts or progress bars. Avoid overwhelming patients with raw data. Highlight meaningful milestones ("You have completed 6 of 12 modules" or "Your sleep efficiency improved from 62% to 78%").
• Therapeutic homework and exercises: CBT-based DTx products typically include between-session exercises (thought records, behavioral activation schedules, exposure hierarchies). Track completion rates and allow patients to review past exercises. Incomplete homework is a strong predictor of treatment dropout, so surface gentle reminders without being nagging.
• Crisis detection and escalation: If a patient's PHQ-9 Item 9 (suicidal ideation) scores above threshold, your app must immediately surface crisis resources (988 Suicide and Crisis Lifeline) and alert the treating clinician. This is not a feature you can defer to a later sprint. It must be in your MVP. The FDA will expect a documented risk mitigation strategy for this scenario.

Clinician Dashboard

Clinicians do not have time to dig through raw data for each patient. Your dashboard must surface actionable information in under 30 seconds per patient. If it takes longer, clinicians will stop checking it.

Essential clinician dashboard features:

• Patient panel overview: A sortable list of all assigned patients with color-coded status indicators (on track, needs attention, critical alert, inactive). Clinicians should immediately see which patients need intervention.
• Outcome trend summaries: Compact visualizations of key outcome measures over time. Show the current score, the trend direction, and the clinically significant change threshold. A clinician glancing at a patient card should instantly know: is this person getting better, staying the same, or getting worse?
• Adherence metrics: Module completion rates, session frequency, homework completion, and time-in-app. Low adherence is the biggest predictor of treatment failure in DTx, so surface it prominently.
• Alert queue: A prioritized list of patients requiring clinical attention, triggered by crisis indicators, significant score deterioration, extended inactivity (7+ days without a session), or protocol engine flags. Each alert should include context and recommended actions.
• Clinical notes and overrides: Clinicians need to document their review of patient data and any treatment adjustments they make. Support structured note templates and the ability to override protocol engine recommendations when clinically appropriate. Log all overrides with rationale for audit purposes.

Build the clinician dashboard as a responsive web application, not a mobile app. Clinicians use it at their desktop during clinic hours, and a web app avoids the friction of downloading yet another app. Use role-based access controls to ensure clinicians only see their own patients, with supervisor roles for clinical directors who oversee multiple providers.

Your DTx product does not exist in isolation. It lives inside a healthcare ecosystem where clinicians use Epic, Cerner (now Oracle Health), Allscripts, or athenahealth for their daily workflows. If your product cannot plug into those systems, it becomes an extra tab clinicians have to open, which means they will not use it. Integration is not a nice-to-have. It is a commercial requirement.

HL7 FHIR: The Integration Standard

HL7 FHIR (Fast Healthcare Interoperability Resources) is the standard for healthcare data exchange. The 21st Century Cures Act and ONC's information blocking rules have pushed most major EHR vendors to expose FHIR APIs. Use FHIR R4 as your baseline. The key FHIR resources for a DTx product are:

• Patient: Demographics, identifiers, and contact information. Use this to match patients across systems.
• MedicationRequest: The prescription for your DTx product. When a clinician prescribes your DTx through the EHR, this resource triggers patient enrollment in your system.
• Observation: Clinical outcome data (PHQ-9 scores, pain ratings, sleep metrics) that your app writes back to the EHR. This is how your therapeutic outcomes appear in the patient's medical record.
• CarePlan: The treatment plan linking your DTx to the patient's broader care. This resource connects your protocol to other treatments the patient is receiving.
• DiagnosticReport: Summary reports of patient progress that clinicians can review within their EHR workflow.

For deeper context on healthcare interoperability, see our guide to building a healthcare app, which covers FHIR integration patterns in detail.

Epic and Oracle Health Integration

Epic controls roughly 38% of the US hospital EHR market. Oracle Health (formerly Cerner) holds about 25%. Together, they cover the majority of health systems you will need to integrate with.

Epic offers the App Orchard (now rebranded as the Epic App Market) for third-party integrations. To list your app, you need to complete Epic's review process, which includes a technical review, a security review, and a clinical review. Budget 3 to 6 months for the full App Market onboarding process. Epic uses SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) for app launches within the EHR context. Your app launches inside the EHR via an embedded browser, and the clinician stays in their workflow.

Oracle Health's integration approach uses their FHIR APIs and the CDS Hooks specification for clinical decision support. CDS Hooks lets your DTx trigger recommendations within the clinician's workflow. For example, when a clinician opens a patient chart with a qualifying diagnosis, your CDS Hook could suggest prescribing your DTx product.

ePrescribing for DTx

Prescription digital therapeutics need to be prescribable through standard clinical workflows. The most direct path is integration with ePrescribing networks like Surescripts. When a clinician writes a prescription for your DTx in their EHR, the order flows through the ePrescribing network to your system, which enrolls the patient and initiates the treatment protocol.

Getting listed on Surescripts requires your product to have an NDC (National Drug Code) or similar identifier. Some DTx companies work with pharmacy benefit managers (PBMs) to get their product listed as a pharmacy benefit, which simplifies prescribing and reimbursement. Others use medical benefit channels with CPT codes. Your reimbursement strategy dictates which integration path you pursue.

Budget $100,000 to $300,000 for comprehensive EHR integration (Epic + Oracle Health) including development, testing, certification, and the first year of maintenance. This is one of the most expensive and time-consuming components of a DTx build, and also one of the most critical for commercial viability.

Your DTx product handles protected health information (PHI) and is subject to both HIPAA and FDA cybersecurity requirements. The FDA's premarket cybersecurity guidance (updated in 2023) requires a Secure Product Development Framework (SPDF) and a Software Bill of Materials (SBOM). Security is not a compliance checkbox. It is a regulatory requirement that the FDA reviews during your submission.

Infrastructure and Stack

Use a HIPAA-eligible cloud provider with a signed Business Associate Agreement (BAA). AWS is the most common choice for DTx companies because of its comprehensive HIPAA-eligible services and FedRAMP authorization. Google Cloud (GCP) and Azure are also viable options. For a detailed breakdown of compliance infrastructure costs, see our guide on HIPAA compliance costs.

A proven DTx technical stack:

• Mobile client: React Native or Flutter for cross-platform delivery. DTx products need to ship on both iOS and Android, and cross-platform frameworks reduce your development and maintenance burden by 30 to 40%. Use Expo (for React Native) to streamline builds and over-the-air updates.
• Backend API: Node.js with NestJS, Python with FastAPI, or Go. Choose based on your team's strengths. The backend handles protocol execution, outcome data processing, clinician dashboard APIs, and EHR integration endpoints.
• Database: PostgreSQL for relational data (patient records, protocol definitions, clinical outcomes). Use an append-only event store pattern for patient state changes to maintain a complete audit trail. Consider TimescaleDB for time-series outcome data if you are collecting high-frequency sensor data.
• Authentication: OAuth 2.0 with PKCE for mobile clients. Integrate with health system identity providers via SAML or OIDC for clinician single sign-on. Enforce multi-factor authentication for all users accessing PHI.
• Content delivery: Store therapeutic content (videos, audio, interactive exercises) in encrypted S3 buckets with CloudFront distribution. Use signed URLs with short expiration times so content is only accessible to authenticated, authorized patients.

FDA Cybersecurity Requirements

The FDA's cybersecurity guidance requires:

• Threat modeling: Conduct a threat model (STRIDE or similar) during design and update it when the architecture changes. Document threats, mitigations, and residual risks. Submit this with your regulatory package.
• SBOM (Software Bill of Materials): Maintain a machine-readable SBOM listing every software component, library, and dependency in your product. Use CycloneDX or SPDX format. The FDA uses this to assess vulnerability exposure. Tools like Snyk, Dependabot, or FOSSA automate SBOM generation and vulnerability monitoring.
• Patch management plan: Document how you will identify, assess, and deploy security patches throughout the product's lifecycle. The FDA wants to know that you will not abandon security updates after clearance.
• Encryption standards: AES-256 for data at rest, TLS 1.3 for data in transit. End-to-end encryption for any direct patient-clinician messaging. No exceptions.

Continuous Integration and Deployment for Regulated Software

Software changes to a cleared DTx product require change control under your QMS. That does not mean you cannot do CI/CD. It means your CI/CD pipeline must enforce your change control process. Every merge to the release branch triggers automated tests (unit, integration, end-to-end), generates a test report artifact, and requires documented review and approval before deployment. Use GitHub Actions or GitLab CI with approval gates. Tag every release with a version number that traces back to your design history file (DHF).

For over-the-air (OTA) mobile updates, be careful. The FDA's guidance on software changes determines whether an update requires a new submission. Bug fixes and minor UI changes generally do not. Changes to the therapeutic protocol engine, clinical decision logic, or intended use almost certainly do. Build your deployment pipeline to flag changes that touch regulated components and route them through your regulatory team before release.

Building a DTx product from concept to FDA clearance is a multi-year effort. Anyone who tells you otherwise is either cutting corners on clinical evidence or does not understand the regulatory landscape. Here is a realistic breakdown.

Phase 1: Discovery, Protocol Design, and Regulatory Strategy (3 to 6 months, $50,000 to $150,000)

Define your therapeutic area, develop the clinical protocol with your clinical advisory board, choose your regulatory pathway, and file your pre-submission meeting request with the FDA. Conduct competitive landscape analysis and IP review. Produce your product requirements document (PRD) and software requirements specification (SRS). Set up your QMS.

Phase 2: Core Product Development (6 to 12 months, $300,000 to $800,000)

Build the protocol engine, patient-facing mobile app, clinician dashboard, backend infrastructure, and data pipeline. Implement design controls per FDA requirements. Run software verification testing (unit tests, integration tests, system tests). Conduct usability testing with both patients and clinicians per IEC 62366. Complete your risk management file per ISO 14971.

Phase 3: Clinical Validation (12 to 18 months, $500,000 to $1,500,000)

Design and execute your pivotal clinical study. This includes IRB approval, patient recruitment, data collection, statistical analysis, and clinical study report preparation. If you are using the De Novo pathway, your clinical evidence bar is higher and your study will likely need to be larger and longer. Continue software development in parallel to address findings from usability testing and clinical feedback.

Phase 4: Regulatory Submission and Review (6 to 18 months, $150,000 to $500,000)

Prepare your regulatory submission package (510(k) or De Novo). This includes your software documentation, clinical evidence, labeling, risk analysis, cybersecurity documentation, and SBOM. Respond to FDA information requests (expect 1 to 3 rounds). For Breakthrough Device products, the timeline compresses somewhat due to priority review and sprint discussions with FDA reviewers.

Phase 5: Commercial Launch and EHR Integration (3 to 6 months, $200,000 to $500,000)

Complete EHR integrations (Epic, Oracle Health), establish ePrescribing workflows, negotiate payer contracts, train sales representatives, and launch with initial health system partners. Post-market surveillance begins immediately. You are required to track adverse events and submit periodic reports to the FDA.

Total timeline: 30 to 60 months from concept to commercial launch. Total investment: $1.2 million to $3.5 million.

These numbers are not meant to scare you. They are meant to help you plan honestly. The DTx companies that fail are the ones that underestimate the regulatory timeline, skimp on clinical evidence, or run out of money before they clear the FDA. The ones that succeed plan for the full journey from day one.

If you are building a digital therapeutics product and want a development partner who understands both the software engineering and the regulatory complexity, book a free strategy call with our team. We have shipped FDA-regulated software and can help you scope the full build, from protocol engine to EHR integration to submission support.