A custom digital therapeutic for mental health care providers, eHealth start-ups, hospitals, rehabilitation services and private practitioners. CBT, mindfulness, exposure therapy, practice modules, mood tracking and secure data sharing with the treating clinician, designed with MDR, NEN 7510 and the AI Act in mind and built by a senior Dutch team.
A therapy app sits at the intersection of two worlds that rarely meet. On one side, it is simply a mobile app: an interface that patients use, a back end that processes data, and a team that rolls out features and monitors them. On the other, it is a clinical product handling patient-record-sensitive data, evidence-based treatment modules, possible MDR classification and a vulnerable user group. App development and clinical development disciplines do not overlap naturally, and this is where things often go wrong in practice. A sprint-driven app team building without clinical context delivers something technically sound but clinically unusable. A clinical team designing without mobile realities produces specifications that do not scale or that drive patients away straight away.
We build therapy apps for mental health care providers, eHealth start-ups, hospitals with rehabilitation or pain programmes, physiotherapy practices extending their treatment pathways digitally, and private practitioners who want to scale their own offering. What they have in common is that the app is not optional: somewhere in the pathway there is a clinician, a protocol, a record and a responsibility that does not end with "the user accepts the terms". Drawing on our broader app development practice and working closely with our healthcare software discipline, we build apps that take this into account.
What distinguishes a therapy app from a fitness or wellness tool: there is a protocol underneath, there is a feedback loop with a professional, the data is patient data in the legal sense, and the outcome touches on clinical responsibility. For cognitive behavioural therapy (CBT) that means schema modules and thought records; for mindfulness, guided exercises with compliance tracking; for exposure therapy, anxiety hierarchies and in-vivo or in-virtuo exposure; for physiotherapy and occupational therapy, exercise programmes with video feedback; for speech therapy, speech exercises with audio recording. In each case, technology serves the treatment.
The right form depends on who owns it, how deep the clinical integration goes and which regulatory route fits the solution. A mental health module within an existing treatment requires something different from a standalone digital therapeutic that comes to market as a medical device. We advise on the direction in the first conversation.
A complement to the in-person treatment: a diary, exercises, assignments between sessions, mood tracking and reminders. The clinician gets a dashboard showing patient progress. This is not a standalone intervention, so it often falls outside MDR scope, but GDPR and NEN 7510 apply in full to the patient data. Suitable for private practices, primary mental health care and physiotherapy practices extending their treatment pathway digitally.
A structured treatment module, often developed together with a mental health institution or eHealth start-up. CBT protocol as modules, exposure flow addressing fear and avoidance, a mindfulness curriculum with guided exercises, and behavioural experiments with logging and evaluation. EHR integration via FHIR or MedMij with the institution's patient record, including the relevant EHR app integration. Depending on the intended claim, this may fall under MDR class I or IIa.
A standalone digital therapeutic placed on the market as a medical device, typically class IIa or IIb under the MDR. Clinical effectiveness must be substantiated through evaluation or a dedicated clinical study, and you will need a technical file, post-market surveillance and CE marking. Often includes an AI layer for treatment personalisation, biomarker analysis from wearables or risk detection; for the treatment model layer we work closely with our AI development practice to ensure that layer is set up in line with the AI Act.
A therapy app often brings together a set of clinical workflows that, in a protocol or treatment plan, exist separately from one another. For the patient and clinician, it becomes a streamlined flow, with the right data in the right place, and without data leaking outside the patient record.
Six client profiles we see again and again. If you recognise your situation in one of them, a first conversation quickly turns into a concrete picture of what is feasible and worthwhile.
You are a mental health care provider with an existing care offering, and you want to extend treatment between sessions with a custom app for assignments, diaries, mood tracking and possibly a light blended-care component. Your own brand, your own treatment model, integration with your existing EHR, and compliance that fits your current information security policy (NEN 7510).
You are an eHealth start-up with a protocol grounded in research or practice, and want to bring that protocol to market as a digital therapeutic. We build the app, help with the regulatory route (MDR class I, IIa or IIb), advise on reimbursement, and ensure the architecture is ready for the clinical study or evaluation you still plan to conduct.
A hospital or rehabilitation centre with its own programme, such as orthopaedic rehabilitation after knee or hip surgery, pain coping or cardiac rehabilitation, that wants to support home exercise with an app. Exercise videos, progress tracking, adherence monitoring, integration with the EHR for clinicians, and optionally wearable data for objective progress measurement.
You are a psychologist, physiotherapist, occupational therapist or speech therapist with your own practice and want to make your offering scalable through your own app. Your own brand, your own treatment model, an affordable management setup, and compliance at a level that suits your practice: no heavier than necessary, but fully robust on GDPR and patient data.
An occupational health or lifestyle service provider that supports employees' mental wellbeing with a digital offering. Often a B2B2C model with the employer as the customer and the employee as the user, with privacy by design so that the employer can never see individual data, only aggregated population trends.
A university, university medical centre or clinical research group that delivers an intervention via an app and wants to use the data for clinical evaluation or academic research. Ethics committee approval, data governance, anonymisation and data export for analysis in REDCap, R or similar tools, all built into the design from the outset.
A conversation in which we establish which clinical protocol sits behind your app, or will sit behind it, who the end user is, which clinician is involved, and which regulatory route fits. We discuss the sensitivity of the data, your existing IT landscape (EHR, identity provider) and the stage you are at: idea generation, a first version, or further development of an existing app.
Together with you and, where available, your clinical lead, we determine which modules belong in the first version and which will follow later. At the same time, we establish the MDR classification: whether the app falls under "wellness" and MDR does not apply, or whether there is a diagnostic or treatment claim, in which case class I, IIa or IIb comes into play. We work with notified bodies and assess whether a clinical evaluation is sufficient or whether a dedicated clinical study is needed.
Before building begins, we set up the data architecture: which data is stored where, what encryption is used, which access applies to each role, what retention applies and what audit trail is kept. For processing BSN (citizen service number), we use the appropriate route, often via a ZorgID or UZI integration. For patient onboarding via DigiD or iDIN, we set up the identity flow as our NEN 7510 software discipline requires. We also set up an initial DPIA (data protection impact assessment) so that you have the evidence you need ready.
Every two weeks, a working build that your clinical lead can genuinely test, not only for functionality but also for clinical accuracy. Schedule modules against the protocol, exposure flows against the treatment guideline, and mood-tracking formulas against the validated scales. We first build the core module to working order (often the CBT record or exposure flow) and then expand from there.
Integrations with your institution's patient record via FHIR (HiX, Epic, Nexus, NEDAP ONS, USER), with MedMij environments where relevant, and with Apple HealthKit or Google Health Connect for wearable data. We build these integrations explicitly, not as a "data dump", so that the right resources land in the right place in the record and the clinician can work with them clinically.
Submission to the Apple App Store and Google Play, with the privacy labels and, where applicable, the medical device categorisation properly set. Clinical evaluation or bridging study where required. Then a phased rollout to your patient population, training for clinicians, ongoing maintenance, security patches and the post-market surveillance that MDR requires if the app is classified as a medical device.
With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.
Explore OneDayBuild →A therapy app touches several regulatory frameworks at once: the MDR for medical device classification, the GDPR and NEN 7510 for patient data, the AI Act for clinical AI components, and specific interfaces such as MedMij for patient access. We build compliance in from the first sprint, not as reporting after the fact.
A therapy app with a diagnostic or treatment claim falls under the MDR (Regulation 2017/745). Depending on the claim, it becomes a class I, IIa or IIb medical device. We prepare the classification rationale, help with the technical file, support CE marking, and ensure that post-market surveillance and vigilance reporting are built into the architecture.
Patient data is special category personal data within the meaning of the GDPR. In the Netherlands, NEN 7510 is the standard for information security in healthcare and is almost always a requirement of organisations that want to work with you. Encryption at rest and in transit, BSN processing via the correct route, audit trail, retention, DPIA, and sub-processors in Europe: everything this entails is included as standard in our setup.
An AI layer that contributes to a clinical decision (risk detection, treatment personalisation, biomarker interpretation) is generally high-risk under the EU AI Act. This brings obligations on risk management (Art. 9), data governance (Art. 10), transparency (Art. 13) and human oversight (Art. 14). We build that compliance in together with our AI development practice.
For exchange with EHRs we use HL7 FHIR with the relevant Dutch profiles (Zib's, Nictiz). For patient access, we connect to MedMij where relevant. We map resources explicitly: QuestionnaireResponse for scales, Observation for biomarkers, CarePlan for the treatment plan, so that the data arrives at the clinician in a form they can clinically interpret.
For patient onboarding we use DigiD (public healthcare) or iDIN (private or lighter-touch contexts), depending on the setting. For healthcare professional access we connect to a UZI pass or an identity provider managed by your organisation via SSO. The identity layer is deliberately kept separate from the clinical data layer, with explicit authorisation per role and per record.
The Apple App Store and Google Play have specific policies for health apps: privacy labels, data minimisation, no claims of treatment without substantiation, and an explicit medical disclaimer where applicable. We follow these rules in the submission and keep the information up to date, as they are revised several times a year.
A therapy app involves a number of architectural decisions that carry more weight than in an ordinary consumer app — offline behaviour, encryption, audit trail, anonymisation. Below are some fixed frameworks we apply, with room for variation depending on your situation.
For clinical work where performance, HealthKit/Health Connect access and App Store reliability come first, we often choose native iOS (Swift) and Android (Kotlin). For projects where the same feature set must run in parallel and team capacity is limited, we choose Flutter — with explicit plug-ins for HealthKit and Health Connect so we retain native access where it is clinically necessary.
All patient data is encrypted at rest with keys held in a dedicated KMS, TLS 1.3 in transit, with perfect forward secrecy. For the most sensitive elements (clinical notes, crisis alerts) we consider end-to-end encryption with device keys. An immutable audit trail records who viewed or changed what and when — useful for clinical accountability and NEN 7510 audits. Backups are encrypted and stored in the EU.
For population analysis and scientific research, we work with pseudonymisation: direct identification is strictly separated from clinical data, with a pseudonymised key that can only be linked back under strict conditions. Exports to REDCap, R or your own data warehouse go through controlled pipelines, with logging of who pulled which export and when. Ad-hoc database queries on production data are never permitted.
What healthcare and eHealth clients typically want to know before starting a therapy app.
A free, no-obligation introductory call of half an hour. Tell us about the protocol or treatment you want to make digital, your target group, and the organisation or care network where the app needs to land. We will help you think through scope, regulatory route and a realistic build sequence. You can also email fabian.vandijk@appfront.nl directly, or look at related healthcare software projects for the wider context.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
