An OpenLoop-to-TEHR migration should begin by identifying which technology, clinical and operational services your current arrangement provides, then planning their transition separately. TEHR publishes this destination guide for operators considering its platform; the objective is continuity and a tested handoff, not an assumption that every OpenLoop customer uses the same configuration.

TEHR can start migration work as soon as your data is available. The complete cutover is coordinated around validation and continuity of care. The under-24-hour launch capability for new brands is separate from a patient migration timeline.

Why does the existing OpenLoop configuration matter?

As of October 22, 2026, OpenLoop describes both Launchpad and existing-stack integration, including branded patient and commercial workflows. Its pharmacy and diagnostics page describes connected prescribing, fulfillment and laboratory services. It is therefore inaccurate to assume every migration is simply replacing a clinician network.

List the services your business actually uses and the entities responsible for them. Separate source software from clinical care and external systems you intend to retain. A custom storefront connected to OpenLoop can create a different project from a brand using a turnkey patient experience.

Review TEHR versus OpenLoop and OpenLoop alternatives before finalizing the destination. Define the reason for the move in operational terms. Clearer commercial scope, a different workflow or a preferred support arrangement can be legitimate goals without claiming the current provider lacks documented capabilities.

How do you map the current care operation?

Create a service map from the patient’s first intake through evaluation, prescribing when appropriate, fulfillment and follow-up. For each step, identify the software, clinical organization, support team and relevant partner. Mark which responsibilities will move, remain or overlap temporarily.

Inventory patients by current care state, not only by account status. Someone awaiting an evaluation needs different handling from a person with a completed episode of care. Pending laboratory results, follow-up requests and refill needs can create time-sensitive work that does not appear in a simple list of active customers.

The migration checklist provides a broader inventory framework. Add a named owner for every open clinical or fulfillment item. The destination team should be able to answer what happens next for a representative patient before a large cohort moves. That is more useful than beginning with a target date based only on record volume.

What information should the data crosswalk preserve?

A crosswalk connects source identifiers, records and statuses to the destination. Preserve relationships between the patient, encounter, prescription, laboratory order and commercial order where those data are available and lawfully transferable. A flat contact export cannot represent the full history of an active care program.

Record or workflowContinuity question
Patient identityHow are source and destination accounts matched and ambiguous cases reviewed?
Clinical historyWhich notes, attachments, consents and results are accessible to the receiving team?
Pending evaluationWho completes the work and communicates with the patient?
Prescriptions and ordersWhich items remain with the existing pharmacy workflow?
Follow-up and renewalsWhat is due next, and which team is responsible?

Keep a record of excluded or unavailable fields. An omission should become an explicit operational decision or remediation task, rather than a silent gap that the support team discovers after launch.

How should the receiving clinical team prepare?

The receiving clinical organization should review the intended programs, patient population and available records. It should define what additional evaluation or information is needed and how patients with unresolved issues will be handled. The brand’s migration deadline should not determine clinical decisions.

An existing prescription history or recurring subscription does not automatically authorize a new provider to continue treatment. The federal temporary telemedicine rule, for example, preserves requirements for controlled prescribing; data transfer itself is not prescribing authority.

Agree on a clinical transition process before moving active patients. Some may need to finish a current step with the existing care team, while others can enter the destination workflow after the appropriate review. Use the TEHR platform demonstration to show how those states are represented. A clear account of responsibility is essential when both arrangements are temporarily involved.

How do pharmacy and laboratory work affect the cutover?

Separate completed historical activity from open service obligations. A shipped order, a prescription awaiting dispensing, a specimen in transit and a pending result each have different next steps. The migration plan should not overwrite them with a generic destination status.

Confirm the routing of new activity and the handling of work already in progress. If a pharmacy or laboratory relationship remains in place, determine how the new workflow will identify the correct patient and order. If a partner changes, define the transition with the clinical and operational teams rather than assuming a data import changes the underlying service agreement.

Keep patients informed about the instructions that apply to them. A new portal does not necessarily mean an existing kit should be registered differently or a pending shipment has moved to another pharmacy. The TEHR migration overview should lead to a project-specific plan that preserves clarity around these physical and clinical processes.

What should happen to payments and subscriptions?

Build a commercial ledger that is separate from, but linked to, the clinical transition plan. Record active offers, subscription states, expected renewal dates, outstanding refunds and unresolved disputes. Identify which system is responsible for each future charge during the overlap period.

