Behavioral health EHR implementation, week by week: the decisions before day one, then configuration, migration, parallel running and go-live

The go-live date was agreed on the kickoff call. On the first Monday, a residential tech cannot find where Q15 rounds are recorded, billing discovers that enrollment with the largest Medicaid plan was never approved, and someone notices the old vendor's contract auto-renewed last month. None of those are software problems. They are decisions that were not made, or were made too late. This guide walks through an implementation in the order it actually runs: the decisions that belong before week one, then configuration, data migration, role-based training, parallel running and go-live, and the first month after, when the first full billing cycle runs through the new system. The structure assumes a four-week plan. Longer projects follow the same order; they just spend more time in each step.

Before week one: the decisions that set the schedule

An implementation plan usually starts with configuration. Whether the plan holds is determined earlier, by a handful of decisions that nobody outside your organization can make for you. Each item below is a decision, not a task, and each needs a named owner and a date.

Name one internal owner who can say yes

Not a committee. One person who can decide what a note type is called, which roles can see the medication section, and whether a payer's rate table is loaded now or after go-live. In a hypothetical 30-bed residential program that might be the clinical director, with the billing manager as deputy for revenue questions. In an outpatient group it is often the practice manager. The test is simple: when a configuration question arrives on Tuesday afternoon, can this person answer it by Wednesday without calling a meeting? If not, every open question costs days, and four weeks of open questions costs the schedule.

Give that person protected time. An implementation owner who is also carrying a caseload and the on-call phone will not spot-check migrated charts in week two, and week two is where that check matters most.

Define scope by program, site and level of care

List every program that will run in the new system on day one: each level of care, each site, each billing entity with its own tax ID and NPI. Then list what you are deliberately deferring. A program opening a recovery residence next quarter does not need it configured now, but it needs to be on the deferred list so nobody discovers its absence during training. If you are partway through adding a level of care, read adding a new level of care first, because licensing and payer contracting run on their own clocks and will not speed up to match your go-live.

Choose the history window

Active work moves by default in any sensible plan: current patients, coverage, active treatment plans, open claims, census and bed assignments, staff credentials. History is a decision. Twelve months of progress notes, twenty-four, or everything since the program opened: the further back you reach, the longer mapping and verification take and the more there is to check.

Decide based on what you will need to produce from the new system rather than what feels complete. Look at open authorizations and upcoming concurrent reviews, any pending audit or records request, look-back provisions in your payer contracts, and your state's record retention rules. Whatever you do not migrate still has to be producible, so the history decision and the archive decision (covered under week two) are made together.

Build the payer and billing entity list from remittances

Every payer you bill, every plan product that behaves differently, every billing entity, and every rendering and supervising provider enrolled with each. Include the payers you bill twice a year. This list drives clearinghouse enrollment, rate tables, scrubbing rules and provider enrollment checks, and the version built from memory is almost always missing something. Pull it from the last twelve months of remittances instead. The plan you billed once in the spring will otherwise surface in week six with no enrollment behind it.

Write down what done means, and what would stop you

A go-live date is not a definition of done. Write three or four criteria the owner can check against: every active patient reconciled against the source system; a first claim batch accepted by the clearinghouse for each high-volume payer; remittances matching and posting in the new system; every clinician has written and signed a note in it. Then write the rollback trigger: what would have to go wrong for you to keep the old system as the record past the planned date, and who makes that call. Deciding this in advance keeps it from being decided by whoever is most anxious on the Friday before cutover.

Find the notice dates on everything you are retiring

Old EHR, clearinghouse, admissions CRM, outcomes tool, training LMS, the census spreadsheet's owner. Read each termination clause now. Some agreements renew automatically and require notice well in advance. For each system you want two dates: the last day notice can be given, and the day you will genuinely be finished with it. You want the second to land before the first renews. Also get in writing what each outgoing vendor will provide on the way out: export format, fee, how long it takes to produce, and how long read-only access lasts afterward.

Sign the BAA before any data moves

