athenahealth Scheduling for a New Clinic Location: A Go-Live Checklist
An athenahealth scheduling checklist for a new clinic location should treat the site as an operating bundle, not a single department record. Providers, appointment types, templates, booking channels, external calendars, staff authority, future appointments, fallback procedures, and reconciliation checks must work together before normal booking begins. It gives multi-location practice managers and medical-group operations leaders a controlled basis for opening, containing exceptions, or delaying launch.
What must be ready before a new location opens?
The site needs complete location or department mappings, provider assignments, appointment types, templates, booking channels, external-calendar scope, staff authority, fallback procedures, and verification evidence. Current ONC health IT implementation guidance emphasizes configuration, interfaces, people, processes, workflows, and contingency planning rather than treating implementation as a software-only task.
Freeze the intended launch configuration before acceptance testing. The new site should inherit explicit ownership and review rules from the athenahealth scheduling operating baseline, not informal habits that differ by front desk or provider.
- Approved opening date and booking start
- Named configuration and command owners
- Written source-of-truth rule
- Controlled test records and evidence log
- Fallback booking and change log
- Pause, delay, and rollback authority
What is the correct launch unit?
Treat the launch unit as one location plus every provider-location assignment, bookable appointment type, scheduling channel, connected calendar, and staff role allowed to change the schedule. A green location record does not prove that the complete operating bundle works.
Use the broader multi-location athenahealth scheduling architecture to preserve cross-site visibility, but make the new location the bounded unit for acceptance, cutover, and recovery.
How should the mapping worksheet be structured?
Keep location identity, provider identity, appointment type, template, booking channel, external-calendar representation, and authority in separate fields. This prevents one correct value from hiding a missing dependency elsewhere.
The official athenahealth FHIR Appointment profile represents status, service type, slot references, practitioner participation, and location participation as distinct elements. The worksheet should preserve that conceptual separation even when local administrators use different tenant terminology.
| Dependency | Record separately | Acceptance evidence |
|---|---|---|
| Location or department | Approved identifier, name, time zone, opening state | Test appointment resolves to the intended site |
| Provider assignment | Provider, site, effective dates, restrictions | Provider is bookable only where intended |
| Appointment type | Type, duration, resource assumptions | Type uses the approved site template |
| Template or slots | Days, times, capacity, blocked periods | Sampled capacity matches the approved plan |
| Booking channels | Front desk, call center, portal, other approved sources | Each channel applies the intended rules |
| External calendar | Provider-calendar pair, scope, location representation | Create, update, and removal tests pass |
| Authority and fallback | Editors, overrides, escalation, manual log owner | Staff can contain an exception without conflicting edits |
If a clinician is also joining the group, run new-provider scheduling onboarding as a separate readiness path. A ready location cannot compensate for an incomplete provider setup.
Which scenarios should be tested before go-live?
Test representative creates, reschedules, cancellations, recurring blocks, provider absences, location changes, travel buffers, competing edits, and recovery paths. Record the actor, test identifier, expected state, observed state, timestamp, and final disposition for each run.
| Scenario | Evidence to capture | Stop condition |
|---|---|---|
| Create | Correct provider, site, type, time, and channel | Wrong dependency or unintended capacity |
| Reschedule | Original state closes and destination state is correct | Duplicate or orphaned entry |
| Cancellation | Appointment and related representations reach the approved state | Stale bookable or calendar state |
| Provider absence | Capacity closes across affected types and channels | Any affected slot remains bookable |
| Recurring block | Series and single-occurrence behavior are distinguished | Unintended series-wide change |
| Cross-location change | Site, provider, time, and communication path remain aligned | Old-site state remains active |
| Travel buffer | Nonbookable transition time exists between sites | Infeasible same-day movement |
| Competing edits | Authority rule produces one reconciled outcome | Two active versions persist |
| Recovery | Fallback log can be replayed and reconciled | Change history is incomplete |
For providers moving between sites, apply the location-pair travel-buffer playbook rather than using a generic gap that ignores direction, time of day, or site pairing.
How should future appointments be controlled during cutover?
Use a ledger that classifies every affected appointment as staying, moving, requiring confirmation, or unresolved. Assign one owner, one approved action, and one verification step to each record before bulk work begins.
| Classification | Cutover rule | Required closure evidence |
|---|---|---|
| Stay | Keep at the current site | Original location and provider rechecked |
| Move | Use an approved destination mapping | Old state closed and new state verified |
| Confirm | Hold action until the defined confirmation occurs | Decision, communication, and final state logged |
| Unresolved | Do not move or release automatically | Named owner, containment, and deadline recorded |
Include the appointment identifier, current and proposed location, provider, type, date, patient-communication requirement, owner, and verifier. Use the reschedule and cancellation reconciliation workflow for ordinary changes, while reserving the cutover ledger for launch-controlled moves.
What decisions can the go-live gate produce?
The gate should produce one recorded outcome: go, go with contained exceptions, delay, or roll back. The opening date is an input, not evidence that the scheduling bundle is ready.
| Outcome | Evidence standard | Operational action |
|---|---|---|
| Go | Required mappings and scenarios pass | Open normal booking under launch monitoring |
| Go with containment | Exceptions are bounded and do not invalidate the bundle | Limit scope and apply temporary controls |
| Delay | A required dependency or fallback is unproven | Keep the existing booking path and retest |
| Roll back | Partial activation created unsafe or unreconciled schedule states | Stop the new path and restore the approved prior state |
Every accepted exception needs a description, affected scope, owner, temporary control, deadline, and closure evidence. “Staff will watch it” is not an adequate containment plan.
What should opening-day control include?
Name one command owner, use one exception queue, limit change authority, schedule reconciliation checks, and define when new-location booking must pause. Staff should know where to report a problem before the first booking is created.
- Publish the command owner and backup.
- Route all launch exceptions to one queue.
- Limit template and mapping changes to named administrators.
- Log every manual booking or schedule correction.
- Reconcile at opening, midday, and close.
- Pause booking for wrong-location appointments, unexplained capacity, repeated duplicates, or loss of the authoritative record.
When the pause trigger fires, contain the smallest affected unit: one channel, appointment type, provider-location pair, or the entire location if the scope is unknown.
How should the launch be verified?
Use Day 0, Day 1, and Day 7 checks to sample provider-location pairs, booked and blocked capacity, future appointments, and unresolved exceptions. Each check should end with a signed decision rather than a list of observations.
| Checkpoint | Minimum review | Decision |
|---|---|---|
| Day 0 | Final mappings, scenario evidence, cutover ledger, authority, fallback | Go, contain, delay, or roll back |
| Day 1 | Creates, changes, cancellations, blocks, channels, manual log, exceptions | Continue, narrow scope, or pause |
| Day 7 | Representative provider-location samples and the full launch exception window | Close launch control or extend monitoring |
Track a denominator for each measure: mappings tested, scenarios passed, appointments reconciled, exceptions closed, and sampled records matching the authoritative schedule. Confirm that corrections did not create duplicate, orphaned, or stale entries.
What should happen if the launch fails?
Contain new bookings, preserve the authoritative schedule, log disruption-window changes, correct the smallest failed dependency, and reconcile before resuming normal operations. Do not repair multiple systems independently without a written authority rule.
- Pause the affected booking scope.
- Declare which schedule is authoritative.
- Capture every create, change, cancellation, and block made during containment.
- Correct and retest the smallest failed mapping or workflow.
- Replay the log, reconcile the full window, and obtain command-owner approval.
The ONC SAFER contingency-planning resource supports preparing fallback procedures for planned or unplanned EHR unavailability. Apply the same discipline to a contained scheduling launch failure.
How should connected calendars be included?
Treat each provider-calendar connection as a separate dependency within the location bundle, not as proof that the whole site is ready. Test identity, ownership, location context, recurrence, time zone, updates, deletions, and recovery for each pair.
Google’s Calendar Event resource separates event identity, status, location, start and end time zones, recurrence, and recurring instances. Its incremental synchronization guidance also requires handling deleted entries and performing a full synchronization when a sync token becomes invalid.
Microsoft Graph’s Event resource exposes properties including change keys, cancellation state, locations, recurrence, and transaction identifiers. Microsoft’s calendar-view delta guidance tracks new, updated, and deleted events for a defined calendar and date range, so each target calendar needs its own acceptance and recovery evidence.
If connected visibility is in scope, review the current Sporo athenahealth and Google Calendar page or Sporo athenahealth and Microsoft Outlook page as vendor descriptions, then confirm the exact approved behavior in writing. If connections are being added during the opening, use the provider-by-provider calendar-sync rollout plan. Calendar fields, permissions, contracts, and regulatory conclusions require authorized practice review.
athenahealth scheduling checklist for a new clinic location
Use this final control list only after the dependency map, scenario matrix, future-appointment ledger, and fallback have named owners.
- Approve the location or department identity.
- Verify every provider-location assignment.
- Map appointment types to templates and slots.
- Test every approved booking channel.
- Test cross-location travel and absence controls.
- Classify every affected future appointment.
- Confirm external-calendar scope where applicable.
- Name edit, override, pause, and rollback authority.
- Record the four-outcome go-live decision.
- Complete Day 0, Day 1, and Day 7 reconciliation.
The checklist is complete only when the practice can show what was tested, who accepted it, which exceptions remain, how those exceptions are contained, and when launch control will end.
Frequently asked questions
Should future appointments be moved in bulk?
No—not until the destination location, provider, appointment type, owner, patient-communication step, and verification rule are approved. Move only records covered by the cutover ledger; leave unresolved records contained and assigned.
Can one provider calendar represent multiple locations?
Yes, but only if each event or block preserves enough location context for staff. Test travel, time zone, recurrence, edit authority, and source-of-truth rules separately for every provider-location pair.
Can Google Calendar and Outlook use the same launch checklist?
They can share governance and acceptance categories, but they need separate platform tests. Validate permissions, recurrence, time zones, updates, deletions, and recovery against current documentation and the approved product configuration.
What decisions can the go-live gate produce?
The gate should record go, go with contained exceptions, delay, or roll back. Any exception needs an owner, temporary control, deadline, and evidence required for closure.
Who can pause new-location booking on opening day?
One named command owner should have authority to pause booking under predefined triggers. Staff should route exceptions to one queue rather than making independent workarounds.
What proves the launch is complete?
Completion requires evidence that the launch window reconciles across providers, locations, appointment states, booking channels, and connected calendars. Open exceptions must be accepted with controls or closed.
What is an athenahealth scheduling checklist for a new clinic location?
It is a location-level control package for mapping dependencies, testing workflows, deciding cutover, and verifying the schedule after launch. It should also define fallback ownership and failure recovery.
Put the location go-live plan into practice
Build the worksheets before requesting activation, and ask every system or integration owner to confirm mappings, authority, tests, and fallback in writing. Visit the Sporo Health homepage to review its current scheduling resources. Practices evaluating the Google Calendar option can also inspect the Sporo Health listing in the athenaConnect Marketplace. Treat vendor descriptions as inputs to acceptance testing, not substitutes for it.
Sources
