The appointment used to rebuild the past from memory. Now it reads a series
Casa Follow Up is a continuous clinical follow-up platform: patients answer short check-ins on their phone over time, and the clinician reads the trajectory instead of the recollection. The product did not exist — Epicora built all three environments from scratch: the patient app (iOS and Android), the clinician web platform and the admin panel. The core of the work was not the screen: it was the protocol engine that carries the clinical methodology written by the Casa Follow Up team without flattening it into a generic form — and the AI layer that reads the series and admits what it cannot assert.
- Client
- Casa Follow Up — continuous clinical follow-up platform
- What we did
- Built the product from scratch: patient app (iOS and Android), clinician web platform and admin panel, with a check-in protocol engine, two-audience AI analysis, recurring subscription and managed infrastructure
- Platform
- React + TypeScript + Vite · React Native · NestJS · MongoDB · AWS + Vercel · AWS SES · Stripe
The starting point
Outpatient follow-up has a gap in the middle. Weeks pass between appointments in which symptoms fluctuate, treatment is followed or not, sleep gets better or worse — and none of it is recorded. When the patient returns, what exists is their memory: what they recall, what they manage to describe, what did not feel important enough to mention. The clinician decides on that slice.
This is not a problem of attention or of appointment length. It is a problem of data source: the information that would describe the patient's trajectory never came into existence. The patient is asked to produce, from memory and under pressure, a report covering several weeks — and what comes out is impression, not a series.
- The gap sits exactly where the condition moves. The interval between appointments is the most informative stretch of follow-up, and it is the only one nobody observes.
- Recollection is retrospective and selective. What stood out weighs more than what was frequent, and what improved tends to vanish from the account.
- Without normalised data there is no comparison. Each patient describes their own condition in their own words — two weeks of the same patient are already not comparable, let alone two months.
- Deterioration and improvement only show up after they happen. No series means no trend; no trend means every adjustment is reactive.
- Adherence becomes guesswork. If nobody records it, there is no way to tell treatment that did not work from treatment that was not followed.
The turning point
The product decision was not to build a better medical record. It was to change who produces the data and when: the patient becomes the one recording, on their phone, on the day the thing happens. And not in free text — by answering the same set of questions over time, inside a protocol the clinician assigned to them. That repetition is what turns perception into a series.
So what Epicora built was not a questionnaire: it was a protocol engine. It has to carry different cadences — daily protocols, weekly ones, and the insomnia pair in which one check-in is answered in the morning about the night that passed and another in the evening about the day that followed. It has to carry different lengths, from four to ten questions, without breaking the reading. It has to accept answer types that become distinct visualisations — a numeric scale that becomes a curve with a period average, a categorical answer that becomes a distribution. And it needs a taxonomy of themes cutting across protocols, so the clinician can read the patient by sleep or by pain, not only by protocol. The clinical content belongs to the Casa Follow Up team; the mechanism that carries it is ours.
On top of the series sits the AI reading — and this is where the real risk of the project was. A model left loose on health data produces text that is plausible and dangerous: it fills gaps, suggests conduct, cites tests nobody ordered. The constraint was built before the feature.
The decision that unlocked it
The AI produces two readings that must never meet — and it declares what it does not know. From the same base come a lay-language text for the patient, with an absolute prohibition on mentioning medication, dosage or conduct, and a technical text for the clinician, restricted to the protocols they themselves assigned. Neither is visible to the other side. And when data is missing, the model says so and calibrates its confidence instead of filling in: rather than describing an evolution it cannot observe, it records that adherence in the period was low and that the reading is therefore limited. A model that admits its own limit is what makes the feature usable in a clinical context — the rest is pretty text over data that does not exist.
What we delivered
01 · The patient app, on both stores
Entry by clinician invitation only, onboarding, a check-in wizard and a history showing the state of each day — answered or not answered, which is what turns adherence into observable data instead of an assumption. Plus an in-app notification centre, filtering by clinician and account deletion inside the app itself. The app is free for the patient, who never pays anything anywhere.
02 · The check-in protocol engine
The layer that takes clinical methodology and puts it into operation: its own cadence per protocol (daily, weekly, or the morning/evening pair about the same condition), variable length without breaking the series, answer types that become different visualisations — a numeric scale with a period average, a categorical answer with a distribution — and a theme taxonomy cutting across protocols, so a patient can be read by sleep, pain, mood or adherence. The platform ships ready-made institutional protocols and still lets the clinician build their own.
03 · AI reading for two audiences
Two distinct reports over the same base — check-ins, comorbidities, medication and the clinical notes recorded by the clinician. The patient's is short and lay; the clinician's is technical and restricted to the protocols they assigned, never crossing into another clinician's data. The AI does not calculate: it reads what the system computed. And where data is missing, it declares the absence instead of filling it.
04 · Subscription, admin panel and operations
Recurring subscription with Stripe — the clinician is the one who subscribes, on the web, and the patient app stays out of any payment flow entirely. An admin panel for managing clinicians, patients and the protocol library. Infrastructure on AWS, transactional email and, after delivery, a maintenance contract: a dedicated support channel, infrastructure care and a monthly block of evolution hours.
How we made it safe
Specific consent for sensitive health data
Health data is a special category under Brazil's data protection law, and a generic acceptance of terms does not cover it. On top of the terms of use and the privacy policy, the product has a third document — a consent form for sensitive data — with its own separate acceptance in the invitation. Whoever joins knows exactly what they are authorising, and there is a record of it.
Isolation by relationship and by audience
A patient's data circulates only to those with an active relationship with them, and the clinician's technical report is never exposed to the patient. One clinician cannot reach a protocol assigned by another. Isolation here is not a permission setting: it is a system rule, applied at the origin of the query.
An explicit limit on what the AI may write
There is a list of what the model may not produce, and it predates the feature rather than patching it afterwards. The AI calculates nothing, never mentions medication, dosage or conduct to the patient, cites no external guideline and invents no test or diagnosis. Every analysis ships with a visible notice that it was generated automatically and does not replace the clinician's assessment.
The result
The product is in production with all three environments live and the clinical library in use: protocols for depression, generalised anxiety, ADHD, insomnia, hypertension, heart failure, asthma, type 2 diabetes, rheumatoid arthritis, fibromyalgia, migraine, oncology and weight management — each with its own cadence and length, on the same mechanism.
The most honest reading of this case is not an adoption metric — the platform is recent and its base is still being formed. It is that a product handling sensitive health data went live with the right constraints built before the features: its own consent, isolation by relationship, account deletion in the app, and an AI that would rather declare its own limit than fill a void. In clinical software, that order is the product.
Related solutions
Related cases
Have a methodology of your own that needs to run as a product?
Epicora builds the mechanism that carries the method of people who know the subject — with the right constraints from the start, and without flattening expert knowledge into a generic form. From the app to the admin panel, from consent to publishing on the stores.