"We operate a little differently here."
In cancer care, operational variability from one institution to the next is real. From one country to another, between public and private, between an academic center and a community clinic, between centers running at capacity and centers with room to spare, depending on the software ecosystem in place, the constraints, the operational rules, and the working habits all differ.
These differences extend into the daily gestures. In radiation therapy, some departments book planning and treatment appointments in a single block, others sequence them one after another. In systemic therapy, some centers prepare medication in advance, others on the day of treatment. Prioritization varies just as much, in one place by a clinical priority specific to each protocol, in another by the date the physician requested. On top of these variations, every institution carries its own workarounds, accumulated over years to cope with the limits of the tools in place.
Beneath the diversity, a shared equation
Beneath these differences, the problem to solve is the same everywhere: matching rising demand to finite capacity, whether that capacity is counted in machines, available staff, chairs, or hours, and doing so across the entire patient trajectory. It is this equation that governs a center's day.
This is precisely where the systems in place reach their limit. Electronic health records were built for clinical documentation, billing, and record-and-verify workflows; oncology information systems, to operate radiation therapy treatment machines and manage RT-specific clinical data. Both have expanded over the years to absorb scheduling functions, and in many centers they have become the reference for appointment data. But neither was built with an optimization engine. At their best, they offer next-available-slot lookups and template-driven appointment placement. They do not compute optimal allocations across constraints, predict cancellations, or recompute downstream appointments under disruption. They record what schedulers decide. They do not help schedulers decide.
GrayOS runs in centers of very different profiles
GrayOS is deployed today across institutions with very different profiles. Canadian academic centers continually pushing the limits of their treatment capacity, such as The Ottawa Hospital, the Centre hospitalier de l'Université de Montréal, and the Princess Margaret Cancer Centre. A US community cancer center standardizing its operations to support growth, the Mary Bird Perkins Cancer Center. A community center such as the CISSS de Laval. A private US center optimizing the management of its clinics, Marin Cancer Care. And Gustave Roussy, the leading cancer center in Europe, which follows more than 50,000 patients a year.
These institutions are public or private, multi-site or smaller, and run on distinct systems: MOSAIQ, ARIA, Epic, Cerner, and others. One diversity of profiles, one capacity-demand equation to manage, one and the same version of GrayOS deployed.
How: a solution built to absorb variability
GrayOS is an optimization engine grounded in operations research. Where the EHR is the system of clinical record and the OIS the system of treatment delivery in radiation therapy, GrayOS is the system of operations: the layer that sits between those systems of record and the daily reality of care delivery, machines, chairs, staff, pharmacy, schedules. Its function is to continuously reconcile patient demand and available capacity, under constraint, in real time, across the full set of departments in a trajectory. It does not replace the systems in place; it takes on what they were never designed to do.
What makes GrayOS applicable to centers this different is that each one has its own configuration environment, where its specific rules are described. That environment covers four families of rules:
Protocol rules: for each treatment, the sequence of appointments, their duration, their spacing, and the dependencies between them.
Capacity rules: what the center has available, machines, nurses, chairs, opening hours, maintenance windows, physician availability, breaks, mirror machines.
Operational rules: how the center handles strain, lead times, overbooking, which patients can be deferred or moved, workload distribution.
Patient rules: clinical priority, mobility constraints, time-of-day preferences.
Customizable labels, or "tags," make it possible to treat certain appointments differently from others, following a logic specific to the center. Some institutions use them, for example, to schedule only in the afternoon the systemic therapy appointments that require a drug delivery.
Once these rules are encoded, the engine generates the schedule and re-optimizes it continuously. It distributes new treatment starts across machines and days, assigns patients to nurses and chairs while respecting breaks and acuity, clusters certain treatments to limit drug waste, and reacts to the unexpected, cancellations, absences, a machine breakdown, without destabilizing the rest of the day. Variability from one center to the next is not an obstacle for this engine. It is its parameters.
Telling justified specificity from inherited habit
Encoding a center's rules is as much operational work as technical work, and it is almost always an occasion to re-examine its processes. The deployment of GrayOS relies on a dedicated framework for making these rules explicit, a necessary step before they can be encoded. The exercise tends to surface a useful distinction, between rules that answer a clinical necessity and rules that settled in over time without ever being re-examined.
Rather than replicating what already exists, GrayOS brings the experience accumulated across many centers: what works, under what conditions, and for what kind of institution. The institution then decides with full understanding. This is the difference between installing software and putting lasting orchestration in place. The engine does not create capacity that does not exist; it makes visible the trade-offs a center absorbs today without deciding them, through overbooking, overtime, or individual improvisation, so that the institution settles them itself.
Who is solving your center's equation today?
A center is always singular. But that singularity most often rests on the memory of two or three people who know how the schedule must come together. The question is concrete: does that logic live in an infrastructure able to carry it, or only in the memory of a few people?
