MediSync-Setu

Inspiration I kept reading about how patients get lost in the shuffle when they move between a clinic, a hospital, and back home again — their medicine list quietly changes at every step and almost nobody double-checks it. WHO's own data backed this up: preventable medication-related harm hits roughly 1 in 20 patients globally, and the risk is even higher in countries like India where a lot of prescriptions are still handwritten and scattered across different providers. That gap between "what was prescribed" and "what the patient is actually taking" felt like a very solvable, very underserved problem.

What it does MediSync-Setu lets a patient upload their old prescription, their hospital discharge summary, and their current medicine list. It compares whatever documents are available and flags the stuff that actually matters — a medicine that quietly disappeared, a duplicate, a dose that changed, an allergy conflict — and turns each one into a plain, specific question the patient can bring to their doctor or pharmacist. It doesn't diagnose anything or change a prescription on its own; it just makes sure nothing slips through the cracks silently. Even if a patient only has two of the three documents, it still reconciles what it can instead of refusing to work.

The part I'm most excited about is that the verified, reconciled list doesn't just sit inside my app — it gets structured as FHIR resources and linked to the patient's ABHA ID, so it becomes part of their actual, portable health record instead of being stuck in yet another siloed medicine-reminder app.

How I built it For this round it's an idea/architecture submission, so the plan is: React for the upload and comparison UI, Node/Express for the reconciliation logic, OCR (Tesseract.js or a vision API) to pull medicine names off prescription photos, and a deterministic rules engine — not AI — for anything safety-critical, since I don't want the app guessing at things that could actually hurt someone. AI only comes in to translate medical instructions into plain language for the patient. For the health-record side, I'm building against ABDM's public developer sandbox so the data is FHIR R4 / India Core compliant from day one.

Challenges I ran into The biggest one was figuring out what I could honestly claim. I initially thought about positioning this as hospital-integrated, but after digging into how ABDM actually works, I learned that only licensed health facilities can register as a "Health Information Provider" — an individual app has to go in as a Personal Health Record (PHR) app instead, the same category as Aarogya Setu 2.0. That's actually a completely valid and buildable path, it just needed the correct framing. The other real challenge is that OCR on handwritten Indian prescriptions is genuinely messy, so the design leans on the user confirming every extracted item before any comparison runs. I also had to stress-test what happens when a patient doesn't have all three documents — the engine is designed to still work with partial data rather than failing outright.

Accomplishments that I'm proud of I'm proud that this idea holds up under scrutiny — every claim in it is something I could actually defend if a judge pushed back on it, instead of vague "AI will solve it" language. Positioning it correctly as a FHIR-native PHR app rather than overclaiming hospital-level integration took real research into how ABDM's HIP/HFR/sandbox system actually works, and I think that grounding is what makes this stand out from existing medicine-reminder apps like Karma Dost or DavaAI.

What I learned I learned a lot about how India's digital health infrastructure actually fits together — ABHA IDs, FHIR R4 resources, the difference between a licensed Health Information Provider and a Personal Health Record app, and why that distinction matters for anyone building health tech here. I also learned to be more careful about separating what a system technically requires from what would just make a nicer demo — designing for missing or incomplete data turned out to be more important than I expected.

What's next for MediSync-Setu If this makes it to the final round, the next step is a working prototype against the ABDM sandbox — starting with clearly typed/printed prescriptions first, with handwriting support as a stretch goal, and making sure the comparison engine still works even if a patient is missing one of the three source documents.

Built With

• abdm
• express.js
• fhir
• hl7
• javascript
• mongodb
• node.js
• ocr
• react
• tesseract.js