One medicine list from a shelf of pill bottles

The idea

Point a phone at the pill bottles on a kitchen shelf and get back one clean list: drug name, active ingredient, strength, dose schedule, prescriber, and pharmacy. The app reads each label with on-device OCR, matches the text to a real drug identity rather than storing a photo of a sticker, and exports a printable one-pager. It also notices when two bottles contain the same active ingredient under different brand names.

Why build this

Every clinical encounter starts with "what are you taking?" and for an older adult on eleven medications the honest answer is a carrier bag of bottles. Adult children managing a parent's care end up rebuilding that list from scratch before every appointment, hospital admission, and pharmacy switch — and the rebuilt list is usually wrong, because brand names, generics, and discontinued doses all live in the same bag.

The reason to do it now is that the boring part got cheap. On-device text recognition is accurate enough on a printed pharmacy label without a server round trip, and the drug vocabularies needed to turn "Lipitor 20mg" into a stable concept ID are free, public, and queryable. What used to need a licensed data deal and a backend is now a weekend of plumbing.

Stack sketch

• Expo / React Native, targeting iOS first — that is where the caregiving demographic's family members are.
• react-native-vision-camera with the MLKit text recognition plugin for on-device OCR. No image ever leaves the phone.
• RxNav's RxNorm APIs (approximateTerm, then rxcui/{id}/related) to resolve messy label text to an RxCUI and pull the ingredient, strength, and dose form.
• openFDA's drug label endpoint for the plain-language "what is this for" blurb and the manufacturer's own warnings text.
• expo-sqlite for local storage, keyed behind device biometrics; no accounts, no server, no sync in v1.
• expo-print to render the list to PDF, plus a plain share sheet so it can be AirDropped or emailed to a clinic.

Scope for v1

In:

• Scan a label, review the parsed fields, correct them by hand. Manual correction is a first-class path, not an error state.
• Per-person lists — a caregiver often manages two parents.
• Duplicate-ingredient detection: same RxNorm ingredient appearing in two entries gets flagged.
• PDF export with a generated-on date and a "verify with your pharmacist" footer.

Out:

• Drug–drug interaction checking. Say so plainly in the UI.
• Reminders and adherence tracking. That is a different app with different retention mechanics.
• Cloud sync, sharing between family members, any account system.
• Anything resembling advice about whether a medication is appropriate.

Where it could go

The obvious next step is the handoff. A caregiver who has a clean list wants it to arrive somewhere — a clinic portal, a hospital pre-admission form, a new pharmacy's transfer request. SMART on FHIR gives you a standards-based way to push a MedicationStatement bundle into a patient portal, and doing that well is genuinely hard, which makes it defensible.

After that, the interesting asset is the change history. If the app has scanned the same shelf every three months for two years, it knows when a dose changed, when something was discontinued, and when a new prescriber appeared. Presenting that timeline to a geriatrician is more useful than the current-state list, and it is a reason to keep the app installed between appointments. A quieter path is white-labelling it for independent pharmacies who want a branded tool to hand new customers at transfer time.

Watch out for

Interaction data is the trap: NLM retired its free interaction API, so anything beyond duplicate-ingredient flagging means a commercial license and a much heavier regulatory posture. Keep the product firmly on the "record what is in the bag" side of that line, and make the disclaimer visible in the export rather than buried in a settings screen.