MRR software switching guide

Switching MRR software? Start here.

Confirm your deadline, keep upcoming reviews on track, and make sure the history you rely on is still usable after the move. Then test the replacement with the kind of work you actually do.

This guide is for independent consultant pharmacists and consultant pharmacy teams replacing an MRR system because support is ending, access may change, or the current process no longer works for the practice.

Build my switching plan Read the transition guide
Question 2 of 5Target month

What month are you aiming to go live?

The exact day is not important. Choose a month and we’ll move straight on.

or

Your plan opens right away. Add it to an account later if you want to return by email.

Before you book demos

Do these five things before you compare products.

First, get control of the deadline and the current workflow. You will ask better questions while the outgoing vendor can still give you useful answers.

  1. Confirm your actual deadline

    Ask the vendor to put each date in writing: when updates stop, when support ends, and when you lose access. The date in a general announcement may not be the date in your contract.

  2. Put one person in charge

    Choose one person to track dates, vendor answers, open problems, and final decisions. In a small practice, that may be you-but write it down anyway.

  3. Ask for a sample export now

    Do not wait until the last month. Get a sample export, field list, report archive, attachment list, and conversion instructions while the current vendor is still available to help.

  4. Plan for reviews during the switch

    Decide how you will complete reviews, send urgent findings, deliver facility reports, and track responses if the old or new system is unavailable.

  5. Know what the current process costs

    Record your monthly MRR volume and the time spent preparing, documenting, following up, reporting, and looking up history. Use those numbers when you compare price and time-saving claims.

Price the work you do now

Know your current labor cost before you set a software budget.

Use the calculator to estimate the monthly time spent preparing MRRs, documenting, following up, reporting, and finding history. You can then compare that number with the time a vendor says its system may save.

This is a planning estimate, not a promise of savings or a complete ROI calculation.

1

Value your current timeUse loaded labor cost, target consulting rate, or owner-time value.

2

Find the repeat workSeparate clinical judgment from searching, re-keying, assembling reports, and rebuilding status.

3

Check the vendor's claimAsk each finalist to show which steps get shorter and which stay the same.

Calculate MRR time and labor value

Read the fine print

Ask what “sunset” means for your account.

Sales, updates, support, and access can end on different dates. Ask the vendor which dates apply to your version and contract, then plan around the earliest deadline that could interrupt your work.

Software lifecycle terms and the question each one leaves open
MilestoneWhat it usually meansWhat to ask
End of saleNew licenses or subscriptions stop being sold.Can existing customers add users, facilities, modules, or capacity?
End of maintenanceRoutine fixes or product improvements stop.Will defects, regulatory changes, and compatibility problems still be addressed?
End of security supportThe vendor no longer commits to security patches or vulnerability remediation.What is the last supported version and its final patch date?
End of technical supportHelp desk, troubleshooting, or implementation assistance ends or narrows.Which support channels, response targets, and transition services remain?
Service shutdownHosted access ends, which may also end access to data and reports.What remains available after shutdown, in what format, for how long, and at what cost?

SourcesAssistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

Step-by-step plan

Six stages from the first notice to closing the old system.