The new vendor holds PHI the moment the first export file arrives. HIPAA requires a business associate agreement to be in place before that happens, and substance use disorder records covered by 42 CFR Part 2 carry their own disclosure rules on top. Get the agreement executed, decide who is authorized to send export files, and agree how they are transmitted. An extract emailed as an attachment by a helpful office manager is the start of a breach assessment, not a migration step.

Week one: configuration

Week one turns your organization into settings. The goal by Friday is a system that looks like your program: your sites and levels of care, your note types, your roles, your payers. In rough order of consequence:

• Programs, sites and levels of care, each tied to the billing entity that bills for it.
• Note types and forms, starting with the ones that drive billing and audits: progress notes, group notes, assessments, treatment plans and their review cycle, discharge summaries. Build from your current forms and your payer and accreditation requirements, not from a vendor's sample library alone.
• Roles and permissions by record section: who can edit, who can view, who sees nothing. Decide explicitly who can view Part 2 protected records and who can export anything.
• Scheduling templates: group schedules, program days, and shift patterns for 24-hour units.
• Payers, plans, rate tables and authorization rules, from the list you built beforehand.
• Staff records with license, credential and payer enrollment dates. A clinician who cannot be scheduled or billed in week four is a week-one omission.

Start payer EDI enrollment on day one

Electronic enrollment for claims, remittances and eligibility is submitted per payer and per billing entity, and approval times vary widely from payer to payer. Some turn it around quickly; government plans are often the slowest. It is the longest item in most implementations and the one you have least control over, so it starts on the first day, not after configuration is finished. Track every enrollment with a submission date, a current status and a named person who follows up. Your slowest high-volume payer will usually decide when you can stop submitting through the old clearinghouse, whatever the project plan says.

Resist rebuilding every form

Configuration is when people want to fix the forms they have disliked for years. Some of that is worth doing. Most of it should wait. Every new field is a training topic in week three and a mapping question in week two, and a redesigned form nobody has used is a source of unsigned notes in week five. A workable rule: change a form during implementation only if a payer, regulator or accreditor requires the change, or if the current version is demonstrably causing denials or audit findings. Everything else goes on a list for the first quarter after go-live, when people know the system well enough to judge the change.

Week two: data migration

Migration is a data question rather than a project-management one. The questions are what moves, in what shape, and how you will know it arrived intact.

Pick the extraction path early

Most migrations run on file exports: CSV or spreadsheet extracts from the old system, mapped field by field once. Where the old system offers a FHIR or API export, mapping is lighter, but the result still has to be verified the same way. Ask the outgoing vendor in the first days of the project how long an export takes to produce. Some require a written request and join a queue, and a two-week wait for a file will consume the whole migration window.

Set a snapshot date and keep a change list

An export is a picture taken on a particular day. Anything that changes in the old system after it, an admission, a discharge, a corrected coverage record, a resubmitted claim, has to be carried across by a later delta load or by hand. Agree the snapshot date, and assign one person to keep the list of changes made after it. A short, deliberate list beats a reconciliation discovered a month later.

Load to a sandbox, then reconcile

Nothing goes to production until it has been checked in a test environment. Reconcile in this order:

1. Record counts. Active patients, open episodes, active treatment plans, open claims, census by unit, staff records. Compare against the source system's own reports, not against an estimate.
2. Coverage. Subscriber IDs, payer order and effective dates. A wrong primary payer produces rejections that look like a billing problem weeks later.
3. Authorizations. Every active authorization with its approved units or days, utilization to date and end date. A wrong remaining balance becomes a missed concurrent review.
4. Clinical spot checks. Someone clinical opens real charts: a residential admission, an IOP patient with a group-heavy week, a MAT patient with a complicated medication list. They confirm the chart reads the way it did in the old system.
5. Consents. Part 2 consents arrive with recipient, scope, expiration and revocation status intact as structured records, not as scanned images nobody can enforce.
6. Documents. Scanned files keep their original dates and attach to the right patient and episode.

