Moving data into an electronic health record (EHR) sounds straightforward until you see what actually happens during the cutover window. A migration is not just a technical exercise, it is a clinical continuity problem. The moment you switch systems, every missing lab result, truncated allergy, incorrect patient identifier, or orphaned medication order can ripple into patient safety and billing integrity. Accuracy and completeness are not “nice to have” targets, they are the outcomes that decide whether clinicians trust the new system on day one.
I have seen migrations succeed because teams treated data like a living clinical asset. They planned for messy source data, they designed validation around real workflows, and they assumed that edge cases would show up at the worst possible time. This article focuses on practical ways to get accuracy and completeness, what to measure, and where projects tend to fail.
Why EHR migrations are different from “regular” data moves
A general data warehouse migration can tolerate some drift. You can backfill later, patch reports, or replay the ETL pipeline overnight. An EHR migration is different. It connects to clinical decision-making and revenue cycles immediately. If a patient’s demographics, problem list, allergies, or medication history does not land correctly, clinicians feel it in seconds, not weeks.
A few migration realities make the stakes feel unusually high:
First, EHRs have complex, intertwined data models. A single “problem” record can connect to encounter context, onset dates, status codes, and clinical categories. A medication history line can depend on drug codes, directions, start and end dates, and sometimes prior authorization details. When you transform any one of these fields, the assumptions in other fields may no longer hold.
Second, EHR data is not just structured. Free text in notes often contains critical information that users expect to see. The trade-off is that you can migrate it, but you must preserve context and timestamps so it remains useful and auditable.
Third, EHR data governance is operational. You are not only moving “what” data exists, you are moving “how” the organization expects it to be represented. That includes local coding practices, medication reconciliation preferences, and how the facility handles uncertainty (for example, unknown onset dates or partially verified allergies).
Defining “accuracy” and “completeness” before anyone writes code
The most common mistake I see is teams jumping directly into extraction and mapping without defining measurable success criteria. Accuracy and completeness become slogans instead of metrics.
A stronger approach starts by defining what “correct” means for each data domain in business terms, then translating that into validation rules.
Accuracy typically includes questions like:
- Did the patient identifier match the right person? Did clinical fields land with the correct values and code systems? Did date and time values preserve meaning across time zones and formats? Did the migration keep the original source provenance where it matters?
Completeness is broader and often harder to measure. Completeness is not only “did we transfer all rows.” It is also “did we preserve all clinically meaningful records and history,” including rows that were previously excluded by upstream filters.
For example, many organizations exclude “test patients” or inactive records from exports. That can be correct, but it requires agreement on what “inactive” means. Some systems treat “inactive” as “no longer eligible for future appointments,” while others use it as “do not display.” If the destination uses that field differently, you can accidentally hide data clinicians expect to see.
The practical step is to define domains such as patient demographics, encounters, allergies, medications, problems, immunizations, lab results, vitals, radiology, documents, and billing-relevant data if applicable. For each domain, specify:
Source of truth Field-by-field mapping expectations What “missing” means Validation thresholds and acceptable error rates A remediation path if failures exceed thresholdsIf you can’t answer those points clearly, the project will drift into reactive debugging during pilot and go-live.
Building a data inventory that reflects real clinical use
A migration plan often includes an extract spec and a mapping spreadsheet. That is necessary, but it is not sufficient. You also need a data inventory that reflects what clinicians and staff actually use.
I recommend building the inventory around how the EHR will function on day one. In practice, that means asking stakeholders to name what they will search for during rounds, chart review, and patient handoffs. For many facilities, the answer is usually something like: allergies, medication list, recent labs and imaging, active problems, and immunizations, plus demographics and contact information.
Then you translate that into the inventory as measurable assets:
- Count of unique patients expected in each domain Date ranges covered by the migration Expected frequency and volume of records per patient Code systems used in the source (for example, local drug codes, ICD-9 versus ICD-10) Dependencies, like which encounters are required to contextualize results
When I have seen teams struggle, it was rarely because the mapping spreadsheet was “wrong.” It was because they discovered late that a key dependency was missing. For instance, lab results might arrive but their ordering encounters are absent, leaving the EHR unable to anchor results to a visit. Another team might migrate problem list items, but they exclude the underlying clinical note that contains the rationale and original clinician assessment. The data did migrate, but it migrated in a way that clinicians immediately noticed.
A data inventory that mirrors real clinical use gives you a way to prioritize validation and minimize surprises.
Patient matching and identifiers: the highest-risk step
Patient matching is often the central risk. If your migration includes any kind of cross-system matching or normalization, you need to be deliberate. Even when you rely on an authoritative master patient index (MPI), the EHR may enforce its own constraints, such as unique key rules for certain demographic fields or requirements for insurance linkage.
Accuracy in patient matching is usually measured by match rates, collision rates, and reconciliation outcomes. Completeness is measured by coverage: how many source patients you expect to appear, and what portion end up as exact or survivable matches.
A practical lesson: do not treat patient matching as a one-time step. It is iterative. During pilot migrations, you will see patterns in mismatches. Common causes include:
- Inconsistent formatting of names and dates of birth Missing middle initials or alternate identifiers Data entry quirks like swapped day-month ordering Multiple source records that represent the same person
To protect clinicians and minimize operational disruption, migrations typically include a remediation workflow for mismatched records, rather than trying to “fix it all automatically.” Automated normalization can get you accuracy quickly, but human review is where ambiguity gets resolved safely.
Data mapping is where clinical meaning can get lost
Mapping is usually presented as value transformation: “ICD codes go here, drug codes go there.” In reality, mapping decisions encode clinical meaning.
A few examples illustrate what can go wrong:
- Medication directions: Source systems may store sig text differently from the destination. If you split fields incorrectly, clinicians may see an incomplete “how to take” instruction. Allergy types: Some source systems record allergy versus intolerance separately. If the destination only supports one concept and you force everything into one type, decision support may behave unexpectedly. Date granularity: Source systems sometimes store only a date, while the destination expects datetime. If you default missing times to midnight without a convention, sorting and clinical timelines can become misleading. Unit conversions: Lab results might store values with separate unit fields. If units get dropped or conversion rules differ, clinicians may interpret results incorrectly.
This is why mapping validation must include more than record counts. It must include semantic checks. A useful validation strategy is to sample patient charts that include a range of complexities: chronic conditions, polypharmacy, historical allergies, patients with multiple encounters, and patients with sparse data. You are testing meaning, not just structure.
Validation strategy that earns trust from clinicians and analysts
A strong validation plan uses multiple layers: automated checks, targeted audits, and workflow-based testing. You want to catch systemic errors early and catch “looks fine in a spreadsheet” issues before go-live.
Automated validation checks
Automated checks typically cover:
- Referential integrity: do migrated child records reference existing parent keys? Field-level completeness: are required destination fields populated? Format and range checks: dates are valid, numeric results within plausible bounds, code fields conform to expected formats. Duplicate detection: are there unexpected duplicates that could cause chart clutter or clinical confusion?
These checks help you move quickly. However, they do not guarantee clinical meaning is preserved.
Targeted chart audits
Chart audits are where quality becomes real. The goal is to compare the Find more information source chart to the destination chart, focusing on what a clinician would notice. A chart audit does not need to cover every record, but it should cover enough complexity to reveal mapping gaps.
You can use sampling logic such as:
- Random samples across the patient population High-impact samples like ICU stays, oncology patients, and long-term care residents Samples designed to hit edge cases: partial dates, missing units, ambiguous allergies, and records with unusual coding
When I have participated in these audits, the most valuable findings were not always catastrophic errors. Often they were “silent failures,” like allergy status mapped to the wrong field so it still displayed but filtered incorrectly in search, or lab result timestamps shifted by a day because of time zone handling.
Workflow-based testing
The final layer is testing how staff will actually use the system. That means validating that the EHR can find and display data across common navigation paths. Clinicians do not care about your ETL pipeline. They care about whether they can reliably review a patient history and reconcile medications.
Workflow testing also reveals performance and usability constraints that interact with data quality. For example, if migrated documents are missing metadata, search may not find them even though the files exist. Or if medication histories load slowly because of indexing issues, users may assume “the data is missing.”
Migration choreography: pilot, parallel run, and what to do with deltas
Most organizations use a phased approach rather than a single “big bang.” Even when there is no full parallel run, you need a way to handle changes during the migration window.
A common approach is:
- Pilot migration: a representative subset of patients or time range Fix and iterate: address mapping issues and validation failures Production migration: migrate all required data Delta handling: migrate records created or updated after the initial extraction
Delta handling is where completeness can break down. If you extract early and then only partially capture changes, the destination can end up missing new orders or updated lab results between extract time and cutover.
The most defensible strategy is to define a clear delta capture method and validation rules for deltas. You also need an agreement on cutover timing. If you cut over at 7:00 AM, what systems are authoritative for data updates after that timestamp? If a lab posts between the delta window and cutover, who wins?
Operational clarity matters. You do not want a debate during go-live about whether a missing result is a migration defect or an expected cutover artifact.
Remediation workflow: how you prevent “known issues” from lingering
Even with strong planning, something will fail validation. The question is whether the remediation process is fast enough and disciplined enough to prevent “known issues” from becoming permanent.
A remediation workflow typically includes:
- Issue triage categories (data mismatch, mapping transformation error, missing reference keys, transformation logic bug) Severity grading based on clinical impact Assignment to an owner, like data engineering versus interface team versus clinical informatics A fix verification step, including regression tests for related domains Documentation of decisions, especially for any rule overrides
I have seen teams focus so hard on fixing the first batch of failures that they ignore a “near miss” list. Near misses are data quality issues that barely pass a threshold. They are often the first clues of systemic problems, like a code mapping set that is missing a small subset of values. Those “almost correct” records show up later as clinician complaints, because they are exactly the kind of data that users search for when something feels off.
If your remediation workflow has good logs and a clear closure policy, it becomes easier to trust your final data set.
Measuring completeness with business-facing metrics
Counts and percentages can mislead you if they do not reflect what users need. A migration might show 99.9 percent field population for a required column, yet still feel incomplete if the missing records cluster in a clinically critical group.
To measure completeness in a way stakeholders understand, tie metrics to business-facing outcomes. Examples of business-facing metrics include:
- Coverage of recent labs for active patients Presence of current medication lists for patients with recent encounters Allergy completeness, including allergy type and status Document availability for the last N months Encounter context for results display
You do not need to measure everything, but you need enough to demonstrate that completeness aligns with daily workflows. In one project, automated checks passed for immunizations, but a targeted audit found that immunization records for patients with external provider data were missing because the source interface filtered by a system-specific provider ID. The overall field completeness looked fine, but the coverage for a high-use subgroup was poor. Once the team corrected the provider mapping logic and reran validation, clinician trust increased quickly.
Special cases that often cause trouble
EHR migrations are full of edge cases. If you do not plan for them, they will absorb time during the final week.
Partially known dates
Birth dates, onset dates, medication start dates, and lab times sometimes include partial information. Your destination may expect a complete datetime or a specific granularity. If you default dates arbitrarily, clinical timelines can become wrong.
A electronic health record (EHR) defensible pattern is to preserve the original granularity where possible and flag uncertainty where the EHR supports it. If the EHR does not support uncertainty, you at least document your defaulting rules and validate downstream display behavior.
Code system differences
Mappings between code systems are rarely perfect. Drug vocabularies, diagnosis code systems, allergy coding conventions, and lab test codes often differ. A mapping that sends everything to a fallback “unknown” code may satisfy a structural rule but damages clinical utility and reporting.
You need a method for handling unmapped values. It can be a fallback display, an “external code” preservation, or a clinical review queue. Whatever you choose, measure how often it happens, and prioritize fixing the most frequent unmapped categories.
Duplicates and near duplicates
Duplicates can creep in during migration when patient matching is imperfect or when source systems represent the same clinical event in multiple tables. Even if duplicates exist in the source, you might amplify them by joining incorrectly or by migrating both original and derived records.
The best approach is to use duplicate detection checks that look for combinations, like patient key plus encounter key plus timestamp plus code. Automated detection needs careful tuning to avoid false positives that waste time, and to avoid false negatives that create chart clutter.
A realistic cutover checklist for accuracy and completeness
You cannot validate everything at the last minute, but you can prepare a tight cutover plan focused on the domains most likely to fail.
Here is a short checklist style reminder of what I would personally insist on before flipping the switch:
Confirm that patient identifiers are unique and consistent across migrated domains, with a documented remediation path for mismatches Verify that allergies, active medications, and key problem list fields display in a clinician-facing chart view for a sample of real patients Run referential integrity checks so results, orders, and documents anchor correctly to encounters and chart sections Validate delta extraction and updates across cutover boundaries, then spot-check recent activity for a handful of patients Freeze change management on mapping logic during the final validation period, with tightly controlled hotfix handlingThat is deliberately short. In practice, you will add domain-specific checks in parallel, but this gives a sense of the areas where accuracy and completeness are most likely to be compromised during cutover.
Governance and auditability, not just “data loaded”
After go-live, migrations often face two pressures: clinicians who want their history to make sense immediately, and analysts who need traceability for reporting and audits.
A migration can produce complete data but still fail governance if provenance is lost. Provenance means knowing where a value came from, when it was extracted, and how it was transformed. In many organizations, provenance matters for:
- Clinical documentation disputes (what did the record show originally?) Billing and compliance reviews Investigations into erroneous mappings Future migrations and upgrades
You do not need to create a full audit warehouse for every field. But you should maintain enough logging to reconstruct mapping decisions and data lineage. That includes interface logs, transformation logic versions, and counts by domain and time window.
If you handle this well, it becomes far easier to respond when a clinician asks a simple question like, “why is this allergy marked as resolved?” without turning it into a guessing game.
Balancing completeness with what the EHR can practically show
One temptation during migration is to load everything, including questionable historical data. Completeness feels safer than trimming.
In practice, overly inclusive migration can degrade usability. Clinicians may face long lists of irrelevant items, outdated entries, or records with unreliable timestamps. The EHR becomes slower to navigate, and decision support logic may behave in ways that do not reflect clinical intent.
The right balance depends on local policy and the EHR’s capabilities. Some organizations migrate historical events broadly but mark them as inactive or superseded. Others only migrate a rolling window plus critical long-term history such as allergies and chronic diagnoses.
A useful decision is to treat “clinical relevance windowing” as a governance policy rather than a technical convenience. If you decide to keep only the last X months of certain domains, that should be explicit, reviewed, and validated against user expectations.
What quality looks like in day one reality
On day one, “accuracy and completeness” show up in small interactions:
- A clinician opens a chart and sees allergies in the right status and type, so they do not have to double-check everything. The medication list matches what the patient reports, or at least includes the same key medications, so medication reconciliation feels like refinement rather than reconstruction. Lab results show in the right time order, so trends are visible without manual re-sorting. The notes and documents that matter for care transitions are searchable and attached correctly, so staff does not recreate missing summaries.
When those interactions land well, teams stop asking “is the migration complete?” and start asking more productive questions about workflows, templates, and training.
When they land poorly, you get a flood of manual work. People will copy data forward, recreate medication lists, and keep parallel spreadsheets. That is a sign that the migration did not just fail a technical requirement, it failed to preserve clinical meaning.
Common failure patterns and how to prevent them
You can avoid many migration problems by recognizing where teams get lazy.
Here is a compact mapping of common failure patterns to prevention steps, based on what I have seen during EHR transitions:
| Failure pattern | Typical symptom | Prevention step | |---|---|---| | Field mapping passes validation but semantic meaning shifts | Data displays, but filters and timeline sorting behave oddly | Validate against clinician-facing views and ordering logic, not only row counts | | Missing referential integrity | Results or documents appear without proper encounter context | Enforce parent-child key checks and test navigation from encounters to results | | Unhandled delta changes | Recent labs or orders missing after cutover | Define cutover authority windows and validate delta coverage with spot-checks | | Overreliance on automated checks | Migration “looks correct” in logs but breaks chart workflows | Pair automation with chart audits across complex patient profiles | | Too many last-minute mapping tweaks | Unexpected regressions near go-live | Freeze mapping logic late, route hotfixes through strict validation gates |
This table is not exhaustive, but it captures a pattern: failures often hide behind “it loaded.” The fix is to validate what clinicians do, how they look for data, and how the system organizes it.
Keeping quality after go-live: monitoring and continuous improvement
Migration work is not finished at go-live. After the switch, you need monitoring focused on data correctness and completeness. Clinician feedback is essential, but it should be paired with objective checks.
Good post-go-live monitoring includes:
- Dashboards for error rates and missing data indicators in key domains Reconciliation counts, such as how often a clinician sees “no results found” for patients expected to have results Tracking of high-priority issues with root cause analysis A process for reprocessing or patching data when fixes are identified
One practical detail: decide early how you will handle re-migrations. Sometimes the fix is to adjust transformation logic and rerun a subset. Other times it is better to patch destination records directly. Either approach can work, but it must be controlled so you do not create new inconsistencies.
The bottom line: accuracy and completeness are engineered outcomes
Data migration for an EHR is not merely about moving data from one format to another. It is about preserving clinical meaning, ensuring that patient context survives transformations, and maintaining trust at the exact time clinicians need it most.
The projects that perform best tend to share a few habits: they define accuracy and completeness in measurable, business-facing terms; they validate with real workflows rather than only automated checks; they plan for delta handling and patient matching risks; and they build a remediation process that moves quickly without losing rigor.
If you build those habits into your migration program, you reduce the chaos that otherwise shows up right before cutover. More importantly, you improve the chance that the first time a clinician opens a patient chart in the new system, the history feels familiar and complete, not fragile and incomplete.