Define the exact record before requesting an export
List residents and facilities, medication-review history, recommendations, responses, status history, users and authorship, timestamps, report artifacts, attachments, configuration, and source identifiers. Mark which elements are clinically or operationally necessary after termination and which are desirable for future analysis or convenience.
This inventory is not a claim that every system must export every internal field. It turns the buyer's continuity need into a testable requirement before contract language fixes the available options. If the vendor excludes an element, record the exclusion and its operational consequence instead of assuming another file will contain it.
Include inactive residents, closed recommendations, corrected reports, and older records in the sample. A current-resident export can look complete while leaving the history needed for later review, facility questions, or transition work outside the package.
Request both human-readable and machine-usable tests
Open a sample PDF or archive as a future reviewer would. Can that person identify the resident, facility, author, dates, recommendation, response, status, correction, and report context without access to the former application? Note what requires a code list, linked file, or vendor explanation.
Separately inspect structured files for stable identifiers, field definitions, dates, encoding, relationships, status meanings, and missing values. A CSV can be structured yet unusable if codes are unexplained or resident relationships are lost. A polished PDF may preserve reading context while remaining difficult to load into the next workflow.
Test whether relationships survive outside the old interface
Use a synthetic or appropriately protected sample containing two facilities, an active and inactive resident, a recommendation with a response, a later correction, an attachment, and a covering pharmacist. Follow the identifiers across every exported file and document. The parts should remain connected without relying on screen order or filenames that can collide.
Check one-to-many relationships and chronology. Can multiple recommendations remain attached to the correct review? Does a response point to the recommendation it answers? Can an original report and correction be distinguished? Record each orphan, duplicate, unexplained code, and date that changes meaning.
Reconcile the package before declaring portability
Compare counts by facility, resident status, review type, report type, and time period, then sample the underlying records. Count agreement is useful but not sufficient: a package may contain the expected number of rows while losing text, relationships, attachments, provenance, or status history.
Have a permitted reviewer who did not prepare the export open the sample and answer a small set of continuity questions. Record what can be found, what is ambiguous, what needs a conversion step, and what cannot be recovered from the supplied package. Do not backfill missing history to make the test pass.
Put the exit path in the commercial review
Confirm who may request an export, available formats, delivery method, preparation time, cost, post-termination access, correction handling, vendor retention, and deletion or return commitments. Ask which assistance is included, how a failed or incomplete export is corrected, and when the customer must finish validation. Obtain qualified contract and privacy review.
Assign owners on both sides for request, secure delivery, verification, discrepancy resolution, acceptance, access shutdown, and later retention or deletion steps. A promise that data are exportable does not identify who performs those tasks or whether the timing fits the practice's transition plan.
Keep export success separate from migration parity
For RxPertise or any other migration, do not assume perfect parity. Test representative history, attachments, recommendations, dates, authors, status meanings, and reports, and record what will not transfer. A readable archive and a successful import into a replacement system are different acceptance results.
The sources below provide security and interoperability context; they do not define a universal MRR export package or guarantee that a vendor's output meets this practice's continuity needs. The buyer still needs a written scope, sample files, and observed acceptance test.
Test the exit while leverage remains
Run the sample before signing and repeat it after material workflow or contract changes. Preserve the inventory, file definitions, test results, unresolved gaps, and agreed remedies with the buying record.
Portability is proven only to the limits of the package tested on that date. The practical goal is narrower: ensure authorized people can retrieve, understand, protect, and hand off the records the practice has decided it must keep.