Lou is our medication and care notebook for households – in development, currently single-user-per-device, everything stored locally. This post is the legal homework we did before deciding what it’s allowed to become. It is not legal advice; we are not lawyers; the actual next step is paying someone who is. If you’re building a health app and making decisions with real consequences, do that step too.

The shape of the problem

Medication doses and health readings are about as sensitive as personal data gets. The law agrees, loudly, in several jurisdictions at once. A US/Canada health app can touch, depending on what it does: HIPAA, FDA device regulation, the FTC Act and its Health Breach Notification Rule, Washington’s My Health My Data Act, Nevada SB 370, California’s CMIA, more than a dozen comprehensive state privacy laws, COPPA, PIPEDA, Quebec’s Law 25, and CASL. That list is why “we’ll figure out the legal stuff later” is a plan with a short shelf life.

The useful discovery from working through all of it: the regimes differ in wording but agree on one governing principle. The law protects the person the data is about, not the person holding the phone. Keep those two identities the same and most obligations stay quiet. Let them diverge – which is the entire premise of a caregiving app – and obligations attach from every direction at once.

That principle splits the problem cleanly in two.

The easy path: one user, one device

Lou today stores everything in a local database on the user’s device. There is no account, no server, no analytics, no crash reporting, no networking code at all. We never receive, transmit, or possess any user data. We arrived there as a privacy conviction rather than a legal strategy, but it turns out to be the single most legally consequential design decision available to a health app:

  • HIPAA doesn’t apply. HIPAA is the most famous health-privacy law in America, which is presumably why it gets credited with jurisdiction over everything up to and including your neighbor asking about your knee. It actually binds covered entities – providers, health plans, clearinghouses – and their business associates. A direct-to-consumer app where the caregiver enters data that never leaves the device makes the developer neither. (This changes the day a clinic or pharmacy starts directing patients to your app as part of care – a trigger worth writing down now so a future partnership doesn’t drift across the line unnoticed.)
  • The FTC’s Health Breach Notification Rule has nothing to bite. The rule covers vendors of personal health records, and a breach concerns data the vendor holds or discloses. Hold nothing, and there is nothing you can breach.
  • State health-privacy laws mostly aim past you. Washington’s My Health My Data Act and its cousins target entities that collect and process consumer health data. The strong reading is that a developer who never receives the data isn’t collecting it – the consumer is processing their own data on their own device. These statutes are new and aggressively worded, so this is a position to have counsel confirm rather than a certainty, but the posture is about as good as postures get.
  • The App Store privacy label is simply “Data Not Collected.” A rare label, and one that has to stay true at every release – more on that below.

What “not applicable” does not mean is “nothing to do.” The easy path still has a to-do list, and it’s worth being specific about it, because most of it is invisible in screenshots.

What you still owe, even on the easy path

A real terms-of-use and medical disclaimer. Less a formality than the legal expression of what the product honestly is. Lou’s terms say, in plain English: this is a record-keeping and reminder tool; it is not medical advice, not a dosing calculator, and not a guarantee that any reminder arrives on time; everything it shows – “ready,” countdowns, progress rings – is arithmetic on the schedule you entered; and if the app and the medication label ever disagree, the label is right and the app is wrong. Users accept this at first run on a screen that can’t be dismissed and can’t be agreed to without scrolling to the end, and the accepted version and timestamp are recorded. Delivery of reminders gets its own honest paragraph, because iOS genuinely cannot promise a notification arrives – Focus modes, battery conditions, and the operating system all get a vote – and a terms document that pretends otherwise would be the deceptive claim the FTC actually enforces against.

Marketing discipline, because the FDA classifies claims, not code. Most of Lou sits squarely in the FDA’s stated low-risk categories: medication logs, adherence tracking, user-configured reminders, symptom journaling. The gray zone is that Lou doesn’t just log – it shows whether the minimum interval and daily maximum you entered are currently satisfied. Described one way, that’s an automated version of the paper log every caregiver already keeps. Described another way – “prevents double-dosing,” “keeps your family safe” – it’s a safety device, and safety devices are regulated. Same binary, different product, and the difference is the verbs. So the rule we hold ourselves to, in the App Store listing and everywhere else: Lou tracks, logs, reminds, and organizes. It does not prevent, protect, ensure, or decide. (You may now appreciate the lawyerly caution with which this very paragraph is written. Blog posts are marketing copy too.)

Sample data curation, of all things. Our demo household used to take insulin. It was a perfectly good demo medication apart from the part where it’s a high-alert drug whose mistimed dose has real consequences – exactly the wrong screenshot to hand a regulator or an App Review team wondering whether you’re a dosing calculator. The demo family now enjoys robust over-the-counter health.

Apple’s own layer. The App Store has its own quasi-regulatory regime: a privacy manifest declaring which sensitive APIs you use and why (missing one is submission-blocking), an export-compliance declaration, an honest answer to the medical-content age-rating questions, and Guideline 1.4.2, which restricts drug dosage calculators to drug manufacturers, hospitals, universities, health insurers, pharmacies, and other approved entities. “When can the next dose be taken” is dosage-adjacent, so the review notes explaining what the app is and isn’t get written with the same care as the terms. And the license texts for open-source dependencies need a screen of their own – the least glamorous compliance artifact, and among the easiest to forget.

