Patient-authorized EHR integration

How to normalize FHIR data across EHRs without losing the source.

Normalization should reduce application branching while retaining the evidence needed to explain, reconcile, and refresh every clinical fact.

Updated: 2026-08-25 · 12 min read

The bottom line

Normalize into stable product categories, but preserve the source resource type, logical and business identifiers, coding systems, timestamps, and availability state. A normalized value without provenance is easier to display but harder to trust.

Key takeaways

Use a canonical application model and retain a reversible link to the source representation.
Deduplication is a domain decision; equal display strings are not sufficient evidence that two records are the same.
Missing, unsupported, delayed, and revoked are different states and should not collapse into an empty array.

Evidence boundary: Uses FHIR R4 identity and Provenance semantics plus FinchNode’s source-aware record contract.

Author: FinchNode Engineering

Put every normalized item inside a provenance envelope

type NormalizedRecord<T> = {
  id: string;
  category: string;
  data: T;
  source: {
    connectionId: string;
    organizationId: string;
    fhirBaseUrl: string;
    resourceType: string;
    resourceId?: string;
    identifiers: Array<{ system?: string; value: string }>;
    lastUpdated?: string;
  };
  availability: 'available' | 'partial' | 'unsupported' | 'syncing' | 'revoked';
};

Normalize codes without flattening meaning

Retain every source coding system, code, display, and original text.
Add normalized terminology as an additional mapping rather than replacing the source coding.
Record the mapping version and confidence or review state.
Do not equate units until quantities have compatible dimensions and an explicit conversion.
Keep reference ranges source-specific because age, sex, method, and laboratory can change them.

Use layered, explainable deduplication

A conservative order for assessing possible duplicate records
Signal	Strength	Caution
Same source and stable business identifier	Strong	Confirm identifier system and source namespace
Same source logical ID and version lineage	Strong within one server	Logical IDs can change when copied between servers
Same code, value, date, and performer	Moderate	Repeated clinical events can be legitimately identical
Same display text	Weak	Text can hide different code systems or clinical meanings

Represent completeness as data

A source can authorize successfully while returning no resources for a category. That may mean the patient has no matching records, the server does not support the search, the scope was not granted, the source is delayed, or the connection is still syncing. Preserve the reason and observation time instead of returning an unexplained empty result.

Primary sources

More FinchNode interoperability guides

Frequently asked questions

Why normalize FHIR if it is already a standard?

FHIR standardizes resource structures and API patterns, but implementations can use different profiles, codes, resource choices, optional fields, and search behavior. Applications still need a stable product contract.

Should normalized data keep the original FHIR resource?

Keep an integrity-protected source representation or reference when policy and storage constraints permit it. At minimum, retain enough provenance and identifiers to explain and reconcile the normalized item.

Can records be deduplicated by code and date?

Those fields are useful signals but not proof. Repeated clinical events can share the same code and date, so deduplication should be source-aware and explainable.

What is the difference between missing and unsupported data?

Missing means a supported query returned no known value. Unsupported means the source or granted scope cannot provide that category. Syncing, failed, and revoked are additional distinct states.