The sunset notice: extracting your practice from a dying vendor

Your data is yours: what the vendor owes you

Your patient records belong to your practice, not to the software company holding them. An EHR vendor is a business associate — it creates, receives, maintains, and transmits PHI on your behalf under a signed agreement, and that agreement is where you look first. A compliant business-associate agreement obligates the vendor, at termination, to return or destroy the PHI it holds and to help you get a usable copy 1Ref 1HHS Office for Civil Rights (2026).Business Associates.That an EHR vendor is a business associate whose BAA must govern return or destruction of PHI at termination and the practice's right to a usable copy..

Pull the contract before you call anyone. The clauses that matter now: data return or destruction on termination, your right to an export, any fee for it, and the format the vendor will provide. If those clauses are thin, that is the leverage problem you are solving — a bankruptcy trustee or an acquiring company inherits the BAA's duties, so the obligation survives the vendor's collapse. Put your export request in writing and date it.

The first two weeks: your sequence

Treat the sunset notice like a countdown and work it in order. The single worst outcome is a shutdown date arriving with your records still trapped inside. So: read the notice for the hard cutoff, request a full export immediately, confirm what format you will get, then plan the ehr migration around a verified copy in hand — never around a promise. Everything else waits behind securing the data.

• Day 1 — Read the cutoff. Find the exact date access ends and whether read-only access continues after it.
• Day 1 — Request the export in writing. Ask for a complete, standard-format copy (C-CDA / FHIR / USCDI) plus attachments, images, and the audit trail.
• Week 1 — Escalate if the vendor stalls. A stalled export is an escalation, not a wait; put deadlines in writing and copy your practice email of record.
• Week 1 — Plan for downtime. Assume a gap between systems and prepare paper or PDF workflows so you can still see patients during the switch.
• Week 2 — Migrate against a verified copy, then decommission old access only after you confirm completeness.

Exporting a complete, auditable record

A copy that opens is not the same as a copy you can defend in an audit. Export in a standardized clinical format — C-CDA, FHIR, or the USCDI data set — rather than a flat PDF dump, so the next system can ingest structured data instead of forcing you to re-key it. Then verify completeness against your own patient count and encounter count before you let the old system go dark.

Authentication is the part solos forget. Medicare requires that services be authenticated by a handwritten or electronic signature, and it spells out what counts and how an attestation can cure a missing one in review 2Ref 2Centers for Medicare & Medicaid Services (2023).Complying with Medicare Signature Requirements.That services must be authenticated by handwritten or electronic signature, and that an attestation can cure a missing signature in review — so an export must preserve authentication.. If your export strips the signer, date, or credential from notes, you have created an audit gap; capture the audit trail and signature metadata in the export, or generate signed attestations for anything the migration flattens. Save a read-only archive of the original record as it existed at export.

You are an actor under the information-blocking rule too

During a chaotic migration, it is tempting to tell a patient their records are 'unavailable right now.' Be careful: the 21st Century Cures Act prohibits practices from interfering with the access, exchange, or use of electronic health information, and clinicians are actors under that rule, not bystanders 3Ref 3Office of the National Coordinator / ASTP (2026).Information Blocking.That the 21st Century Cures Act prohibits interfering with access to electronic health information, that clinicians are actors, and that eight defined exceptions apply.. A vendor transition is not a blanket excuse to withhold access — the rule has eight defined exceptions, and 'we are switching systems' is not automatically one of them.

Keep answering patient access requests through the switch, even if it means a manual PDF while the new system comes online. If a genuine, temporary infeasibility applies, document which exception you are relying on and for how long — a dated, specific note, not a vague delay. The vendor's certified software is also an actor, which is added leverage when you demand your data out: holding your export hostage is its compliance problem, not just yours.

Protecting PHI in transit: security and breach

Moving an entire record set between vendors is exactly when PHI leaks — unencrypted drives, personal email, an open cloud bucket. The Security Rule requires administrative, physical, and technical safeguards for ePHI, scaled to your practice size and anchored in a risk analysis, and its contingency-plan standard is where the contingency plan for a system loss lives 4Ref 4HHS Office for Civil Rights (2026).Summary of the HIPAA Security Rule.That the Security Rule requires administrative, physical, and technical safeguards for ePHI scaled to practice size, including a contingency-plan standard, during a migration.. Encrypt every copy in motion and at rest, and log who touched the export.

If a copy is lost or exposed during the move — a misplaced drive, a wrong-address email — run the breach analysis. Notice to individuals is owed without unreasonable delay and no later than 60 days, with HHS on the annual log when fewer than 500 people are affected and promptly at 500 or more 5Ref 5HHS Office for Civil Rights (2026).Breach Notification Rule.The breach-notice timeline if PHI is lost or exposed in transit: individuals no later than 60 days, HHS annually if under 500, and the encryption safe harbor.. Data that was properly encrypted and stayed encrypted is not 'unsecured,' which is one more reason to encrypt the migration end to end.

Redo your risk analysis after you land

A new EHR is a new set of doors, so the risk analysis you did for the old system no longer describes your practice. Redo it once the migration settles. ONC and OCR publish a free Security Risk Assessment tool sized for small practices, which walks a solo through the administrative, physical, and technical questions the Security Rule expects and produces a report you can keep on file 6Ref 6Office of the National Coordinator / ASTP (2026).Security Risk Assessment Tool.That ONC/OCR publish a free Security Risk Assessment tool sized for small practices to redo the risk analysis after migrating to a new EHR.. Schedule it as part of go-live, not someday.

Update your policies to name the new vendor, sign a fresh business-associate agreement with it before any PHI moves, and revoke the old vendor's credentials and access the day you confirm your archive is complete. Keep the original export's read-only archive; it is your proof of the record's state at the moment you left.

Choosing the next EHR without locking in again

Pick the next system partly on how easily you could leave it, because you just learned what lock-in costs. Ask every candidate for its export terms in writing before you sign: what formats it produces, whether it charges for your own data, and how it handles a shutdown. Favor systems built on open standards and national exchange, so your data stays portable rather than trapped in a proprietary schema.

TEFCA sets a national floor for network-to-network exchange through QHINs, so an EHR that participates in modern interoperability keeps your data reachable and movable rather than siloed 7Ref 7Office of the National Coordinator / ASTP (2026).TEFCA — Office of the National Coordinator for Health Information Technology.That TEFCA sets a national floor for network-to-network exchange via QHINs, informing choice of an interoperable next EHR that keeps data portable.. Read the contract's termination and data-return clauses the way you now wish you had read the last one — that section, not the feature list, is what protects you the next time a vendor fails. Build a simple continuity plan for the switch so the next transition is a task, not a crisis.