The most nerve-wracking process in replacing an electronic record is data migration. Because past records directly relate to patient safety and continuity of care, loss or garbled text is unacceptable. Yet migration is complex, and a loose plan tends to reveal major problems just before cutover.
This article explains, from a practical viewpoint, the steps from deciding migration scope through inventory, mapping, test migration, verification, and go-live, along with how to think about cost and how to avoid failure.
Migration tends to be left to the vendor, but the hospital's involvement is indispensable in judging scope and schedule. What to keep and what to give up can only be decided by the field that knows the reality of care. Not dumping it, but a collaborative stance that grasps the key points, is a prerequisite for success.
How to Decide Migration Scope
Trying to fully migrate all data inflates both cost and duration. The starting point is to separate information essential to care from information that only needs to be referenceable. A realistic policy is to migrate recent records into the new chart and keep old records separately for reference.
- Migrate: recent years of records, prescriptions, allergies, and key test results
- Reference storage: keep old records and scanned documents viewable separately
- Excluded: do not migrate duplicate or unneeded data; organize to cut cost
Inventory and Mapping
Inventory—clarifying what data exists in which fields and formats in the current system—is the process that determines migration success. If master structures, disease codes, or unit notations differ between old and new, data cannot be moved correctly as is. Unique operational rules and exceptional entries accumulated over years of use are often hidden, so it is important to surface unexpected data formats early.
Create a mapping table pairing old fields to new fields and define code conversion rules one by one. The more carefully this is done, the more garbled text and value discrepancies in later steps are prevented. Proceeding while ambiguous causes consistency problems after go-live.
In mapping, handling fields that do not correspond one-to-one between old and new is the hard part. When a free-text field in the old system is a selection in the new, or multiple fields are merged into one, the conversion policy must be decided in consultation with the field. Recording the basis for decisions helps in later verification and audits.
Test Migration and Verification
Before go-live, always perform a test migration using part of the real data. It is important to have the field verify not only that counts match but that content displays correctly with no garbled text or loss. External characters, old-form kanji, and platform-dependent characters are especially prone to garbling. Do not end testing in one pass; plan a schedule with margin, assuming iteration of fixing problems and re-migrating to check.
- Count matching: reconcile record counts by field between source and target
- Content verification: extract representative patients and visually compare records
- Garble check: intensively inspect display of external, old-form, and special characters
- Test values and units: confirm numbers and units carry over correctly
Coordinating with the Former Vendor
Migration requires extracting data from the current system, which stalls without the former vendor's cooperation. Since requests near contract end tend to be delayed, confirm the extraction format, cost, and schedule in writing early.
In principle the hospital owns the data, but extraction cost and delivery format depend on the contract. Being conscious of the exit from the renewal-contract stage, anticipating migration, makes later negotiation smoother.
How to Think About Cost
Migration cost depends more on conversion complexity and verification effort than on data volume. Large master differences, many external characters, and huge volumes of documents or scans push up cost. When taking estimates, clarify scope and compare vendors on equal terms.
Organizing unneeded data at migration reduces both cost and future operational burden at once. When considering whom to consult, discussing scope and cost thinking early with a vendor that has migration support, such as the Sakigake line, makes planning easier.
Having the estimate broken down by process—extraction, conversion, verification, and attendance—reveals where cost accrues. Choosing by cheapness alone can cut verification effort and end up harming quality, so assess the reasonableness of both the amount and the processes together.
Go-Live Schedule and Switchover
Plan go-live on a schedule that minimizes impact on care. The basics are to use long weekends or closed days and secure ample work and verification time for switchover. On the day, proceed per the procedure manual and prepare a contact structure for the unexpected.
What matters is deciding in advance the rollback criteria—at what point to revert to the old system if a problem occurs. Vague criteria delay the decision on the day and raise the risk of care stoppage. Defining the decision owner and contact flow in advance and having all stakeholders share the same procedure is the foundation of safe switchover.
Just after switchover is a period when old and new records easily coexist. It is safer to keep the old system referenceable for a set period and leave room for parallel checking until the field grows used to the new environment.
Checklist to Avoid Failure
- Have you documented migration and reference-storage scope and agreed across departments
- Have you created and reviewed the mapping table and code conversion rules
- Has the field verified garbling, loss, and unit discrepancies in test migration
- Have you secured the extraction request, cost, and deadline with the former vendor in writing
- Have you prepared the go-live switchover steps and rollback criteria
Summary
Data migration success is determined by narrowing scope, careful inventory and mapping, test migration and field verification with real data, and early coordination with the former vendor. Because cost moves with conversion and verification complexity rather than data volume, clarifying scope for comparison is important. Proceed step by step without rushing, preparing even rollback procedures for go-live.
RELATED