Fixture first
Every owner can build and test against committed data before an adjacent feature exists.
Non-emergency medical transport
One request. One suitable ambulance. One documented handoff.
MediDispatch connects institutional concierges, ambulance-company dispatchers, and drivers in one fixture-backed system for immediate and scheduled non-emergency patient transportation.
Final outcome
The complete demonstration
Every developer demonstrates one identifiable contribution inside this shared journey.
1 · RequestA concierge selects or creates a patient and submits an immediate or scheduled ride.
2 · MatchEligible ambulances are filtered, ranked by ambulance distance, and offered progressively.
3 · AgreeA dispatcher accepts the estimate or sends a reserved counteroffer.
4 · TransportThe active driver advances one valid stage at a time with automatic timestamps.
5 · DocumentSigned transport evidence becomes an immutable, downloadable PDF.
Ownership
Four teams of four
Short role names make ownership memorable. Detailed boundaries keep each developer independent and integration safe.
Delivery model
Independence without fragmentation
Contract first
Weeks 1–2 freeze minimum shared shapes; teams never read another domain’s tables directly.
One owned result
Each developer owns code, fixtures, tests, documentation, and a final acceptance demonstration.
Core before bonus
Maps, surcharges, passenger tracking, and system administration cannot delay required work.
Product boundary
Deliberately narrow
Required cycle
- Institution-private patients and inline walk-in creation.
- Immediate and scheduled single-direction ride requests.
- Strict vehicle capabilities and distance-ranked progressive matching.
- Company estimates, defaults, counteroffers, and agreed-price history.
- Fleet availability, schedule conflicts, and ambulance-specific driver shifts.
- Driver progression, transport record, drawn signatures, and PDF versions.
- Hebrew RTL product interfaces with deterministic fixture operation.
Explicitly excluded
- Emergency dispatch, triage, diagnosis, and treatment advice.
- Consumer ordering, payments, invoices, and insurance claims.
- Live maps/GPS, SMS, email, push, and native applications.
- Round trips as one order, multiple stops, and route optimization.
- Maintenance, inventory, payroll, sales CRM, and advanced administration.
- Claims that the project form is an official Ministry document.
Safety boundary: MediDispatch is for non-emergency transportation. The product displays emergency-service guidance but performs no medical triage.
Architecture
Three experiences, one deterministic core
Concierge portal
Patients, booking, request decisions, tracking, history, and documents.
Dispatcher portal
Offers, fleet, schedules, active rides, cancellations, and amendments.
Driver portal
Shift, current/next ride, sequential progress, record, signatures, and completion.
Node + PostgreSQL
TypeScript contracts, organization-scoped services, migrations, fixtures, and document storage.
Minimum shared contracts
RideRequest {
institutionId, patientSnapshot,
timing: immediate | scheduled,
pickup, destination,
requiredCapabilities[],
requestedAt, scheduledFor?
}
RouteEstimate {
provider, distanceKm, durationMinutes,
calculatedAt, fixtureVersion
}AmbulanceOffer {
rideId, ambulanceId, companyId,
rank, offeredAt, stillEligible,
estimatedPrice, outcome
}
RideEvent {
rideId, from, to, actor,
occurredAt, reason?
}Counteroffer {
offerId, originalEstimate,
proposedAmount, reason?,
expiresAt, status
}
ActiveAmbulanceShift {
ambulanceId, deviceId, driverId,
startedAt, endedAt?
}TransportDocument {
rideId, patientSnapshot,
driver, attendant?, sections,
exceptions[], signatures[],
version, generatedAt, amendedFrom?
}16-week cadence
Understand, build, connect, prove
The same rhythm applies to every assignment while each weekly goal remains feature-specific.
| Weeks | Theme | Expected evidence |
|---|---|---|
| W1–2 | Understand & contract | Flow, boundaries, producer/consumer contract, success and failure fixtures, unresolved decisions. |
| W3–4 | Prepare & first slice | Deterministic fixtures and the smallest visible or callable end-to-end feature. |
| W5–6 | Build | Main behavior, persistence, validation, and expected user path. |
| W7–8 | Failure states & tests | Invalid, unavailable, empty, error, deterministic, RTL, and accessibility coverage. |
| W9–10 | Connect | Minimum typed integrations and producer-consumer contract tests. |
| W11–12 | Complete & safe | Integrated journey, authorization, privacy, accessibility, and sensitive-data checks. |
| W13–14 | Stabilize & polish | Larger fixtures, concurrency where relevant, responsive presentation, and measured behavior. |
| W15–16 | Handoff & demonstrate | Runbook, known limits, owned code/tests/fixtures, and individual live acceptance demonstration. |
All owners
Sixteen clear roles
| ID | Assignment | Owned output |
|---|