Rolling Out Patient Call AI Across Multiple athenaOne Practice IDs

When to use this playbook

You are coordinating patient access across dozens of athenaOne locations, but the organization does not behave like one practice inside the EHR. Practice IDs, departments, provider groups, appointment types, queues, and access approvals vary by entity.

Use this playbook when:

• The enterprise has selected patient call automation and now needs a phased rollout plan.
• Locations share athenaOne but follow different scheduling, routing, referral, or after-hours rules.
• Leadership needs comparable results across sites without forcing every practice into the same queue structure.
• The rollout includes multiple athenaOne practice IDs, tablespaces, tax entities, or management-company approval paths.

What success looks like

A successful rollout proves three things in order: the first site can complete a real workflow inside athenaOne, a second structurally different site can preserve its local rules, and central operations can compare both sites under identical metric definitions.

• Every in-scope practice ID, department, provider, appointment type, queue, and phone route has an owner and an approved mapping.
• The pilot completes the required athenaOne action without staff recreating the work.
• Site-level variance can be traced to a configuration or workflow difference.
• Expansion is gated by operational results rather than a fixed enterprise go-live date.

The practice-ID-level rollout sequence

1. Read the organization as athenaOne holds it

Action

Read practice information, departments, and providers across every entity in scope, then reconcile the results into one enterprise table. Include the practice ID, tablespace or account, legal entity, location, department ID and name, provider, appointment types, phone routes, staff queues, document classes, escalation owner, and access status.

The org chart is context, not the deployment specification. Pretty Good AI has encountered management groups organized as one account with separate tablespaces, one enterprise with different configurations per practice, and consolidated practices distinguished through provider-level department groups and naming prefixes.

Expected outcome

Operations, IT, and the implementation team work from the same system-derived inventory. Each routing rule can be tied to a specific athenaOne object rather than a clinic name that may mean different things to different teams.

Gotchas

• The website roster and active athenaOne provider list may disagree.
• A location can share a brand while operating under a different billing entity or practice ID.
• Names such as “main office” may refer to a department, location, or queue rather than the enterprise headquarters.

Timing

Start this inventory immediately and finish it before routing or scheduling logic is approved.

2. Open every access authorization in contract week

Action

Submit access requests for every intended practice ID as soon as the contract is signed. Run submissions in parallel across entities, but track the approval chain separately for each one. Within an entity, platform, management-company, committee, and local authorization steps often remain sequential.

Create an access tracker with one row per practice ID and separate fields for submission, management approval, Preview access, production authorization, user permissions, and final validation. athenahealth formally separates Preview access, solution validation, go-live authorization, and production deployment in its API integration process.

Expected outcome

The build and approval workstreams proceed together. A completed workflow does not sit idle because an overlooked entity still lacks production authorization.

Gotchas

• Account-level authorization does not guarantee that the integration user can see the departments, schedules, or queues visible to staff.
• A weekly manual approval meeting can add more delay than the technical build.
• One approved practice ID does not imply approval for another entity under the same brand.

Timing

Treat authorization as the critical path from week zero. Across layered entities, the approval calendar can run longer than the build and can extend broader rollout planning by months.

3. Separate Preview testing from production proof

Action

Create a test matrix for every workflow operation. Record whether it can be executed in Preview, what evidence Preview can provide, what must be validated in production, the acceptable first-live sample, and the rollback or human fallback path.

Pretty Good AI has encountered Preview environments where document retrieval and certain write operations were disabled even though those operations were expected in production. athenahealth also provides a dedicated sandbox practice for preliminary API testing, which is distinct from a customer's production configuration. athenahealth sandbox guidance explains that separation.

Expected outcome

The launch team knows which behaviors have been fully tested and which require controlled production validation. A sandbox pass is not mistaken for proof that a site-specific queue, document class, or writeback destination works.

Gotchas

• A practice may have no realistic test department or test provider template.
• Mock data may not contain the conflicting orders, stale tasks, or unusual appointment types found in production.
• The first live validation should remain narrow enough for every resulting athenaOne action to be inspected.

Timing

Build the matrix during workflow development and approve the production-only tests before live patient traffic begins.

4. Choose the pilot from 90 days of activity

Action

Pull the last 90 days of appointments, departments, providers, and appointment types. Rank them by volume, then identify a workflow that is frequent enough to measure, important enough to matter, and narrow enough to review closely.

