Why a vendor should publish this
This article exists because a company that will not explain how to leave it is telling you something. We would rather say it plainly than have it discovered.
The reasoning is not principally ethical. A pharmacy's patient records belong to the pharmacy, and the pharmacy carries the regulatory obligation to hold and produce them. A system that makes retrieval difficult has therefore shifted a practical dependency onto a party that cannot lawfully accept it. When an inspector, an insurer, a purchaser's adviser or a patient asks for a record, the answer cannot be that the software supplier is looking into it.
Our buyer's guide lists exit as one of ten criteria to score every vendor against, including this one. It would be incoherent to make that criterion hard to satisfy here. This is the criterion answered.
What can you export from Dataforge PMR?
| Data | Format |
|---|---|
| Patient records and demographics | CSV |
| Prescription and dispensing history | CSV |
| Consultation and clinical assessment records | CSV, with free-text preserved |
| Notes and clinical annotations | CSV, attributed and timestamped |
| Documents and attachments | Original files, with a manifest linking each to its patient |
| Bookings and appointment history | CSV |
| Audit trail entries | CSV |
Structured data exports as CSV because every spreadsheet, database and competing PMR can read it. Attachments come out as the files they were, not embedded in something only we can open. A manifest lets you match each document to its record after it leaves our system. An export in a format only the vendor can read is not an export; open formats are the difference between the two.
Taking a routine export
The most useful thing in this article is the recommendation to do this before you need to.
An export taken calmly can be opened, spot-checked and verified. One taken during a migration deadline, a dispute or an incident usually cannot — nobody has time to confirm it is complete. A quarterly export, opened once and checked against a handful of known records, turns an assumption about portability into a fact. It takes an hour.
Three checks make it worthwhile rather than ceremonial. Confirm the row counts look right against what the system reports. Open a sample of patient records and check the clinical detail is present, not truncated. And confirm the attachments actually opened — a manifest referencing files that did not download is the failure mode worth catching early.
Store it as the sensitive data it is, encrypted and access-controlled, on the reasoning set out in the security baseline. An unprotected export sitting on a desktop is a breach waiting for a laptop to be stolen.
The full migration export
If you are moving to another system, or being acquired, a full migration export is available on request. It covers the complete dataset rather than the reporting views. It is designed to be handed to another vendor's implementation team.
What we provide alongside it matters as much as the files. A schema description explaining what each column contains — a CSV without documentation is a puzzle. A manifest for attachments. And a point of contact who will answer the receiving vendor's questions during the mapping, because migrations fail in the translation, not the transfer.
We would rather a departing customer arrived at their new system cleanly than left with a grievance. The reputational arithmetic in a market this small is not complicated.
What happens to your data if you cancel
What happens to patient data after a contract ends should be answered in the contract, not discovered at the end of one. It is the clause pharmacies read last and need most. Four things should be written down before signing with any vendor. Whether a full export can be requested during the notice period, and at what cost. How long the vendor retains the data after termination, and whether that period is within the pharmacy's control. When and how deletion occurs, and whether confirmation is provided. And what happens if the pharmacy needs a record after deletion — a realistic scenario, given how long professional retention obligations run. Our own position: an export can be requested at any point, including during notice, and retention and deletion arrangements are set out contractually, not at our discretion. Read that clause here too. Treat any vendor unwilling to commit to it in writing as having answered a different and more useful question.
Your retention obligations after leaving
This is the part most easily missed in a migration. It is entirely the pharmacy's.
Professional and legal record-keeping obligations continue after a system changes. They do not transfer to a former supplier. Migrate and discard the old export, assuming the history now lives in the new system, and you have a problem when someone requests a record predating the migration. Imports frequently carry the current dataset, not the full history.
The practical rule: keep the final export from any system you leave, in readable form, for as long as the underlying obligations require. Check periodically that it can still be opened. Formats age, and a file nobody has tried to read in four years is an assumption rather than a record.
What export does not solve
Honesty about the limits is the point of this article, so three.
Field mapping. Systems structure data differently, so a receiving system needs the columns interpreted rather than merely loaded. This is normal, and it is work.
Configuration does not transfer. Workflows, templates, questionnaire configurations, roles, label formats and integrations are rebuilt in the new system, not exported into it. A migration plan that budgets for the data and not the setup will run late.
Integrations must be re-established. Anything connected to the PMR, including a website booking flow, needs pointing at the new system. That work sits with whoever built the connection.
An honest migration plan therefore assumes the data moves and the configuration is rebuilt. That is a project, not a file transfer. A vendor who describes it as a file transfer has either not done one or is not telling you about it.
Questions to ask any PMR vendor
Including us, on identical terms.
Can I export all my data, and does that include free text, attachments and the audit trail? In what formats, and can a competitor read them? Can I take an export myself whenever I want, or must I request one? Is there a charge, and is it stated in the contract? What is provided alongside the export to help a receiving vendor map it? How long do you retain my data after termination, and when is it deleted? And will you put all of that in writing before I sign?
A vendor who answers these readily is not necessarily the right choice. A vendor who avoids them is reliably the wrong one.
Key takeaways
- Your patient records are yours. The regulatory obligation to hold and produce them sits with the pharmacy, not the software supplier.
- Dataforge PMR exports patients, prescriptions, dispensing history, consultations, notes, bookings and the audit trail as CSV, with attachments as original files and a manifest.
- Take a routine export quarterly rather than urgently. Check row counts, clinical detail and attachments, and store it encrypted.
- A full migration export is available on request with a schema description, a manifest and a contact for the receiving vendor's questions.
- Read the termination and deletion clause before signing with any vendor. It should cover export during notice, retention period, deletion and confirmation.
- Retention obligations continue after you leave and do not transfer. Keep the final export from any system you exit, and check periodically that it still opens.
- Export does not solve field mapping, configuration rebuild or integrations. Plan a migration as a project, not a file transfer.
Sources and further reading
FAQs
Your records, yours to take.
The fastest way to test a vendor's export claims is to ask for one. See it working, then bring us your own case. We will run a live export of sample data, show you the formats and walk through exactly what happens to your records if you leave.
See Dataforge PMR