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

An EHR Switch Is Four Connected Projects

The incoming vendor will usually hand you a polished implementation schedule. It may cover account configuration, training and the vendor’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 how much coordination you need. It doesn’t change the standard. A solo clinician and a multisite group both need a written definition of what “successfully moved” means before anything moves.

Build The Conversion Manifest Before You Set The Cutover Date

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

On every row, record whether the result will be discrete usable data, a viewable document, a searchable archive or only temporary legacy access. Each row also gets source, destination and exception counts, an owner, a due date and a sign-off.

Read The Old And New Contracts As Operational Documents

Before you cancel anything, read the subscription agreement, the business associate agreement, the order form, the data-export and interface terms, the services scope and the renewal notice. Treat this as operational guidance. It isn’t legal advice, and legal conclusions belong with qualified counsel.

Ask both vendors to answer these questions 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 a corrected export be produced?
• What are the export, conversion, interface, consulting, storage, and read-only-access fees?
• What is the cancellation notice, renewal date, minimum term, and post-termination access?
• What secure transfer method and file-size limits apply?
• Who owns field mapping, exception cleanup, reconciliation, and failed-record correction?
• Which historical records can the destination import as discrete data, and which become attached documents?
• What support is available during test conversion and go-live, including for interfaces and connected services?
• When and how will remaining copies be returned, retained, or destroyed under the governing agreements and applicable requirements?

HHS explains that a business associate generally can’t block a covered entity’s access to PHI it maintains on the entity’s behalf, and that the business associate agreement governs how PHI is returned at termination. HHS is also clear that the covered entity is still responsible for making sure its own PHI is available. In other words, the practice can’t hand that responsibility to the vendor. 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. You still have to verify that your particular product, module, information category and workflow are actually 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. It gives you reusable resources and implementation rules. What it doesn’t give you is a 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 you commit 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 the access itself. Is it patient-level or organization-level, read-only or write-enabled, sandbox or production? And are history, provenance and documents available at all?

Don’t assume a certified API has to be free. ASTP/ONC requires vendors to publish technical and business terms, fee information included, and its rules prohibit some fees while permitting others in defined circumstances. Read the vendor’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 leave you with a cash-flow problem if nobody’s clear on who owns claim submission, acknowledgments, remittance, posting and follow-up. 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 some other 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. Having a software account doesn’t prove each provider/payer transaction is active. For each one, record the submission date, confirmation, payer or trading-partner status, test result and production-ready date.
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, and name the system of record and the owner for each category.
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 find out a queue went missing.

Medicare’s official EDI guidance shows why this has to be explicit. 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 updated arrangements. It’s in the Medicare Claims Processing Manual, Chapter 24. Commercial and Medicaid processes vary, so check each payer’s current rules rather than applying Medicare’s steps everywhere.

Run A Test Conversion That Can Fail Safely

A test conversion isn’t done until practice owners can prove the priority data is accurate, usable, correctly permissioned and working in realistic workflows.

Build Test Cohorts Intentionally

Put the hard cases in on purpose: 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, documentation, signature, amendment and release workflows, run all the way through.
• 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 permitted, receive acknowledgments, work a rejection, and verify remittance/posting behavior.
• Operational and financial reports, reconciled to known source totals.
• An export from the new system, so you already know your next exit path.

Use severity levels and stop/go thresholds. A cosmetic label can wait for a post-launch fix. Missing signed notes, incorrect patient matching, broken prescribing, incorrect claim identity, inaccessible time-sensitive information or a material financial imbalance can’t. Any of those should trigger a hold unless an authorized leader accepts a documented safe workaround.

ASTP/ONC’s SAFER Guides emphasize contingency planning and the safe configuration, validation and maintenance of EHR systems and system-to-system APIs. They’re worth reading before you design your testing and downtime controls: SAFER Guides.

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

A go-live plan should say exactly when the old system stops taking each type of new work, when the final extracts run, when interfaces switch over, who verifies each milestone, and how staff record work if a critical function goes down. “Call the vendor” isn’t a rollback plan.

Minimum Cutover Controls

• A minute-by-minute or checkpoint-based cutover schedule with named owners and backups
• Final source freeze rules and an exception log for work created during the transition
• Secure final exports, checksums or file inventories where appropriate, and access logs
• Contact paths for both vendors, clearinghouses, interfaces, payment services, and internal leaders
• Downtime forms and instructions for scheduling, documentation, prescribing, billing, and urgent operational communication
• Go/no-go checkpoints and the person authorized to delay or reverse each part of launch
• A rollback time limit, data-reentry plan, and rule for reconciling work completed in either system
• Daily stabilization huddles, issue severity, response owner, next update time, and closure evidence