Your dates will vary. The order should not: write requirements before you sign, compare the converted records before go-live, and check live work before you close the old system.

  1. Immediately

    Get the dates and responsibilities straight

    Turn the notice into a short list of confirmed dates, named contacts, and decisions you need to make.

    • Save the notice, contract, amendments, invoices, BAA, support terms, and current technical requirements.
    • Find out who controls the license, database, backups, interfaces, hosting account, encryption keys, and vendor relationship.
    • Work backward from the last day of access. Set dates for contract notice, export requests, test conversion, go-live, and a possible rollback.
    Before you move onOne page showing every deadline, who confirmed it, and who owns the next step.

    SourcesAssistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

  2. First week

    List the work and data you cannot lose

    Decide what must move into the new system, what can stay in a secure archive, and how reviews will continue during the change.

    • Walk through a normal review from data receipt to facility report and follow-up. Include admission, interim, urgent, correction, and covering-pharmacist work.
    • Find every place ePHI is stored: the application, local databases, laptops, shared drives, report folders, backups, email, portals, and vendor systems.
    • Separate data that came from the pharmacy or facility from the reviews, recommendations, and follow-up your practice created.
    Before you move onA list of each data set, where it lives, who owns it, how far back it goes, and where it will go after the switch.

    SourcesU.S. Department of Health and Human Services, Office for Civil RightsElectronic Code of Federal Regulations

  3. Before shortlisting

    Write requirements from a real review

    Use the switch to cut unnecessary repeat work without losing steps that protect residents, facilities, or your practice.

    • Mark each step in your current process: keep it, improve it, replace it, or stop doing it.
    • Write down the minimum you need for data intake, review history, recommendations, responses, psychotropic work, reports, user access, export, and support.
    • Use your own labor cost, consulting rate, or value of owner time in the labor calculator instead of relying on the default.
    Before you move onA ranked requirements list and a realistic estimate of what the current process costs in time.

    SourcesAssistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

  4. Before contracting

    Give every finalist the same test

    Compare what each system can actually do for your workflow, migration, security, support, and eventual exit.

    • Use synthetic resident data; do not place real PHI into an uncontracted demo environment.
    • Include the messy parts: a duplicate resident, a missing field, an edited recommendation, a correction, a covering pharmacist, and an export request.
    • For every requirement, mark what you saw, what the contract promises, what is unavailable, and what still needs an answer.
    Before you move onA completed demo checklist, clear security responsibilities, a full cost estimate, and a sample export you can inspect.

    SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil RightsAssistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

  5. Before go-live

    Test the conversion before you commit

    Make sure the new system is ready for real work and that missing or changed records are visible before you leave the old process.

    • Compare record counts by facility and record type, then check a useful sample field by field.
    • Run key reports, check user permissions, find open work, and look up older history in the replacement system.
    • Practice the cutover and downtime process. Agree in advance on what would stop the go-live and send you back to the old system.
    Before you move onA signed comparison, a list of unresolved problems, clear go/no-go rules, and a rollback plan the team has walked through.

    SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil RightsAssistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

  6. After cutover

    Check the first live cycles before closing the old system

    Confirm that day-to-day work and history are available and accurate before old access, servers, or backups are removed.

    • Check the first review cycles for each facility, including urgent findings, corrections, covering-user access, reports, responses, and history lookups.
    • Resolve open problems, remove accounts and connections you no longer need, update the risk analysis, and keep a record of the final decisions.
    • Follow the applicable contracts and retention rules when you return, archive, or destroy data and dispose of old media.
    Before you move onA signed post-live check, a record of what happened to the old data, updated procedures, and a named owner for any archive.

    SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil Rights

Before you request the export

Decide what you need to keep and how you will check it.

PDFs preserve readable reports. A structured export gives you data that can be searched or moved into another system. You may need both. You probably do not need every internal field, but you should know what will be left behind before you agree.

Residents and facilities

Stable identifiers, active/inactive status, assignments, locations, census context, and source-system identifiers.

Acceptance testCounts by facility match; duplicate, merged, discharged, and moved residents are explained.

Reviews and clinical history

Review type, service date, author, findings, notes, medication context, supporting dates, and completion state.

Acceptance testA sample across years, facilities, review types, and authors is readable and correctly related.

Recommendations and outcomes

Recipient, priority, category, original wording, response, rationale, status changes, follow-up, and timestamps.

Acceptance testOpen work remains open; closed work keeps its chronology; no status is silently remapped.

Reports, attachments, and released artifacts

Facility reports, prescriber communications, amendments, attachments, delivery evidence, file names, and versions.

Acceptance testRequired files open, link to the correct record, preserve readable dates, and distinguish originals from corrections.

Users, roles, and record history

Authors, user status, facility access, role history, activity records, source labels, and markers for imported records.

Acceptance testAuthorship survives; former users are not reactivated; imported activity is not presented as newly created.

Configuration and dependencies

Templates, categories, report profiles, rules, integrations, import schedules, code mappings, and custom fields.

