What it takes to deploy GrayOS: an honest account of the work
Any operations leader who has lived through a heavy clinical software rollout asks the same question before the next one: what will this cost my team, in hours and attention, before it returns anything. It is the right question. A Care Orchestration Platform continuously balances patient demand against finite capacity across departments, and a layer that does that is not something you switch on out of the box. It has to be fitted to how a specific center actually runs. The honest answer is not that the effort is trivial. It is that the effort is real and it is shared. The center invests in encoding how it runs, Gray does the work of fitting the platform around that, and the part the center invests is spent once and returns automation for years.
There is a way to see this that makes the cost feel smaller, and it happens to be the accurate one. You are already doing the work. You are already digitizing your operations and documenting your processes so your staff can book patients correctly. Deployment is not a separate project stacked on top of that work. It is the step that makes the work you are already doing return more than it does today.
1. There is real setup work, and it is exactly the work that creates the value
GrayOS ships with a large toolbox for modeling how complex care operations run, and deployment is the work of combining those tools to fit one center's reality: its operating rules, its hours, its modality mix, and the exceptions that today live in the heads of a few experienced staff. Encoding those rules is the setup work, and it is the same act that produces the return. Once the rules are in the system, the schedule no longer depends on the two or three people who hold them, disruptions are absorbed against the same constraints instead of triggering hours of manual rework, and leaders can see how capacity is actually being used.
That work is the cost of genuine flexibility. The philosophy behind GrayOS is that software should serve how a care team works rather than impose its own constraints on it, so the platform is built to bend to how a center operates, with virtually no limit to how far it configures to specific rules and constraints. A rigid tool is quick to switch on precisely because it cannot adapt, and it forces the center to adapt to it instead. GrayOS makes the opposite trade, with minimal disruption to clinical workflows, and the configuration effort is the visible side of that choice.
2. GrayOS does not replace your EHR or OIS, it makes the digitization you already invested in work harder for you
GrayOS sits above the systems a center already runs and reads from them, which is why it augments the EHR and the OIS rather than replacing them. That design is also what lets a center extract more value from digitization it has already paid for. Where a center makes advanced use of MOSAIQ care plans or ARIA care pathways, GrayOS reads that structure directly to populate its own care plans and scheduling activities, so the more digitized the input, the more automation a center can expect and the less manual setup remains.
A center that is not yet digitized is not at a disadvantage in principle. GrayOS has been used as many centers' starting point in their digitization journey, with great success, precisely because they benefit operationally and immediately from the effort they put into digitizing their rules and objectives. Either way, the starting point is built from what the center already has.
How deep the integration goes will vary from one environment to the next. That variation is rarely about the platform and almost always about how the surrounding systems structure their data and what their interfaces support. GrayOS is architecturally adaptable to that reality, which is a different claim than promising integration is effortless. It is not effortless, and we would rather say that plainly than promise otherwise.
3. Gray arrives already understanding oncology
A large part of what makes a clinical software rollout exhausting is rarely in the contract: it is the time the center spends educating the vendor. Explaining the domain, the constraints, why the workflow is the way it is, why an exception that looks trivial is not. With Gray, most of that cost is removed before it appears.
Gray takes the acquisition and internal dissemination of domain knowledge seriously, as a discipline rather than a byproduct. Working with a Gray person means you are not explaining the difference between per os and intravenous regimens, and you are not explaining why the system must never book a radiation course across linacs from different vendors. We arrive understanding the shape of the problem, which means the conversation starts at your center's specifics instead of at oncology 101. The hours a center would otherwise spend bringing a vendor up to speed are hours it does not spend here.
4. The deployment follows a clear, repeatable arc, at a pace the center sets
A typical deployment runs in three phases over roughly the first six months. It opens with scoping and setup: an on-site visit to understand the department's workflows through stakeholder interviews and shadowing, the technical setup of the environment, and a data security and privacy review. It moves into training and calibration, where super users are trained and the platform is fine-tuned until they are confidently booking the large majority of their appointments in GrayOS. It closes with impact evaluation, and the work does not stop at go-live: Gray and the center align on the metrics that define success, then keep working together on calibration, adoption, and change management so the deployment continues to move the center's own objectives forward.
Throughout, two tracks run in parallel. A clinical track covers rules, workflows, and a rollout sequence that minimizes disruption. A technical track covers setup. The pace is set by what the center is comfortable with, and Gray works alongside the team at each phase rather than handing over a tool and stepping back.
5. The obvious is configured before a user ever touches the system, so your effort goes only where it is needed
The process is built on deployments across very different environments, from large academic centers to small community clinics, highly digitized sites and paper-based ones. It streamlines the collection of everything needed to configure and calibrate the platform, beginning with a set of calibration questionnaires that capture how the center runs.
We do not claim the configuration is mostly done before you arrive. Everything mechanical and obvious is handled in advance, so your effort goes only where your judgment is actually required. A care plan named "Brain Cyberknife 5 FX" should only ever be bookable on the institution's Cyberknife unit. We set that for you. You do not spend a meeting on it.
What stays with the center is the part only the center can own. Filling and finalizing the care plans, because no one but the center can say how it treats its patients. In systemic therapy specifically, it is also building and maintaining the infusion clinic roster templates and the daily rosters. This is worth naming plainly, because in many systemic therapy programs the real daily ceiling on new starts is set by pharmacy capacity, not by the number of chairs. Encoding that ceiling, and the roster rules that follow from it, is exactly the kind of constraint GrayOS is built to hold, so that allocating new starts stops being a manual negotiation every morning and becomes a structured decision the whole team can see.
The remaining refinement is done on a recurring basis with one or two super users as they begin scheduling in the system, supported throughout by white-glove service rather than left to the team alone.
"We're extremely satisfied with the results. When it comes to responsiveness, Gray is in a league of its own compared to other private companies."
Karine Lepage, Associate Director of Nursing Oncology, JGH
6. The infrastructure footprint is small
GrayOS is a web application with a deliberately light footprint. It deploys either in the cloud, where Gray provisions and manages a dedicated, isolated environment, or on-premise, where it runs on a single modest server the institution hosts and a single IT contact can stand up. It connects to a center's existing systems through the standard healthcare interfaces those systems already support, and the data it reads is kept deliberately lightweight. As one point of reassurance, a large academic center has run live for over a year with more than seventy users and no performance issues.
None of this is the part that should weigh on an operations leader deciding whether to start. The right next step is a scoping conversation that sizes all of this to your environment and gives you a center-specific picture of who does what, and how many hours it actually takes.
