Full checklist › Allergy & problem-list granularity loss
Allergy & problem-list granularity loss High-risk silent loss
Status and granularity fields default-flatten during migration. A refuted or entered-in-error allergy arriving as 'active', or a resolved problem reappearing as active, is a patient-safety event — not a cosmetic data issue.
Anchored to:
• FHIR AllergyIntolerance (R4) — HL7 International
• USCDI — US Core Data for Interoperability — ONC/ASTP (Standardized data classes/elements; the portability baseline.)
General IT / operational guidance — not medical, legal, or compliance advice. This is a data-integrity validation checklist for EHR migration. Standards and versions revise; verify every citation and version against the live owner page and confirm requirements with your EHR vendor and your organization's compliance/HIM team before acting.
What to validate
- AllergyIntolerance: confirm `clinicalStatus` and `verificationStatus` (unconfirmed|confirmed|refuted|entered-in-error) do NOT default-flatten — a refuted/entered-in-error allergy migrating as active is a safety event.
- Confirm `reaction.manifestation` (the actual symptom) and per-reaction `severity` (mild|moderate|severe) and `criticality` (low|high|unable-to-assess) survive as distinct fields.
- Condition (problem list): preserve `category` so problem-list-items aren't merged with encounter-diagnoses or dropped.
- Preserve `clinicalStatus` (active|recurrence|relapse|inactive|remission|resolved) so resolved problems don't reappear as active.
- Confirm `onset[x]` / `abatement[x]` datatypes round-trip (date vs Period vs Age) without coercion.
Get the runnable validation toolkit →All 7 failure modes
Not medical advice. IT/operational guidance for EHR data-migration validation, anchored to official HL7/FHIR, ONC/ASTP, HIPAA (eCFR), and code-system sources. Last verified 2026-06-22. Verify versions and requirements with your vendor and compliance team. Some outbound links may be referral links.