Why a vendor should publish this
This article exists because a company which will not explain how to leave it is telling a customer something, and 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, which means a system that makes retrieval difficult has transferred 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, so it would be incoherent to make the criterion difficult to satisfy here. This is that 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, rather than embedded in something only we can open, with a manifest so that a document can be matched to the record it belongs to after it leaves our system. An export in a format only the vendor can read is not an export, and choosing open formats is 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. An export taken during a migration deadline, a dispute or an incident usually cannot, because nobody has time to confirm it is complete. A quarterly export, opened once and checked against a handful of known records, converts an assumption about portability into a fact, and 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 confirm the clinical detail is present rather than truncated. And confirm the attachments actually opened, since 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
Where a pharmacy is 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, and is intended 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, since 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 rather than in the transfer.
We would rather a departing customer arrives at their new system cleanly than leaves with a grievance, and the reputational arithmetic in a market this small is not complicated.
What happens to your data if you cancel
The question of what happens to patient data after a contract ends should be answered in the contract rather than discovered at the end of one, and 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, which is a realistic scenario given how long professional retention obligations run. Our own position is that an export can be requested at any point including during notice, and that retention and deletion arrangements are set out contractually rather than at our discretion. A pharmacy should nonetheless read that clause here, and should 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, and it is entirely the pharmacy's.
Professional and legal record-keeping obligations continue after a system changes, and they do not transfer to a former supplier. A pharmacy which migrates and discards the old export, on the assumption that history now lives in the new system, has a problem when a record predating the migration is requested, since imports frequently carry the current dataset rather than the full history.
The practical rule is to retain the final export from any system you leave, in readable form, for as long as the underlying obligations require, and to 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 rather than exported into it. A migration plan which 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, and 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 rather than a file transfer, and 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 answering these readily is not necessarily the right choice, and a vendor avoiding them is reliably the wrong one.
Key takeaways
- Your patient records are yours, and the regulatory obligation to hold and produce them sits with the pharmacy rather than 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, covering export during notice, retention period, deletion and confirmation.
- Retention obligations continue after you leave and do not transfer, so 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, so plan a migration as a project rather than a file transfer.
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 and 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