Accenture Innovation Challenge 2026 · Prototype Development
Track: PatientTriage.ai
TriageSetu turns a crowded emergency-department queue into a continuously prioritized, explainable workflow — combining clinical safety rules, ML-assisted risk scoring, ABHA-enabled patient context, and clinician oversight.
Emergency departments operate under pressure: many patients arrive at once, clinical information is incomplete, and the order in which patients are reassessed can change rapidly as waiting time increases.
The challenge is not simply predicting risk. A useful triage system must answer four questions at the point of care:
- Who needs attention first?
- Why was this patient prioritized?
- How confident is the system?
- What happens when the clinician disagrees or the patient's condition changes?
TriageSetu is designed around these questions.
TriageSetu is a clinician-in-the-loop emergency triage platform built around a conservative hybrid decision architecture.
Patient arrival
│
▼
Structured intake ────────► ABHA / prior-history context
│ │
▼ ▼
Clinical safety rules Relevant patient history
│ │
└──────────────┬───────────────┘
▼
ML risk estimation
│
▼
Conservative fusion
│
▼
ESI-prioritized queue
│
┌──────────┴──────────┐
▼ ▼
Clinician review Reassessment loop
│ │
▼ ▼
Confirm / override Escalate if needed
│ │
└──────────┬──────────┘
▼
Audit trail
The result is not a black-box score. It is an operational triage workflow that keeps the clinician in control while making the reasoning and urgency visible.
Instead of asking an ML model to make the entire decision, TriageSetu combines:
- Hard clinical safety rules for red-flag presentations.
- Model-derived risk estimation from structured patient signals.
- Conservative fusion when the two paths disagree.
- Explicit confidence and uncertainty rather than presenting every prediction as equally reliable.
Critical safety signals can therefore take priority over a lower model score.
A patient's position in the queue is not treated as permanent.
TriageSetu incorporates:
- wait-time tracking
- tier-specific reassessment windows
- deterioration escalation
- surge-mode prioritization
- continuous queue reprioritization
This reflects the real ED workflow: the risk of a patient who has been waiting is not necessarily the same as the risk measured at arrival.
Every recommendation exposes a compact decision trace:
Rule safety net → ESI tier
ML risk model → ESI tier
↓
System recommendation → ESI tier
↓
Primary contributing inputs
Clinicians can see the reasoning without having to interpret a model dashboard or inspect raw probabilities.
Prior medical history can be brought into the triage workflow through a dedicated, consent-gated ABHA/ABDM integration layer.
The interface focuses on the information most useful during triage:
- relevant conditions
- allergies
- medications
- recent encounters
ABHA information is deliberately presented as clinical context, not as an automatic instruction to the scoring model.
The prototype includes a deterministic synthetic ABHA demonstration flow so the complete workflow can be evaluated without requiring real patient records.
The system recommends; the clinician decides.
A clinician can:
- confirm the recommendation
- change the clinical tier
- provide a rationale
- transfer the patient
- mark treatment/disposition
- add clinical notes
Confirmation and overrides are recorded in the audit trail, creating accountability without removing human judgment.
A structured intake captures the signals used by the triage engine:
- age and demographic information
- heart rate
- respiratory rate
- SpO₂
- temperature
- systolic blood pressure
- AVPU consciousness level
- chief complaint
- safety flags
- prior-history availability
The recommendation updates live while the clinician types, allowing the intake operator to see the emerging triage result before submitting the patient.
Enter ABHA number
↓
Confirm patient/attendant consent
↓
Fetch relevant history
↓
Review compact history
↓
Continue triage
The application masks the stored ABHA identifier and keeps the history retrieval behind a server-side adapter.
The queue is designed for rapid scanning rather than data-heavy administration.
Patients are surfaced using:
- ESI tier
- confidence
- wait time
- deterioration/reassessment state
- key red flags
- clinical status
Urgent patients remain visually prominent while lower-risk patients continue to be monitored rather than disappearing into a static list.
Selecting a patient opens a dedicated clinical workspace containing:
- patient identity and current triage tier
- confidence level
- vital-sign strip
- clinical summary
- chief complaint
- prior history
- recommendation trace
- primary model inputs
- clinical notes
- clinician tier confirmation/override
- transfer and disposition actions
The modal uses an independently scrolling clinical body and a persistent action area so the decision controls remain immediately accessible.
TriageSetu treats waiting as a clinical variable.
Prototype reassessment windows are tier-aware:
| Triage tier | Reassessment window |
|---|---|
| ESI 1–2 | 15 min |
| ESI 3 | 30 min |
| ESI 4–5 | 90 min |
A patient whose waiting time crosses the safety boundary can be surfaced for reassessment rather than remaining passively ranked by the original intake score.
During periods of unusually high demand, the workflow can switch into surge mode, increasing the operational visibility of high-risk patients and tightening prioritization around the most important safety signals.
This is intended to support the exact environment where manual triage queues become hardest to manage: many arrivals, limited attention, and rapidly changing priorities.
TriageSetu uses a 15-feature structured representation of the patient.
Two decision paths run independently:
Transparent safety rules identify presentations that require immediate escalation, including signals associated with:
- impaired consciousness
- severe bleeding
- oxygenation compromise
- neurological symptoms
- concerning chest symptoms
- age-specific vital-sign abnormalities
The model path estimates a triage risk tier from the structured clinical signal.
The runtime uses the distilled scoring logic in src/lib/triage.ts, allowing the complete prototype to run locally without depending on an external inference service.
The final recommendation considers:
Rule result
+
Model result
+
Confidence / uncertainty
+
History availability
+
Wait-time / reassessment state
↓
Final recommended tier
When uncertainty or disagreement is meaningful, the system favors escalation and clinician review rather than false precision.
Tested on held-out data, not assumed. The model path alone under-triages (assigns a less urgent tier than the true one) 17.7% of tier 1-2 patients. The rule engine alone under-triages 14.0%. Fused, as the production code actually runs, the under-triage rate drops to 4.7%. This is the measured effect of the design in score(), not an assertion of it. The training data, the trained model, and the script that produces these numbers are in /model, reproducible with python3 model/validate_fusion.py.
Healthcare AI needs more than a good prediction. TriageSetu therefore treats trust as a product feature.
ABHA history retrieval is gated by an explicit consent action in the intake flow.
Only a compact, triage-relevant subset of patient history is surfaced in the UI.
The raw ABHA number is not retained in the patient record; the displayed identifier is masked.
A change to the recommended tier requires a clinical rationale, preserving the human decision behind the final action.
Important workflow events — including scoring, overrides, history access, and status changes — are recorded for traceability.
TriageSetu is designed to augment clinical prioritization, not replace clinical judgment.
| Module | Purpose |
|---|---|
| Live Queue | Prioritized ED patient workflow |
| New Intake | Structured arrival assessment + live scoring |
| ABHA History | Consent-gated prior-history retrieval |
| Patient Detail | Explainable clinical review workspace |
| Reassessment | Wait-time safety monitoring |
| Surge Mode | High-load operational prioritization |
| Bed Board | Capacity visibility |
| Staff Roster | Operational staffing view |
| Analytics | Queue and triage insights |
| Audit Trail | Accountability and event history |
| Settings | Hospital/workflow configuration |
TriageSetu is a full-stack web prototype built for rapid deployment and demonstration.
Frontend
Next.js 16
React 19
TypeScript
Tailwind CSS
Radix UI
Framer Motion
Application
Next.js Route Handlers
Structured triage engine
ABHA/ABDM adapter
Data
Prisma ORM
SQLite for the prototype
Visualization
Recharts
State / UX
Zustand
React Query
React Hook Form
The architecture keeps the scoring engine, service layer, API boundary, and UI components separated so the prototype can evolve into a larger clinical platform.
TriageSetu treats ABHA as an identity and consent-aware health-data entry point rather than as a direct medical-record download key.
TriageSetu
│
▼
Consent-aware ABHA workflow
│
▼
ABHA / ABDM adapter
│
├── Demo mode → synthetic health history
│
└── Live mode → registered ABDM/HIU integration
The adapter normalizes relevant information into a compact structure that the application can display consistently.
The live integration boundary is server-side so credentials are never exposed to the browser.
The repository includes a synthetic ABHA demonstration flow for evaluating the complete user experience.
Demo ABHA numbers:
12345678901234
98765432109876
To demonstrate the workflow:
- Open New Intake.
- Enter the patient's structured clinical information.
- Enter one of the demo ABHA numbers.
- Confirm consent.
- Select Fetch history.
- Review the returned conditions, allergies, medications, and encounters.
- Submit the patient.
- Open the patient from the queue to see the history alongside the recommendation trace.
- Confirm or override the recommended tier with a clinical rationale.
This makes the entire workflow demonstrable from arrival → history → scoring → queue → clinician review → disposition.
- Node.js 20+
- Bun 1.0+ recommended
git clone https://github.com/HarshvardhanJ/TriageSetu.git
cd TriageSetu
bun install
bun run db:push
bun run devOpen:
http://localhost:3000
Create .env.local from .env.example.
For the included demonstration workflow:
ABDM_MODE="demo"No external ABHA credentials are required for the synthetic demo.
bun run dev # Development server
bun run build # Production build
bun run start # Production server
bun run lint # ESLint
bun run db:push # Apply Prisma schema
bun run db:generate # Generate Prisma client
bun run db:reset # Reset demo databaseTriageSetu/
├── model/ # Model development / evaluation material
├── prisma/
│ └── schema.prisma # Database schema
├── src/
│ ├── app/
│ │ └── api/ # API route handlers
│ │ └── abha/history/ # ABHA history endpoint
│ ├── components/
│ │ └── triage/ # Clinical workflow UI
│ │ ├── intake-form.tsx
│ │ ├── patient-detail.tsx
│ │ ├── live-queue.tsx
│ │ ├── analytics.tsx
│ │ ├── bed-board.tsx
│ │ ├── staff-roster.tsx
│ │ ├── audit-trail.tsx
│ │ └── settings-view.tsx
│ └── lib/
│ ├── triage.ts # Triage scoring engine
│ ├── service.ts # Data/service layer
│ ├── api.ts # Browser API client
│ └── abha.ts # ABHA/ABDM adapter
├── db/ # Prototype database
├── .env.example
└── README.md
TriageSetu's goal is simple:
Make the right patient visible at the right time, while keeping the clinician in control.
The prototype brings together three capabilities that are often separated in emergency-care software:
clinical safety intelligence + longitudinal patient context + operational queue management.
The result is a triage workflow designed not merely to predict risk, but to help emergency teams act on risk, explain it, reassess it, and remain accountable for the final decision.
TriageSetu
Accenture Innovation Challenge 2026 · PatientTriage.ai
MIT