MedLens handles some of the most sensitive data a person owns. Three deliberate design boundaries protect it: local-first storage, a regulatory firewall that keeps clinical interpretation out of the app, and strict rules on what can appear on a lock screen.
Local-first by default
All records — photos, text, vitals, medications, lab values, events — live in a local SQLite database and a structured photo directory on the device, encrypted at rest. The app has no account system and no server that holds medical data. The default OCR tier runs entirely on-device, so on the default settings nothing leaves the phone at all.
Photos are the audit trail and are never auto-deleted; deletion is always an explicit user action. When a photo is deleted, the records it produced are kept and simply unlinked — a corrected medication entry is still valuable even without its source image. Export is “copy one folder”: a patient’s entire photo set lives under a single directory.
The SaMD firewall
MedLens is the patient-side half of a deliberately split two-app stack. The split is also a regulatory boundary, drawn to keep MedLens out of Software-as-a-Medical-Device territory:
- MedLens (patient side) captures, displays, stores, and exports. It does no interpretation, generates no flags, and never says “this is dangerous.” It is patient-controlled and local-first.
- The clinician side is where interpretation, pattern detection, and flags live — surfaced only to clinicians, who see the inputs and the logic and decide independently.
This division is load-bearing. Moving flag generation, rule evaluation, or any “this looks concerning” UI into MedLens would turn a capture tool into a regulated medical device. The only path by which data crosses the firewall is an explicit, patient-directed disclosure: the patient hands a clinician a scoped, time-limited token or a printed QR code; the clinician redeems it; that is the only moment data flows out.
Notification PII rules
Local notifications (medication reminders, check-in reminders) are treated as semi-public, because a locked phone can show the notification body in full on the lock screen. The rule: notification bodies must not contain patient PII by default — no patient name, drug name, dose, diagnosis, lab values, vitals, room number, MRN, or date of birth.
The pattern every notification follows:
- The title is a short generic category label (“Medication Reminder”, “Daily Check-in”).
- The body is generic and PII-free (“Tap to view”).
- The entity ID (an opaque UUID, not a name) is carried in the notification’s data payload so the tap router can open the right screen inside the unlocked app.
- The Android channel is registered private, and the iOS category carries a preview placeholder, as defense in depth.
Putting a medication name in the body is possible only behind an explicit, default-off user preference. Each privacy-safe default is pinned by a regression test that asserts no PII-shaped substring appears in the body.
What MedLens deliberately does not do
The scope is intentionally narrow. MedLens does not do clinical decision support, symptom checking, or dose calculation; it does not write back to any institutional EHR; it does not sync across devices through a cloud; and it does not replace the patient portal for messaging, refills, scheduling, or telehealth. Each of those is excluded for a concrete reason — it needs a live institutional integration the patient cannot operate alone, it needs server-side state that contradicts local-first, it has a far better incumbent, or it crosses into regulated-device territory. MedLens earns its keep as the capture layer for everything that happens outside the portal: whiteboard photos, IV bag labels, lab printouts, monitor screens, and conversations after rounds.
See also Trends and Charts for how the display stays on the safe side of that line.