Closing an athenahealth Clinic Location: A Schedule-Consolidation Checklist
An athenahealth clinic location closure scheduling checklist should treat the shutdown as a controlled schedule migration, not a department toggle. Growing medical-group leaders should set six closure clocks, assign a disposition to every future appointment and waitlist item, approve destination capacity by cohort, retire booking surfaces in stages, reconcile connected calendars, and verify that the closed location cannot accept new bookings before declaring completion.
What does a controlled clinic-location closure require?
Close the location as a schedule migration, not as a single department deactivation. A closure reverses the activation logic in a new-clinic scheduling go-live checklist, but it cannot simply run those steps backward: existing appointments, waitlist demand, provider obligations, resources, and external representations must first reach owned outcomes.
A location may remain in historical records while becoming unavailable for new work. Separate that historical identity from active provider capacity, public booking visibility, staff edit authority, and referral routing. The official athena Appointment profile represents appointments with status and relationships to locations, practitioners, service types, and slots. The athenaPractice capability statement also documents searches across those dimensions. Closure evidence therefore needs to be record- and cohort-level rather than based only on whether a location label remains visible.
Which six clocks should control the closure?
Use separate clocks for announcement, last booking, final service, migration freeze, system deactivation, and stabilization. Combining them creates gaps in authority: staff may continue creating appointments after migration begins, or administrators may hide schedules before unresolved records have been found.
| Clock | Operational boundary | Required decision |
|---|---|---|
| Announcement date | The closure becomes an authorized program. | Name the closure owner, scope, destinations, and communication path. |
| Last bookable date | No new appointment may be added at the closing site beyond the approved rule. | Shut or redirect each approved booking channel. |
| Last service date | Routine care at the site ends. | Confirm which appointments may still complete in place. |
| Migration freeze | Uncontrolled template and assignment changes stop. | Route changes through the closure ledger. |
| System deactivation | Completed scheduling components become inactive. | Deactivate only scopes whose future obligations are resolved. |
| Stabilization end | Enhanced reconciliation may end. | Accept scorecard results and remaining exceptions. |
Record changes to any clock with an approver, reason, affected interval, and downstream actions. A date change is not complete until booking rules, patient communication work, migration cohorts, and verification windows reflect it.
How should future appointments and waitlists be classified?
Give every future appointment and waitlist item one disposition, one owner, and one verification step. Use the reschedule and cancellation reconciliation workflow to execute individual transactions after the closure ledger has authorized their destination.
| Disposition | Use when | Closure evidence |
|---|---|---|
| Complete at closing site | The appointment is authorized before the last service boundary. | Service date and location remain valid. |
| Move with same provider | The provider and approved appointment cohort continue elsewhere. | Destination, time, dependencies, and communication are verified. |
| Reassign provider | Another authorized provider can accept the appointment. | Provider, appointment type, location, and patient communication are confirmed. |
| Reschedule after confirmation | A viable option exists but requires agreement or operational review. | The original record stays controlled until the new booking is confirmed. |
| Authorized cancellation | An approved reason and communication process permit cancellation. | Reason, authority, communication, and connected artifacts are reconciled. |
| Unresolved hold | No safe disposition has been approved. | The record remains visible in an exception queue with an owner and deadline. |
Do not bulk-move records merely because one destination location exists. Move only cohorts whose provider, appointment type, resource needs, operational dependencies, communication path, and verification rule have been approved. Reassess waitlist entries against destination eligibility, service, provider, and outreach rules instead of copying them automatically.
What must the destination-capacity gate prove?
Destination capacity must be approved for the exact cohort being moved, not inferred from a location record or apparently open slot. Apply the same allocation discipline described in the provider capacity reserve-and-release playbook before accepting work from the closing site.
- Provider: Is the assigned clinician authorized and scheduled at the destination?
- Appointment type: Can the destination perform and schedule that visit type?
- Location and date range: Is capacity valid throughout the affected interval?
- Resources: Are required rooms, equipment, and support roles available?
- Operational dependencies: Are referral, preparation, language, or workflow needs supported?
- Communication: Is there an approved path for informing affected patients?
- External calendars: Are provider and resource representations mapped correctly?
- Verification owner: Who confirms the appointment after migration?
If any gate item fails, keep that cohort out of the migration wave. An unresolved-hold queue is safer than fictional capacity or a record that disappears when the source schedule is deactivated.
When should schedules and booking channels be deactivated?
Deactivate the smallest completed scope only after its affected future records have approved dispositions. When clinicians are continuing at another site, use the narrower provider department move checklist to control their reassignment instead of treating every provider identically.
| Scheduling surface | Deactivate when | Do not deactivate if |
|---|---|---|
| Patient-facing booking | The last-bookable boundary and redirect path are active. | The channel can still create unowned appointments. |
| Staff and call-center booking | Users have a destination or exception route. | Staff still need the location to resolve future records. |
| Recurring templates | Affected appointments and release rules are reconciled. | Future demand remains hidden beneath the template. |
| Provider-location assignments | Final service and approved provider moves are complete. | The assignment is required to finish or verify migration. |
| Resources and recurring blocks | Rooms, equipment, and reservations have final dispositions. | Linked obligations remain open. |
| Waitlists and referral paths | Every item is reassessed, redirected, or held. | Demand would be stranded by deactivation. |
This sequence prevents a superficially clean location from concealing unresolved work. A disabled interface is not proof that the underlying appointments, waitlists, and calendar artifacts reached valid outcomes.
How should connected calendars be reconciled?
Record the authoritative scheduling decision first, then update and verify its Google Calendar or Outlook representation. Do not let a bulk calendar edit determine the destination, cancellation, or provider assignment of a patient appointment.
The Google Calendar Events resource distinguishes event location, time-blocking transparency, and cancelled state, while Google’s recurring-events guide separates parent series, instances, moved exceptions, and cancelled instances. The Microsoft Graph event resource likewise exposes locations, availability state, recurrence, exceptions, and cancelled occurrence identifiers. A closure check should therefore test these states separately rather than relying on one visual calendar scan.
- Verify the event’s date, time, and destination location.
- Confirm whether it should remain busy, move, or be removed.
- Inspect one-off exceptions to recurring series.
- Check provider, room, equipment, and shared calendars separately.
- Find stale events left at the closed location.
- Reconcile the full affected interval after any failed update.
How do you scan for residual booking exposure?
Attempt to find and book the closed location through every approved and unapproved path that could still expose capacity. Use the exception ownership and evidence discipline in the daily schedule reconciliation playbook throughout migration and stabilization.
- Local staff scheduling workflows
- Centralized call-center workflows
- Patient-facing web or portal booking
- Waitlists and cancellation-fill processes
- Recurring provider templates and blocks
- Referral and order-driven scheduling paths
- Room, equipment, and other resource calendars
- Third-party links, directories, and saved booking URLs
- Connected provider calendars in Google Calendar or Outlook
Record each test with the channel, user role, appointment type, provider, date range, expected result, actual result, evidence, and retest owner. Test both positive redirects and negative attempts to book the closed site.
What should happen when a closure dependency fails?
Contain the affected cohort, preserve the authoritative schedule, correct the failed dependency, and reconcile the full affected interval before continuing. Do not advance unrelated deactivation steps if the failure could hide or misroute appointments.
The ONC SAFER Guides address planned and unplanned EHR unavailability, system management, assigned responsibilities, validation, and recovery. A clinic closure is not necessarily an EHR downtime event, but the same contingency discipline is useful: define fallback communication, preserve access to authoritative information, document changes during the disruption, and verify recovery before normal work resumes.
What proves that the location is closed?
Closure is complete only when every denominator is known and the approved completion rule is satisfied. Counts without denominators can hide unreviewed appointments, untested channels, or calendar artifacts outside the sampled view.
| Measure | Numerator | Denominator |
|---|---|---|
| Appointment disposition coverage | Future appointments with verified dispositions | All future appointments in closure scope |
| Waitlist disposition coverage | Waitlist items reassessed and verified | All waitlist items attached to closing capacity |
| Booking-surface test coverage | Surfaces tested with accepted results | All inventoried booking surfaces |
| Calendar-artifact resolution | Artifacts corrected or formally accepted | All identified connected-calendar artifacts |
| Sampled schedule agreement | Sampled records matching authoritative decisions | All records in the approved sample |
| Exception closure | Exceptions closed or formally accepted | All exceptions opened during closure |
The final gate should also confirm that no unapproved channel can book the location and that every remaining exception has an accepted owner, deadline, operational containment, and documented authority.
How should teams execute the athenahealth clinic location closure scheduling checklist?
Run the checklist as a sequence of evidence-producing gates, with authority to pause after every material step. The closure owner should coordinate practice operations, scheduling administration, destination leaders, provider representatives, communications owners, and connected-calendar administrators.
- Approve the closure scope, owner, destinations, and six clocks.
- Inventory providers, appointment types, resources, waitlists, templates, channels, and calendars.
- Freeze uncontrolled changes and open the disposition ledger.
- Classify every future appointment and waitlist item.
- Approve destination capacity by cohort.
- Execute moves, reassignments, reschedules, cancellations, and holds.
- Verify each completed transaction and patient communication status.
- Retire templates, assignments, resources, and channels in phases.
- Reconcile Google Calendar and Outlook representations.
- Run the residual booking-surface scan.
- Review the closure scorecard and contain failures.
- End stabilization only after formal acceptance.
Used this way, the athenahealth clinic location closure scheduling checklist becomes a closure-evidence package rather than a one-time configuration task.
Where do connected-calendar tools fit?
Connected-calendar tools can support visibility and reconciliation, but they should not decide appointment dispositions or certify closure on their own. Practices evaluating options can review the Sporo Health healthcare-automation overview, its current athenahealth and Google Calendar connection, the athenahealth and Microsoft Outlook connection, and the Sporo Health athenaConnect Marketplace listing. Treat product descriptions as vendor claims and verify the configured event, recurrence, location, retention, and failure behavior before a closure cutover.
Frequently asked questions
What is an athenahealth clinic location closure scheduling checklist?
It is a controlled schedule-migration plan that stops new booking at defined boundaries, dispositions every future appointment and waitlist item, retires capacity and channels in sequence, reconciles connected calendars, and proves the site is no longer bookable.
When should booking stop at a closing clinic location?
New booking should stop on the approved last-bookable date, before the last service date, after destination rules, communication paths, and exception ownership are ready.
Should all future appointments move to one destination clinic?
No; move only cohorts whose provider, appointment type, operational dependencies, destination capacity, communication path, and verification rule have been approved.
What if no destination clinic can accept an appointment?
Keep the appointment in a controlled unresolved-hold queue for an authorized disposition and communication decision rather than inventing capacity or letting the record disappear.
What happens to waitlists and recurring blocks when a clinic closes?
Reassess waitlist items against destination eligibility and outreach rules, and retire recurring blocks only after their affected appointments and resource obligations have approved dispositions.
How should Google Calendar or Outlook events be updated during closure?
Record the authoritative scheduling decision first, then verify location, time, busy state, recurring exceptions, resource calendars, and stale events separately in Google Calendar or Outlook.
How do you verify that a closed clinic location is no longer bookable?
Test every staff, call-center, patient-facing, referral, waitlist, template, resource, third-party, and connected-calendar surface, and close only when failures have owners and deadlines.
Sources
