The problem InfinityCare solves

🏥 The Problem InfinityCare Solves

Healthcare today is broken at the data layer. InfinityCare fixes it.

---

The Core Problem

Modern healthcare generates enormous amounts of sensitive data — prescriptions, lab reports, discharge summaries, medicine records — but the systems managing this data are siloed, insecure, forgeable, and inaccessible at the moments that matter most.

---

Who Suffers

Patients     → No control over their own medical records
Doctors      → Make decisions with incomplete or unavailable history
Hospitals    → Can't verify patient identity in emergencies
Pharmacies   → No way to confirm if a prescription is real
Vendors      → Medicine authenticity unverifiable at point of sale

---

What InfinityCare Solves

🔐 1. Patient-Owned Medical Records

Patients upload their documents (lab reports, prescriptions, insurance) to a encrypted, personal medical vault. They explicitly grant or revoke access per institution — no hospital sees your records without your consent toggle.

🧬 2. Biometric Emergency Identification

If a patient arrives unconscious at a hospital, a nurse can run DeepFace neural network matching against the registered patient database to identify them in seconds — unlocking only the records that patient pre-authorized for hospital access.

💊 3. Blockchain-Verified Medicine Supply Chain

Every medicine batch is registered on the Algorand blockchain by the vendor at manufacture. A unique QR code is generated and attached. Pharmacies and patients can scan this QR to verify authenticity — GENUINE, EXPIRED, TAMPERED, or SUSPICIOUS — with an immutable on-chain record that cannot be faked or revised.

📄 4. AI-Powered Prescription & Document Analysis

Patients can upload any medical document and receive an AI-generated clinical summary — symptoms, medicines, dosage, and notes extracted automatically. A separate disease prediction engine takes symptom input and returns ranked differential diagnoses. Everything runs through server-side proxies: no raw medical data touches a third-party API directly.

🖊️ 5. Digital Doctor Prescriptions with QR Codes

Doctors issue digital prescriptions signed with their uploaded signature and encoded as a scannable QR code. Pharmacies scan the QR to instantly pull and verify the prescription — eliminating handwriting errors, forgeries, and lost paper slips.

📋 6. Full Audit Trails with Patient Notifications

Every time a hospital accesses a patient's record, an access log is written and the patient is notified in real time. Patients see exactly who viewed what and when — creating genuine accountability in a space that currently has none.

---

The Unified Stack

InfinityCare doesn't solve these as disconnected features — it's one coherent platform with role-based access for every actor in the healthcare chain:

PATIENT  → Upload docs · Grant access · Get AI summaries · Verify medicines · View notifications
DOCTOR   → Issue digital prescriptions · View patient summaries · Track dispensing
HOSPITAL → Search patients · Emergency face ID · View authorized records
NURSE    → Run emergency biometric face matching
PHARMACY → Scan & validate prescriptions · Log dispensing · Check medicine stock
VENDOR   → Register medicines on blockchain · Generate verification QRs

---

Why Now, Why Blockchain + AI + Biometrics

These three technologies have historically been used in isolation. InfinityCare is one of the first attempts to combine them into a single, end-to-end healthcare trust layer:

• Blockchain makes medicine provenance immutable and publicly verifiable
• AI makes patient data useful without requiring human intermediaries
• Biometrics solves the hardest identity problem in healthcare: the unconscious patient

Together, they eliminate the three biggest failure points in healthcare data: forgery, inaccessibility, and lack of consent.

---

Built for Hacktropica Hackathon · InfinityCare — Trust Infrastructure for Healthcare

Challenges we ran into

🚧 Challenges I Ran Into

A candid breakdown of the real technical challenges faced while building InfinityCare — a full-stack healthcare platform combining blockchain medicine verification, AI-powered document analysis, biometric face recognition, and a multi-role access control system, all built under hackathon time constraints.

---

1. Prisma Client Not Generating After npm install

Q: Why did the app crash with Cannot find module '.prisma/client/default' immediately after cloning and installing?

A: Prisma generates its typed client into node_modules/@prisma/client at build time via prisma generate. This generated output is gitignored, so a fresh npm install alone is never enough. The app would boot, hit [src/lib/db.ts], and immediately throw a runtime crash before a single page could render.

Fix: Run npx prisma generate after every npm install. We also added it as a postinstall script so it's automated.

| Step | Command |
| Install deps | npm install |
| Generate Prisma client | npx prisma generate |
| Start dev server | npm run dev |

---

2. Prisma + Supabase Connection Pooling (PrismaPg Adapter)

Q: Why couldn't we just use the default Prisma connection string with Supabase?

A: Supabase's hosted Postgres requires connection pooling via PgBouncer for high-concurrency serverless environments (Next.js API routes spin up per-request). The standard DATABASE_URL with ?pgbouncer=true added breaks Prisma's native migrations and client. We had to use the @prisma/adapter-pg driver adapter combined with the pg connection pool, while stripping query params (?pgbouncer=true) when connecting from the Python service.

// src/lib/db.ts - The non-obvious solution
const pool = new Pool({ connectionString });
// @ts-expect-error mismatched @types/pg between pg and @prisma/adapter-pg
const adapter = new PrismaPg(pool);

The @ts-expect-error suppression itself is a symptom of the version mismatch between pg, @types/pg, and @prisma/adapter-pg — all three need to be pinned to aligned versions.

---

3. Integrating BetterAuth with a Custom role Field

Q: Adding user roles (PATIENT, DOCTOR, HOSPITAL, etc.) clashed with BetterAuth's opinionated user schema — how did we handle it?

A: BetterAuth generates its own User table via its own migration system. Our Prisma schema needed an additional role enum field that BetterAuth doesn't know about. The challenge was keeping BetterAuth's session/account tables in sync while adding our domain-specific fields without breaking the adapter.

Solution: Declared role as an additionalFields in the BetterAuth config with input: true so it's accepted during sign-up. We also had to ensure the Prisma schema's Role enum exactly matched what the auth client sent, and that the middleware could read it from the session cookie without an extra DB round-trip.

---

4. Algorand Blockchain Integration — Signing Transactions in the Browser

Q: How did we handle wallet signing for medicine registration without exposing private keys or writing a custom wallet?

A: We used the Pera Wallet SDK for browser-based transaction signing. The tricky part: algosdk generates a Transaction object server-side (or in a utility), but signing must happen client-side via the user's connected wallet. This meant:

1. Building the transaction on the client using algosdk.makePaymentTxnWithSuggestedParamsFromObject
2. Encoding medicine metadata as a UTF-8 note field (max 1KB on Algorand)
3. Sending the signed transaction to the Algorand Testnet via AlgoNode's public API (no token needed)

A 0-ALGO self-payment with a JSON note is the canonical "data anchoring" pattern on Algorand — but finding that pattern and understanding its constraints took significant research time.

---

5. DeepFace Python Service — Cold Start, Dependencies & CORS

Q: The face recognition feature requires a Python Flask service running locally. What made this difficult?

A: Several compounding issues:

• TensorFlow download size: deepface depends on tensorflow (~350MB). On a weak or throttled network (common at hackathons), pip would fail mid-download with Connection forcibly closed by remote host.
• Module not found at runtime: psycopg2 and deepface weren't in the system Python — we had to create a dedicated venv and install into it.
• VGG-Face model auto-download: The first /match request triggers DeepFace to download the VGG-Face model weights (~550MB) into ~/.deepface/weights/. This adds a >1 minute cold start to the very first recognition attempt with no UI feedback.
• CORS: The Next.js frontend (:3000) calling