Switching EHRs: What Behavioral Health Practices Need to Know Before They Sign

An EHR Switch Is Four Connected Projects

The incoming EHR company will usually hand you a polished implementation schedule. It may cover account configuration, training and the EHR company’s own import. It may not touch your open claims, clearinghouse relationships, payer specific enrollments, unposted remittances, unscheduled referrals, the portal transition, custom reports, or the exceptions that don’t fit the import template.

Practice size changes the coordination you need, not the standard: everyone needs a written definition of “successfully moved” first.

Build The Conversion Manifest Before You Set The Cutover Date

A conversion manifest names each information category with its source, destination format, owner and acceptance test. “Move all patient data” isn’t one. Where risk justifies it, go down to field and document type.

Each row should state the result: discrete usable data, a viewable document, a searchable archive or only temporary legacy access. Include source, destination and exception counts, a person’s name, a due date and a sign-off.

Read The Old And New Contracts As Operational Documents

Before canceling, read the subscription agreement, business associate agreement, order form, data export and interface terms, services scope and renewal notice. This is operational guidance, not legal advice; leave legal conclusions to qualified counsel.

Ask both EHR companies to answer in writing:

• Who may request a full-practice export, and how is identity and authority verified?
• Which record types, fields, identifiers, attachments, logs, and financial details are included, and which are excluded?
• Which outputs are structured and computable, which are PDFs or images, and how is the format documented?
• Are future appointments, recurring rules, open tasks, portal messages, authorizations, claims, ERAs, adjustments, and audit history included?
• How long does an export request take, how long is the download available, and can you get a corrected export?
• What are the export, conversion, interface, consulting, storage, and read-only-access fees?
• What are the cancellation notice, renewal date, minimum term, and post-termination access?
• What secure transfer method and file size limits apply?
• Who handles field mapping, cleanup of unconverted records, reconciliation and fixing failed records?
• Which historical records import as discrete data, and which become attached documents?
• What support covers test conversion and go-live, including interfaces and connected services?
• When and how will remaining copies be returned, retained, or destroyed under the agreements and applicable requirements?

HHS explains that a business associate generally can’t block a covered entity’s access to PHI it maintains for the entity, and that the business associate agreement governs PHI return at termination. The covered entity must still make its own PHI available; the practice can’t hand that to the EHR company. Read the HHS guidance on business associate access and return of PHI and the HHS sample BAA provisions.

For certified health IT, ASTP/ONC’s EHI export criterion describes single-patient and patient population export in electronic, computable formats, with the format documented. Verify your product, module, information category and workflow are covered. The official EHI export criterion is the place to start.

API And FHIR Access Can Help But Neither Means “everything Migrates”

FHIR is an HL7 standard for exchanging healthcare information electronically, with reusable resources and implementation rules. It doesn’t promise that every operational, clinical, scheduling or financial object in a specific EHR is exposed, writable, or accepted by the other EHR. Start with the HL7 FHIR overview.

Before committing to an API based conversion, get both systems’ capability statements, implementation guides, scopes, resource lists, limits, identifier rules and production registration process. Then pin down whether access is patient or organization level, read-only or write-enabled, sandbox or production, and whether history, provenance and documents are available.

Don’t assume a certified API is free. ASTP/ONC requires certified developers to publish technical and business terms, fees included, and prohibits some fees while permitting others in defined circumstances. Read the EHR company’s terms alongside the official API Condition and Maintenance of Certification guidance.

Treat Revenue Cycle Cutover As A Separate Controlled Launch

A go-live can succeed clinically and still cause a cash-flow problem if ownership of claim submission, acknowledgments, remittance, posting and follow-up is unclear. Build an RCM cutover matrix by payer, network, provider, location, billing organization/Tax ID, clearinghouse, transaction type and effective date.

