Een maatwerk digital-therapeutic voor GGZ-instellingen, eHealth-startups, ziekenhuizen, revalidatie en private behandelaren. CBT, mindfulness, expositie, oefen-modules, mood-tracking en veilige gegevensdeling met de behandelaar — ontworpen met MDR, NEN 7510 en de AI Act in gedachten, gebouwd door een senior NL-team.
Een therapie-app raakt aan twee werelden die zelden samenkomen. Aan de ene kant is het gewoon een mobiele app: een interface waar een patient mee aan de slag gaat, een backend die data verwerkt, een team dat features uitrolt en monitort. Aan de andere kant is het een klinisch product met patientendossier-gevoelige data, evidence-based behandelmodules, mogelijke MDR-classificatie en een gebruikersgroep die kwetsbaar is. De disciplines van app-ontwikkeling en die van klinische ontwikkeling overlappen niet vanzelf — en daar gaat het in de praktijk vaak mis. Een sprint-georienteerd app-team dat zonder klinische context bouwt, levert iets dat technisch klopt maar klinisch onbruikbaar is. Een klinisch team dat zonder mobile-realiteit ontwerpt, levert specificaties die niet schalen of die patienten meteen weer doen afhaken.
Wij bouwen therapie-apps voor GGZ-instellingen, eHealth-startups, ziekenhuizen met revalidatie- of pijn-programma's, fysiotherapie-praktijken die hun behandeltraject digitaal verlengen, en private behandelaren die hun eigen aanbod schaalbaar willen maken. Het gemeenschappelijke kenmerk is dat de app niet vrijblijvend is: ergens in het traject is er een behandelaar, een protocol, een dossier en een verantwoordelijkheid die niet bij "de gebruiker accepteert de voorwaarden" ophoudt. Vanuit onze bredere app-ontwikkelingspraktijk en in nauwe afstemming met onze zorg-software-discipline bouwen we apps die daar oog voor hebben.
Wat een therapie-app onderscheidt van een fitness- of wellness-tool: er ligt een protocol onder, er is een feedback-loop met een professional, de data is patient-data in juridische zin, en de uitkomst raakt aan klinische verantwoordelijkheid. Voor cognitieve gedragstherapie (CBT) zijn dat schema-modules en gedachtenrecords; voor mindfulness geleide oefeningen met compliance-tracking; voor expositie-therapie angsthierarchien en in-vivo of in-virtuo expositie; voor fysiotherapie en ergotherapie oefen-programma's met video-feedback; voor logopedie spraak-oefeningen met audio-opname. Telkens technologie in dienst van de behandeling.
De juiste vorm hangt af van wie de eigenaar is, hoe diep de klinische integratie gaat en welke regulatoire route bij de oplossing past. Een GGZ-module binnen een bestaande behandeling vraagt iets anders dan een standalone digital therapeutic die als medisch hulpmiddel op de markt komt. We adviseren de richting in het eerste gesprek.
Een aanvulling op de fysieke behandeling: dagboek, oefeningen, opdrachten tussen sessies door, mood-tracking en herinneringen. De behandelaar krijgt een dashboard waarin patient-voortgang inzichtelijk is. Geen losse interventie, dus regulatoir vaak buiten MDR-scope — wel volwaardig AVG en NEN 7510 voor de patient-data. Geschikt voor private praktijken, eerstelijns-GGZ en fysiotherapie-praktijken die hun behandeltraject digitaal verlengen.
Een gestructureerde behandelmodule, vaak in samenwerking met een GGZ-instelling of eHealth-startup. CBT-protocol als modules, expositie-flow met angst- en vermijdingstrek, mindfulness-curriculum met geleide oefeningen, gedragsexperimenten met logging en evaluatie. EPD-koppeling via FHIR of MedMij naar het patientendossier van de instelling, met de bijbehorende EPD-app-integratie. Afhankelijk van werkingsclaim mogelijk MDR klasse I of IIa.
Een standalone digital therapeutic die op de markt komt als medisch hulpmiddel, doorgaans klasse IIa of IIb onder de MDR. De klinische werking is onderbouwd met evaluatie of een eigen klinische studie, er is een technical file, post-market surveillance en CE-markering nodig. Vaak met een AI-laag voor behandelpersonalisatie, biomarker-analyse uit wearables of risico-detectie — voor de behandelmodel-laag werken we nauw samen met onze AI-ontwikkelingspraktijk zodat die laag AI-Act-conform wordt opgezet.
Onder een therapie-app valt vaak een verzameling klinische werkprocessen die in een protocol of behandelplan los van elkaar bestaan. Voor patient en behandelaar wordt het een gestroomlijnde flow, met de juiste data op de juiste plek — en zonder dat data buiten het patientendossier wegvloeit.
Zes opdrachtgever-profielen die we keer op keer terugzien. Herkent u uw situatie in een ervan, dan vertaalt een eerste gesprek snel in een concreet beeld van wat haalbaar en zinvol is.
U bent een GGZ-instelling met een lopend zorgaanbod en wilt de behandeling tussen sessies door verlengen met een eigen app — voor opdrachten, dagboek, mood-tracking en mogelijk een lichte blended-care-component. Eigen merk, eigen behandelmodel, koppeling met uw bestaande EPD, en compliance die past bij uw bestaande informatieveiligheidsbeleid (NEN 7510).
U bent een eHealth-startup met een protocol dat onderbouwd is in onderzoek of praktijk, en wilt dat protocol als digital therapeutic naar de markt brengen. We bouwen de app, helpen mee in de regulatoire route (MDR klasse I, IIa of IIb), denken mee over reimbursement en zorgen dat de architectuur klaar is voor de klinische studie of evaluatie die u nog gaat doen.
Een ziekenhuis of revalidatiecentrum met een eigen programma — orthopedische revalidatie na knie- of heupoperatie, pijn-coping, hart-revalidatie — dat thuis-oefenen wil ondersteunen met een app. Oefen-video's, voortgang, compliance, koppeling met EPD voor de behandelaar, en eventueel wearable-data voor objectieve voortgangsmeting.
U bent een psycholoog, fysiotherapeut, ergotherapeut of logopedist met een eigen praktijk en wilt uw aanbod schaalbaar maken via een eigen app. Eigen merk, eigen behandelmodel, betaalbare beheer-vorm, en compliance op het niveau dat past bij uw praktijk — niet zwaarder dan nodig, maar wel volwaardig op AVG en patient-data.
Een arbo- of leefstijl-dienstverlener die mentale gezondheid van werknemers ondersteunt met een digitaal aanbod. Vaak in een B2B2C-model met de werkgever als afnemer en de werknemer als gebruiker — met privacy-by-design zodat werkgever nooit individuele data kan inzien, alleen geaggregeerde populatie-trends.
Een universiteit, UMC of klinische onderzoeksgroep die een interventie via een app aanbiedt en de data wil gebruiken voor klinische evaluatie of wetenschappelijk onderzoek. ECC-goedkeuring, data-governance, anonimisering en exporteerbaarheid van data voor analyse in REDCap, R of vergelijkbare tools — allemaal als uitgangspunt van het ontwerp.
Een gesprek waarin we begrijpen welk klinisch protocol onder uw app ligt of komt te liggen, wie de eindgebruiker is, welke behandelaar erbij betrokken is, en welke regulatoire route past. We spreken over de gevoeligheid van de data, over uw bestaande IT-landschap (EPD, identity-provider) en over de fase waarin u zit — ideevorming, eerste versie, of doorontwikkeling van een bestaande app.
Samen met u en, indien aanwezig, uw klinisch lead bepalen we welke modules in de eerste versie horen en welke later komen. Tegelijk bepalen we de MDR-classificatie: valt de app onder "wellness" en is MDR niet van toepassing, of is er sprake van een diagnose- of behandelaanspraak waardoor klasse I, IIa of IIb in beeld komt. We werken samen met aangemelde instanties en bekijken of er een klinische evaluatie volstaat of dat een eigen klinische studie nodig is.
Voor de bouw begint zetten we de data-architectuur op — welke data waar staat, welke versleuteling, welke toegang per rol, welke retentie en welke audit-trail. Voor BSN-verwerking gebruiken we de juiste route (vaak via een ZorgID- of UZI-koppeling), voor patient-onboarding via DigiD of iDIN regelen we de identity-flow zoals onze NEN 7510-software-discipline dat voorschrijft. Een eerste DPIA opzetten doen we hier ook, zodat u de bewijslast klaar heeft.
Elke twee weken een werkende build die uw klinische lead daadwerkelijk kan testen — niet alleen op functionaliteit, maar ook op klinische correctheid. Schema-modules tegen het protocol, expositie-flow tegen de behandelrichtlijn, mood-tracking-formules tegen de gevalideerde schalen. We bouwen eerst de kernmodule werkend (vaak CBT-record of expositie-flow) en breiden daarna uit.
Koppelingen met het patientendossier van uw instelling via FHIR (HiX, Epic, Nexus, NEDAP ONS, USER), met MedMij-omgevingen waar relevant, en met Apple HealthKit of Google Health Connect voor wearable-data. We bouwen die integraties expliciet, niet als "data-dump", zodat de juiste resources op de juiste plek in het dossier landen en de behandelaar er klinisch mee kan werken.
Submissie naar Apple App Store en Google Play, met de privacy-labels en (waar van toepassing) de medisch-hulpmiddel-categorisering goed gezet. Klinische evaluatie of bridging-studie waar dat hoort. Daarna gefaseerde uitrol naar uw patient-populatie, training voor behandelaren, doorlopend beheer, security-patches en de post-market surveillance die MDR voorschrijft als de app als medisch hulpmiddel is geclassificeerd.
Met OneDayBuild maken we je idee in één dag tastbaar voor €950, zodat je weet of verdere ontwikkeling de investering waard is. Besluit je door te gaan met de volledige bouw? Dan verrekenen we de kosten volledig.
Bekijk OneDayBuild →Een therapie-app raakt aan meerdere regulatoire kaders tegelijk — MDR voor medisch hulpmiddel-classificering, AVG en NEN 7510 voor patient-data, de AI Act voor klinische AI-componenten, en specifieke koppelvlakken zoals MedMij voor patient-toegang. We bouwen die naleving in vanaf de eerste sprint, niet als rapportage achteraf.
Een therapie-app met een diagnose- of behandelaanspraak valt onder de MDR (Verordening 2017/745). Afhankelijk van de claim wordt het een klasse I, IIa of IIb medisch hulpmiddel. Wij maken de classificatie-onderbouwing, helpen bij de technical file, ondersteunen bij CE-markering en zorgen dat post-market surveillance en vigilantie-rapportage architectuur-niveau ingebouwd zijn.
Patient-data is bijzondere persoonsgegevens in de zin van de AVG. NEN 7510 is in NL de norm voor informatieveiligheid in de zorg, vrijwel altijd de eis van instellingen die met u willen werken. Encryptie-at-rest en in-transit, BSN-verwerking via correcte route, audit-trail, retentie, DPIA, sub-verwerkers in Europa — alles wat hierbij hoort zit standaard in onze opzet.
Een AI-laag die meeweegt in een klinische beslissing (risico-detectie, behandelpersonalisatie, biomarker-interpretatie) is onder de EU AI Act doorgaans high-risk. Dat brengt verplichtingen mee op risico-management (Art. 9), data-governance (Art. 10), transparantie (Art. 13) en menselijk toezicht (Art. 14). Wij bouwen die compliance in samen met onze AI-ontwikkelingspraktijk.
Voor uitwisseling met EPD's gebruiken we HL7 FHIR met de relevante Nederlandse profielen (Zib's, Nictiz). Voor patient-toegang sluiten we, waar relevant, aan op MedMij. Resources mapping we expliciet — QuestionnaireResponse voor schalen, Observation voor biomarkers, CarePlan voor behandelplan — zodat de data klinisch interpreteerbaar landt bij de behandelaar.
Voor patient-onboarding gebruiken we afhankelijk van de context DigiD (publieke zorg) of iDIN (private/lichtere context). Voor zorgmedewerker-toegang sluiten we aan op UZI-pas of een door uw instelling beheerde identity-provider via SSO. Identity-laag is bewust gescheiden van de klinische data-laag, met expliciete autorisatie per rol en per dossier.
Apple App Store en Google Play hebben specifieke beleidsregels voor gezondheids-apps: privacy-labels, data-minimalisatie, geen aanspraak op behandeling zonder onderbouwing, expliciete medische-disclaimer waar van toepassing. Wij volgen die regels in de submissie en houden de informatie actueel — ze worden meerdere keren per jaar bijgewerkt.
Een therapie-app heeft een aantal architectuur-beslissingen die zwaarder wegen dan bij een gewone consumenten-app — offline-gedrag, encryptie, audit-trail, anonimisering. Hieronder een aantal vaste kaders die we toepassen, met ruimte voor variatie afhankelijk van uw situatie.
Voor klinisch werk waar performance, HealthKit/Health-Connect-toegang en App-Store-betrouwbaarheid bovenaan staan, kiezen we vaak native iOS (Swift) en Android (Kotlin). Voor projecten waar dezelfde feature-set parallel moet draaien en de teamcapaciteit beperkt is, kiezen we Flutter — met expliciete plug-ins voor HealthKit en Health Connect zodat we native-toegang houden waar dat klinisch nodig is.
Alle patient-data versleuteld at-rest met sleutels in een dedicated KMS, TLS 1.3 in-transit, perfect forward secrecy. Voor het meest gevoelige stuk (klinische notities, crisis-meldingen) overwegen we end-to-end encryption met device-keys. Onveranderlijke audit-trail van wie wat wanneer zag of wijzigde — bruikbaar voor klinische verantwoording en NEN 7510-audit. Backups versleuteld, in EU.
Voor populatie-analyse en wetenschappelijk onderzoek werken we met pseudonimisering: directe identificatie strikt gescheiden van klinische data, met een gepseudonimiseerde sleutel die alleen onder strikte voorwaarden weer terug te koppelen is. Exports naar REDCap, R of een eigen warehouse via gecontroleerde pipelines, met logging van wie welke export wanneer trok — nooit ad-hoc database-queries op productiedata.
Wat opdrachtgevers in zorg en eHealth meestal willen weten voor we beginnen aan een therapie-app.
Een kennismaking van een half uur, vrijblijvend. Vertel ons over het protocol of de behandeling die u digitaal wil maken, over uw doelgroep, en over de instelling of het organisatie-verband waarin de app moet landen. We denken mee over scope, regulatoire route en een realistische volgorde van bouwen. Liever direct mailen kan ook bij fabian.vandijk@appfront.nl, of bekijk verwante zorg-software-trajecten voor de bredere context.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
