Validate behavioral health migration identity links across people, requests, episodes, encounters, documents, and financial records with exception evidence.
Migration identity validation should test both the person match and the relationships linking episodes, encounters, documents, appointments, and financial records. A correct patient total does not establish that the right information belongs to each person.
This guide describes acceptance planning for behavioral health data migration. It does not prescribe a universal matching algorithm or authorize record merges. Use the organization's approved patient-identification, clinical, privacy, and record-management processes.
EHR migration patient identity validation starts with keys
Inventory the identifiers used by every source and destination. Patient, request, episode, encounter, document, appointment, claim, and transaction identifiers can represent different objects. Preserve the crosswalk needed to explain their relationships.
The ASTP/ONC SAFER patient identification guide provides a primary safety reference. Use the organization's approved review process when defining identity decisions rather than assuming a convenient field match is sufficient.
Identify which system is authoritative for each relationship. A billing account and a clinical patient record may use different keys. The mapping should make the connection explicit without treating every source identifier as interchangeable.
Separate person matching from episode mapping
One person can have several legitimate episodes, requests, locations, or program relationships. The migration should preserve those distinctions while avoiding duplicate patient identities.
Use a fictional person with two historical episodes and one current request. Ask the receiving reviewer to identify which encounters, plans, documents, appointments, and balances belong to each relationship. A single consolidated timeline can be useful if attribution remains understandable.
Conversely, two people can share a name or contact information. Test whether the proposed process identifies uncertainty and routes it to authorized review instead of combining records automatically on insufficient evidence.
Preserve demographic changes and source history
Names, addresses, contact details, and other demographics can change. A difference between sources does not automatically establish a different person, and a matching value does not automatically establish the same person.
Record the evidence and decision behind an approved match. Keep the relevant source identifiers and dates so a later reviewer can explain how the migration linked records. Avoid depending on a one-time spreadsheet whose meaning disappears after cutover.
The ASTP/ONC EHI export test method provides a certification-related export reference. Inspect actual export identifiers and documentation; an available export does not by itself establish correct receiving-system identity mapping.
Build a known exception cohort
Choose fictional or appropriately authorized cases that challenge the mapping. Include same-name people, spelling changes, shared family contacts, duplicate source records, multiple episodes, and records imported from another organization.
Write expected relationships before the test. An importer should not be considered correct simply because the output looks plausible after the fact. Known expected cases let reviewers identify wrong associations and missing links.
| Exception | Relationship to inspect |
|---|---|
| Same name, different people | Documents and encounters remain separate |
| Changed demographics | Approved identity continuity and source history |
| Shared contact details | No unsupported person merge |
| Multiple episodes | Correct plan, service, and closure attribution |
| Duplicate source identity | Authorized review and documented treatment |
| External document | Correct person, source, and episode association |
| Financial account | Correct connection without losing transaction context |
The cohort supports learning and acceptance. It is not a statistical sampling method or a universal guarantee about every record in the migration.
Validate relationships at the record level
Open the receiving record as ordinary clinical, scheduling, and billing users. Check whether they can find the correct historical and active information. A technical foreign-key relationship can exist while the user-facing view remains confusing.
Compare source and destination identifiers, dates, document titles, authorship, episode context, and relevant financial references. Use totals as a completeness check, but inspect individual associations for correctness.
One missing record and one wrong association can leave aggregate counts unchanged. Record-level validation is necessary to identify that difference. Preserve discrepancies with evidence and owners rather than adjusting a total until it agrees.
Route uncertainty without forcing a match
Create an exception process for records that cannot be matched confidently under the approved method. Identify the evidence needed, authorized reviewer, next action, and disposition. Do not silently discard uncertain records or attach them to the most similar name.
Keep uncertain data access appropriately restricted. A broad migration tracker can contain references and status without exposing full clinical or financial records. Detailed evidence belongs in an authorized location.
If an approved correction changes the mapping, identify affected downstream records and retest them. A patient-level decision can influence encounters, attachments, schedules, reports, and balances. The review scope should reflect the actual relationships.
Test changes between rehearsal and cutover
Source records can change while migration preparation continues. Define how new patients, corrected demographics, new episodes, and approved source merges are reflected in the final crosswalk.
Use a fictional change after the rehearsal extract. Ask how the team identifies it, updates the mapping through the approved process, and validates the final result. A successful early import does not establish that later changes are covered.
Preserve crosswalk versions and final acceptance evidence. The organization should be able to distinguish the tested rehearsal from the final cutover mapping and explain any differences.
Put identity acceptance into the migration scope
Assign clinic and vendor responsibilities for source analysis, mapping, exception review, technical import, clinical and financial validation, and final acceptance. The technical importer should not decide every identity ambiguity or approve all business meaning alone.
Record available functions, configuration, manual review, external source dependencies, and unverified claims in the written proposal. A broad deduplication promise is less useful than a demonstrated process with known exceptions and accountable decisions.
Ease Health publishes this guide and offers a unified CRM, EHR, and RCM platform for behavioral health. Ask vendors to demonstrate the identity crosswalk and relationship validation with known fictional cases. Related material includes the EHR overview, migration source inventory, and duplicate-referral review guide.
The useful result is an evidence-backed set of identity links and an explicit unresolved queue. It gives the organization more confidence than matching counts without knowing which records belong together.
Related reading
Frequently Asked Questions
Does matching patient counts prove identity mapping is correct?
No. Counts can match while records are linked to the wrong person or episode. Validate relationships and known exception cases as well as totals.
Should name matching alone merge source records?
No. Follow the organization's approved identification and review process using appropriate evidence. Similar names and changed demographics can create uncertainty that needs authorized review.
What identity cases belong in a migration test?
Include same-name people, changed demographics, shared contact information, duplicate source records, multiple episodes, external documents, and unresolved matches.
Who should approve uncertain matches?
Assign authorized identity and record reviewers under the organization's policies. Technical staff should preserve the evidence and route uncertainty rather than silently resolving every ambiguity through an import rule.
