Healthcare data migration testing

What does healthcare data migration testing cover?

Two questions asked at the same time: whether everything that left the source arrived, and whether it still means what it meant. The second one closes at cutover. While the old platform answers, any disagreement can be settled by going back and looking at it. Once it is switched off or frozen, the record in the new system is the record, and a comparison nobody made is a comparison nobody can make.

That asymmetry sets the scope, and it is the only respect in which this work differs from testing a system that will still be there next quarter. Findings that would sit in a backlog on any other release have to be produced before the switch, because the evidence they rest on is part of what gets decommissioned. Five things therefore fall inside the engagement rather than after it: the mapping of fields and of the relationships between records, the reconciliation between the two systems, the treatment of coded content that was written under older releases, the fate of the audit trail, and the disposition of the source platform itself.

The last of those is usually treated as an infrastructure task and belongs in the test scope, for a reason set out further down: several obligations attached to the data outlive the system that held it.

Why can a migration defect not be settled after cutover?

Because the reference copy is the thing being retired. A defect report needs two sides, and after the switch there is one. The new system can be shown to be internally consistent, to accept the formats it claims, and to behave the way its own specification says. None of that answers whether the value it now shows is the value a clinician wrote, and nothing inside the target can answer it.

The Security Rule states the obligation this sits under. section 164.312(c)(1), Integrity requires policies and procedures that protect electronic protected health information from improper alteration or destruction, and nothing in it exempts an alteration that was planned. Its implementation specification, section 164.312(c)(2), is addressable and asks for electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Corroboration is a comparison, and a comparison needs both sides available.

What has to be reconciled while both systems still answer?

The things that are equal as data and different as meaning, plus everything that is a relationship rather than a field.

Values first. Two systems can hold the same number under different units, the same timestamp under a different zone or a different precision, and the same empty cell meaning "not recorded" in one and "recorded as zero" in the other. A comparison written on equality reports all three as matches. The comparison that finds them is written per field, from the meaning both sides claim, and it is the part of the work that takes the longest to agree and the least time to run.

Relationships next, and this is where a table by table load loses the most. A correction and the value it corrected, a superseded result and the one that replaced it, an attachment and the note it belongs to, a merged patient and the two histories now filed under one identity: each of those is a link, and a load that maps one table at a time carries fields and drops links. The chart still renders. What is gone is the ability to say which of two values came first.

The third is the audit trail, and it needs a decision rather than a mapping. section 164.312(b), Audit controls is a required standard of the Security Rule with no implementation specification under it, so it names no format and nothing obliges a legacy log to be loadable anywhere. section 164.308(a)(1)(ii)(D) then requires procedures to regularly review records of information system activity, such as audit logs, access reports and security incident tracking reports, and that duty has no start date at your cutover. A pre-cutover log left on a platform that is about to be wiped leaves the review with nothing to run against for the period before the switch. Where the log lives afterwards, and in what form it can still be read, is a line item in the plan rather than a task for whoever turns the machine off.

What happens to the system you switch off?

It stops being a system and becomes a retention question, on a clock that does not reset. Four provisions decide what may be done with it and for how long, and each one runs against different material.

HIPAA provisions in 45 CFR part 164 governing a source system retired by a healthcare data migration, set against what each makes testable.

The question about the source system	Where the obligation sits	What it makes testable
How long does the documentation have to survive the platform	45 CFR 164.316(b)(2)(i) and 164.530(j)(2), both six years from creation or from the date last in effect, whichever is later	Whether each retained artefact is still readable, and by whom, at the end of that period
Are decedent records out of scope once the system is retired	45 CFR 164.502(f), fifty years after death	Whether the archive holding them is still inside the same access and audit regime as the live system
What may be done with the hardware and the media	45 CFR 164.310(d)(2)(i) Disposal and (d)(2)(ii) Media re-use, both required implementation specifications	Whether the disposal actually happened, against the record of it
Who has the retired copy now	45 CFR 164.310(d)(2)(iii) Accountability, addressable, a record of the movements of hardware and electronic media	Whether the movement record accounts for every copy made during the migration

The row that catches projects is the last one. A migration produces copies: extracts, staging databases, defect reproduction environments, a back-out snapshot held in case the cutover fails. Each is electronic protected health information in a place that was created for the project and has no owner afterwards. Counting them is cheap while the project is running and close to impossible a year later.

Which questions will the new system be asked about records it did not create?

The individual rights questions, and they reach back further than the platform does. section 164.524(a)(1) gives the right of access to protected health information in a designated record set "for as long as the protected health information is maintained in the designated record set", so what a migration decides to keep, and where it puts it, is also the decision about which future requests can be answered. section 164.528(a)(1) reaches six years back for an accounting of disclosures, which is longer than many platforms last, so a request arriving next year can land on a period that was served by a system that is now off.

Two consequences fall on the mapping specification rather than on the target product. The material appended under section 164.526(c)(1) and section 164.526(d)(4) for an amendment, whether it was accepted or denied, exists as links to the records it concerns, and links are what a load written table by table drops. And section 164.524(e) makes the inventory of designated record sets subject to access a documentation obligation in its own right, which the migration invalidates on the day it completes: the record now sits in different stores, under a different vendor, with a different set of workflow tables around it. How those three rights behave inside a product, with the deadlines and the denial paths, is set out under patient portal testing. What this engagement adds is evidence about whether the history they run against arrived in a state that can answer them.

What does a coded history do when it is reloaded?