1. One ownership rule. Decide which system owns charges and claims by date of service, entry date, payer or another rule nobody can misread, then publish examples for the hard cases: late notes, corrected claims, secondary claims and retroactive eligibility.
2. Every connection, inventoried. That covers eligibility, claim submission, claim acknowledgments, claim status, attachments, ERA delivery, EFT destination, statements, card processing, prior authorization, and any payer portal or direct connection you rely on.
3. Enrollment and routing for every transaction. A software account doesn’t prove each provider/payer transaction is active. Record the submission date, confirmation, payer or trading partner status, test result and production ready date for each.
4. Protect old A/R. Keep a worklist for accepted claims, rejections, denials, appeals, underpayments, unapplied cash, refunds, credits, secondary balances and timely-filing deadlines, with a system of record and owner for each.
5. Reconcile daily. Compare encounters to charges, charges to claim files, claim files to acknowledgments, payments to ERAs/EOBs, and deposits to posted payments. Month-end is too late to learn a queue vanished.

Medicare’s EDI guidance shows why: provider, clearinghouse and billing service relationships run through EDI enrollment and trading partner processes, and changing a billing agent or clearinghouse can require notice or new arrangements. See the Medicare Claims Processing Manual, Chapter 24. Commercial and Medicaid processes vary, so check each payer’s current rules instead of applying Medicare’s.

Run A Test Conversion That Can Fail Safely

A test conversion isn’t done until you can prove the key data is accurate, usable, correctly permissioned and works the way staff really use it.

Test Different Patient And Billing Scenarios

Put the hard cases in: active and inactive patients, several coverage and claim states, different locations and roles, guardians and minors, duplicate or restricted charts, recurring appointments, amended documents, active authorizations, credits, unusual characters, and records near known limits.

Test Each Workflow From Start To Finish

• Patient registration or lookup, without creating a duplicate.
• Schedule, reschedule, cancel, and complete an appointment.
• Intake, consent, notes, signatures, amendments and release of records, each run start to finish.
• Role-based access, including proof that access doesn’t exist where it shouldn’t.
• Prescriptions, labs, telehealth, fax, portal, reminders and any interfaces in scope.
• Create a charge, submit a test claim where allowed, receive acknowledgments, work a rejection, and check how remittances post.
• Operational and financial reports, reconciled to known source totals.
• An export from the new system, so you know your next exit path.

Give every issue a severity level and set stop/go thresholds early. A cosmetic label can wait. Missing signed notes, incorrect patient matching, broken prescribing, incorrect claim identity, inaccessible time-sensitive information or a material financial imbalance can’t, and each should trigger a hold unless an authorized leader accepts a documented safe workaround.

ASTP/ONC’s SAFER Guides cover contingency planning and the safe configuration, validation and maintenance of EHR systems and system to system APIs. Read them before designing testing and downtime controls: SAFER Guides.

Use A Documented Go-Live Plan With A Real Rollback Decision

A go-live plan should say when the old system stops taking each type of new work, when final extracts run, when interfaces switch, who verifies each milestone, and how staff record work during an outage. “Call the EHR company” isn’t a rollback plan.

Minimum Cutover Controls

• A minute by minute or checkpoint based schedule with named owners and backups
• Final source freeze rules and an exception log for work created during transition
• Secure final exports, checksums or file inventories where appropriate, and access logs
• Contact paths for both EHR companies, clearinghouses, interfaces, payment services, and leaders
• Downtime forms and instructions for scheduling, charting, prescribing, billing and urgent messages
• Go/no-go checkpoints and who can delay or reverse each part of launch
• A rollback time limit, data reentry plan, and rule for reconciling work done in either system
• Daily post-go-live huddles covering each issue’s severity, owner, when the next update is due and proof it’s closed

You can’t always roll a migration back in one move. You might pause interfaces, keep read-only access longer, return to the old scheduling setup, or send claims from the old system while notes stay in the new one. Plan any split before go-live and name each task’s system of record.

Have Staff Complete The Work Before Go Live

Sitting through training doesn’t prove readiness. Require role-based practice: schedulers handle exceptions, clinicians document and amend, billers work acknowledgments, managers reconcile, and administrators manage permissions and downtime. Record who passed and who needs support.

What Practitioners Say And How To Use Anecdotes Responsibly

