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

An EHR switch is four connected projects

Practices often receive a polished implementation schedule from the incoming vendor. That schedule may cover account configuration, training, and the vendor’s import. It may not cover the practice’s open claims, clearinghouse relationships, payer-specific enrollments, unposted remittances, unscheduled referrals, portal transition, custom reports, or the exceptions that do not fit the import template.

The size of the practice changes the coordination burden, not the standard. A solo clinician and a multisite group both need a written definition of what “successfully moved” means.

Build the conversion manifest before you set the cutover date

A conversion manifest names each information category, its source, destination format, responsible person, and acceptance test. “Move all patient data” is not a manifest. Go down to the field and document type when the risk warrants it.

For every row, record whether the result is discrete usable data, a viewable document, a searchable archive, or only temporary legacy access. Assign source, destination, and exception counts plus an owner, due date, and sign-off.

Read the old and new contracts as operational documents

Before cancellation, review 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; use qualified counsel for legal conclusions.

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 may not block a covered entity’s access to PHI it maintains on the entity’s behalf, and that the business associate agreement governs return of PHI at termination. HHS also emphasizes that the covered entity remains responsible for ensuring its own PHI is available. Review 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 capabilities in electronic, computable formats, with documentation of the format. That does not remove the need to verify whether the particular product, module, information category, and customer workflow are covered. See the official EHI export criterion.

API and FHIR access can help—but neither means “everything migrates”

FHIR is an HL7 standard for exchanging healthcare information electronically. It provides reusable resources and implementation rules; it is not a promise that every operational, clinical, scheduling, or financial object in a specific EHR is exposed, writable, or accepted by another EHR. The authoritative starting point is the HL7 FHIR overview.

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

Do not assume a certified API must be free. ASTP/ONC requires publication of technical and business terms, including fee information; its rules prohibit some fees and permit others in defined circumstances. Review the vendor’s terms and the official API Condition and Maintenance of Certification guidance.

Treat revenue-cycle cutover as a separate controlled launch

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

1. Choose the ownership rule. Define which system owns charges and claims by date of service, entry date, payer, or another unambiguous rule. Publish examples for late notes, corrected claims, secondary claims, and retroactive eligibility.
2. Inventory every connection. Include eligibility, claim submission, claim acknowledgments, claim status, attachments, ERA delivery, EFT destination, statements, card processing, prior authorization, and any payer portal or direct connection.
3. Confirm enrollments and routing. A software account does not prove that each provider/payer transaction is active. Record 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. Name the system of record and 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. Do not wait for month-end to discover a missing queue.

Medicare’s official EDI guidance shows why this must be explicit: provider, clearinghouse, and billing-service relationships are governed through EDI enrollment and trading-partner processes, and changes in billing agents or clearinghouses can require notice or updated arrangements. See the Medicare Claims Processing Manual, Chapter 24. Commercial and Medicaid processes vary, so verify each payer’s current rules instead of applying Medicare steps universally.

Run a test conversion that can fail safely

A test conversion is complete only when practice owners can prove priority data is accurate, usable, permissioned correctly, and operational in realistic workflows.

Build test cohorts intentionally

Include 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 the work, not just the screen

• Register or locate a patient without creating a duplicate.
• Schedule, reschedule, cancel, and complete an appointment.
• Complete intake, consent, documentation, signature, amendment, and release workflows.
• Verify role-based access and the absence of access where it should not exist.
• Check prescriptions, labs, telehealth, fax, portal, reminders, and interfaces that are in scope.
• Create a charge, submit a test claim where permitted, receive acknowledgments, work a rejection, and verify remittance/posting behavior.
• Run operational and financial reports and reconcile them to known source totals.
• Export a record from the new system so the practice understands its next exit path.

Use severity levels and stop/go thresholds. A cosmetic label may be accepted for post-launch correction. Missing signed notes, incorrect patient matching, broken prescribing, incorrect claim identity, inaccessible time-sensitive information, or a material financial imbalance 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 are a useful source for designing 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 receiving each type of new work, when the final extracts run, when interfaces change, who verifies each milestone, and how staff record work if a critical function is unavailable. “Call the vendor” is not 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. A practice may pause interfaces, extend read-only access, revert a scheduling workflow, or temporarily submit claims from the prior system while clinical documentation remains in the new one. If a split state is possible, define it before go-live and specify the source of truth for every workflow.

Staff readiness is evidence, not attendance

Training attendance does not 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 discussions are anecdotes, not evidence of universal vendor performance. They can still surface questions to test. In one r/therapists discussion about changing EHRs with a large caseload, participants described work involving downloads, imports, cleanup, retraining, and billing continuity. In another EHR-transfer discussion, the original poster worried about future schedules and secure retention of exported records.

Use anecdotes to build demonstrations and contract questions, not to make purchasing claims. Ask a vendor to show your exact future-appointment import, note format, billing-history treatment, portal experience, and exception report with representative test data.

How AdvanceAPractice can help when the timeline is tight or the practice is large

Compressed timelines and larger practices create a coordination problem before a software problem. More locations, clinicians, billing combinations, interfaces, forms, and open work mean more ways for one missed dependency to affect patients, staff, or cash flow. AdvanceAPractice adds experienced operational capacity without taking project ownership away from the practice.

We can rapidly inventory the current environment, turn vendor promises into a field-level conversion manifest, identify the high-risk gaps, and establish a single owner and acceptance test for each item. We coordinate written questions and working sessions with the outgoing EHR, incoming EHR, clearinghouse, billing team, and relevant vendors. We do not guarantee how quickly a third party will respond or complete its work; we make dependencies, requests, dates, decisions, and escalation paths visible so the practice can act sooner.

For data conversion, we can organize test extracts, mapping decisions, test conversions, exception cleanup, and count-based and sample-based validation. For revenue cycle, we can 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 can translate configuration into role-based scenarios, collect test evidence, track open issues, and prepare practical downtime instructions.

When Command Suite is included in the engagement, the practice can see the project as a working operating system rather than a collection of email threads: every conversion object, vendor dependency, test result, owner, next action, due date, risk, and decision is tracked in one controlled view. The final product is a documented go-live plan with checkpoints, sign-offs, contingency steps, and post-launch ownership—not a generic recommendation deck.

Our team brings hands-on behavioral-health operations, billing, credentialing, workflow, and systems experience. Technology can organize evidence and monitor tasks, but experienced people make mapping decisions, challenge assumptions, coordinate the parties, validate results, and help the practice decide whether it is safe to proceed.

Frequently asked questions

How long does it take to switch EHRs?

There is no responsible universal timeline. The duration 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 rather than choosing a date from a sales estimate alone.

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 may not cover every document, task, schedule rule, audit detail, custom field, claim artifact, or financial ledger item your practice uses. Compare the source and destination capabilities against a field-level conversion manifest.

Should we keep read-only access to the old EHR?

Read-only access is often operationally useful while the practice validates converted information, resolves old receivables, satisfies retention obligations, and handles exceptions. The correct duration and access method depend on the contract, record-retention requirements, cost, security, and what was successfully exported. Confirm those terms before cancellation and obtain legal advice where needed.

How do we reduce cash-flow disruption during the switch?

Run an explicit revenue-cycle cutover. Define 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 daily. Keep unresolved items in a named-owner worklist until they are closed.

What should we test before EHR go-live?

Test representative and high-risk records plus the complete workflows staff will 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. Reconcile counts and financial totals, record exceptions, and require owner sign-off.

When should a practice bring in outside migration help?

Consider 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 cannot pause their daily work, or neither vendor owns end-to-end validation. The outside team should produce concrete controls and completed work, not only a diagnosis.