Not every migration can be rolled back in one motion. You might pause interfaces, extend read-only access, revert a scheduling workflow, or temporarily submit claims from the old system while clinical documentation stays in the new one. If a split state is possible, define it before go-live, and name the source of truth for every workflow.

Staff Readiness Is Evidence, Not Attendance

Sitting through training doesn’t prove anyone’s ready. Require role-based practice instead: schedulers handle exceptions, clinicians document and amend, billers work acknowledgments, managers reconcile, and administrators manage permissions and downtime. Then write down who passed and who still needs support.

What Practitioners Say And How To Use Anecdotes Responsibly

Reddit threads are anecdotes. They aren’t evidence of how a vendor performs across the board, but they do surface good questions to test. In one r/therapists discussion about changing EHRs with a large caseload, participants described the downloads, imports, cleanup, retraining and billing continuity work involved. In another EHR-transfer discussion, the original poster worried about future schedules and keeping exported records secure.

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

How AdvanceAPractice Can Help When The Timeline Is Tight Or The Practice Is Large

A compressed timeline or a larger practice turns into a coordination problem well before it’s a software problem. Every added location, clinician, billing combination, interface, form and piece of open work is another place where one missed dependency can hit patients, staff or cash flow. AdvanceAPractice adds experienced operational capacity. The practice keeps ownership of the project.

We can inventory the current environment quickly, turn vendor promises into a field-level conversion manifest, find the high-risk gaps, and put a single owner and an acceptance test on every item. We coordinate the written questions and working sessions with the outgoing EHR, the incoming EHR, the clearinghouse, the billing team and the other vendors involved. What we can’t do is guarantee how fast a third party responds or finishes its work. We make the dependencies, requests, dates, decisions and escalation paths visible, so the practice can act sooner.

On the data side, we can organize test extracts, mapping decisions, test conversions, exception cleanup, and both count-based and sample-based validation. Revenue cycle gets its own track. There we map the claim and remittance pathways, build the payer/provider/location cutover matrix, assign old A/R and define daily reconciliation. For staff readiness, we translate configuration into role-based scenarios, collect test evidence, track open issues, and prepare downtime instructions practical enough to use.

When Command Suite is part of the engagement, the practice sees the project as a working operating system instead of a pile of email threads. Every conversion object, vendor dependency, test result, owner, next action, due date, risk and decision sits in one controlled view. What you get at the end is a documented go-live plan with checkpoints, sign-offs, contingency steps and post-launch ownership. It isn’t a generic recommendation deck.

Our team brings hands-on behavioral health operations, billing, credentialing, workflow and systems experience. Software can organize evidence and watch tasks. People with experience make the mapping decisions, push back on assumptions, coordinate the parties, validate results, and help the practice decide whether it’s safe to go.

Frequently Asked Questions

How Long Does It Take To Switch EHRs?

There’s no responsible universal timeline. How long it takes 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 times. Build the date backward from confirmed dependencies and acceptance criteria. Don’t pick it from a sales estimate.

Does FHIR Mean All Of Our Data Will Move Automatically?

No. FHIR is a standard for exchanging healthcare information, but a particular implementation may expose only certain resources, fields, operations or access scopes. It might not cover every document, task, schedule rule, audit detail, custom field, claim artifact or financial ledger item your practice uses. That’s why you compare the source and destination capabilities against a field-level conversion manifest.

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

Often, yes. Read-only access is useful while the practice validates converted information, works old receivables, meets retention obligations and handles exceptions. How long you keep it, and how, depends on the contract, record-retention requirements, cost, security and what actually exported successfully. Confirm those terms before you cancel, and get legal advice where you need it.

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

Run the revenue cycle cutover as its own explicit project. Decide which system owns each charge and date-of-service range, verify payer and clearinghouse routing, protect 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 named owner until it’s closed.

What Should We Test Before EHR Go-Live?

Test representative and high-risk records, plus the complete workflows staff will actually perform: identity matching, scheduling, intake, documentation, signatures, permissions, prescribing and interfaces when in scope, claims, acknowledgments, remittance, posting, reporting, downtime, and export from the new system. Then reconcile counts and financial totals, log the exceptions, and don’t go live without owner sign-off.

When Should A Practice Bring In Outside Migration Help?

Bring in experienced help when the deadline is compressed, the practice has multiple locations or many roles, billing combinations are complex, open A/R is material, interfaces or custom workflows are involved, internal leaders can’t step away from daily work, or neither vendor owns validation across the whole process. Whoever you bring in should deliver working controls and finished tasks. A diagnosis on its own isn’t enough.