Confirm payment-token portability and merchant-account arrangements with the relevant providers. A patient can be clinically ready for the destination while still needing to update a payment method. Conversely, a transferred billing record does not establish clinical readiness. Track those states independently so one does not imply the other.

TEHR uses a flat platform subscription plus a flat transaction fee and 0% revenue share. Contact TEHR for a scoped quote and compare it with your actual existing terms. Pricing and the cost guide help structure that comparison. Do not assume an OpenLoop revenue-share percentage or savings amount that is not supported by your contract.

Which privacy and access decisions must be resolved?

Establish the lawful basis, recipient and purpose for each dataset. HHS business-associate guidance describes responsibilities that can apply to permitted handling and safeguards. The actual roles and agreements matter more than a generic assertion that both systems support healthcare.

Identify any specially protected records or restrictions and preserve the relevant information with the transfer. Limit access during migration to authorized participants and document what they receive. Use secure channels agreed by the responsible organizations; ordinary sales email is not an appropriate substitute for a transfer process.

Plan continuing access to historical information and patient requests. A cutover changes the active workflow, but it does not automatically end retention or access responsibilities. Ask who handles a patient seeking an older record and how staff can direct that request after the source platform is no longer the everyday operating system.

How should parallel operation and the pilot work?

Choose a pilot cohort that reflects the real program mix and includes meaningful exceptions. Test identity matching, historical records, active care states, billing ownership and patient messages. A clean import count is only one check; the team also needs to validate that the records are usable in the destination workflow.

Define the boundary between systems during parallel operation. For example, new enrollments may enter the destination while selected existing activity completes in the source arrangement. Whatever the design, make it explicit enough that support, finance and clinical teams can identify the responsible workflow without improvising.

Keep a reconciliation log and a release decision for each cohort. If a material issue appears, pause the next cohort rather than allowing the discrepancy to expand. The launch planning framework provides useful readiness concepts, but a migration schedule must reflect the additional dependencies of existing care.

What should determine the final timeline and success criteria?

The reviewed OpenLoop pages describe integration options but do not establish a universal outbound patient-migration format or service-level deadline. Obtain the actual export scope, contract terms and transition assistance for your arrangement. Missing public detail should remain a question, not be converted into a claim of lock-in.

Define success in measurable operating terms: required records reconciled, unresolved activity assigned, patient access working, renewals owned by the correct system and support teams trained. Include a stabilization period for delayed messages, late results and customer questions that appear after the main cutover.

TEHR’s operator experience includes migrating thousands of its own patients. Apply that experience through a scoped plan rather than treating it as a promise that every project takes the same time. Review provider-network options if the clinical arrangement is central to your decision. The destination should support a coherent service after the transition, not just an imported database.

What else should you know?

Is OpenLoop only a provider network?

No. Its current public platform materials describe turnkey and integration options with broader patient and commercial workflows. Your migration scope should reflect the services your business actually uses. Avoid relying on an older or narrower description when estimating what needs to move.

Can we retain parts of our current stack?

Potentially. Identify the systems you want to retain and the interfaces they need with TEHR. Keeping a storefront or external service can preserve useful assets, but the project must define how identifiers, statuses, payments and support responsibilities connect to the destination.

Will patients automatically continue the same treatment?

No automatic clinical outcome should be promised. The receiving clinical organization determines what records, evaluation and other steps are required. Migration can preserve useful history and improve continuity, but it does not replace independent judgment or applicable prescribing requirements.

Can we move everyone on one day?

Only if the scoped project and readiness evidence support that approach. A staged cutover may be more appropriate when records, programs or open service obligations vary. The decision should follow the pilot and reconciliation results, not a desire for a simpler announcement.

Does this page establish OpenLoop’s export terms?

No. Public product information does not determine your contract or account-specific export process. Request the current terms and available formats directly. This guide explains how to plan the destination and the questions to resolve before transferring data or changing workflows.

What should a migration kickoff produce?

A service map, data inventory, ownership matrix, secure transfer plan, clinical continuity plan and milestone schedule. It should also identify unresolved questions and who will answer them. Those outputs make the project reviewable before large-scale patient or billing changes occur.

Which sources support this guide?

Public sources reviewed as of 2026-10-22. Vendor statements describe the vendor’s published offering; your contract determines actual scope.

Build around your operation.

Discuss your categories, patient experience and costs with TEHR.