Healthcare Data Migration

What is healthcare data migration?

Healthcare data migration is the planned transfer of health data from systems being replaced or retired, such as an EHR, PACS, billing platform or document store, into a new system or a searchable archive. It covers mapping codes and formats, matching patients, moving data securely and proving through reconciliation that nothing was lost or altered.

Which systems besides the EHR need a migration plan?

Imaging, billing, documents and departmental systems each need their own plan, owner and test. They hold different data shapes and different volumes, and they are often owned by teams that are not part of the EHR project.

• Imaging: DICOM studies and reports in a PACS or vendor neutral archive, usually the largest data set by volume and the slowest to move.
• Billing and revenue cycle: Open claims, patient balances, payment plans, credit balances and remittance history, which finance teams still need after the clinical cutover.
• Documents and scanned charts: Referral letters, consent forms, outside records and scanned paper charts, with their indexes, document types and dates.
• Departmental systems: Lab, pharmacy, cardiology, oncology and therapy systems with their own patient identifiers and code sets.
• Patient-facing data: Portal messages, questionnaires and app data that patients expect to see again in the new portal.

One patient, many identifiers

Each of these systems usually has its own patient identifier. Before any data moves, build a crosswalk that links every legacy ID to the target system's ID through a master patient index, and route uncertain matches to a trained team for review. A study or claim filed under the wrong patient is a safety and privacy problem, and it is far harder to find after go-live than before.

Migrate, archive or retire: how to decide per data set

Decide each data set on its own terms: migrate what clinicians and staff use in daily work, archive what must be kept and occasionally viewed, and retire what is already held elsewhere. Clinical, finance and legal leaders should sign each decision.

• Migrate when: The data drives current care or work, such as active problems, medications, allergies, recent results, open claims and recent imaging priors that radiologists compare against.
• Archive when: The data must be retained and occasionally viewed, such as older encounters, closed claims and historical documents. Clinicians should open the archive from the new system in patient context.
• Retire when: The data exists in another system of record, or retention has expired and no legal hold applies, with the decision and the evidence written down.
• Split the history when: A lookback period, for example a set number of years of discrete data, goes into the new system and the rest goes to the archive. The period is a decision for clinical leaders, not a technical default.
• Pause when: A legal hold, open audit or pending litigation covers the data. Nothing on hold is retired until counsel releases it.

What a usable archive needs

An archive that nobody can search is a retention store, not an archive. It needs patient search by any legacy identifier, a launch from the new EHR in patient context, document and study viewers, role-based access with audit logging, release of information workflows for access requests, and a retention clock per record type so data can be disposed of when its period ends.

Which rules govern old data during and after the move?

Old data keeps its legal status after cutover. Records sent to an archive are still PHI, still subject to patient access and still covered by state retention law.

• No HIPAA retention period: HHS explains that the Privacy Rule does not set a retention period for medical records. State laws set it, and the Privacy Rule requires safeguards for as long as records are kept.
• Hospital records: The Medicare Conditions of Participation at 42 CFR 482.24(b)(1) require hospitals to retain medical records in original or legally reproduced form for at least 5 years, and many state laws require longer.
• Patient access to archives: Under 45 CFR 164.524, patients may access their designated record set, which includes archived records, and covered entities must act on a request within 30 days, with one 30-day extension allowed.
• Copy before moving equipment: 45 CFR 164.310(d)(2)(iv) is an addressable specification to create a retrievable, exact copy of ePHI before equipment is moved, which applies to legacy servers and storage arrays.
• Disposal: 45 CFR 164.310(d)(2)(i) and (ii) require policies for the final disposal of ePHI and its media and for removing ePHI before media is reused.

For providers, which are actors under 45 CFR Part 171, a migration plan that leaves legacy EHI unavailable to patients or treating clinicians can be information blocking unless an exception applies, so plan archive access before the cutover date.

How does an imaging migration differ?

An imaging migration moves large DICOM objects whose identifiers must stay consistent with the reports and orders that point to them. The work is mostly about identifiers and throughput, not mapping.

• Identifiers: Each study carries a Study Instance UID, an accession number and a patient ID. If the new PACS or archive uses a different patient ID domain, tag values must be changed consistently, with the original values kept.
• Priors first: Radiologists compare new studies with priors, so migrate recent studies for scheduled patients ahead of the bulk history.
• Throughput: Bulk moves run for long periods. Schedule them around clinical hours, track progress per study, and resume from the last confirmed object instead of restarting.
• Proof: Compare study, series and instance counts between source and target per patient, and open a sample of studies with their reports to confirm they display correctly.
• Non-DICOM images: Wound photos, endoscopy clips and scanned media may sit outside the PACS and need their own route.

How should scanned documents move?

Scanned documents should move with their index data intact, because a PDF without its patient, date and document type is close to useless. The index is often in a separate database from the files.

• Index mapping: Map each legacy document type to the target system's categories, and keep the original type as metadata.
• Dates: Carry the service date and the scan date separately, so documents sort correctly in the new chart.
• Formats: Convert proprietary or multi-page TIFF formats only if the target cannot display them, and keep a checksum of every original file.
• Unfiled items: Expect documents never linked to a patient. Give them a review queue rather than dropping them.

Running down a legacy billing system

Billing data is usually wound down rather than moved. Many organizations keep working open claims in the old system until they are paid or written off, while new charges go to the new platform from cutover.

• Freeze date: A clear date after which no new charges enter the old system.
• Remittance routing: X12 835 files for old claims keep arriving for months. Decide where they post and who works the denials.
• Balances and credits: Patient balances, payment plans and credit balances move as opening balances, reconciled to the general ledger.
• History for appeals: Keep claim and remittance history viewable for appeals, audits and refunds after the old system goes read-only.
• Payer enrollment: Confirm clearinghouse and payer enrollment for the new platform before the freeze date, so the first new claims are not rejected.

How do you prove the migration is complete?

Prove completeness with reconciliation rules written before the first load, then a sign-off from the owner of each data set. A finished load job is not proof. The rules should say what counts as a match, which differences are acceptable and who decides when a gap is explained.

• 1. Count: Records, documents, studies and claims per data set, source against target, with every gap explained.
• 2. Compare fields: Key values such as result values, units, dates, balances and document types, checked by script.
• 3. Review with people: Clinicians compare sample charts side by side, radiologists open sample studies and billers check sample accounts.
• 4. Rehearse: Run at least one full dry run on production-sized data to measure timing and catch the gaps in the rules.
• 5. Record: Keep an audit trail of each load, the mapping version used and every manual correction.
• 6. Retire: Move the legacy system to read-only, keep it until sign-off and retention needs are met, then dispose of the data and media under your disposal policy.

How Agnotic can help

A migration that spans imaging, billing and documents needs one technical owner who sees every data set at once. Agnotic Technologies provides that role through its healthcare fractional CTOs, with data engineers who build the source inventory, the per-data-set decisions, terminology and identity mapping, DICOM and document pipelines, reconciliation scripts and the archive access that keeps old records reachable from the new system.

Sources

• HHS: Does the HIPAA Privacy Rule require covered entities to keep medical records for any period?
• 42 CFR 482.24: Condition of participation, medical record services
• 45 CFR 164.524: Access of individuals to protected health information
• 45 CFR 164.310: Physical safeguards, device and media controls
• 45 CFR Part 171: Information blocking
• DICOM Standard (NEMA)