Architecture

How MediWall protects your health data

A technical write-up for people who want the details, not the promise

Most health apps ask you to trust a privacy policy. We think that's backwards: a policy is a promise about what a company chooses to do with data it holds. We'd rather not hold it. This page explains, concretely, how that works.

The one-sentence version: MediWall has no accounts and no servers that store health data, so your records are encrypted on your device and stay there — we couldn't read them if we wanted to.

No account system at all

There is no sign-up, no email, no password, and no user table. This isn't a setting we could flip later — there is simply no identity infrastructure in the product. The consequences are worth spelling out:

  • There is no credential of yours to be phished, reused, or leaked.
  • There is no database of MediWall users that could be breached, subpoenaed, or sold in an acquisition.
  • We cannot email you about your health data, because we don't know who you are.

On-device encrypted storage

Your records live in a SQLCipher-encrypted SQLite database on your iPhone — AES-256, encrypted at rest. Everything durable rides in that one encrypted file: medications and dose history, appointments and visits, your care team and their notes, symptoms, mood check-ins, conditions and allergies, lab results, medical to-dos, document attachments, and the audit log.

The encryption key is generated on-device and stored in the iOS Keychain, backed by the Secure Enclave. The database is opened fail-closed: if the key is missing or empty, the app refuses to open the database rather than silently falling back to an unencrypted one.

Biometric gate

You can require Face ID or Touch ID at launch, with your device passcode as the fallback. This is a lock on top of the encryption, not a substitute for it — the data is encrypted whether or not the gate is on.

Connecting your hospital records (SMART on FHIR)

When you connect a hospital, MediWall uses SMART on FHIR — the same patient-access standard the Cures Act made universal — with an OAuth 2.0 authorization-code flow using PKCE. In practice:

  • You sign in on your hospital's own portal page. MediWall never sees your portal username or password.
  • The hospital releases records directly to your device, where they're written into the same encrypted database.
  • Access tokens are stored in the iOS Keychain (expo-secure-store), never in the database or on a server.
  • You can revoke MediWall's access at any time from your patient portal's security settings — nothing needs to go through us.

One deliberate exception to "no servers": the OAuth redirect. iOS Safari refuses a server-side redirect straight to a custom app scheme, so the hospital returns you to a bounce endpoint on this website that immediately re-emits the link into the app. That endpoint is a redirect and nothing else — it does not receive, log, or store your records. Your health data goes hospital → your phone, never hospital → us → your phone.

Backup: encrypted, and in your iCloud, not ours

iCloud backup is optional and off until you turn it on. When enabled, MediWall writes a whole-file encrypted snapshot of the database into your personal iCloud container. We have no access to that container.

So a restored snapshot is decryptable on your new phone, the database key is mirrored through the iCloud Keychain — Apple's end-to-end encrypted keychain sync, which Apple itself cannot read. The practical upshot: your backup is useless to anyone who isn't you, including us and including Apple.

You can see and take everything

  • Audit log — sensitive actions are recorded and visible to you inside the app.
  • Export — take the whole database out as JSON, any time, no request form.
  • Delete — erase everything with one tap. Since there's no server copy, deleted means deleted.

What we do collect

Optional, de-identified usage counts — the number of times a feature was used, with no health data, no free text, and no identifiers attached. It tells us "the Emergency Card was generated 40 times today," never who, never what was on it. It's disclosed on first run, switchable off in Settings, and the allowed event list is a fixed allowlist on both the app and the receiving endpoint: anything not on that list is dropped.

This website's waitlist form stores the name, email, and optional message you type into it. That's a marketing list, entirely separate from the app, and it never contains health data.

Details we sweat

  • Release builds strip console logging, so health data can't leak into device logs.
  • Lock Screen widgets show times and counts only — never medication names or appointment titles — because Lock Screen content renders before you authenticate.
  • Caregiver profiles are separate encrypted databases. If you manage a parent's care alongside your own, each profile is its own encrypted file with its own backup — not co-mingled rows in one table.
  • Attachments live inside the encrypted database, not as loose files on disk, so a photo of a lab result gets the same encryption and the same backup coverage as everything else.

Honest limitations

A trust page that only lists strengths isn't a trust page. So:

  • Your device's security is the floor. On a jailbroken or malware-compromised phone, on-device encryption can't save you.
  • If you lose your phone with backup off, the data is gone. That's the direct cost of us not holding a copy. Turn on iCloud backup.
  • Records from your hospital are governed by your hospital. We show you what they release; we can't correct errors in their chart.
  • Once you export or share, it's out of our architecture. A JSON export or a printed Emergency Card is a normal file or piece of paper.
  • MediWall is not a medical device and doesn't provide medical advice. It organizes what you and your providers put in.

Regulatory posture

MediWall's privacy practices are aligned with PIPEDA (Canada) and HIPAA safeguard principles (United States). Notably, because health data never reaches our infrastructure, the most dangerous category of breach — a central store of many people's medical records — doesn't exist here. The full policy, with compliance mappings, is in the privacy policy.