The Event-Driven Front Office: Subscribing Instead of Polling

Most multi-site groups run an event-driven front office in name only. Something changes at one location, and the systems that care about that change find out when a report runs, a sweep completes, or a person at another site happens to look. The gap between the change and the response is where the rework lives.

At a single practice the gap is survivable, because the person who made the change is usually within earshot of the person affected by it. An MSO does not have earshot. It has forty locations, shared central teams, and a set of processes that each assume they are looking at current data.

So the group compensates by checking more often. Nightly refreshes become hourly. Reports get scheduled twice a day. Central teams build a habit of re-verifying anything important before acting on it, which is a rational response to data they cannot trust and an expensive one to run at scale.

Polling makes you pay for the whole panel to learn about a few records

The cost of a sweep is set by the size of the group, and the value of a sweep is set by how much actually changed. Those two numbers move in opposite directions as an MSO grows.

A nightly recheck of every upcoming appointment across forty sites is a large amount of work to discover that a few hundred things moved. Worse, it establishes the response time. Nothing can be acted on faster than the sweep that finds it, so a cancellation at 9am and a cancellation at 4pm get the same treatment, which is to say they both get treated tomorrow.

athenaOne supports the other pattern directly. A practice can subscribe to change events and then read what changed, through surfaces like GET /appointments/changed for appointment slots, GET /documents/patientcase/changed for patient cases, and GET /patients/changed for patient records. The unit of work stops being the panel and becomes the change.

That shift is what makes response time an operational choice rather than a consequence of batch size. It also makes the front office cheaper to run at forty sites than at four, which is the opposite of how most multi-site automation behaves.

The events an MSO actually cares about are boring and high-volume

The temptation with change feeds is to subscribe to everything, which recreates the sweep with extra steps.

The useful subscriptions map to work somebody is already doing by hand. An appointment moved or cancelled means a slot to backfill and possibly an authorization that no longer matches the date. A patient case opened means intake work sitting in a queue with a clock on it. A patient record changed means demographics or coverage that downstream processes were about to rely on.

Each of those is a trigger for a specific task, and each has a natural owner. That is the design question worth spending time on: not which events exist, but which events start work, and who is on the other end of that work when it starts.

The events nobody should subscribe to are the ones with no attached action. A change feed with no consumer is a report, and an MSO already has enough reports.

The complication: the configuration changes too, and it changes without notice

This is the failure that makes multi-site automation look unreliable, and it has nothing to do with the automation.

One practice retired its entire cosmetic and procedure appointment-type catalog overnight and folded it into a single fifteen-minute follow-up type. That type cannot hold a forty-five-minute service. Every rule built on the old catalog kept running, and kept producing bookings that were wrong in a way nothing flagged, because from the system’s point of view a valid appointment type was being used.

In an MSO this happens constantly and locally. A site adds a provider, retires a template, renames a department, or changes which types a generic slot may hold. None of those feel like changes to a central team, because the person making them is solving a local problem on a Tuesday.

The defense is to treat configuration as a subscribed feed rather than as documentation. Read the appointment-type catalog and the department and provider structure on a schedule, compare it to what the automation currently believes, and raise a difference as an exception the moment it appears rather than the first time a patient is booked wrong.

The handoff is the difference itself. An automation should not guess what a retired appointment type became. It should stop using the rule that depended on it, state plainly which sites and which workflows are affected, and put the mapping question in front of the operations lead who can answer it. A system that silently substitutes its best guess is how a configuration change at one site becomes a month of quiet misbookings across the group.

Central teams get a queue instead of a report

The organizational payoff of working from events is that centralized functions stop being scheduled and start being continuous.

A central scheduling or authorization team working from a twice-daily report spends its first hour deciding what is still true. Working from a change queue, the same team gets items in the order they happened, already carrying the site, the department, and what changed. The judgment they were hired for gets applied to the item rather than to the freshness of the list.

This is also where the staffing conversation lands honestly. A June 2, 2026, MGMA Stat poll of 260 applicable responses found that 68% of practice leaders say their organization has not redesigned a role or adjusted staffing with the help of AI in the past year, while 26% say they have. The groups in that 26% mostly describe small, practical moves concentrated in the front office, revenue cycle, and call center rather than eliminated roles.

That matches what event-driven work actually does to a central team. It does not remove the team. It removes the part of their day spent reconstructing state, and it lets a group cover more sites without the coverage model scaling with headcount.

Governance is what makes this work across forty sites

Multi-site groups already know that decentralized configuration is the thing that breaks enterprise processes. Event-driven work makes that consequence visible faster, which is uncomfortable and useful.

MGMA reporting on new-patient access notes that multispecialty groups frequently operate with siloed scheduling templates and decentralized governance, which limits cross-departmental coordination, and recommends standardized scheduling templates and shared visit taxonomies across specialties. That is the same prerequisite an event-driven front office runs into on day one: a change event is only actionable if the thing that changed means the same thing at every site.

So the sequencing matters. Standardize the taxonomy first for the workflows you intend to automate, subscribe second. A group that subscribes to change events across forty sites with forty different appointment-type vocabularies has built a very fast way to distribute inconsistency.

The practical middle path is to automate narrow and deep before wide. One workflow, every site, one shared vocabulary for that workflow. Then the next one. Groups that try to go wide first end up maintaining forty exception lists, which is the manual process they were trying to leave.

Key Takeaways

Size the work by what changed, not by the panel. A nightly sweep across forty sites costs the same whether ten things moved or ten thousand.
Accept that a sweep sets your response time. Nothing gets acted on faster than the batch that finds it, so a morning cancellation and an afternoon one get identical treatment.
Subscribe only to events that start a specific task with a named owner. A change feed nobody consumes is another report.
Watch configuration as a feed, not as documentation. Appointment-type catalogs, templates, and department structures change locally and without notice.
Make the automation stop and escalate when configuration moves underneath it. Silently substituting a best guess turns one local change into months of quiet misbookings.
Give central teams a change queue instead of a twice-daily report so their first hour is not spent working out what is still true.
Standardize the taxonomy for a workflow before you subscribe across sites. Event-driven work distributes inconsistency just as fast as it distributes work.
Automate one workflow across every site before adding the second. Going wide first produces forty exception lists, which is the manual process you were leaving.

An MSO front office running on scheduled sweeps is paying twice: once for the sweep, and again for the hours central teams spend re-verifying data they know is stale. Subscribing to change is the cheaper design, but it only holds if the group treats its own configuration as something that moves and builds the automation to notice when it does. An AI team working inside athenaOne can consume those change events across every department, start the work the moment something moves, and escalate the cases where the configuration no longer matches the rule rather than guessing at what it became.

Sources