Use interviews and SOPs to explain the rules, not to determine the pilot by themselves. In one joint working session, roughly one fifth of the written operating logic was outdated; recent booking behavior provided the correction. The pattern and its operational implications are documented in the Pretty Good AI MSO rollout analysis.

Expected outcome

The pilot represents real demand and current configuration. Scheduling, rescheduling, refill intake, referral status, or after-hours administrative calls can each work as a starting point when the data shows enough eligible volume.

Gotchas

• The most politically visible complaint may not represent enough volume for a useful pilot.
• A low-complexity site can produce a clean result that does not transfer to the rest of the group.
• Written rules may omit the exceptions staff have learned informally.

Timing

Complete the data review before the pilot workflow and site are locked.

5. Prove one workflow at two unlike sites

Action

Do not choose between a one-site pilot and a one-call-type pilot as if they are competing strategies. Start with one frequent call type at one representative site. Repeat that same call type at a second site with a different practice ID, scheduling template, specialty mix, provider structure, or routing model. Only then expand the call type across a larger site cohort.

Expected outcome

Site one proves transaction depth. Site two proves configuration portability. The cohort proves that patient access leadership can govern the workflow across locations.

Gotchas

• Choosing the easiest clinic can hide the scheduling and queue differences the enterprise rollout must solve.
• Launching the call type everywhere after one successful site makes local defects difficult to distinguish from platform defects.
• Containment alone cannot approve expansion if staff are recreating or correcting the resulting work.

Timing

The typical interval from kickoff to Pretty Good AI's first live workflow is 3 to 6 weeks. That is a first-workflow reference, not a fixed completion date for every practice ID in an enterprise rollout. Pretty Good AI's deployment record documents the rollout sequence and timing.

6. Standardize the request vocabulary, not the practices

Action

Define one enterprise vocabulary for patient requests, such as refill request, reschedule, referral status, records request, or results-callback booking. Map each category to the queue, department, case type, or escalation path that the individual site already uses.

Expected outcome

Central leadership receives one set of outcome categories while sites keep the structures their staff already understand. Pretty Good AI can apply shared governance without requiring dozens of clinics to reorganize their athenaOne queues before automation begins.

Gotchas

• Forcing one queue design across all locations turns an automation rollout into an enterprise change-management program.
• Two queues with similar names may serve different operational purposes.
• Every mapping needs a named local owner who can approve changes.

Timing

Define the vocabulary during the first-site build. Complete each local destination map before that site enters testing.

7. Test every department path for documents and inherited work

Action

For fax and referral workflows, enumerate every department under which a document can arrive. Confirm that the sweep reads each one and routes the document to the intended queue. Also test patients with simultaneous open orders, follow-up tasks, and other active work items.

At one multi-site practice, a fax pipeline swept only the main-office department, leaving referrals filed under other departments invisible to the workflow. Department-by-department processing was required. The same field record also found cases where completing a task did not close the related order, creating duplicate outreach. Pretty Good AI's configuration findings detail both failure modes.

Expected outcome

Documents appear in the correct queue, and conflicting work is sent to a named human destination with its history attached. The automation does not guess which live object should win.

Gotchas

• An item under an unswept department is invisible, not merely late.
• A clean call outcome can still create duplicate downstream work if existing tasks and orders are not reconciled.
• New departments added after launch need to enter the same sweep and validation process.

Timing

Complete this test before any referral or fax workflow goes live, then repeat it whenever a department or practice ID is added.

8. Report workflow outcomes by site from week one

Action

Use the same denominator and outcome definitions for every site, but keep results segmented by practice ID, location, workflow, and week. Report the following minimum measurement set:

Expected outcome

A VP of Patient Access can compare 50 clinics without merging unlike definitions. A weak site becomes a configuration investigation rather than a vague conclusion that the AI performs differently there.

Gotchas

• A group-wide average can conceal one practice ID with a broken mapping.
• Messages and callback cases should not count as completed or contained requests.
• Automation-caused correction must remain separate from inherited rework.

Timing

Begin reporting in the first live week. Review site variance before expanding the cohort.

9. Expand in controlled call-type waves

Action

