Digital therapeutics

Digital Therapeutics (DTx) Backend

A DTx product turns evidence-based intervention into a structured program the patient runs through. The data model is mostly FHIR-shaped already: CarePlan for the program, Task for the daily activities, QuestionnaireResponse for the outcomes, Observation for the device data when present.

Read the CarePlan docs Book a DTx architecture review

What you can build

  • Program structure as CarePlan

    The therapeutic protocol is a CarePlan with activities. Daily Tasks materialize from the activities on schedule.

  • Patient-reported outcomes as QuestionnaireResponse

    Diaries, symptom checks, and adherence prompts land as typed QuestionnaireResponses linked to the patient.

  • Clinician oversight as a separate role

    Clinician review uses the same backend with its own role. No parallel database for clinician data.

What you get out of the box

Capability With Fire Arrow Building it yourself
Protocol definition PlanDefinition for the protocol, CarePlan for the patient instance, ActivityDefinition for repeatable activities. Custom protocol modeling and instance generation per patient.
Daily Task materialization Server-side scheduling materializes Tasks from CarePlan activities on the program schedule. Custom job runner generating Tasks per patient per day.
Outcome capture QuestionnaireResponse with item validation against the linked Questionnaire. Custom forms backend with manual validation per question.
Clinician oversight Clinician role with Care team scope; reads outcomes and CarePlan status. Separate clinician portal with its own access logic.
Regulatory fitness Standard FHIR R4; aligns with DiGA, MDR, and FDA Class II considerations through deployment. Custom data model whose regulatory fit must be argued from scratch.

Who this is for

DTx product teams designing the backend for a new therapeutic, and clinical leads evaluating the data model against regulatory and reimbursement requirements.

Clinical applicability

A DTx for chronic insomnia delivers a structured CBT-I program. The CarePlan defines the eight-week protocol, Tasks materialize daily activities, QuestionnaireResponses capture sleep diaries, and a clinician reviews progress weekly.

DTx data model in FHIR terms

The therapeutic content is a PlanDefinition. The patient-specific instance is a CarePlan that references the PlanDefinition. Activities inside the CarePlan turn into Tasks on schedule. Outcomes are QuestionnaireResponses; objective measures are Observations.

Clinician notes attach as Communication or DocumentReference depending on the structure. The same backend serves the patient app, the clinician portal, and the analytics pipeline through different roles.

Adherence and engagement

Adherence is a search: Tasks for the patient with status complete vs not-complete. The product can compute streaks, weekly adherence percentages, and program completion from the same Task records the patient interacts with.

Engagement events that do not need a clinical record (login events, screen views) typically stay in a separate analytics store. The clinical record is what enters the patient's chart and what supports outcome studies.

Outcomes and study evaluation

DTx products usually need outcome data to support reimbursement and regulatory claims. The same QuestionnaireResponse and Observation data the program uses operationally feeds the outcome study.

A study analyst gets a research role with property filters that strip identifiers. Same database, different access scope. The audit log records the analyst access alongside the clinician access.

Related docs

Related pages

FAQ

Can the patient access their own data?

Yes. The Patient role has read access to their CarePlan, Tasks, QuestionnaireResponses, and Observations through the PatientCompartment validator.

How does this align with DiGA requirements?

DiGA submissions benefit from FHIR-native storage and explicit access rules. The DiGA backend page covers the BfArM Fast-Track checklist in detail.

Can I use the backend across multiple DTx products?

Yes. Multi-tenant deployments can host multiple products in the same backend with tenant-scoped roles and data partitioning.

How are protocol updates handled?

PlanDefinition versioning lets the product roll out new protocol versions while existing CarePlans continue against the version they started on.