Features the law strongly implies. Some requirements arrive dressed as product work: an optional app lock, because a household device is shared by definition and health data deserves a biometric check; a discreet-notifications option, because even “Time for Pat to take cetirizine” on a lock screen is a health-data disclosure to whoever’s standing nearby; a true “erase all data” action, because soft-delete tombstones that linger forever make the word “delete” quietly dishonest; and suppressing the “ready” arithmetic entirely if the database ever fails open in a degraded state, because dose math over missing history is worse than no answer.

And the honest big one: liability. For a caregiving app, the realistic worst case isn’t a fine. It’s a family harmed after relying on the app, followed by perfectly ordinary negligence claims. The mitigations are unglamorous: the disclaimer users actually read, engineering rigor around exactly the failure modes that matter (stale “take” buttons, duplicate recording, clock changes), and a test suite that pins each one. A test suite is not usually a legal document. Ours may someday be read by someone billing by the hour, as evidence of a standard of care. We write it accordingly – and, on advice we’d give anyone: form the legal entity and have the insurance conversation before public distribution, not after.

One more wrinkle, because Fortibus is an EU company: GDPR follows the developer’s establishment, not the users’ location. It stays quiet today only because no personal data reaches us at all – but the moment any does, GDPR applies in full even with zero EU users. For us the “no data leaves the device” line isn’t just a promise to users; it’s the load-bearing wall in two legal systems at once.

Planned -- not yet built

Sharing: where the easy path ends

Everything above describes a calm, well-understood position – and it describes Lou as it exists. What follows does not exist yet: it’s the legal homework for the feature everyone asks for, the one the entire app was built around: households. Two parents recording a child’s doses on two phones. An adult coordinating a parent’s medications with a sibling. This is the actual shape of caregiving, and supporting it would require data to move between people.

The moment it does, the governing principle bites. The account holder and the data subject diverge – the person tapping “share” is not the person the medication list describes – and nearly every “not applicable” above flips:

  • The Health Breach Notification Rule wakes up, and its definition of breach includes unauthorized disclosure, not just intrusion. Read that twice: a consent screen with a defect – a share that went further than the user validly authorized – is a reportable breach event with a 60-day notification clock, no hacker required.
  • Washington’s My Health My Data Act demands separate opt-in consent for collection and a distinct, specific authorization for sharing – one bundled “I agree” covering both is non-compliant on its face – and it comes with a private right of action.
  • California’s CMIA expressly covers consumer software “designed to maintain medical information,” with statutory damages.
  • Comprehensive state privacy laws treat health data as sensitive personal information: opt-in consent, documented risk assessments.
  • COPPA enters conditionally, since households contain children.
  • And the FTC’s most reliably enforced rule stands over all of it: no third-party analytics, advertising, or attribution SDK may ever receive health data or anything derived from it. The GoodRx, Premom, and BetterHelp actions all ran on exactly that fact pattern. Lou satisfies this one by the elegant mechanism of containing no such SDKs to begin with.

Privacy maximalism doesn’t exempt you

Here’s the part we found genuinely humbling. Our instinct for sharing is maximal privacy: end-to-end encryption, keys generated and held on users’ devices, content keys wrapped per recipient so that what someone can see is bounded by what they can decrypt – and the operator (us) unable to read anyone’s health data, ever, by construction. That is the single highest-leverage decision in the whole design: if the server holds no plaintext, a server compromise is substantially not a disclosure, and the public privacy claim survives contact with reality.

We assumed, briefly, that this would also make most of the legal work fall away. It does not. It changes which work remains:

  • An authority model. Before anyone shares a child’s or a parent’s data, the system has to record on what basis they’re entitled to manage it at all – self, parent or guardian of a minor, healthcare power of attorney – as an explicit, typed attestation, not a line buried in the terms. The app can’t verify the claim and must never pretend to; the legal function is an identified person making an identified representation. But the record of who attested what, when, under which exact wording has to be reconstructible years later.
  • Authorization per recipient, per scope. Sharing consent is a discrete, affirmative act, separate from onboarding and separate from collection consent – naming the recipient, the data categories, the purpose, and how to revoke. Adding a recipient or widening their access requires a new authorization. Narrowing doesn’t.
  • Scope enforced by cryptography, not UI. “The app doesn’t show it to them” is a filter. “They can’t decrypt it” is a boundary. Regulators, it turns out, can tell the difference.
  • Revocation that means something. Revocable at any time, effective immediately, keys rotated so old material doesn’t decrypt new data – and honest about its limits, because an offline device can’t be reached and a screenshot can’t be recalled. “Deleted everywhere instantly” would itself be a deceptive claim. The legally safe sentence is also the true one: best effort, clearly described.
  • An audit log that works under encryption. The system must be able to answer, years later and without reconstruction: who could see what, when, on whose authority – about content we’ve deliberately made ourselves unable to read. So the log records grants, scopes, attestations, revocations, key rotations, and access events – metadata, never content – tamper-evident, retained past statutory limitation periods, and visible to the data subject as an access history of their own records. Keeping meticulous records about data you cannot read is the kind of requirement that sounds paradoxical right up until you imagine the family-court subpoena.
  • Notification at grant time. The person whose data is being shared (or their representative) hears about it when the share is created, not when it’s first used. Silent grants are the precise mechanism by which a family dispute becomes litigation.
  • Recovery that doesn’t quietly defeat the whole thing. An account-recovery flow that lets the operator restore plaintext is an E2EE system with a hole in it, and every public claim made in reliance on the encryption goes down with it.
  • And a documented risk assessment before launch – required by several state laws and, if Quebec is ever in scope, mandatory before deployment.