Expect differences. Formatting inside free-text notes can shift, custom fields with no equivalent need a decision, and some systems export documents without their original dates. The goal is not zero differences. It is that every difference is known, decided and written down before the production import.

Decide where unmigrated history lives

What you leave behind still has to be producible for a records request, a payer audit, or a patient asking for their own record. The options are read-only access to the old system for a defined period, a complete archival export in a format that opens without the old software, or both. Get the archive in hand before access ends, confirm it opens, and record where it is stored and who can reach it. Keep the old system's access log with it: a question about who viewed a record last year will be answered from that log, not from the new system.

Week three: role-based training

Training belongs in the week before go-live, not a month ahead, because people forget what they have not used. Train by role, on your own configuration, using your own form and program names.

• Clinicians: individual and group notes, treatment plan updates, signing and co-signing, and where their documentation deadlines show.
• Nursing and residential staff: medication administration, safety rounds, shift handoff and census changes.
• Front desk and intake: inquiry and admission entry, eligibility checks, scheduling and rescheduling.
• Billing: claim review and scrubbing edits, remittance posting, denial work queues and patient balances.
• Leadership and compliance: dashboards, permission reports, the activity log and records-request production.

Run each session against a realistic scenario rather than a tour of menus. Admit a test patient, place them in a group, write the note, build the claim, post a remittance against it. The person who has done it once on Wednesday will do it on Monday. Record sessions for night shift and for next month's new hire, and track attendance by name. The clinician who skipped training is reliably the one with a stack of unsigned notes in the first week after go-live.

Train the exceptions too: what staff do when the system is unavailable, where the downtime forms are kept, and who back-enters paper documentation afterward and how it is dated.

Week four: parallel running

Parallel running is the most misunderstood step in an implementation. It does not mean every clinician documents every session in both systems. Double documentation exhausts staff within days and produces two records that disagree, which is precisely the problem you are switching to solve.

It means both systems are live and you have decided, workflow by workflow, which one is the record. A split that works for most programs:

• New clinical documentation, new admissions and scheduling: the new system, from the first day of the parallel period.
• Claims for dates of service before the cutover: finished in the old system and the old clearinghouse.
• Claims for dates of service after the cutover: the new system, payer by payer as EDI enrollment is approved.
• Remittances: posted wherever the claim was submitted, until the old claims run out.
• The old system: read-only reference for history, not a place for new work.

Hold a fifteen-minute check every day of the parallel week with the owner, a clinical lead and the billing lead. Three questions: what did people do in the old system today that belonged in the new one, what did the new system get wrong, and which payer enrollments moved. Fix the first with training, the second with configuration, and log the third against the enrollment tracker.

Reconcile one day end to end

Pick one complete weekday. Take the midnight census, the group rosters, the individual sessions and the medication administrations, and trace each to a signed note and, where billable, to a claim, all in the new system. Every gap you find in one day will repeat every day until someone fixes it, so this is the cheapest audit you will ever run.

Go-live and the first thirty days

Go-live is the day the old system stops receiving new work. It is not the day the old system is switched off, and it is not the day the project ends. The month afterward is where most implementation risk actually lands, because it is when the first full billing cycle runs through the new system. Watch these in order:

• Documentation timeliness, daily. Unsigned notes accumulate fastest when people are unsure where a form lives. A late-note backlog in week one becomes a held-claims backlog in week three.
• The first claim batch per payer. Confirm acceptance at the clearinghouse, not just submission. A rejection on the first batch usually points to a configuration problem that will affect every claim to that payer.
• The first remittances. Confirm lines match to claims and post. Unmatched lines in the first files usually mean an ID or payer-mapping issue.
• Authorizations. Confirm every active authorization carried the right remaining utilization and end date. A concurrent review missed in the first month is a migration error that looks like a utilization review failure.
• Month end. Compare billed days or units against census and attendance, and compare cash posted against a comparable prior month. A gap is a question to answer, not a conclusion.

Keep the issue log open for thirty days and close it deliberately. Configuration problems go back to the owner; training problems go to the relevant role lead; payer problems go to billing with a follow-up date. If you track revenue cycle KPIs, mark the cutover date on every chart so a dip in the first month is read in context.