Acceptance testEvery dependency has an owner, replacement, exception, or documented retirement decision.

Get the export details in writing

“We will give you your data” is not enough.

Ask who can request an export, what records and history it includes, what format you will receive, how much it costs, and how it will be delivered. Also confirm correction help, access after termination, and what the vendor will keep or destroy. HHS says that when a BAA requires PHI to be returned, the agreed format should keep the information accessible and usable.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsAssistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

HIPAA and security during the move

Check who is responsible for each part of the system.

The HIPAA Security Rule does not favor desktop or cloud software. A BAA also does not prove that a product is secure. Look at your actual setup: who protects the computers, database, network, backups, accounts, and data transfers?

Current-rule watch

HHS's Security Rule summary says the existing rule remains in effect while proposed cybersecurity modifications proceed through rulemaking. Do not treat proposed requirements as current law; check HHS again before final approval.

SourcesU.S. Department of Health and Human Services, Office for Civil Rights

Update the risk analysis

Changing vendors, hosting, data flows, or supported software changes the environment around ePHI. Document where the information is stored and sent, what could go wrong, which safeguards are already in place, and what still needs attention.

Keep on fileA dated risk analysis with systems, data flows, open risks, assigned owners, decisions, and a review date.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil Rights

Check support status, not the age of the interface

HIPAA does not require a modern-looking interface or cloud hosting. Missing patches or vendor support can create risk, but a newer product does not prove that the old one is unsupported or noncompliant.

Keep on fileThe supported version and environment, patch history, vulnerability process, final support dates, and any safeguards used to address known gaps.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil Rights

Put the BAA in place before the vendor handles real data

A company is not automatically a business associate just because it sells software. If it hosts PHI or accesses PHI during conversion, setup, or support, it generally is. Confirm the relationship before giving the vendor access.

Keep on fileA signed BAA when required, along with permitted uses, incident terms, subcontractor duties, and written responsibilities.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil Rights

Control access and check the converted records

Limit who can handle the migration, protect data in transit, compare the old and new records, document problems, and keep an approved way to reach needed history. The worksheet checks are practical controls, not a specific HIPAA-mandated test.

Keep on fileAn access list, secure transfer method, conversion checks, problem log, archive-access test, and incident contact.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil Rights

Know how reviews will continue if the cutover stalls

The plan should cover backups, restoration, downtime work, disaster recovery, and the tasks that cannot wait. A backup is not enough unless someone has shown that the records can be restored and used.

Keep on fileA recovery owner, backup scope, a recent restore test, downtime instructions, key contacts, and a clear rollback trigger.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil Rights

Confirm export, archive, and deletion terms

Put the export format, timing, fees, access after termination, and return or destruction terms in writing. HIPAA does not set one universal medical-record retention period, so check the state, setting, facility, contract, legal-hold, and professional rules that apply.

Keep on fileContract terms, a sample export, an archive plan, the rule supporting each retention period, and records of return or deletion when appropriate.

SourcesU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil RightsU.S. Department of Health and Human Services, Office for Civil RightsElectronic Code of Federal Regulations

Questions for both vendors

Get answers to these eight questions in writing.

Ask the outgoing and replacement vendors who owns each handoff. Problems often appear in the work that each side thought the other side would handle.

  1. On what date do sales, updates, security fixes, technical support, hosting, and data access end? If the documents show different dates, which one applies to our account?

  2. Which versions, operating systems, databases, browsers, integrations, and hosting arrangements will you support through those dates?

  3. Who creates the export? What records and history are included or excluded, which formats and field definitions come with it, and what will it cost?

  4. How long will the outgoing vendor help with the transition? What response time and escalation contact will apply?

  5. How will resident identity, authors, dates, recommendation statuses, attachments, released reports, corrections, and audit history carry over?

  6. Who handles cleanup, field mapping, duplicates, failed records, conversion checks, security setup, training, and final approval?

  7. If go-live fails, how quickly can we return to the old workflow? How will work completed during the gap be entered later, and who decides to roll back?

  8. After the contract ends, what can we still access, what will be returned or destroyed, and how will any retained copies stay protected?

