Switching clinic software without losing your records

Clinic software migration is often the largest hidden switching cost in a UK neurodevelopmental service, mostly because of the fear of losing records. It is a solvable engineering problem. UK health records for adults must be kept for at least eight years, so the goal is to move a complete record you can check, rather than start again. Tools like Cerebric can run alongside your old system while you do.

Why migrations feel risky

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, and the rest of this article sets it out.

What the law says you must keep

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), and the numbers travel with the record whatever system holds it. Adult health records not covered by another category are kept for a minimum of eight years after the last entry. Children's records (which the Code says include "video and audio formats") are kept until the patient's 25th birthday, or 26th if they were 17 when treatment ended. The Code says they "must always be considered the minimum period."

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," and 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.

Records also have to be kept a long time because a claim can be brought years after care. Under the Limitation Act 1980, clinical negligence and personal injury claims generally allow three years from the date of knowledge (a judge can extend this, and there is no clock at all for a child until they turn 18). 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 on keeping a record. Whatever you move, you must still be able to produce the full past record for as long as you have to keep it.

What counts as a record

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.

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," and it only covers a narrow set of data: data the person gave you, held on the basis of consent or a contract, and handled by computer. It gives a clinic no way to get its whole database out of a vendor.

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), and 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, which is why you should read it before you sign.

The migration playbook: list what you hold, then check the export

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.

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 and, for each, roughly how many you hold and how far back they go: active patients, discharged patients, referrals that never went ahead, draft and signed reports, letters, questionnaire answers, recordings, financial records. This is what you will later check the move against.

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 leaves out.

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 cut 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.

Mapping and the run-alongside cutover

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, such as a free-text status that needs splitting into structured stages, a payer field that must be sorted into Private, Right to Choose and Contract, dates in an unclear format. Write down every mapping decision. That record is what lets a colleague, or an auditor, understand later why a value looks the way it does.

For cutover, avoid a single big-bang switch. A step-by-step approach works better: 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, so 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.A step-by-step cutover, with the old system read-only, compared with a single big-bang switch.

Checking the move and signing it 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.

Switching off the old system, and the exit terms to check before you buy

You cannot simply delete the old system. The Code deals with this directly for electronic patient record systems: where a system cannot destroy records in line with the retention schedule, when it is switched off (decommissioned) the records "should be made inaccessible to system users," and 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, and keep a log of any records you destroy.

This is why 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. Weigh this up alongside everything else when you choose: see our buyer's guide to clinic software for the wider decision, and the clinic buyer's guide to DSPT, DTAC and DCB0129 for the compliance evidence to look at beside it.

What to do next

The worry about switching comes down to the duty to keep records, live pathways, and signed documents and history. Each can be handled with a checklist:

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 cut over in stages rather than all at once.
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.