Keeping revenue moving during the switch

Cash interruption is the fear that delays most switches, and it is largely avoidable with one clean rule: cut over by date of service. Claims for services before the cutover finish in the old system. Claims for services after it originate in the new one. Mixing the two, for example resubmitting old-date claims from the new system, creates duplicate-claim risk and remittances that land somewhere nobody is watching.

Keep the old clearinghouse live until three things are true for every payer: enrollment on the new path is approved, at least one batch has been accepted, and remittances are arriving and posting. Only then give notice. Claims already submitted through the old clearinghouse are worked to completion there, including denials and appeals, so someone needs continued access for as long as appeal windows on those claims remain open. Check each payer contract for its appeal and timely filing windows rather than assuming a standard one.

Watch for one quiet failure: the payer that keeps sending remittances to the old destination after enrollment changes. If expected payments stop appearing in either system, call the payer before you assume the claims are still pending.

Staying compliant while two systems are live

An implementation briefly doubles the number of places PHI lives. Treat that period as a compliance event with its own controls.

• Access. Remove departed staff from the old system before you start, and limit old-system access during the transition to the people who need it for history and old claims.
• Part 2 consent. Confirm consents migrated as enforceable records and that new disclosures run from the new system's consent controls. Any release made from the old system after cutover should still be checked against the current consent, including revocations recorded only in the new one. See 42 CFR Part 2, explained for operators.
• Export files. Once migration is verified, delete working copies of extracts from shared drives, inboxes and laptops, and record that you did.
• Audit trail. Keep the old system's access log available for as long as you may need to answer who viewed a record before cutover.
• Retention. Your obligations under state record retention rules and payer contracts do not change because the software did. The archive of the old system is part of meeting them.

Where implementations usually go wrong

Most failures are predictable, and almost none of them are about the software itself:

• The owner had no time. Decisions waited, configuration slid into week three, and training was squeezed into a single afternoon.
• The payer list missed rarely billed plans. The first claim to one of them surfaced weeks after go-live with no enrollment behind it.
• Migration was verified by counts alone. The counts matched, coverage order was wrong on a set of patients, and nobody opened a chart until the rejections arrived.
• Parallel running became double documentation. Staff burned out within days and the two records drifted apart.
• Notice was given at kickoff to save a month of fees. Then a payer enrollment slipped and there was no fallback.
• Forms were redesigned during configuration. Training covered forms nobody had used, and the next chart audit found notes written on three versions of the same template.
• Credentials were not loaded. Clinicians who could see patients could not be scheduled or billed under the new system's checks.

A pre-week-one checklist

1. One named owner with protected time who can make configuration decisions without a meeting.
2. A written scope: programs, sites, levels of care and billing entities, plus what is deliberately deferred.
3. A history window, decided against open authorizations, pending audits, contract look-backs and retention rules.
4. A payer list built from twelve months of remittances, with every billing entity and enrolled provider.
5. Written go-live criteria and a rollback trigger, with the person who calls it.
6. Termination clauses and notice dates for every system being retired, and written export terms from each outgoing vendor.
7. An executed BAA and an agreed, secure method for transmitting export files.
8. A decision on where unmigrated history and the old access log will live, and for how long.
9. A list of open audits, reviews and appeals, with the system each will be finished from.
10. Current staff licenses, credentials and payer enrollments, ready to load in week one.

How Unisona Health runs this

The order above is the order we use. Unisona Health's four-week implementation runs configuration in week one, data migration in week two, role-based training in week three and parallel running in week four, with payer EDI enrollment through the included Claim.MD connection submitted on day one and no implementation fee on Solo or Group Practice. The migration guide sets out which records move by default, which move on request, and how sandbox reconciliation works before the production import.

Whichever system you choose, ask the vendor for a written plan that answers every item on the checklist above, and ask what they need from you before week one starts. If they cannot tell you, the schedule is already at risk.

Frequently asked questions