Project Story – DialysisConnect India
1. What inspired me
I started exploring this problem while reading about India’s National Dialysis Programme and the gaps in how dialysis patients are tracked and transferred between hospitals. In many cases:
- A patient is registered at one center, but when they move (due to job, migration, or cost), their treatment history is lost.
- Doctors at the new center don’t know how frequently the patient missed sessions, what their vascular access history is, or what complications they had.
- Government and hospital administrators have limited consolidated data to see where missed sessions are high, where peritoneal dialysis is underused, or where new centers are needed.
I realized that even if we cannot directly solve financial access or build new machines, we can still improve reliability and continuity of care for patients who already have access to dialysis.
That insight became the core of DialysisConnect India: a government-ready, dialysis-specific platform that connects government, hospitals, doctors, and nurses through a unified registry, automated IVR confirmations, and structured cross-hospital record transfer.
2. What I learned
2.1 About the problem
Through research and reading reports, I learned:
- Many patients in India face fragmented care when they move between facilities.
- Missed sessions are common and dangerous; they can lead to severe complications and even death.
- Existing systems like PMNDP already do some registration and transfer, but there is still a need for:
- Better operational workflows (IVR-based confirmations instead of app-only reminders).
- Structured summaries for transfers, not just raw document uploads.
- Role-specific dashboards that focus on patient safety and policy insights.
2.2 About building a health-tech product
I also learned that:
- A health product must be realistic about what it can and cannot solve.
DialysisConnect India is not a solution to cost or physical access; it’s a reliability and continuity layer for patients who already have access to dialysis. - The system must be designed for how people actually work:
- Nurses and lab technicians often do the operational work.
- Doctors need quick, actionable insights, not long reports.
- Government needs aggregated data, not individual-level noise.
This shaped my thinking: 4 dashboards (Government, Hospital Admin, Doctor, Nurse/Lab Tech), no patient app, and IVR-based communication.
3. How I built the project
3.1 Conceptual design
I started with a problem statement:
“How can we reduce missed dialysis sessions and improve continuity of care when patients move between hospitals, without assuming that every patient has a smartphone app?”
From this, I defined the core features:
Unified dialysis registry
- Each patient has a unique ID.
- Fields: demographics, dialysis type, frequency, comorbidities, preferred center, and recent labs.
Role-based dashboards
- Government Admin:
- District/state-level stats: total patients, missed session rates, hemodialysis vs peritoneal dialysis.
- Transfer tracking and capacity indicators.
- Hospital Admin:
- Patient registration.
- Appointment scheduling.
- IVR campaign management.
- Cross-hospital record request and transfer.
- Doctor:
- Patient clinical summaries.
- Trends in labs and vitals.
- Flags for missed sessions and complications.
- Nurse / Lab Technician:
- Daily session list.
- Lab upload and session completion marking.
- Care flags for high-risk patients.
- Government Admin:
Automated IVR call system
- Calls sent 48 hours and optionally 24 hours before the session.
- Options:
- Press 1: Confirm attendance.
- Press 2: Request reschedule.
- Press 3: Indicate intention to transfer hospital.
- Each response updates the appointment status on all dashboards.
Cross-hospital record transfer
- When a patient moves:
- Current hospital sends a transfer request to the previous hospital.
- Previous hospital generates a Dialysis Summary:
- Last 6 months: sessions per week, average weight, key labs.
- Vascular access type and infection history.
- Complications (e.g., frequent hypotension).
- New hospital receives and views this summary in the doctor dashboard.
- When a patient moves:
This design intentionally avoids:
- A patient-facing app (to remain realistic for low-digital-literacy populations).
- An AI chatbot (to avoid over-reliance on unverified medical advice).
Instead, it focuses on structure, workflows, and data quality.
4. Challenges I faced
4.1 Realism vs ambition
Initially, I imagined a more complex system with:
- Patient dashboards.
- AI chatbot for triage.
- Real-time machine integration.
But as I researched, I realized:
- Many patients do not have smartphones or digital literacy.
- AI chatbots in healthcare are risky if not tightly controlled.
- Direct machine integration is beyond the scope of a student project.
So I simplified the idea to:
- Hospital and government dashboards only.
- IVR-based reminders instead of app notifications.
- Structured summaries for transfers rather than raw data dumps.
This was a key challenge: scaling ambition down to something implementable and realistic.
4.2 Designing the transfer workflow
Designing the record transfer logic was tricky:
- I had to decide:
- What data should be shared?
- How to ensure patient consent?
- How to track the status of the transfer (requested, pending, completed)?
I modeled this as a simple state machine:
[ \text{TransferState} in { \text{Requested}, \text{Pending}, \text{Completed}, \text{Rejected} } ]
Each state transition is logged, so the system can show:
- When the request was sent.
- How long it has been pending.
- Whether the summary was received.
This keeps the transfer process transparent and auditable.
4.3 Balancing government and hospital needs
Another challenge was making the system useful for both:
- Government needs:
- Aggregated, anonymized data.
- Policy insights (missed sessions, capacity gaps).
- Hospitals need:
- Operational tools (scheduling, call management, transfers).
- Patient-level insights for doctors and nurses.
I had to design separate views:
- Government dashboard: district-level charts, maps, and trend lines.
- Hospital dashboards: tables, forms, and alerts.
This required careful separation of concerns in the UI design, even though I haven’t implemented the full system yet.
4.4 Avoiding over-engineering
I struggled with:
- Whether to add too many advanced features.
- Whether to try to model every edge case in transfers and IVR flows.
To stay within a realistic scope, I decided:
- Focus on the core workflow:
- Registration → Scheduling → Call campaign → Session completion → Transfer.
- Treat other features (e.g., advanced analytics, patient cards) as future enhancements.
5. What this project means to me
This project is more than a hackathon idea for me. It’s:
- A way to apply my interest in AI, product management, and systems thinking to a real health problem.
- A step towards understanding how technology can support continuity of care and policy planning, not just individual convenience.
- A practice in being honest about limitations: I can’t solve cost or access, but I can help make existing access more reliable and continuous.
Moving forward, I want to:
- Build a minimal prototype (e.g., mock dashboards and a simple simulated IVR flow).
- If possible, talk to someone in nephrology or hospital operations to validate the design.
- Keep refining the idea based on real feedback, not just imagination.
DialysisConnect India is still in the idea and design phase, but it represents a clear direction: a practical, government-ready platform that makes dialysis care in India more reliable, continuous, and data-driven.
Log in or sign up for Devpost to join the conversation.