How Acclaim Autism Unified Clinical and Operational Work on One Platform

Clinicians rely on the system to document sessions and manage clinical information. Scheduling teams use it to coordinate services. Administrative and compliance teams depend on accurate records and authorizations. Billing and payroll processes may rely on information generated through those same workflows. And throughout the transition, everyone still has their regular responsibilities, and families still need services.

When Acclaim Autism transitioned to CentralReach, coordinating all of those moving parts became one of the most important parts of my role as project manager.

Looking back, what helped us most was not any single configuration decision or project tool. It was treating the transition as an organizational change rather than simply a software implementation: involving the people doing the work, connecting system setup with our procedures, creating a consistent project rhythm, phasing the rollout, and planning for support after go-live.

Jamie Turner's September article on Project Management and OBM in ABAdiscusses how temporary projects eventually become part of day-to-day operations. Our EHR transition was a very practical example of that process-and, nearly a year later, it is also a reminder that implementation does not end at go-live.

The project included representation from clinical, operations, administration, scheduling, HR, intake, technology, and billing. That mattered because no EHR workflow truly belongs to only one department.

A change to scheduling can affect what a clinician sees. A change to permissions can affect whether an administrator can complete a task. A documentation requirement can influence compliance, billing, payroll, or reporting downstream.

Having those perspectives represented during implementation allowed us to identify those connections while we were designing the workflows rather than discovering all of them afterward.

Our clinical team, for example, did much more than attend training after the system had been configured. Clinical colleagues helped build instructional note templates, ABC data templates, prompting and criteria templates, elements of the goal library, and other resources they would eventually use in practice.

That distinction is important.

The people who understand the work should help design the system that will support the work.

For organizations planning a similar transition, I would involve those stakeholders as early as possible, not only when it is time for user acceptance testing or training.

At the time of implementation, my responsibilities included both operational leadership and technology. That made it easier for me to translate between two different types of questions.

On one side: What can the system do?

On the other: How should Acclaim actually do the work?

Those are not always the same question.

Every configuration decision eventually becomes an operational decision. Who is responsible for this step? What information do they need? What happens next? What happens when something is missing? Who needs visibility into it? Does an existing standard operating procedure still make sense after the system changes?

Our SOP review made the scale of that work very clear. More than two dozen administrative procedures alone were identified for updates or retirement because of the CentralReach transition. Those procedures touched areas ranging from intake and authorizations to compliance, onboarding, payroll-related checks, and technical support.

That reinforced an important lesson for me: replacing an EHR without revisiting the procedures surrounding it risks recreating yesterday's workflow inside tomorrow's technology.

Implementation gave us an opportunity to ask not only, "How do we configure CentralReach?" but also, "How should this process work going forward?"

We established recurring project calls throughout implementation so we had a regular place to review progress, discuss risks, answer questions, and identify what needed to happen next. Our meeting agenda consistently brought together practice management, clinical work, migration, training, and rollout preparation.

We also documented the project in multiple ways for different purposes.

Jira helped us track work and ownership. Confluence served as a central project reference. Our shared project notes captured meeting discussions, checklists, training topics, current priorities, risks, and next steps.

We also created a Tech & Ops Hub for CentralReach training and guidance. The goal was to connect system instructions with Acclaim's own procedures so staff had somewhere to return when they needed help after a training session.

That became increasingly important as we moved closer to go-live.

A training session can introduce a workflow, but most people will not remember every step weeks later when they encounter a less-familiar situation. Accessible documentation turns training from a one-time event into an ongoing resource.

Different employees interacted with very different parts of the system.

Scheduling staff needed to understand appointments, permissions, labels, and staff-client connections. Administrative employees worked with contact information, care teams, authorizations, and data updates. Clinical employees needed their clinical tools, but they also needed to understand the practice-management functions that intersected with their work, including scheduling, service codes, files, authorizations, and session-related workflows.

This was one reason cross-functional involvement mattered so much.

People do not experience an EHR in modules. They experience it through their jobs.

We tried to build training around those responsibilities and around the situations people would actually encounter.

We also used a phased implementation rather than moving every team and location at once. The rollout progressed through regional phases before full implementation, giving us a structure for coordinating training, preparation, and support as more teams began working in the new environment.

Phasing did not eliminate every question or challenge, but it gave us a more manageable way to move the organization through a significant change.

In many ways, that is when the most useful feedback starts.

Once employees begin working in a system every day, they encounter situations that are difficult to reproduce during configuration or testing. They also begin asking more specific questions because the workflows are no longer hypothetical.

We planned post-go-live support into the transition and gave staff a structured way to raise those questions.

I created CentralReach support forms and routing automation so staff could identify their role, the type of issue they were experiencing, its urgency, and the information needed to understand the problem. Issues could include areas such as session notes, conversions and verification, scheduling visibility, access, template updates, service codes, or additional training.

The purpose was simple: employees needed a clear place to ask for help, and the people supporting them needed enough information to take ownership of the issue.

The support process also helped us distinguish between different types of problems. Sometimes something required a configuration change. Sometimes the procedure needed clarification. And sometimes the system was working as designed, but we needed better training or documentation.

Those are very different problems, and they require different solutions.

We successfully moved the implementation into regular operations, but there are still areas we continue to improve.

One is deeper adoption and expertise across CentralReach's different modules. Employees naturally become more comfortable with the functions they use most often, while other capabilities take longer to develop. Continued training, documentation, and experience remain important.

We are also continuing to customize and refine workflows supporting our compliance requirements. An EHR provides tools, but every organization still has to determine how those tools support its own documentation, review, escalation, and quality processes.
Session conversions remain another area of focus.

During implementation, one recurring example involved understanding the difference between a session being converted and a session being fully verified with a complete and compliant note. A system status alone did not necessarily establish that every required documentation and verification step had been completed.

That may sound like a small distinction, but it is exactly the kind of detail that connects clinical documentation, operations, compliance, billing, and payroll.

It also demonstrates why implementation cannot be treated as simply teaching employees where to click.

People need to understand what each step means within the larger process.

Clear project ownership matters, but ownership does not mean working in isolation. The people closest to each process need meaningful involvement in the decisions that affect their work.

System configuration and operating procedures should be reviewed together. Changing the technology without changing the surrounding workflow leaves part of the implementation unfinished.

Training should reflect what people actually do-not simply how the software vendor organizes its modules.

Documentation needs to remain accessible after training ends.

And support after go-live should be designed as part of the project, not added when problems begin appearing.

Most importantly, organizations should expect implementation to evolve into optimization.

A go-live date answers the question, "Can we begin using the system?"

The months that follow answer a more important question: "Are we using it as effectively as we can?"

For us, the transition to CentralReach became more than an EHR project. It became an exercise in coordinating clinical, operational, and technical perspectives around the way work moves through our organization.

The strongest part of that effort was the participation across our teams. People brought their expertise, raised questions, helped build resources, and continued improving the processes after implementation.

Technology can support the work. But successful implementation still depends on the people who understand the work, the procedures that guide it, and the systems an organization builds to help people succeed.