None of this made us reconsider the privacy stance. It did permanently cure us of the idea that privacy-by-design is a shortcut. It’s the right wall to build; it is not a door out of the building.

And Canada

We’d like Lou to work in Canada – the honest scope today is “possibly Canada,” and here’s the short version of why it’s its own decision rather than a checkbox. PIPEDA requires express consent for sensitive data, which health data always is – directionally similar to the US state laws, so a design that clears Washington’s bar travels reasonably well. Quebec’s Law 25 goes further: a privacy impact assessment before deployment, privacy-by-default as a legal requirement rather than a design preference, explicit consent, and its own breach regime. And CASL puts the notification messages themselves on the checklist – its core rules cover commercial electronic messages, and whether the email that says “you’ve been given access to Emma’s readings” counts as one is a question a CASL analysis has to answer, not an assumption to make. This is honestly rather sensible; it is also one more thing. Health Canada’s software-as-medical-device rules would need the same claims-discipline analysis we did for the FDA before any launch there. Canada is on the list. It is not a footnote to the US launch, and we won’t treat it as one.

Planned -- not yet built

The path we’ll probably take: ask the person

So, knowing all of that – what will we actually do? Plans, not promises: single-user, local-only Lou is the product that’s shipping, sharing has no date, and the technical backend design isn’t settled. But the direction has been fixed for a while, because every line of the analysis above points at the same door:

Get permission from the person the data is about, and mean it.

Concretely, the sharing model we’re designing toward:

  • You invite; nothing is shared by default. Sharing is initiated by the user, per person, as a deliberate act – never an account setting that quietly applies to everything.
  • You control visibility, granularly. A recipient sees the subset you chose – which household member, which categories – starting from the minimum, expanding only by your explicit say-so.
  • You can see exactly who has access. A plain-language list, at any time: who, to what, since when, on whose authority.
  • You can revoke anyone, at any time. Effective immediately, keys rotated, the recipient’s device told to delete its copy – described to you with best-effort honesty, not marketing absolutes.
  • We can’t read any of it. End-to-end encrypted, keys on your devices, and our inability to access your health data preserved as deliberately as the data itself. The same property that has been Lou’s whole personality since the first commit, carried into the one feature that most tempts an app to abandon it.

There’s one more thing the legal analysis handed us, and it’s the practical insight this whole exercise was worth: almost all of the authority-model complexity exists only where the account holder and the data subject diverge. Where they’re the same person – you, sharing your own medications with your spouse or the babysitter – the authority question answers itself, and everything else (granular consent, scoped grants, revocation, audit) still applies but is buildable. That’s a viable first slice: start where consent is simplest and the law is satisfiable, design the data model for the split from day one, and bring in proxy-managed subjects – the child, the aging parent – once the authority model has been through counsel. The phase line, usefully, was drawn for us by the law itself.

The quiet punchline of the whole exercise: the most private design and the legally lightest design turned out to be the same design, and it still takes this much work to do properly. That asymmetry explains a lot about the health-app market – door number three, the one where you bolt on an analytics SDK and monetize the “engagement,” is cheaper right up until the FTC explains otherwise. We’d rather do the homework. The label is right and the app is wrong; the law, for once, mostly agrees with the ethos.

Lou is in development for iPhone and iPad. If you’d like to hear when it’s available, or you’re interested in early testing, get in touch – we’d love a few households who care about this as much as we do.

Edited 2026-07-24. Two corrections: the App Store rule for drug dosage calculators is Guideline 1.4.2, not 1.4.3, and its allowed list is broader than we first wrote (drug manufacturers, hospitals, universities, health insurers, pharmacies, and other approved entities). Also updated the count of comprehensive state privacy laws, which has grown well past half a dozen.

Edited 2026-07-27. The sections on multi-person sharing and end-to-end encryption are now marked as planned – they describe a design we’re working toward, not features of the shipping app, and the surrounding prose has been adjusted to match. Three smaller fixes: Lou is named in honour of the author’s daughter, not for the households feature; the lock-screen notification example now uses an over-the-counter medication, consistent with the demo-data curation described above it; and the CASL sentence is hedged, since whether an access-notification email is a commercial electronic message is a question for analysis rather than a given.