How to switch clinic software without losing patient records

To switch clinic software without losing records, list everything the old system holds, check the vendor's export against that list, move in stages while the old system stays read-only, and keep the old records available for as long as the NHS Records Management Code of Practice requires (at least eight years for adult health records, and 20 years for mental health and psychology records).

Moving records is often the largest hidden cost of switching software in a UK neurodevelopmental service, mostly because clinics fear losing them. It is a solvable engineering problem, and tools like Cerebric can run alongside your old system while you do it.

1. Switching clinic software carries three risks, and each has a checklist#

Many software decisions stall on one question: what happens to everything we already hold? For an ADHD or autism assessment service, that worry is reasonable, and it has three sources.

• The legal duty to keep records. You can't leave old data behind when you change systems. The law expects you to keep it, in full, for years.
• Live pathways. At any moment some patients are part-way through: a referral not yet booked, questionnaires sent but not returned, an assessment recorded but the report not yet signed. Breaking an in-progress case does more harm than damaging a closed one.
• Signed documents and history. Signed reports, letters to GPs, uploaded school evidence, and the audit trail that shows who did what and when. A basic export often leaves these out.

Each of those three worries can be handled with a checklist.

2. Keep patient records at least eight years: switching software does not reset the clock#

The rules on keeping records are the reason you cannot simply switch off the old system. The NHS Records Management Code of Practice sets minimum periods in its Appendix II retention schedule (the list of how long to keep each type of record). The numbers travel with the record, whatever system holds it. The Code says children's records include "video and audio formats", and that its periods "must always be considered the minimum period."

The Code covers Right to Choose work; Regulation 17 applies either way#

Be careful about who the Code applies to. It applies to NHS organisations and, as its scope section spells out, to "records of patients treated on behalf of the NHS in the private healthcare sector" and "records created by providers contracted to deliver NHS services." So if you deliver Right to Choose work, you are covered by it.

A purely private provider is, in the Code's own words, "not strictly covered", but it says such providers "can also use this Code." The Health and Social Care Act 2008 sets the legal rules either way. Regulation 17 of the Regulated Activities Regulations 2014, made under that Act, requires providers to "securely maintain accurate, complete and detailed records," and the CQC may look at the Code when it inspects.

Claims can come years after care, and the clock follows the record#

Records also have to be kept because a claim can be brought years after care, under the Limitation Act 1980 (see the table). The six-year period people often quote is the usual limit for contract claims and other tort (civil wrong) claims.

Switching software never resets the clock: whatever you move, you must still be able to produce the full past record for as long as you have to keep it.

3. A complete patient record has five layers; flat exports tend to drop four#

Before you can move a record you have to agree what one is, and this is where exports go wrong. A patient record in an assessment service has several layers:

• structured data (demographics, referral source, payer type, appointments);
• uploaded documents and outgoing letters;
• completed patient and informant questionnaires and their scores;
• any recordings or transcripts;
• the audit trail.

Miss any layer and the record you have moved is incomplete.

The five layers of a patient recordWhat a flat export keepsStructured datademographics, referral source, payer type, appointments1Often lost in a flat exportUploaded documents and outgoing letters2Patient and informant questionnaires and their scores3Recordings and transcripts4Audit trailwho did what, when5A complete migration moves all five layers. Attachments, questionnaire scores and the audit trail are the layers most often missing from a flat export.The five layers of a patient record, and the four that a flat export tends to leave out.

4. The contract's data-return clause, not GDPR portability, gets your records back#

Data portability is a patient's right, not a clinic's way out#

Clinics often think UK GDPR's right to data portability lets them take their data with them. It does not. As the ICO explains, portability is an individual's right to receive their own data in "a structured, commonly used and machine-readable format." It gives a clinic no way to get its whole database out of a vendor.

The processor contract must provide for return or deletion of all your data#

The route that works is the contract. Under UK GDPR, your software vendor is a processor (it handles data for you) and you are the controller (you decide how it is used). The processor contract must state that at the end of the contract the processor will, at your choice, delete or return all the personal data it holds for you. That clause is what gets your records back. The table compares the two routes.

Exit terms set the export formats, completeness, timescale and cost#

It pays to read the exit terms before you buy. The duty to return data is set in law, but the details are set in the contract: the export formats, whether attachments and audit trails are included, the timescale, and above all the cost of getting the data out. A vendor who charges heavily to hand back your own data, or who cannot describe the process, has built in lock-in.

Our buyer's guide to clinic software covers the wider decision, and the clinic buyer's guide to DSPT, DTAC and DCB0129 covers the compliance evidence to check beside it.