It gets re-judged, all of it, by whichever code file the target has loaded. 45 CFR 162.1000(a) requires a covered entity to use the medical data code sets that are valid at the time the health care is furnished, so the verdict on a stored diagnosis depends on a date that has to survive the load alongside the code itself. A migration is the single moment when years of records pass through one transformation, and a record whose date of service did not travel cannot be re-judged afterwards by anyone.

Serialisation is the cheap defect underneath the interesting one. ICD-10-CM codes have two written forms: the tabular XML writes them dotted, as A00.0, while the flat distribution files write them undotted, and CMS documents the field as "ICD-10-CM or ICD-10-PCS code. Dots are not included." A00.0 and A000 are the same code. A reconciliation written on string equality between two systems that chose differently reports every coded row as changed, which buries the rows that actually did change. The structural rules a validator has to encode, and the release-by-release mechanics of the annual and mid-year updates, are on ICD-10 code mapping testing requirements.

Which products does this work sit inside?

Three on this site, and the record that has to survive is different in each.

An EHR or EMR carries the clinical history, so the reconciliation is built around what a clinician can read rather than around what a database holds. A medical billing product carries claims and ledger entries whose meaning depends on a date and on an adjudication that happened elsewhere, so a migrated charge has to reconcile against a payer response the new system never received. A patient portal exposes the migrated history to the person it is about, which is the fastest way an unnoticed load defect reaches someone who will report it.

Where the migration coincides with a change of interface partner, the exchange side is separate work and is covered by healthcare interoperability testing.

Which standards does the work close?

Three, and each one closes against a different artefact.

The Security Rule closes against the integrity, audit and disposal evidence above: the reconciliation record for 164.312(c), the decision about where the pre-cutover log lives for 164.312(b) and 164.308(a)(1)(ii)(D), and the disposition record for 164.310(d)(2). The safeguard by safeguard reading of Subpart C is on HIPAA testing requirements for software.

The code set rules close against the revalidation report, which is the only document that says which stored codes were judged against the release in force on their own date of service.

The certification criteria close against the export, on the source side rather than the target. 45 CFR 170.315(b)(10)(ii) covers an export of all the electronic health information that can be stored at the time of certification by the product, and 170.315(b)(10)(iii) requires the export formats used to be kept up to date. Where the source product is certified, that gives a source extract a documented format instead of a reverse-engineered schema, and the conditions the export itself has to meet are set out under ONC certification testing requirements. Neither the certification nor the compliance position moves to a testing supplier. What the work produces is the evidence underneath both.

What do you receive?

Seven documents, and every one of them answers a question that gets asked after the source system is gone.

The mapping specification carries one rule per field and one rule per relationship, each with the date it was agreed and the name of whoever agreed it. A field with no rule is reported as such, because an undecided field is the finding, and it is cheaper to find in a specification than in a chart.

The pre-cutover reconciliation record holds the run itself: which records were compared, on which rule, against which versions of both systems, and every difference with its direction. It is dated to the window when both systems answered, which is what gives it standing later.

The coded content revalidation report lists the stored codes by date of service and says which release each was judged against. Codes that arrived with no usable date are a separate list, because they cannot be judged at all.

The history and linkage inventory names the relationships in the source and says what happened to each: carried, transformed, or flattened into a current value. A flattened relationship is a legitimate decision. An unrecorded one is not.

The designated record set inventory restates, for the estate that exists after cutover, which stores hold records subject to access, and who processes a request against each.

The source system disposition record says what is kept, where, in which format, who administers it, which copies were made during the project, and the date each retention obligation ends.

The defect record separates findings the migration created from findings that were in the source before anyone touched it. That column keeps a pre-existing data quality problem out of the load, where a quiet correction turns into a transformation that appears in no specification.

Where does migration testing go wrong?

• The load's own summary is filed as the reconciliation, so every defect the mapping caused is inside the count of successes.
• Reconciliation is scheduled after go-live, and the source is frozen or wiped before the first disagreement is investigated.
• The comparison is written on equality, so two systems that disagree about units, time zone precision or the meaning of an empty cell report a match.
• Tables are mapped and links are not, so corrections, superseded results and attachments arrive as unrelated rows.
• Merged and duplicate patients in the source are treated as a data quality problem for later, and the merge decisions are made silently by the load.
• The date of service does not travel with the code, so the target judges a decade of records against whichever release it has loaded.
• The audit trail is left on the platform being decommissioned, and the review obligation has nothing to run against for the period before cutover.
• Staging databases, defect reproduction copies and the back-out snapshot are never added to the inventory of places that hold ePHI.
• A pre-existing source defect is corrected during the load rather than afterwards, so the target contains a transformation that appears in no specification.
• The source system is frozen and quietly falls out of access review, log review and patching while still holding the retained record.

How does it fit the cutover you have already planned?

It is planned backwards from the cutover date, because most of the work has to be finished before the switch rather than after it. Test data is the first decision. A migration suite eventually runs against real history or a full copy of it, since the defects it looks for are properties of that history. The question of what has to be in place before an outside team opens such a copy is raised at working with protected health information. Until it has an answer, the trial load has no environment to run in.

The back-out plan is tested rather than written. A cutover that cannot be reversed has one attempt, and the decision to proceed is then made on whatever evidence exists at that hour. Where a return to the source is genuinely available, the reconciliation window can be shorter and the risk in each finding is lower, so the value of testing the reversal is highest for exactly the projects that assume they will never use it.

After the switch, what continues is narrower and does not disappear. Interfaces that write into the migrated history need the same assertions the exchange work uses, historical records go on being re-judged every time a code set release lands, and the retention dates recorded above come due one at a time, each of them years after the team that set them has moved on.