Medical Health Records Tracker
A mobile app that turns scattered medical records into one shared timeline and tracker for the whole family to see.
Project Context
This past summer, I had the opportunity to visit my grandparents in Chennai and spend some time with them. The first few weeks I was there, they were in and out of the hospital, dealing with multiple hospital stays, doctor visits, etc. and I began to notice how along with trying to manage the current health situation, a lot of the conversation revolved around keeping track of medical health paperwork.
Which doctor needs to see the blood results? Do we need to bring this paper to show this doctor so that she can be discharged? Make sure you bring the prescriptions to show the medicines she is taking so that the doctors know what medicines to give in the hospital."
These were just a few of the questions that I overheard my family discussing while running back and forth from the hospital. It made me realize the breakdowns in the healthcare system in India wasn't the healthcare provided by the doctors, but the system itself. Without medical records or any knowledge of your medical history, doctors in India cannot properly know how to treat you. It was this that prompted me to make this app.
What is the current system like?
How is my app different?
It stores data, not documents. Most tools in this space save the scan. You upload a report, the app keeps the PDF, and later you open the PDF and read it. That handles storage but not retrieval. This app breaks each document into individual results — test, value, unit, date, source — so a lab value from 2019 and one from last month can be compared directly instead of read off two separate pages.
It's organized around the patient, not the institution. Hospital portals contain only what happened at that hospital. My grandmother's history spans several, so no single portal holds it. Here the record is structured by person, which is the one thing every document has in common and the thing the existing system doesn't index by.
The primary user isn't the patient. This shaped the interface more than anything else. Consumer health apps assume the patient logs in and tracks their own results. In my family, the patient is elderly and her care is managed by relatives in other cities. So the app supports multiple users from the start, the capture flow is built for whoever is at the hospital that day, and nothing assumes the person holding the phone is the person the record belongs to.
How does it work?
Step 1 — Take a photo of the document.
Anyone in the family opens the app and photographs a prescription, lab report, or discharge summary. That's the entire input. No typing, no scanner, and no need to understand what's on the page — whoever is at the hospital that day can just take the picture.
Step 2 — The app reads the document.
An AI vision model pulls out the details: medicine names and dosages, test names and results, dates, and the doctor's name. I used a vision model rather than normal scanning software because these documents are handwritten, often in more than one language, and formatted differently at every hospital.
Step 3 — You confirm what it read.
The app shows you everything it found and asks you to check it before saving. This step can't be skipped. Handwriting gets misread sometimes, and a wrong number in a medical record is worse than a slower process, so nothing is stored until a person has approved it.
Step 4 — The information gets saved, not the picture.
Instead of keeping the report as an image you'd have to open and read, the app saves each result on its own — the test, the number, the date, and the hospital it came from. Medicines and hospital visits are saved the same way.
Step 5 — Results with different names get matched up.
One lab writes "Creatinine," another writes "Serum Creatinine." The app keeps a master list of test names and matches all the variations to the same one, so results from different hospitals line up instead of looking like unrelated tests.
Step 6 — Everything appears in one timeline.
A result from 2019 at one hospital and a result from last month at another show up on the same chart. Medicines prescribed by different specialists who never spoke to each other appear on one screen. The question my family kept asking in hospital hallways becomes something you can answer in a few taps.
Step 7 — The whole family can see it.
Relatives coordinating care from other cities can open the same history from their own phones, instead of waiting for someone to photograph a page into a group chat.
Capture Flow, Medication History, List of Current Medications
Today, a medical record is a physical object that only exists where someone left it. A doctor writes on paper at the appointment. That page joins years of others in a folder at home. Whoever is present photographs it into the family group chat so relatives in other cities can see it. At the next appointment — often at a different hospital — someone has to find the right page again, and whatever isn't found simply isn't part of the conversation. The next doctor plans treatment from a partial history, and the cycle starts over.
Prototype
Login Screen, Landing Page, Example Test Report, Medical Test Timeline
Results, Doctor Summary, Sharing & Access
From Prototype to Code
After validating the design as an interactive prototype, I moved into building the application itself in Claude Code, Anthropic's AI development environment.
The build progressed in deliberate stages. First, the prototype's screens were connected to a real foundation: a Node.js/Express API and a PostgreSQL database, replacing every placeholder interaction with live data. Next came the core capability — an AI extraction pipeline using the Claude API, which reads a photographed lab report or prescription and returns structured data (test values, medications, dates, and a plain-language summary) that the user reviews and can edit before saving.
For storage, I kept a single source of truth: PostgreSQL, hosted on Supabase. Relational tables hold accounts, patient profiles, and records — with each document's structured extraction stored as JSON alongside indexed metadata, and the original PDF or photo stored as binary data linked to its record. Every query is scoped to the authenticated account, so one family's data is never visible to another, and original files are served only through single-use, expiring access links.
I deployed the application on Render with continuous deployment from GitHub — every push rebuilds the live app — and packaged it as an installable Progressive Web App, giving it a home-screen icon, full-screen launch, and instant opening on both Android and iPhone without app-store distribution (For right now).