5. A data export audit is the go/no-go point: count everything first#

The migration playbook, with one go/no-go gateInventorycount every category, how far backGateExport auditformat, is it complete, attachments, historyMappingdocument every field decisionCutovernew referrals in new system, old read-onlyCheck the movematch up counts, spot-check contentSwitch off the old systemkeep it reachable while records must be keptThe export audit is the go/no-go gate. Count the records in the export before cutover: if the old system says twelve thousand records and the file has eleven and a half thousand, find the missing five hundred first.The six stages of a migration, with the export audit as the go/no-go point.

An inventory of every record type comes before the export#

Start with an inventory, a list of what you hold, before you ask for an export. List every type of record in the old system: active patients, discharged patients, referrals that never went ahead, draft and signed reports, letters, questionnaire answers, recordings, financial records. For each, note roughly how many you hold and how far back they go. This is what you will later check the move against.

A sample export should pass three tests: format, completeness, attachments#

Then check the export (the export audit). Ask your vendor for a sample export and test it against three questions:

• What format? CSV or a structured export (JSON, XML) for data, the original file types for documents and letters, and a written description of every field (a schema) so you know what each one means.
• Is it complete? Check it covers every type of record on your list, not only the easy tables.
• Do attachments and history come too? Uploaded documents, questionnaire scores and the audit trail are what an incomplete export usually drops.

As an engineer, I count every export before I trust it. If the old system says twelve thousand records and the file has eleven and a half, you need to find the missing five hundred before you switch over. Treat the export audit as the go/no-go point. If a vendor cannot hand over a complete, clearly described export when asked, I would think again about the move.

6. Map every field in writing and move over in stages#

Most fields map cleanly; write down every decision on the mismatches#

Mapping is the middle stage: deciding how each field in the old system lands in the new one. Most fields map cleanly. The work is in the mismatches: a free-text status that needs splitting into structured stages, a payer field that must be sorted into Private, Right to Choose and Contract, or dates in an unclear format. Write down every mapping decision, so a colleague or an auditor can later understand why a value looks the way it does.

Moving in stages avoids one moment where everything must be perfect#

When you switch over, avoid moving everything at once. New referrals start in the new system from day one, while older records import in the background and the old system stays available read-only. This "run alongside" approach means no single moment where everything must be perfect, and no gap where clinicians cannot see a patient's history.

This is the model Cerebric is built for. It works on its own or alongside your current EHR, including through a Chrome extension that shows its tools over your current system. Teams can start using it without stopping work for a migration weekend.

Step-by-step cutover compared with a big-bang switchNew systemNew referrals start here from day oneOld systemRead-only; older records import in the backgroundBig-bangEverything switches over on a single date (the approach to avoid)Running the two systems alongside each other avoids a single switchover date and keeps each patient's history visible to clinicians throughout. Cerebric works on its own or alongside your current EHR through a Chrome extension.Moving over in stages with the old system kept read-only, compared with switching everything on one day.

7. A migration is finished only after counts, spot checks and a named sign-off#

A migration is finished when someone has checked and signed off that it is correct. Checking has two parts:

1. Match up the counts. The number of patients, reports, letters and questionnaires in the new system should match your inventory from the old one, and any gap should have a written explanation.
2. Spot-check the content. Pull a sample of different kinds of record (a complex older case, an in-progress pathway, a discharged patient, one with many attachments) and confirm that the data, the documents and the history all arrived whole and readable.

Then get a named person to sign it off. Checking the move is a clinical safety matter as well as an IT one. Treat it as a formal step in bringing in the new system (the kind your DCB0160 work should already cover), so there is a written record showing it worked.

8. Keep the old system and its audit trails for the last entry's retention period#

You cannot simply delete the old system. The Code deals with this directly for electronic patient record systems that cannot destroy records in line with the retention schedule. When such a system is switched off (decommissioned), the records "should be made inaccessible to system users." The system, "along with the audit trails, should be retained for the retention period of the last entry."

So budget for keeping the old system, or a checked archive of it, available for years after you stop using it day to day. Keep a log of any records you destroy.

9. Five steps let you switch clinic software without losing records#

1. Know how long you must keep each record, and plan to keep all of it.
2. Check the export before you trust it, and count everything.
3. Map with care and switch over in stages.
4. Check with counts, spot checks and a named sign-off.
5. Keep the old system reachable for as long as the law requires.

Most important, read the data-return clause before you sign the contract, while you can still get it changed.