Reddit threads are anecdotes, not evidence of EHR company performance, but they raise questions worth testing. In one r/therapists discussion about changing EHRs with a large caseload, participants described the downloads, imports, cleanup, retraining and billing continuity involved. In another EHR transfer discussion, the original poster worried about future schedules and securing exported records.

Use anecdotes to shape demos and contract questions, not purchasing claims. Have the EHR company demonstrate, with representative test data, your exact future appointment import, note format, billing history treatment, portal experience and exception report.

How We Help When The Timeline Is Tight Or The Practice Is Large

On a tight timeline or in a bigger practice, an EHR switch is a coordination problem before it’s a software problem. Every added location, clinician, billing combination, interface, form and open item is another place a missed step can hit patients, staff or cash flow. We add experienced hands; you keep control.

We can inventory your setup quickly, turn the EHR company’s promises into a field level conversion manifest, find the high-risk gaps, and put one name and one acceptance test on every item. We run the written questions and working sessions with both EHRs, the clearinghouse, your billing team and anyone else involved.

We can’t control how fast a third party responds or finishes its work. We can keep every dependency, request, date and decision in plain view, with who to push when something stalls, so you can act sooner.

On the data side, we organize test extracts, mapping decisions, test conversions, exception cleanup, and count and sample checks. Revenue cycle gets its own track: we map claim and remittance pathways, build the payer/provider/location cutover matrix, assign old A/R and set up daily reconciliation. For staff, we build role-based scenarios, collect test evidence, track open issues, and write usable downtime instructions.

When Command Suite is part of the work, you see the whole project in one place instead of email threads: every conversion item, outside dependency, test result, due date, risk and decision, with a name and next step on each. At the end you get a written go-live plan with checkpoints, sign-offs, backup steps and a named owner for every post-launch task.

We’ve done behavioral health operations, billing, credentialing and systems work hands-on. Software can organize evidence and watch tasks. People who’ve done this before make the mapping calls, push back on assumptions, keep parties moving, check results, and help you decide whether it’s safe to go.

Frequently Asked Questions

How Long Does It Take To Switch EHRs?

There’s no responsible universal timeline. It depends on contract and export lead times, practice size, data volume and quality, import limits, interfaces, payer and clearinghouse work, staff availability, testing results and third-party response. Build the date backward from confirmed dependencies and acceptance criteria, not a sales estimate.

Does FHIR Mean All Of Our Data Will Move Automatically?

No. FHIR is a standard for exchanging healthcare information, and a given EHR’s version might expose only some resources, fields, operations or access scopes, and leave out documents, tasks, schedule rules, audit details, custom fields, claim artifacts or ledger items you rely on. Check what the source and destination can each do against a field level conversion manifest.

Should We Keep Read-Only Access To The Old EHR?

Often, yes. Read-only access helps while you validate converted information, work old receivables, meet retention obligations and handle exceptions. How long you keep it, and how, depends on the contract, retention requirements, cost, security and what exported successfully. Confirm those terms before you cancel, and get legal advice where needed.

How Do We Reduce Cash-Flow Disruption During The Switch?

Treat the revenue cycle cutover as its own project. Decide which system owns each charge and date-of-service range, check payer and clearinghouse routing, protect your old A/R, track acknowledgments and remittances, and reconcile encounters, charges, claims, payments and deposits every day. Anything unresolved stays on a worklist with a name on it until it’s closed.

What Should We Test Before EHR Go-Live?

Test typical and high-risk records first, then every staff task start to finish: identity matching, scheduling, intake, notes, signatures, permissions, prescribing and interfaces when in scope, claims, acknowledgments, remittance, posting, reporting, downtime, and export from the new system. Reconcile counts and financial totals, log anything that didn’t convert cleanly, and don’t go live before sign-off.

When Should A Practice Bring In Outside Migration Help?

Bring in experienced help when the deadline is tight, you have multiple locations or many roles, billing combinations are complex, open A/R is material, interfaces or custom setups are involved, leaders can’t step away from daily work, or neither EHR company owns testing across the move. Whoever you bring in should hand you working controls and finished tasks rather than a diagnosis alone.