Price the whole switch

Look beyond the monthly subscription.

Include setup, conversion, data cleanup, parallel work, training, interfaces, support, contract length, your own time, the old archive, and the cost of leaving later. Compare that total with your current labor estimate.

Estimate the current labor

Printable conversion worksheet

Compare the totals, then open the records.

Print / save as PDF

Totals can show that a group of records is missing. Opening a sample can show that dates, authors, statuses, or links changed during conversion. Do both. Add rows for your custom data and record any problem that still needs to be fixed.

MRR software migration reconciliation and sign-off worksheet
Record or configuration groupExpected / outgoingConverted / archivedSample and exception resultOwner / sign-off
Facilities and active resident counts--□ Pass   □ Exception-
Inactive, discharged, moved, duplicate, and merged residents--□ Pass   □ Exception-
Review counts by type, facility, month, and author--□ Pass   □ Exception-
Open, accepted, declined, deferred, and closed recommendations--□ Pass   □ Exception-
Psychotropic and GDR-related history used in later review--□ Pass   □ Exception-
Released reports, corrections, attachments, and file readability--□ Pass   □ Exception-
Authorship, timestamps, source identifiers, and imported-record labels--□ Pass   □ Exception-
User roles, facility access, integrations, templates, and report profiles--□ Pass   □ Exception-
Clinical ownerName / date
Operational ownerName / date
Privacy / security ownerName / date
Final go / no-goDecision / date

About this worksheet: These checks are a practical way to test whether records stayed complete and available. HIPAA does not require these exact rows, sample sizes, or sign-off roles.

Frequently asked questions

Common questions about changing MRR systems.

What does it mean when a software vendor sunsets a product?

It can mean several different things. Sales, updates, security fixes, technical support, hosted access, and data access may all end on different dates. Ask the vendor which dates apply to your version and contract, and what you can still access afterward.

What should a consultant pharmacy practice do first after an end-of-life notice?

Get the dates in writing, put one person in charge, save the notice and contracts, ask for a sample export, and list the work and history you cannot lose. Also decide how the next review cycles will continue if either system is unavailable. Do this before demos take over your calendar.

Can a healthcare organization keep using unsupported software under HIPAA?

The word unsupported does not produce an automatic yes or no. The organization needs a risk analysis based on the actual system and must address the risks it finds. HHS warns that unsupported legacy systems can be especially vulnerable and recommends planning for retirement when possible. Get qualified advice for your specific setup.

Does moving to cloud software make the practice HIPAA compliant?

No. The Security Rule is technology neutral. A cloud vendor may be a business associate, a BAA may be required, and both parties still have responsibilities. Product selection alone does not establish compliance.

What MRR data should be tested during migration?

Check resident and facility identity, reviews, recommendations, responses, status history, psychotropic or GDR history used in later reviews, reports, attachments, corrections, authors, dates, source identifiers, user roles, templates, and integration settings. What you are required to keep depends on your practice, setting, contracts, and applicable law.

How can a practice estimate what replacement software may be worth?

Measure current review volume and the time spent preparing data, finding information, documenting, following up, reporting, and retrieving history. Use that as one input when you set a budget. It is not guaranteed savings or a complete ROI calculation. Estimate your current MRR time and labor cost with the calculator.

Sources

Where the guidance comes from.

