Rostering Engine

Timing & workload

Slot length and the consecutive-order break threshold for this unit.

Default assignment mode

What happens when Digicare doesn't specify a mode explicitly for an order in this unit.

Address lookup (geocoding)

Automatic: an address with no coordinates is looked up (house number removed first; repeat addresses are cached). Manual: nothing is ever sent for lookup for this unit — every row must carry latitude/longitude.

Recent assignment events

Last 25 decisions for this unit, most recent first.

1. Download templates

CSV templates with sample rows and column definitions. Fill in your own phlebo and order data, keeping the header row unchanged.

2. Upload phlebo data

Upserts by phleboId into the selected unit — safe to re-upload after edits. Enter coordinates directly if you have them (e.g. looked up in Google Maps), or an address for automatic lookup. Real Digicare exports (e.g. a Slot Utilization Report) work directly too — the platform detects the format.

2b. Add a single phlebo

For onboarding one new staff member without building a spreadsheet. Enter their coordinates directly (look them up once in Google Maps, or wherever) — this is the primary way to set a phlebo's location; address-based lookup is available as a fallback if you'd rather type an address.

3. Upload orders & run allocation

Orders are processed in file order and auto-confirmed as they're assigned, so route-continuation and the break-after-N-orders logic play out across the whole batch — the same as a real night-time bulk plan. Same as phlebos: just enter the patient address, coordinates are looked up automatically. Real Digicare exports (e.g. a Detailed Appointment Report) work directly too.

History load — add this file to the reports only (no address lookup, no allocation). Use it for past days' Digicare exports so Booked / Consumed / Cancelled reports have history.

Results

Staff on file (validate & download)

The phlebotomists currently stored, with name, home address and coordinates decrypted so you can check what was actually saved. "Coordinates check" flags missing or out-of-India values. Admins only; every download is recorded in the audit log (who and when, never the data).

Override an assignment (Team Leads & admins)

Pick the phlebo you want for one order. Your choice is final — if it breaks a break/shift rule you get a warning, never a refusal. Your name and the phlebo you replaced are recorded.

Data protection maintenance (super admin)

Encrypts any sensitive field saved as plain text by an older version (staff names/addresses, cached addresses). Safe to run repeatedly. Run the check first — it only counts.

Upload history

A record of what was uploaded and the outcome — never the row content itself (see README "PII handling on upload" for why).

Billing units

This list drives every unit picker in the console (rules, test data, user access). A unit id is just a label this platform uses internally to group phlebos and orders together - it does not need to match any real Digicare billing number unless a live Digicare API integration exists later. Add one row per operational pool, e.g. Delhi/NCR's 7 spokes share one unit here.

Spoke mapping

This is what actually resolves a spoke/location name from a real Digicare upload (e.g. "East Spoke", "Lucknow") to a billing unit here - one row per spoke, not free text. Digicare billing ID is optional and purely for your own reference; it's never compared against anything.

Create a user

Super admins can create admins or users. Admins can only create users.

Existing users

Platform settings

Operational configuration - takes effect within ~30 seconds, no redeploy needed. Signing secrets (JWT keys) aren't here on purpose; see the README if you're curious why.

Everything uploaded from Digicare, grouped by slot status, with the same filters applied to all tabs. No patient details are stored or shown. "Consumed" fills in once Digicare reports completed visits (a Completed status or a check-out time).

Summary by spoke

Complete request/response log - manual (console) or API, successful or not. Passwords are redacted; everything else is shown as sent and received. Separate from the per-unit "Recent assignment events" panel, which only covers rostering decisions.