Telehealth Patient Migration Checklist for Existing Brands

What belongs in the migration scope?

Begin with a list of what the new operation must know on the first day. Patient identity is only one category. The receiving team may also need histories, allergies, documents, prior encounters, consents, current clinical tasks, pharmacy clarifications, delivery issues, subscription states and support conversations. Decide which information is necessary and how it will be used.

Describe the scope in business language before discussing file formats. For example, an active patient may mean someone with an active subscription, a recent encounter, an unresolved order or scheduled follow-up. Those are different groups. Define them separately so the project does not hide clinical work inside a billing status.

TEHR was built by operators behind DudeMeds, Peptiders, TellyMeds and FansMeds who migrated thousands of their own patients. That experience supports a practical discussion of the work; it does not mean every source system has identical export capabilities or that every migration has the same duration. The TEHR migration overview is the starting point for scoping your case.

Who may provide, receive and use the records?

Identify the source custodian, the receiving care organization and the technology or service providers handling the information. HHS explains that business-associate contracts define permitted PHI handling and related safeguards. The correct agreements should match the actual data flow and responsibilities.

Do not assume that every transfer requires the same patient authorization or that none does. HHS describes treatment, payment and operations permissions with different conditions. The purpose, parties, state law and record type matter. A marketing list is not automatically a treatment disclosure simply because the business also provides access to care.

Record the approved basis for each major data set and any restrictions that travel with it. Determine who handles patient access requests during the transition. If the old vendor relationship is ending, align the export, continuing access and termination provisions before scheduling a cutoff.

How should the team inventory and map the source?

For each field, record its meaning, allowed values and destination. A status called complete can mean an encounter finished in one system and a shipment delivered in another. Do not map labels solely because the words match. Resolve the meaning with the teams who use the data.

Keep the original source identifier and provenance where appropriate. They help trace an issue back to its origin and avoid presenting a historical record as newly created. Preserve unknown values as unknown instead of filling gaps with convenient defaults.

Which patient groups deserve special attention?

Group patients by the work that must continue, not only by their marketing segment. Useful groups include people awaiting an initial evaluation, active patients with an upcoming review, patients with an unresolved prescription clarification, those with an order in transit, and those who have canceled but still need access to historical records.

Assign an owner and transition rule to each group. A patient awaiting a pharmacy response should not be routed through a brand-new sales funnel. A person who canceled should not be automatically reactivated because the receiving system treats all imported accounts as active.

Review specially protected records separately. HHS explains that 42 CFR Part 2 adds requirements for qualifying substance-use-disorder records and some recipients. Preserve applicable restrictions and consent information rather than treating every clinical attachment as interchangeable.

Controlled-medication programs also need specific continuity planning. The Ryan Haight guide explains why importing a chart does not itself authorize a new prescription or establish every required encounter.

What should a pilot migration prove?

Select cases that represent complexity, not merely the easiest accounts. Include a patient with multiple documents, a corrected identity, an active subscription, a paused subscription, a pending pharmacy task, an upcoming appointment and a cancellation. Use the smallest representative set that can expose the important mapping failures.

Check both aggregate results and individual records. A matching row count does not prove that dates, units, authors, statuses or attachments were mapped correctly. Review the records as the receiving support and clinical teams will see them. A technically valid import can still be unusable if essential context is buried or mislabeled.

Document expected results before the test. Otherwise, the team may accept whatever the system produces. Record failures, fix the mapping and repeat the affected cases. The aim is not a ceremonial test report; it is confidence that the next action for each representative patient remains clear.

Also test permissions. Confirm that each role can access what it needs and cannot see information outside its responsibilities. A successful transfer should not expand access simply because the destination makes sharing easier.

How should billing and subscriptions be transitioned?

Treat the financial state as a separate reconciliation project. Identify renewal dates, amounts, cancellation status, credits, refunds, failed payments and what each plan includes. Confirm how the payment arrangement can transition; do not assume payment credentials can be copied like ordinary profile fields.

Make duplicate-charge prevention explicit. Establish which system is allowed to initiate a charge during the transition and when that authority changes. Test a renewal near the cutoff, a paused plan and a recently canceled plan. A good migration does not rely on support discovering duplicate charges after customers complain.

Keep commercial subscription status separate from clinical eligibility. Paying for a plan does not guarantee a prescription. Likewise, a clinical decision should not silently rewrite the billing agreement. The patient-facing explanation should make the relationship understandable.

Review TEHR pricing and implementation scope with these scenarios. Ask which billing tasks are included, which payment-provider steps remain, and who reconciles exceptions before the old process ends.

What should patients be told?

Explain the practical changes: where to sign in, what they need to do, how upcoming care is handled, where support is available and whether any terms or care entities change. Use direct language and a recognizable sender. Avoid implying that patients must purchase a new plan simply to access an existing record.

Sequence communications around the actual rollout. A message sent too early may direct people to an account that is not ready. A message sent too late can make a legitimate change look suspicious. Coordinate the timing with the receiving system and support capacity.

Prepare answers for common exceptions. What if an invitation does not arrive, an address is outdated, a patient has two accounts, an appointment is already booked or an order is in transit? Give support a clear resolution path instead of asking patients to repeat the same story to multiple organizations.

Preserve the distinction between a technology transition and a medical decision. Patients should know who handles care questions and when they need to contact that team. Brand continuity should make the change easier to understand, not obscure the responsible clinical entity.

What happens during cutover and reconciliation?

Define the cutoff, the final source export and the way new changes are captured during the transition. If the old system remains active for a period, explain how updates will be reconciled. A migration window without a rule for late changes can lose appointments, messages or cancellations even when the main import succeeds.

Use a cutover checklist with named owners. Confirm patient access, staff access, open tasks, scheduled appointments, active orders, billing authority and escalation channels. Record unresolved exceptions with a next action rather than hiding them inside a global complete status.

Maintain a rollback or containment plan appropriate to the move. That may mean delaying a cohort, retaining a source workflow for specific cases or pausing a particular automated action. Define the trigger before launch so the team can act quickly without debating basic responsibilities during an incident.

The TEHR platform discussion should include how these handoffs are supported, not just how the imported patient list looks on screen.

When can the old system be retired?

Retirement follows reconciliation, access planning and applicable retention requirements. HHS states that the HIPAA Privacy Rule does not set a general medical-record retention period; state requirements and other obligations must be considered. Do not delete source material just because the import job finished.

Confirm who can retrieve historical records, respond to corrections and support any outstanding clinical or financial issue. Document the archive location, permissions and retrieval process. An archive nobody can practically use is not an adequate operational answer.

Close the project with a clear exception register and ownership transfer. The receiving team should understand which issues remain and how they will be resolved. For related planning, explore the telehealth brand operating model and the TEHR resource hub.

What else should you know?