Federal sources provide the legal and security background. The ONC switching guide is written for EHRs, so we use it only for relevant health-IT contracting questions; it is not an MRR software rule. Vendor pages support only the dated RxPertise note.

  1. Assistant Secretary for Technology Policy / Office of the National Coordinator for Health IT

    Transition Issues: Switching EHRs

    EHR-specific contracting guidance that is useful by analogy for support periods, transition services, data formats, conversion, fees, and access to the outgoing system. It is not an MRR-specific mandate.

    Accessed July 16, 2026

  2. U.S. Department of Health and Human Services, Office for Civil Rights

    Summary of the HIPAA Security Rule

    Explains the currently effective Security Rule, including risk analysis, safeguards, contingency planning, evaluation, business-associate arrangements, and documentation.

    Accessed July 16, 2026

  3. U.S. Department of Health and Human Services, Office for Civil Rights

    Guidance on Risk Analysis

    Describes the required scope and elements of a risk analysis for electronic protected health information.

    Accessed July 16, 2026

  4. U.S. Department of Health and Human Services, Office for Civil Rights

    Securing Your Legacy System

    Discusses unsupported legacy systems, risk analysis, compensating safeguards, contingency planning, and retirement planning.

    Accessed July 16, 2026

  5. U.S. Department of Health and Human Services, Office for Civil Rights

    System Hardening and Protecting Electronic Protected Health Information

    Explains that risk analysis includes unpatched and obsolete software and discusses ongoing vulnerability management and compensating controls.

    Accessed July 16, 2026

  6. U.S. Department of Health and Human Services, Office for Civil Rights

    Is a software vendor a business associate of a covered entity?

    Explains that a software vendor is generally a business associate when it hosts or needs access to PHI, while merely selling software does not itself create that relationship.

    Accessed July 16, 2026

  7. U.S. Department of Health and Human Services, Office for Civil Rights

    Guidance on HIPAA & Cloud Computing

    Explains cloud business-associate duties, shared security responsibility, BAAs, risk analysis, service levels, encryption limits, backup and recovery, and data return after termination.

    Accessed July 16, 2026

  8. U.S. Department of Health and Human Services, Office for Civil Rights

    Business Associate Contracts

    Summarizes required contract subjects and sample provisions, including safeguards, incident reporting, subcontractors, and return or destruction of PHI at termination.

    Accessed July 16, 2026

  9. U.S. Department of Health and Human Services, Office for Civil Rights

    May a business associate block or terminate access to PHI?

    Explains availability responsibilities and, when the agreement requires return, returning PHI in a reasonable format that preserves accessibility and usability.

    Accessed July 16, 2026

  10. U.S. Department of Health and Human Services, Office for Civil Rights

    Fact Sheet: Ransomware and HIPAA

    Discusses backup, restoration testing, disaster recovery, emergency operations, criticality analysis, and contingency-plan testing.

    Accessed July 16, 2026

  11. U.S. Department of Health and Human Services, Office for Civil Rights

    Does HIPAA require medical records to be kept for any period?

    Explains that the HIPAA Privacy Rule does not set a medical-record retention period; state law generally does. Other HIPAA documentation requirements still apply.

    Accessed July 16, 2026

  12. Electronic Code of Federal Regulations

    42 CFR § 483.70 - Administration, including medical records

    Federal nursing-facility requirements for complete, accurate, accessible, organized, confidential, and safeguarded medical records.

    Accessed July 16, 2026

  13. SoftWriters

    RxPertise Help Center

    The live portal offers current-software downloads, update announcements, feature tutorials, ticketing, and Product ID maintenance-status checks for current users.

    Accessed July 16, 2026

  14. Managed Health Care Associates

    Clinical Consulting Software

    A current public RxPertise description that discusses existing and prospective users and continued enhancements; it does not publish a retirement date.

    Accessed July 16, 2026

  15. SoftWriters

    RxPertise Technical Requirements

    Account-access support material for the installed application's technical environment. Buyers should obtain the current version-specific requirements and responsibility split directly from SoftWriters.

    Accessed July 16, 2026

Have a newer vendor notice or a correction? Send the public source and the exact statement that should change to consultantpharmacistsoftware@tinycall.com. We date substantive source reviews.

Keep planning

Use the planner with an AI assistant

Build and maintain the switching plan through MCP.

Connect an MCP client to https://www.consultantpharmacistsoftware.com/mcp. The planner tools can create and store a private plan, fill in aggregate practice and migration details, manage the shortlist and evidence checks, update tasks and demo dates, add non-sensitive comments, and return the next actions and private calendar feed.

The plan URL, access token, and calendar URL are bearer secrets. Keep them private, and never enter resident or patient information, credentials, payment data, or PHI.

Start with list_software_switching_options, then use create_software_switching_plan. The guide's llms.txt lists every planner tool and its purpose.