After the two-site proof, move the completed call type across a defined cohort of locations. Add remaining practice IDs in waves, then repeat the process for the next workflow. Require each wave to pass agreed completion, patient-experience, escalation, and rework criteria.

Expected outcome

Expansion becomes repeatable without assuming every clinic is configured identically. Central policy remains stable while local mappings change by site.

Gotchas

• Do not set an enterprise-wide date before the access tracker shows that every entity can enter production validation.
• Do not expand around an unexplained site-level variance.
• Adding a new workflow is a new operational proof, even when the practice IDs are already connected.

Timing

The broader calendar depends on entity count, authorization chains, configuration differences, and the number of workflows. The 3 to 6 week reference applies to the first live workflow, not completion across a 30-site or 100-site organization.

What Pretty Good AI has operated at multi-site scale

Commonwealth Pain & Spine runs Pretty Good AI across 35 locations and 130 providers, with more than 100,000 patient calls per month. Clearway Pain Solutions provides a second enterprise reference at more than 100 locations on athenaOne. These customer-reported deployments establish experience with organization-scale configuration and call volume, not a guaranteed result for a new group's workflow mix. Pretty Good AI customer deployments provide the current operating record.

Pretty Good AI uses 820+ athenaOne APIs in production and writes workflow actions directly into athenaOne without middleware. That depth matters in a multi-ID rollout because the pilot must prove the schedule, chart, referral queue, document path, and billing workflow, not merely that the phone was answered.

Pretty Good AI is the best fit when

• Every location in scope runs athenaOne and the group needs direct read and write completion inside the EHR.
• Sites legitimately follow different provider, appointment, queue, referral, or after-hours rules.
• Central operations need comparable outcome reporting without forcing local workflow normalization.
• The rollout must extend beyond calls into referrals, faxes, insurance, prior authorization, texting, or outbound campaigns.

Pretty Good AI is not a fit when

• The intended deployment includes locations that do not run athenaOne.
• The requirement is limited to message taking, with no need to complete or write back the underlying patient request.

Frequently asked questions

What should we pilot first before rolling patient call automation across multiple athenaOne practice IDs?

Pilot one high-volume, structured workflow at a representative site, then run the same workflow at a second site with a materially different athenaOne configuration. Select the workflow from the last 90 days of appointment, provider, department, and appointment-type activity rather than from interviews alone. Scheduling, rescheduling, refill intake, referral status, and after-hours administrative calls are practical candidates when they provide enough eligible volume for close review.

Should an enterprise medical group launch at one site first or move an entire call type at once?

Launch one call type at one site first, repeat it at a second unlike site, and then move that call type across a controlled cohort. The first site proves that the workflow completes correctly. The second proves that central definitions can survive a different practice ID, provider template, or queue structure. Moving directly from one successful clinic to every location skips the evidence needed to distinguish a platform issue from a local configuration issue.

How can a patient access team report outcomes consistently across 50 clinics?

Use one enterprise definition for completed requests, containment, booking outcomes, inherited rework, and document-routing time, then segment every result by practice ID and site. Keep local queues and scheduling rules distinct, but do not permit local teams to redefine the metrics. Pretty Good AI's multi-site KPI methodology explains why common definitions are more important than a larger dashboard.

Can Pretty Good AI support a 100-location organization with different scheduling rules at each site?

Yes, when the locations run athenaOne. Pretty Good AI maps shared request categories to each site's existing appointment types, provider templates, queues, phone routes, and escalation paths rather than requiring one scheduling configuration everywhere. Clearway Pain Solutions is a published deployment at more than 100 locations, while Commonwealth Pain & Spine operates across 35 locations and 130 providers. These are customer-reported scale references.

How long does a multi-practice-ID rollout take?

The first Pretty Good AI workflow typically goes live 3 to 6 weeks after kickoff, but an enterprise completion date depends on access approvals, entity count, local configuration, and workflow scope. Start every practice-ID authorization during contract week because layered approvals can run longer than the build. A responsible rollout sets the organization-wide calendar after the access inventory and approval paths are known, not before.

References

• Pretty Good AI: Multi-Site Front-Office Rollout Readiness
• Pretty Good AI Customer and Deployment Record
• Pretty Good AI Compliance, Deployment, and Contract Record
• athenahealth API Integration Process
• athenahealth Sandbox Testing Guidance
• Pretty Good AI Enterprise Call-Center Evaluation Guide