Skip to content

Product engineering

Talk to us Discuss a Project
Talk to us Discuss a Project

Case study · Workforce scheduling

DocSwap

A shift platform for hospital residency teams, where preferences feed an allocation algorithm and a swap takes a tap rather than a chain of phone calls.

In hospital testing

Engagement
Full product design and engineering
Platforms
Hybrid mobile app and web dashboard
Role
Design, engineering and algorithm development
Market
Australia Verify before publishing
The DocSwap platform: practitioner shift preferences feeding the allocation engine, the admin term roster with its relief pool, and the mobile apps where a practitioner requests and accepts a shift swap.
Industry
Hospital operations
Users
Residents, practitioners, medical admins
Platforms
Mobile + web
Role
Full product build
Capabilities
Rosters, swaps, allocation
Status
In testing

01The business situation

A roster is a negotiation, not a spreadsheet.

DocSwap comes from Citadel Meditech Pty. Ltd. of Australia. Every term, a hospital has to place its residents and practitioners across shifts that must be covered whatever happens. People have preferences, lives and constraints. Historically the balancing was done by hand, and every subsequent change rippled outwards through phone calls. The platform had to hold both halves: build a defensible roster in the first place, and let it flex afterwards without unravelling.

Core challenge

Turn preference-gathering, allocation and shift swapping into one system, without taking the final decision away from the medical admin.

Before

Preferences, rosters and swaps handled by hand

  • Paper Preferences
  • Manual Rostering
  • Phone-call Swaps
  • Ad-hoc Cover

After

One roster everyone works from and can move within

  • Resident
  • Practitioner
  • Medical Admin
  • Relief Pool

DocSwap Platform

02The system at a glance

One roster. Four connected roles.

  • Admin Dashboard Terms, rosters and the relief pool
  • Practitioner App Shifts, preferences and swaps
  • Allocation Engine Preference-weighted scheduling
  • Relief Pool Cover when no swap is available
Core PlatformPreference-driven, admin-controlled scheduling
  • Term Timelines
  • Preference Capture
  • Auto Allocation
  • Shift Swaps
  • Relief Pool
  • Roster Publishing

03Workflow 01

Preferences first, roster second.

Before a term is scheduled, practitioners record what they would prefer. The admin opens and closes that window on a timeline, so allocation runs against a complete picture rather than whoever replied first.

Image placeholder Preference capture: a practitioner setting shift preferences for an upcoming term, beside the admin timeline showing the preference window open and the roster not yet published. assets/portfolio/docswap/workflow-preferences.png · 16 / 11
  • A window, not a raceThe admin controls when preferences open and close, so allocation runs on the full set.
  • Preferences per termResidency runs in terms, and the platform gathers preferences for each one rather than assuming a fixed pattern.
  • Visible before it is fixedPractitioners can see what they asked for before the roster is generated against it.

04Workflow 02

A swap should take a tap.

Once the roster is published, life happens. A practitioner requests a swap, the platform finds a counterparty, and if there is none it falls back to the relief pool rather than to a phone tree.

  1. 1My shifts

    Image placeholder Practitioner app showing the assigned shifts for the current term, with dates, times and locations. assets/portfolio/docswap/step-shifts.png · 1 / 2.04

  2. 2Request a swap

    Image placeholder Swap request screen: the shift being given up and the matching practitioners available to take it. assets/portfolio/docswap/step-swap.png · 1 / 2.04

  3. 3Relief pool cover

    Image placeholder Relief pool fallback: the shift offered to the pool when no direct swap partner is available, with its confirmation state. assets/portfolio/docswap/step-relief.png · 1 / 2.04

05Workflow 03

The algorithm proposes. The admin decides.

Allocation weighs every practitioner’s stated preference against the shifts that must be covered, and produces a roster. It is a starting point, not a verdict: the medical admin can override any placement.

  • Preference-weighted allocationThe algorithm places people against their stated choices, or as close to them as coverage allows.
  • Coverage is the hard constraintShifts that must be filled are filled, with preference satisfied within that limit rather than above it.
  • Override always availableThe admin can change any allocation after generation, so clinical judgement is never overruled by the model.
Image placeholder Medical admin roster board: the generated term schedule as a grid of practitioners against shifts, with the relief pool, unfilled slots and manual override controls. assets/portfolio/docswap/roster-board.png · 16 / 10
Image placeholder Compact admin view: pending swap requests and relief-pool offers awaiting approval. assets/portfolio/docswap/admin-mobile.png · 1 / 2.04

06Engineering behind the product

The system behind a fair roster.

The hard part was never the interface. It was producing an allocation people would accept, and keeping it correct as it changed.

  • Custom allocation algorithm

    Practitioner preferences are weighed against coverage requirements to produce a term roster that is as close to everyone’s choices as the constraints allow.

  • Admin override model

    Allocation is treated as a proposal the medical admin can amend, so the algorithm assists the decision rather than replacing it.

  • Swap matching

    A swap request is matched against practitioners eligible to take the shift rather than broadcast to everyone.

  • Relief pool fallback

    When no direct counterparty exists, the shift moves to a pool rather than leaving the gap unresolved.

  • Hybrid mobile application

    Built in React Native so residents and practitioners get a native experience on both platforms from one codebase.

  • Term timeline management

    Preference windows, generation and publication are stages on an explicit timeline the admin controls.

  • Push notification delivery

    Shift changes and swap outcomes reach practitioners through OneSignal, with email over Mailgun.

07Technical architecture

Under the hood

A hybrid mobile app over a Laravel backend, with a custom allocation algorithm at its centre.

Mobile

  • React Native

Backend

  • Laravel
  • PHP

Frontend

  • Tailwind CSS

Data

  • MySQL

Cloud & services

  • AWS
  • OneSignal (push)
  • Mailgun (email)

Delivery tooling

  • Asana

08Delivery journey

How the platform was delivered.

  1. Research review

    Build on the client’s own surveys

  2. Product definition

    Scope the full product, not an MVP

  3. UX

    Design and approve both surfaces

  4. Algorithm

    Build and tune the allocation model

  5. Engineering

    Build the app and the dashboard

  6. Internal release

    Roll out to hospital teams

  7. Support

    Refine against real term cycles

The company reports release to internal hospital teams, with testing continuing across the hospital chain. Dates, durations and rollout scope are withheld until confirmed. Verify before publishing

09What the system enabled

What the delivered platform enabled

  • Preferences gathered before every term is scheduled
  • Rosters generated against stated preferences and coverage
  • Shifts swapped directly between practitioners
  • A relief pool for shifts with no available counterparty
  • Full admin override of any allocation
  • Rosters and term dates available on mobile

Related systems

NEMS

Healthcare · FHIR Scheduling · Web

A FHIR-compliant patient scheduling platform for one of the largest non-profit community healthcare providers in the United States.

View case study , NEMS

Clunker Busters

Vehicle Inspection · Marketplace · Web + Mobile

A connected platform for customers, inspectors, operations, reporting and payments.

Rostering, dispatch, allocation: the same problem wearing different clothes.

We build the model around how your people actually work, and leave the final call with them.

Discuss your system