Healthcare Staff Scheduling Software

This is source code, not a hosted service. There is no signup, free trial, or support line. You install it on a server you control, connect it to your Postgres database, and complete the domain-specific features yourself. If you need a working schedule quickly and cannot staff the build and operations work, use a hosted product.

Teams may choose this route for healthcare staff scheduling software when they need to keep patient and staff data within infrastructure they control, or when their scheduling rules do not fit available products. Those conditions can justify the additional build and operations work.

What makes clinical rostering different

Generic shift software may assume interchangeable staff and fixed operating hours. Many healthcare schedules require a different model:

Those operational workflows matter more than the appearance of the initial schedule.

What is in the box, and what is not

The table separates running template code from the work you still need to do. Review the right column first.

The right-hand column represents a meaningful amount of work. Recurrence, competencies, coverage, and approvals all depend on your domain rules. A generic product may model them differently, so document those requirements before choosing whether to build or buy.

What you are not building is the calendar rendering, the drag-and-drop interaction, the multi-tenant scoping, the authentication, or the admin app. Those are substantial parts of the application, but they are not specific to healthcare.

Timezone support is partial. startAt and endAt are timestamptz, so the instants are stored unambiguously and the daylight-saving arithmetic will not silently corrupt anything. What does not exist is a timezone per user or per site, and rendering happens in the browser's zone. For a single-site rota that is typically sufficient. If one instance serves sites in different zones, you need to finish the display and preference layer.

Compliance responsibilities

Self-hosting does not make you compliant. It changes who is responsible, and it is worth being precise about the direction it moves things, because both a security team and a hospital administrator can read the same fact and reach opposite conclusions.

Who should take this route

Two questions help determine whether this route fits.

Is there a named person or team responsible for operating the server after the build? That responsibility includes updates, incident response, backups, and restores. If not, a hosted product is likely the safer choice even if it needs some workflow compromises.

And is at least one of your four remaining rows specific to your organization? If your competency rules and coverage floors match common clinic requirements, an existing product may already support them. Look at QGenda, Smartlinx, or ShiftWizard at the specialised end, and at Deputy or When I Work if your requirements are closer to general shift scheduling. A maintained hosted product is preferable to an unfinished internal tool. Building is easier to justify when your rules are unusual enough that available products require significant compromises.

If both answers are yes, then the thing to compare is not this template against a product. It is this template against an empty repository. Starting from a working calendar with tenancy already implemented removes part of the initial application work.

The calendar and pack list follow. Review them with the team that would own the server and the remaining domain work.