The healthcare technology buyer is rarely the user. The buyer is a CIO, a CFO, a medical director, a program director. The user is the person who runs the daily work: a program coordinator, case manager, navigator, intake specialist. Healthcare software is bought for a roomful of stakeholders. It is used by a person sitting at a desk with twelve tabs open and a phone that rings every nine minutes.
This split is not unusual. Most enterprise software is bought above the user and used below the buyer. What is unusual in regulated, multi-stakeholder healthcare is how much of the operating burden of the program lands on the user, and how little of the available software was designed with that user in mind.
The phrase “operator-first” is starting to surface in healthcare technology positioning. It is worth defining precisely, because the imprecise version is just a stylistic move (cleaner UI, fewer clicks) and the precise version is a structural claim about what software should and should not absorb.
The way to define it is to look at what the day actually contains.
Three kinds of work in a coordinator’s day
A program coordinator running a recovery monitoring program does work that falls into three structurally different categories. The categories are not a job description. They are a way of seeing the work that determines what software can and cannot do for it.
Pure-clerical work. Data entry into systems of record. Audit log entries. Document distribution. Schedule reconciliation that is mostly cross-referencing one calendar against another. Status updates that exist only to keep two records in sync. This work has a defining property: a competent system of record could absorb almost all of it. The coordinator does it because the systems do not, or because the systems do not talk to each other.
Coordination-overhead work. Producing the monthly compliance letter. Aggregating the month’s compliance events for review. Reconciling testing results across two or three lab vendors. Distributing the right summary to the right stakeholder under the right consent. Escalating exceptions to a supervisor with the right context attached. This work has a different property: it requires judgment about what to include, who to send it to, and on what basis, but the surrounding mechanics are largely structural. A platform built to model the structure can shrink this work dramatically without removing the judgment that has to stay with the coordinator.
Judgment-and-relationship work. The intake assessment with a new participant. The plan-modification conversation when a participant is struggling. The accountability-contact outreach that has to read the moment correctly. The escalation that requires a clinical lead. The conversation with a sponsor about whether a step backward is a relapse or a recalibration. This work has a third property: it cannot be automated, should not be shrunken, and is the part of the program that determines whether it actually helps the participants in care. Platforms that try to compress this work make the program worse, not better.
The three categories are not equally weighted in time. They are not equally weighted in value. Most importantly, they have completely different relationships with software.
The operator-first question is whether software relieves the categories that should be relieved, supports the categories that should be supported, and stays out of the way of the categories that should be protected.
The shape of pure-clerical work
Pure-clerical work is the easiest category to talk about and the one most healthcare software actually targets, with mixed results.
The shape of it, in a recovery monitoring program: a test result arrives from a lab. The result has to be logged in the participant record. An entry has to be made in the audit log. A status flag may need to be updated. A notification may need to be queued. If the result requires action, that action has to be staged for the coordinator’s review. None of this requires judgment. All of it requires care, because the records produced now are the records the program will be defending years later.
When this work runs on spreadsheets and email, three problems appear.
The first is double entry. The result lives in the lab portal, the participant tracker, the testing schedule, and the monthly summary. Each is a separate place. Each has to be updated. The same data point gets typed in four times. Drift between the four entries is unavoidable.
The second is invisible work. The audit log is supposed to be a contemporaneous record of what happened. In practice, on spreadsheets, it gets reconciled at the end of the day or the end of the week. Some entries get missed. The record of when something happened drifts away from when it actually happened.
The third is reconciliation overhead. End-of-day reconciliation, end-of-week tidying, end-of-month rebuilds. The work of keeping the records consistent grows non-linearly with caseload. At fifty active participants it is manageable. At two hundred it dominates the week.
A platform built for this category should make the answer to all three problems structural. The result is logged once, in one place, and surfaces wherever it is needed. The audit log is generated as a byproduct of the work, not as a separate task. Reconciliation is a query, not a project.
When this category is done correctly, the coordinator does not think about it. That is the test.
The shape of coordination-overhead work
This is the category where the operator-first design discipline matters most, because this category is the largest chunk of the day in most programs and the chunk that healthcare software most often handles badly.
The flagship example in recovery monitoring is the monthly compliance letter. A coordinator at a physician health monitoring program produces, every month, a summary of each participant’s compliance posture for distribution to the relevant stakeholders. The summary is brief by design. The stakeholders are different per participant: a referring medical board, a designated primary care physician, an employer in some cases, the participant’s own copy. The consent posture for each disclosure is different. The data categories that can be included are different.
The work of producing the letter touches every category above. It requires gathering the structured data (clerical). It requires deciding what to include and what to exclude (judgment, but bounded). It requires applying the right consent posture for each disclosure (judgment, but rule-driven). It requires distributing to the right recipients in the right form (clerical, but consent-gated).
A platform that models the structure absorbs the gathering, the disclosure boundaries, the recipient routing, and the audit-trail evidence. What is left for the coordinator is the part that should be left: the review, the call on whether the letter accurately reflects the month, and the small human decisions that make the difference between a letter that lands well and one that does not.
A platform that does not model the structure leaves all of this work to the coordinator, who does it in a word processor against a spreadsheet, with the consent posture held in their head and the recipient list held in another tab. The work gets done. The defensibility of how it gets done does not.
The same shape recurs across the day. Reconciling test results across vendors. Producing a status update for a sponsor under one consent and a status update for a board liaison under a different one. Escalating an exception to a clinical lead with the relevant prior contacts attached. In every case, there is structural mechanics around a small core of judgment. Operator-first software absorbs the mechanics and surfaces the judgment.
The hard part is doing this without flattening the judgment into the mechanics. Software that tries to “automate the compliance letter” by removing the coordinator’s review is worse than software that does not try at all. The point is not to remove the coordinator. The point is to give the coordinator back the time the mechanics were taking from the judgment.
The shape of judgment-and-relationship work
The third category is the easiest to describe in principle and the hardest to design for in practice.
A coordinator’s day includes work that depends entirely on reading a moment correctly. An intake assessment is a clinical interview, conducted under a structured framework but executed through human attention. A plan-modification conversation is a negotiation between what the program requires and what the participant can sustain. An accountability-contact outreach can land as supportive or land as surveillance, depending on how it is framed and who is on the other end of the phone. An escalation to a clinical lead can change the trajectory of a case.
This work cannot be absorbed by software. It also should not be hurried by software. A platform that compresses the time available for this work, by way of dashboards that demand attention or queues that imply urgency, is making the program worse.
The operator-first design move here is the inverse of the move in the other categories. Software absorbs the clerical. Software shrinks the coordination-overhead. Software protects the judgment-and-relationship work by getting out of the way.
The protection has practical implications. The platform’s notifications should not generate noise that distracts from a participant conversation. The platform’s queues should not imply that the next-clicked item is the most important call to make; the coordinator’s read on the day is. The platform’s record of a clinical interaction should be a place to capture what happened in the coordinator’s words, not a structured form that compresses the moment into checkboxes.
The platform’s role in this category is the role of a competent assistant. Surface what is relevant when it is asked for. Stay quiet otherwise. Capture the record of what was decided in a form the coordinator chooses, not in a form the system imposes. Trust the user.
This is the part of operator-first design that is hardest to do well, because the natural pull of software is toward more visibility, more structure, more workflow. Operator-first software resists that pull where it would intrude on the work that has to stay human.
What “operator-first” means as a design discipline
The phrase has been used loosely enough that it is worth saying what it actually requires.
Operator-first is not a UI claim. Cleaner screens and fewer clicks are downstream effects, not the discipline itself.
Operator-first is not a productivity claim. Time saved is one outcome, but a system that saves time by compressing the wrong category of work makes the program worse.
Operator-first is the design discipline that takes the three categories seriously and treats them differently.
It absorbs the pure-clerical category into structure, because that work should not be a person’s job in the first place.
It shrinks the coordination-overhead category by modeling the structure of the work, because most of that work is structural and a platform that knows the structure can do most of it.
It protects the judgment-and-relationship category by getting out of the way, because that work is what the program actually is, and software that intrudes on it makes the program less than it was.
The test of whether a platform is operator-first is not whether the screens look clean. The test is whether the coordinator who used the platform for a year would say that the part of the work that mattered most was easier to do well, and the part that should not have been their job in the first place was no longer their job.
Where Reweave Health stands on this
Reweave Care, the first platform under the Reweave Health umbrella, is built around this three-category lens. The clerical category is absorbed into the structure of the platform. The coordination-overhead category is modeled as structured workflow that the platform handles end-to-end with the coordinator’s review at the right moment. The judgment-and-relationship category is protected: the platform is quiet when the coordinator needs to be present elsewhere, and the records of clinical interactions are kept in the coordinator’s words, not the platform’s forms.
The design discipline is the work. The day-to-day operator is the user we serve. The buyer signs the contract. The user lives with the consequences.
If the question your program is trying to answer is what operator-first software should look like for the work your coordinators actually do, we should talk.