A FHIR-Native Harmonization Overlay for Semantic Interoperability

1. Introduction

The adoption of HL7 Fast Healthcare Interoperability Resources (FHIR) has transformed healthcare data exchange, providing a modern, web-based standard for representing and sharing clinical information [1]. Over the past decade, FHIR has been embraced by healthcare systems, payers, research networks, and government initiatives worldwide, including the Trusted Exchange Framework and Common Agreement (TEFCA) in the United States [2,3]. Despite this widespread adoption, a fundamental challenge persists: semantic interoperability remains elusive even when syntactic interoperability is achieved.

Two endpoints can be fully FHIR-compliant yet encode the same clinical concept using different profiles, extensions, coding systems, value sets, units of measure, and identity practices. A patient's diagnosis might appear as an ICD-10-CM code in one system, a SNOMED CT concept in another, and a local vocabulary in a third. A laboratory result might use LOINC codes with different proprietary extensions, units expressed in varying formats, and reference ranges documented in inconsistent ways. These variations force downstream consumers — analytics platforms, research databases, quality measurement systems, and clinical decision support tools — to rebuild endpoint-specific extract-transform-load (ETL) logic, terminology mappings, and identity resolution workflows repeatedly.

1.1 The Semantic Interoperability Gap

The gap between syntactic and semantic interoperability can be characterized across several dimensions:

1. Profile Variation: Endpoints implement different FHIR profiles, with varying combinations of required and optional elements, cardinality constraints, and extension usage. A Patient resource in one system might include extensive demographic extensions while another uses only core elements.
2. Terminology Heterogeneity: The same clinical concept may be represented using different code systems (ICD-10-CM vs. SNOMED CT), different versions of the same system, local codes not mapped to standard terminologies, or free text when coded values are expected.
3. Value Encoding Differences: Numeric quantities may use different units (mg/dL vs. mmol/L), dates may have varying precision (date vs. dateTime), and missing values may be represented through absent reasons, omissions, or sentinel values.
4. Identity Fragmentation: Patient records for the same individual across different endpoints lack consistent identifiers, forcing probabilistic matching or manual reconciliation. Even when identifiers exist (e.g., MRNs), they are often institution-specific and not shareable.

As healthcare networks grow from tens to thousands of endpoints, the manual effort required to reconcile these differences becomes unsustainable. What is needed is a systematic approach that can observe, learn, and adapt to endpoint-specific patterns while providing consistent, governed harmonization across the network.

1.2 Contributions

This paper presents a FHIR-native harmonization overlay that addresses these challenges through three novel contributions:

1. Data Profile Identifiers (DPIDs): A decentralized primitive for content-addressed fingerprinting of observed FHIR profiles. DPIDs enable endpoints to be compared, clustered, and monitored without requiring a central authority or prior coordination. The DPID is derived from a canonicalized signature that is stable under non-semantic variations (e.g., array ordering, URI formatting differences) but sensitive to meaningful semantic changes.
2. A Formal Profile Space: A mathematical framework for representing observed FHIR profiles as descriptors combining structural path information, terminology usage, and value distributions. We define a similarity metric that enables clustering of similar profiles and detection of drift over time, supporting both exact matching via DPIDs and approximate matching via similarity thresholds.
3. Governed Harmonization Lifecycle: A staged rollout process for harmonization artifacts — profile family assignments, terminology crosswalks, normalization transforms, and identity linkage rules — that ensures safety through shadow evaluation, canary deployment, and automated rollback capabilities. This lifecycle treats harmonization artifacts as versioned, auditable software components subject to quality gates and governance approvals.

1.3 Paper Organization

The remainder of this paper is organized as follows. Section 2 reviews related work in FHIR interoperability, identity management, and profile analysis. Section 3 presents the design goals and system requirements. Section 4 describes the high-level architecture of the harmonization overlay. Section 5 formalizes observed profiles and Data Profile Identifiers, including the canonicalization procedure and similarity metrics. Section 6 addresses federated identity and Global Patient Identifiers. Section 7 specifies the governed artifact lifecycle and rollout stages. Section 8 presents experimental evaluation of DPID stability. Section 9 discusses implications, limitations, and future work. Section 10 concludes.

2. Related Work

The challenge of semantic interoperability in healthcare has attracted significant attention from standards development organizations, product vendors, and research communities. This section situates our contribution within the broader landscape of FHIR interoperability, identity management, profile analysis, and terminology services.

2.1 FHIR Exchange Frameworks and Governance

The most significant policy-level initiative for healthcare interoperability in the United States is the Trusted Exchange Framework and Common Agreement (TEFCA) [2,3]. TEFCA establishes a common governance framework for exchanging electronic health information across networks, defining technical requirements, security protocols, and participant obligations. While TEFCA addresses trust and exchange at the network level, it does not by itself eliminate semantic variation in how endpoints populate FHIR resources. Endpoints can be fully TEFCA-compliant while exhibiting the semantic variations described in the introduction. Our overlay complements TEFCA by providing the semantic harmonization layer needed for consistent interpretation across the network.

The Office of the National Coordinator for Health IT (ONC) has also advanced the United States Core Data for Interoperability (USCDI) standard [4], which defines a standardized set of health data classes and elements for exchange. USCDI provides important guidance on what data should be exchanged but does not prescribe how it should be represented when variations exist across sources.

2.2 Identity Management and Patient Matching

Patient identity resolution is a critical prerequisite for cross-organizational data integration. The Integrating the Healthcare Enterprise (IHE) has developed several profiles addressing identity management:

• Patient Identifier Cross-reference for Mobile (PIXm) [5]: Provides a RESTful interface for cross-referencing patient identifiers across different domains, enabling query of a patient's identifiers in other systems.
• Patient Demographics Query for Mobile (PDQm) [6]: Supports querying for patients based on demographic data, returning matching patient resources with their identifiers.
• Patient Master Identity Registry (PMIR) [7]: Defines workflows for maintaining patient master identity data, including feed, query, and update operations for patient identity sources.

The HL7 Identity Matching Implementation Guide [8] extends these capabilities by defining operations for patient matching across organizational boundaries, including match scoring, threshold configuration, and result ranking.

Enterprise Master Patient Index (EMPI) and Master Data Management (MDM) systems represent mature commercial solutions for identity resolution [9-11]. These systems implement sophisticated matching algorithms — often based on probabilistic record linkage methods such as Fellegi-Sunter [12,13] — and maintain "golden" patient records that consolidate identifiers from multiple sources.

Our approach differs in two key respects. First, we treat identity linkage as an evidence-based process where matches are accompanied by provenance and can be adjudicated through governed workflows. Second, we use observed profile characteristics to inform blocking and matching strategies, adapting to the actual data shapes present at each endpoint rather than assuming a uniform patient representation.

2.3 FHIR Profiling and Implementation Guide Tooling

The FHIR specification includes a robust profiling framework that allows implementers to constrain resources for specific use cases. Tools such as Simplifier [14], Forge [15], and Trifolia-on-FHIR [16] support authoring, publishing, and managing FHIR profiles and Implementation Guides (IGs). These tools focus on declared profiles — the specifications that endpoints claim to implement. In practice, endpoints frequently deviate from declared profiles, mix multiple patterns, or implement profiles that are not formally published.

Our work complements these tools by providing observational profiling: deriving empirical profile signatures from live FHIR instances. This observational approach captures the de facto data shapes in use, which may differ significantly from declared profiles. The DPID primitive enables these observational profiles to be compared, clustered, and tracked across endpoints without requiring endpoints to publish formal IGs.

2.4 Terminology Services and Cross-Mapping

Terminology integration has long been recognized as a core challenge in health informatics. The Unified Medical Language System (UMLS) [17] provides a comprehensive metathesaurus integrating over 200 source vocabularies, including ICD-10-CM, SNOMED CT, LOINC, and CPT. The UMLS includes mappings between codes across different systems, enabling translation between terminologies.

Commercial terminology servers (e.g., Apelon, Health Language, Wolters Kluwer) provide value set management, code validation, and cross-mapping capabilities. The HL7 Terminology Services specification defines standard interfaces for terminology operations.

Our overlay integrates terminology mapping as a governed artifact type, allowing crosswalks to be developed, tested, and deployed through the same staged rollout process as other harmonization artifacts. The profile similarity metric incorporates terminology usage patterns, enabling detection of endpoints that use different code systems for the same semantic concepts.

2.5 Self-Healing Systems and Adaptive Integration

The concept of self-healing systems has been explored extensively in software engineering and database research [18]. In the context of data integration, adaptive systems that learn from feedback and adjust mappings automatically have shown promise [19]. Our approach extends these ideas by providing a formal framework for detecting drift, generating patch candidates, and validating changes through shadow execution before deployment.

2.6 Positioning of This Work

Across these categories, prior work offers important capabilities, but interoperability programs still incur repeated, endpoint-specific effort to reconcile identity, profile variation, and terminology differences. The proposed overlay composes these concerns around a decentralized profile primitive (DPID) and an operational governance lifecycle, enabling semantic harmonization to be executed and evolved safely at scale. The overlay is designed to complement existing infrastructure — it can integrate with established identity systems, terminology servers, and FHIR platforms while filling the practical gap between syntactic conformance and operational semantic reuse.

3. Design Goals and Requirements

This section establishes the design goals and system requirements that guide the FHIR Harmonization Overlay architecture.

3.1 Syntactic vs. Semantic Interoperability

We begin by establishing precise definitions that distinguish between levels of interoperability:

Definition 3.1 (Syntactic Interoperability). Syntactic interoperability is the ability to exchange FHIR resources that validate against the base specification and applicable implementation guides. Two endpoints achieve syntactic interoperability if they can successfully transmit and receive FHIR resources that satisfy the structural constraints of the relevant FHIR version and profiles.

Definition 3.2 (Semantic Interoperability). Semantic interoperability is the ability for two independently produced resources to be interpreted with equivalent meaning in downstream workflows (analytics, registries, decision support) without endpoint-specific transformation. Two resources are semantically interoperable if a consumer can apply the same interpretation logic to both and derive equivalent clinical meaning.

Semantic interoperability requires that resources use consistent representations for concepts, codes, units, and identifiers, or that variations are systematically mapped to a canonical representation through governed transformations.

3.2 System Requirements

A multi-organization interoperability solution must satisfy the following requirements:

1. FHIR-Native Connectivity: The overlay MUST connect to any FHIR R4/R4B server via standard REST APIs, including search, history, and $export bulk data operations when supported. No proprietary extensions or custom APIs should be required.
2. Non-Invasive Deployment: The overlay MUST operate as a sidecar service that reads from FHIR servers but does not modify them directly. No privileged database access, schema modifications, or server replacements are permitted.
3. Privacy-Preserving Control Plane: Orchestration messages MUST remain non-PHI, carrying only identifiers, hashes, and references rather than raw clinical data. Patient-identifiable information should never appear in control-plane messages.
4. Tenant Isolation with Optional Federation: By default, all artifacts and learning are tenant-scoped (per endpoint or per organization). Cross-tenant federation MAY be enabled only with explicit consent, policy acceptance, and appropriate privacy protections.
5. Governance and Auditability: Every harmonization artifact — profile family assignment, terminology crosswalk, identity linkage, normalization transform — MUST be versioned, immutable once published, and accompanied by provenance metadata including creation timestamp, responsible actor, and evidence references.
6. Safe Rollout Capabilities: Artifacts that affect production behavior MUST support staged rollout through shadow (parallel evaluation), canary (limited traffic), and active (full deployment) phases, with automated quality gates and rollback capabilities.
7. Scalability: The system MUST support \(10^2\text{–}10^4\) endpoints and \(10^7\text{–}10^{10}\) resources through sampling strategies, incremental processing, and efficient indexing. Bulk bootstrap operations should leverage FHIR $export where available.

3.3 Design Trade-offs

The overlay design embodies several deliberate trade-offs:

• Stability vs. Sensitivity: The DPID signature is designed to be stable under non-semantic variations (e.g., array ordering, URI formatting) but sensitive to meaningful semantic changes. This trade-off is controlled through hysteresis margins and threshold parameters that determine when a path or terminology is considered part of the stable signature.
• Precision vs. Recall in Identity Linking: Patient matching thresholds balance the risk of false merges against the cost of false non-matches. The overlay supports configurable thresholds and routes uncertain matches to adjudication rather than making irreversible decisions.
• Automation vs. Governance: Self-healing capabilities can propose and validate changes, but promotion to active status requires passing quality gates and, for safety-critical changes, human approval. This ensures that automation accelerates rather than bypasses governance.

4. System Architecture

The FHIR Harmonization Overlay (FHO) is a deployable set of services that operates adjacent to one or more FHIR servers, interacting through standard FHIR APIs and maintaining a governed registry of derived artifacts.

4.1 High-Level Architecture

Figure 1 presents the Hilbert space representation of clinical concepts, which forms the mathematical foundation for our approach. Figure 2 illustrates the calibration methods used to ensure accurate confidence estimates, while Figure 3 shows the Semantic Evidence Graph architecture that provides complete traceability for every classification decision.

The architecture comprises several functional layers:

• Connectivity Layer: Handles communication with FHIR servers, including capability negotiation, bulk data export, incremental change feeds, and subscription management. This layer abstracts away differences in FHIR server implementations and provides a uniform interface to the rest of the system.
• Observation Layer: Performs empirical profiling of FHIR resources, extracting structural patterns, terminology usage, and value distributions. This layer computes observed profile descriptors and generates Data Profile Identifiers (DPIDs) through canonicalization and hashing.
• Identity Layer: Implements federated patient identity management, including match feature extraction, scoring, linkage evidence storage, and Global Patient Identifier (GPID) minting. This layer integrates with existing identity infrastructure when available.
• Harmonization Layer: Maintains governed artifacts including profile family registries, terminology crosswalks, normalization transforms, and identity policies. This layer implements the staged rollout lifecycle and provides APIs for artifact query and retrieval.
• Governance Layer: Manages artifact lifecycles, approval workflows, quality gates, and audit logging. This layer ensures that all changes are traceable, reversible, and compliant with organizational policies.

4.2 Connectivity and Capability Negotiation

Onboarding a new endpoint begins with retrieving its CapabilityStatement to determine which operations and interactions are supported. The overlay negotiates the most efficient data access method:

• Bulk Data Export: If the endpoint supports FHIR Bulk Data Access ($export) [1], the overlay initiates bulk export jobs to efficiently retrieve large volumes of resources. This is the preferred method for initial onboarding and periodic full refreshes.
• Incremental Change Feeds: For ongoing updates, the overlay uses _since parameters on history interactions to retrieve resources modified since a specified timestamp. When supported, subscriptions provide real-time notifications of resource changes.
• Sampling Strategies: For very large endpoints where full export is impractical, the overlay implements stratified sampling to obtain representative resources for profile analysis while minimizing load on the source system.

All data access respects the endpoint's rate limits and includes appropriate retry logic with exponential backoff. The overlay maintains a manifest of processed resources to enable resumable operations and detect missed updates.

4.3 Artifact Storage and Registry

All derived artifacts are stored in a versioned, immutable artifact store with content-addressed addressing. The registry maintains metadata about each artifact including:

• Unique identifier and version
• Content hash (SHA-256) for integrity verification
• Creation timestamp and responsible actor
• Dependencies on other artifacts (e.g., which DPID versions were used to generate a profile family)
• Lifecycle state (draft, shadow, canary, active, deprecated, retired)
• Quality metrics and evaluation results
• Approval records and governance metadata

Artifacts are immutable once published; updates create new versions with appropriate lineage links to predecessors. This immutability ensures reproducibility and auditability.

5. Observed Profiles and Data Profile Identifiers

The core innovation of our approach is the Data Profile Identifier (DPID): a content-addressed fingerprint that enables decentralized comparison and clustering of observed FHIR profiles. This section formalizes the observed profile descriptor, the stable signature, and the canonicalization procedure that makes content addressing meaningful.

5.1 Observed Profile Descriptor

Let \(E\) denote a FHIR endpoint and \(R\) a resource type (e.g., Patient, Condition, Observation). Let \(X_{E,R}\) be a multiset of observed instances obtained from \(E\) over a time window. An observed profile descriptor summarizes empirical structure, terminology, and value behavior:

The components are defined as follows:

• \(P\) is the set of observed element paths using a normalized dot notation with index-free arrays. For example, Patient.name.given and Patient.name.family are paths, with multiple name occurrences collapsed to a single path representation.
• \(C\) captures prevalence and cardinality summaries for each path. For a path \(p\), we record:
  • Prevalence: \(\Pr[x \text{ contains } p]\) across observed instances
  • Cardinality distribution: minimum, maximum, mean, and mode of occurrences
  • Type information: inferred data type based on observed values
• \(M\) captures terminology metadata, including:
  • Code system URIs observed in coded elements (e.g., http://hl7.org/fhir/sid/icd-10-cm)
  • Identifier namespaces observed in identifier systems
  • Extension URLs and their prevalence
  • Value set URIs when available
• \(V\) captures coarse value behavior for stability, including:
  • Categorical value sets for enumerated fields (e.g., Patient.gender values)
  • Date distributions bucketed at appropriate granularities (decade for birth dates, year for event dates)
  • Quantity units and approximate distributions
  • Common patterns for free text fields (e.g., presence of structured templates)

The descriptor intentionally excludes full raw data and precise distributions to preserve privacy while retaining sufficient information for profile comparison.

5.2 Stable Signature and the DPID

A naive approach that hashes all observed statistics would be overly sensitive to sampling noise. A single resource with an unusual extension could change the descriptor and thus the hash, even though the endpoint's typical behavior is unchanged. We therefore define a stable signature \(\sigma(\Pi)\) used for content addressing, derived from \(\Pi\) using hysteresis margins.

Let \(\tau_p\) be the minimum prevalence for a path to be considered "present" in the stable signature, and let \(\delta_p\) be a stability margin. Define the stable path set:

Paths with prevalence between \(\tau_p - \delta_p\) and \(\tau_p + \delta_p\) are considered ambiguous and excluded from the stable signature to prevent oscillation due to sampling variation.

Similarly, for code system and terminology frequencies, define a stable terminology set \(S^\star\):

For value distributions, we retain only stable categorical patterns. For a categorical field with values \(\{v_1, \dots, v_k\}\), define the stable value set:

The complete stable signature is then:

The Data Profile Identifier is a content-addressed hash of the canonicalized signature:

The base64url encoding ensures the DPID can be used in URIs and other contexts without special escaping.

5.3 Canonicalization: Making Content Addressing Meaningful

The DPID guarantee depends critically on a deterministic canonicalization function \(\mathrm{canon}(\cdot)\). Poor canonicalization can over-fragment (same profile → different DPID) or over-merge (different profiles → same DPID). Algorithm 1 specifies the normative canonicalization procedure.

The canonicalization procedure ensures that semantically equivalent profiles produce identical DPIDs regardless of superficial variations in representation.

5.4 Similarity, Clustering, and Drift in Profile Space

While DPIDs provide exact matching, we also need approximate similarity measures for clustering similar profiles and detecting gradual drift. We embed profile descriptors into a feature space and define a similarity metric.

Let \(\phi(\Pi)\) be an embedding function that maps a descriptor to a feature vector. We decompose the embedding into structural, terminology, and value components:

For structural features, we use Jaccard similarity on the stable path sets:

For terminology features, we similarly use Jaccard similarity on stable terminology sets:

For value distributions, we use Jensen-Shannon divergence on normalized histograms. For a value path \(q\), let \(H^q_i\) be the normalized histogram over bins. The Jensen-Shannon divergence is:

where \(M = \tfrac{1}{2}(H^q_i + H^q_j)\) and \(\mathrm{KL}\) is Kullback-Leibler divergence. The average JSD across value paths is:

where \(Q_V\) is the set of value-bearing paths included in the comparison.

The overall similarity metric combines these components with learned weights:

with \(w_P + w_T + w_V = 1\).

This similarity metric enables clustering of profiles into families, detection of drift when consecutive windows show decreasing similarity, and identification of outlier endpoints that deviate from common patterns.

5.5 Incremental Clustering with Prototype Signatures

Given a stream of observed profiles, we maintain clusters using an incremental algorithm that updates prototype signatures. Each cluster \(K\) maintains counts \(c_P(p)\) for each path \(p\) and counts \(c_T(t)\) for each terminology \(t\). The prototype signature for cluster \(K\) is:

where \(\tau_c\) and \(\delta_c\) are cluster-level hysteresis parameters. This yields an explicit, updateable prototype that represents the stable characteristics of the cluster.

When a new profile \(\Pi\) arrives, we compute its similarity to existing cluster prototypes. If \(\max_K \mathrm{sim}(\Pi, \mathrm{proto}(K)) \ge \epsilon\), we assign \(\Pi\) to the closest cluster and update cluster statistics. Otherwise, we create a new cluster with \(\Pi\) as its initial prototype.

This approach scales linearly with the number of profiles and supports online operation as new endpoints are onboarded.

5.6 Drift Detection

For a fixed endpoint and resource type, we compute descriptors in consecutive time windows \(t\) and \(t+1\) and report drift:

A DPID change provides a coarse drift signal when the stable signature changes. Even without a DPID change, \(\Delta_t\) can increase due to gradual shifts in value distributions or terminology usage patterns.

When drift exceeds a configurable threshold, the system generates a drift alert and may trigger remediation workflows, including re-evaluation of profile family assignments and updates to harmonization artifacts.

6. Federated Identity: Minting Global Patient IDs

Identity harmonization across healthcare endpoints remains one of the most challenging aspects of interoperability. Patient records for the same individual may exist in multiple systems with different identifiers, demographics recorded with varying precision and format, and linkage evidence of varying quality. This section describes how the overlay addresses identity through federated matching and Global Patient Identifiers (GPIDs).

6.1 Identity Goals and Scope

The identity component of the overlay has the following goals:

1. Associate multiple Patient representations (potentially across different endpoints) with a stable person identifier while minimizing false merges.
2. Preserve auditability by recording all linkage evidence, including match scores, blocking keys, and the specific data elements used in comparisons.
3. Support adjudication workflows for uncertain matches, allowing human reviewers to resolve ambiguous cases with full context.
4. Integrate with existing identity infrastructure when available (e.g., PIXm, PMIR, enterprise EMPI systems) rather than replacing it.

6.2 Probabilistic Record Matching Framework

The overlay implements a flexible matching framework based on the Fellegi-Sunter model of record linkage [12]. For a candidate pair of patient records \((a, b)\), we compute a match score:

where \(f_i\) are comparison functions for individual fields (e.g., name similarity, date of birth exact match, phone number normalized comparison) and \(w_i\) are learned weights.

The comparison functions are designed to be robust to common variations:

• Name comparison: Uses phonetic encoding (e.g., Soundex, Metaphone) for surname matching, edit distance for given names, and handles common nicknames and name parts (prefixes, suffixes, middle names).
• Date comparison: Accounts for varying precision (year-only vs. full date), partial agreement (same year and month but different day), and common data entry errors.
• Identifier comparison: Normalizes identifier values by removing formatting characters, handling check digits, and applying system-specific validation rules when available.
• Address comparison: Parses structured addresses, normalizes street names, handles apartment/unit variations, and can use geocoding when available for distance-based matching.

The match score is compared to thresholds:

Thresholds are configurable per endpoint and may be adjusted based on the observed quality of data. POSSIBLE matches are routed to adjudication rather than being automatically resolved.

6.3 Blocking Strategies Using Profile Families

Comparing every pair of patient records across all endpoints would be computationally prohibitive. The overlay uses blocking to reduce the comparison space by only considering records that share one or more blocking keys.

The observed profile families discovered from Patient instances inform blocking strategy selection:

• If a profile family reliably includes telecom with consistent system usage (e.g., always includes phone with country code), blocking keys can incorporate normalized phone numbers.
• If a family consistently includes strong identifiers (e.g., driver's license numbers with known formats), these can serve as high-precision blocking keys.
• If address is sparse or unstructured in a family, address-based blocking may be disabled to avoid false non-matches.
• Multiple blocking passes with different key combinations ensure high recall while maintaining acceptable precision.

This adaptive blocking approach improves both efficiency and match quality by tailoring strategies to the actual data characteristics of each endpoint.

6.4 Global Patient Identifier (GPID) Minting

When a set of patient records is determined to represent the same person (either through automatic matching or adjudication), the overlay mints a Global Patient Identifier (GPID) that serves as a stable reference across all linked records.

The GPID is a content-addressed identifier derived from a canonical representation of the linked set:

where \(\mathrm{consensus}(P)\) is a consensus representation built from the linked patient records, including:

• The most complete demographic information across all records
• All known identifiers with their source systems and confidence
• Linkage evidence references (which records were compared, match scores, adjudication records)
• Timestamp of first linkage and last verification

The GPID is stable across future linkages — adding new patient records to the set does not change the GPID unless the consensus representation fundamentally changes (e.g., through conflict resolution).

6.5 FHIR-Native Representation

When supported by the endpoint, the overlay can represent cross-record linkage using FHIR native resources:

• Person resource: Can link multiple patient records through the link element, with assurance indicating match confidence.
• Linkage resource: Provides explicit representation of item links with source/target relationships and link type.
• Provenance resource: Records the linkage activity, including who performed the match, when, and what evidence was used.

For endpoints that do not support these resources, the overlay maintains an external evidence store with references back to source patient records using canonical URIs.

7. Governed Harmonization Artifacts

Harmonization artifacts are the outputs of the overlay that enable consistent interpretation across endpoints. These artifacts must be managed with the same rigor as production software, including versioning, testing, staged rollout, and auditability.

7.1 Artifact Types

The overlay publishes several types of harmonization artifacts:

1. Profile Family Registry: Assigns each observed DPID to a profile family, with similarity scores and prototype signatures. Profile families represent groups of endpoints that exhibit similar data shapes and can share harmonization rules.
2. Terminology Crosswalks: Maps codes between different systems (e.g., ICD-10-CM to SNOMED CT mappings) with provenance, confidence scores, and validity constraints. Crosswalks may be directional (forward/backward) and may include complex transformations beyond simple code equivalence.
3. Value Set Alignments: Defines how local value sets map to standard value sets, including handling of missing codes, extensions, and partial matches.
4. Normalization Transforms: Specifies how to normalize values to canonical representations, including unit conversions (mg/dL to mmol/L), date standardization (YYYY-MM-DD to FHIR dateTime), and text cleaning rules.
5. Identity Policies: Configures matching thresholds, blocking strategies, and adjudication rules for patient identity resolution, potentially varying by profile family.
6. Harmonization Bundles (HB): Aggregates multiple related artifacts into a coherent package for a specific use case (e.g., "Rural Health Clinic Harmonization" or "Cardiology Registry Integration").

Each artifact type has a schema defining required metadata, validation rules, and dependencies.

7.2 Staged Rollout Lifecycle

Artifacts that can affect production behavior are promoted through defined lifecycle stages:

• Draft: The artifact is under development, not yet applied anywhere. Draft artifacts may be incomplete and are subject to change.
• Shadow: The artifact is computed in parallel with production systems but not used for actual transformation. Shadow execution compares outputs against baseline, collecting quality metrics and detecting regressions without impacting downstream consumers.
• Canary: The artifact is applied to a limited subset of traffic (e.g., 5% of requests for specific endpoints) with close monitoring. Canary deployment allows detection of issues before full rollout.
• Active: The artifact is applied to all eligible traffic as the default behavior. Active artifacts are considered stable and production-ready.
• Deprecated: The artifact is scheduled for removal; new usage is discouraged but existing usage continues.
• Retired: The artifact is no longer available for use; references to retired artifacts return appropriate errors or redirects.

As illustrated by the paper's lifecycle diagram (Figure 4), artifacts progress from Draft → Shadow → Canary → Active with increasing production impact, and can move to Deprecated → Retired for graceful phase-out over a minimum 30-day period. Rollback paths allow reverting to previous versions when issues are detected: shadow deployment enables validation without production impact, and canary deployment limits the blast radius to 5% of traffic.

7.3 Safety Gates

Promotion between stages is gated by measurable criteria that must be satisfied:

• Structural validation: The artifact conforms to its schema, all required fields are present, and references resolve to existing artifacts.
• Test suite passage: The artifact passes unit tests (synthetic test cases) and integration tests (against representative data).
• Shadow evaluation metrics: Shadow execution shows acceptable fidelity compared to baseline, with error rates below thresholds.
• Canary monitoring: Canary deployment meets SLOs for latency (<100ms p95), error rate (<0.1%), and business metrics (e.g., match rate, coverage).
• Fairness checks: For artifacts that may impact different populations differently, fairness metrics are computed and must be within acceptable bounds (e.g., demographic parity within 5%).
• Approval requirements: Depending on artifact type and scope (site-level vs. global), appropriate approvals must be recorded.

Gates are enforced automatically where possible, with human intervention required for certain criteria (e.g., fairness review, safety-critical approvals).

7.4 Rollback and Remediation

Despite rigorous testing, issues may still arise in production. The overlay supports rapid rollback through:

• Versioned artifacts: All artifacts are immutable, so reverting to a previous version is as simple as updating the active pointer.
• Automated rollback triggers: When monitoring detects metric degradation beyond thresholds, rollback can be triggered automatically.
• Canary hold periods: New artifacts remain in canary for a minimum period (typically 24-72 hours) before promotion to active, allowing time for issue detection.
• Rollback testing: Rollback paths are tested as part of the release process to ensure they work when needed.

When issues require remediation beyond rollback (e.g., data corruption, incorrect linkages), the system supports repair workflows that generate correction artifacts while preserving audit trails.

8. Empirical Evaluation: DPID Stability

To validate the core DPID primitive, we conducted a synthetic evaluation measuring stability under controlled perturbations and sensitivity to meaningful semantic changes. This section presents the experimental design, results, and implications.

8.1 Experimental Setup

We generated 10 simulated FHIR endpoints, each producing 5,000 Patient resources and 5,000 Condition resources with endpoint-specific profile parameters:

• Optional element prevalence: Controlled the probability that optional elements (e.g., Patient.multipleBirthBoolean, Condition.onsetDateTime) would be present.
• Extension usage: Introduced endpoint-specific extensions with varying prevalence (e.g., race/ethnicity extensions in some endpoints).
• Terminology choice: For coded elements, endpoints varied in their preferred terminology (ICD-10-CM vs. SNOMED CT for diagnosis codes; LOINC vs. proprietary codes for lab tests).
• Identifier namespaces: Endpoints used different identifier systems (local MRNs, state-level IDs, national identifiers) with varying prevalence.
• Value distributions: For demographic fields (gender, marital status), endpoints had different population distributions reflecting their patient populations.

We computed observed descriptors and DPIDs using thresholds \(\tau_p = 0.05,\ \delta_p = 0.02\) for paths, \(\tau_s = 0.01,\ \delta_s = 0.005\) for terminology systems, and \(\tau_v = 0.1,\ \delta_v = 0.03\) for value categories.

8.2 Perturbation Types

We applied controlled perturbations to evaluate DPID behavior:

1. Non-semantic perturbations:
   • Shuffle array order (coding arrays, identifier arrays, extension arrays)
   • Vary URI formatting (trailing slashes, case variations in hostnames)
   • Reorder object properties (different JSON key order)
   These should not change DPID under proper canonicalization.
2. Semantic perturbations:
   • Swap terminology system (ICD-10-CM ↔ SNOMED CT) for diagnosis codes
   • Introduce a high-prevalence extension (race) above the stability margin
   • Increase optional element prevalence across the stability boundary (e.g., Condition.onsetDateTime from absent to present in >5% of resources)
   • Change value set for a categorical field (add new gender options)
   These should change DPID when they cross stability thresholds.
3. Sampling variation:
   • Generate new independent samples from the same generator without changing parameters
   • DPID should remain stable when sampling variation does not cross thresholds

8.3 Results

Table 1 summarizes the observed stability and sensitivity rates, visualized in Figure 5(a-b).

Interpretation. The results demonstrate that DPIDs are stable under all tested non-semantic perturbations, confirming that the canonicalization procedure effectively eliminates superficial variations. The 10/10 stability for resampling indicates that the hysteresis margins are sufficient to prevent sampling noise from causing DPID changes.

For semantic changes, DPIDs correctly detect meaningful differences when they cross stability thresholds. The "2/10" result for optional element boundary crossing is expected behavior: only those endpoints where baseline prevalence was within the hysteresis band (\(\tau_p \pm \delta_p\)) changed DPID when prevalence increased. Endpoints with prevalence well below the threshold did not cross the inclusion boundary and thus retained the same DPID — correctly indicating that their stable signature did not change.

Canonicalization Ablation. We performed an ablation study removing URI normalization from the canonicalization procedure. When URI normalization was disabled, non-semantic URI formatting differences caused DPID instability: stability under URI perturbations dropped from 10/10 to 0/10 for both resource types. This confirms that canonical URI handling is load-bearing for content-addressed profiling.

Clustering and Drift Detection. Using the similarity metric defined in Section 5, we clustered the 10 endpoints based on their profiles. Figure 5(c) shows the similarity matrix, revealing distinct clusters corresponding to endpoints with similar profile characteristics (e.g., academic medical centers using SNOMED CT, community hospitals using ICD-10). Figure 5(e) visualizes these clusters in 2D using t-SNE.

We simulated drift by gradually changing one endpoint's profile over 12 time windows (e.g., increasing adoption of a new extension). Figure 5(f) shows the drift metric \(\Delta_t\) increasing over time, crossing the detection threshold at window 7. The DPID changed at window 8 when the extension prevalence crossed the stability margin.

8.4 Implications

The experimental results validate the core design choices:

• Canonicalization is essential: Without proper normalization of URIs and order-independent representation, DPIDs fragment unnecessarily, defeating the purpose of content addressing.
• Hysteresis margins work: The stable signature approach successfully filters sampling noise while remaining sensitive to meaningful changes.
• Similarity metrics enable clustering: The combination of Jaccard for structure/terminology and Jensen-Shannon for values provides meaningful similarity assessments that correlate with semantic differences.
• Drift detection is feasible: The drift metric captures both gradual evolution (value distribution shifts) and abrupt changes (terminology swaps).

These findings support the use of DPIDs as a decentralized primitive for profile comparison and clustering across healthcare endpoints.

9. Discussion

The FHIR Harmonization Overlay addresses a critical gap between syntactic conformance and operational semantic interoperability. This section discusses the implications of our approach, its limitations, and directions for future work.

9.1 Why This Overlay Matters

Healthcare interoperability efforts have historically focused on standards development and certification — ensuring that systems can exchange syntactically valid messages. While necessary, this focus is insufficient for the semantic interoperability required by modern analytics, research, and clinical decision support. Applications need to consume data from multiple sources without rebuilding endpoint-specific logic for each new integration.

The overlay's contributions address this gap through:

• Observational rather than declarative profiling: By deriving profiles from actual instances rather than relying on declared conformance, the overlay captures the de facto data shapes in use, which may differ significantly from what endpoints claim to implement.
• Decentralized profile comparison via DPIDs: Endpoints can be compared without a central authority, enabling networks to grow organically while maintaining the ability to cluster similar implementations.
• Governed harmonization artifacts: Treating harmonization rules as versioned software components with staged rollout enables safe, incremental improvement without disrupting production systems.
• Federated identity with evidence preservation: Rather than making irreversible match decisions, the overlay preserves evidence and supports adjudication, building trust in identity linkages.

9.2 Limitations

Several limitations should be acknowledged:

• Synthetic evaluation: The experimental evaluation used simulated endpoints with controlled variations. While this allows precise measurement of DPID behavior, it does not capture the full complexity of real-world healthcare data. Future work should include evaluation on public datasets (e.g., MIMIC, SYNTHEA) and real-world production data.
• Canonicalization coverage: The canonicalization rules defined in Algorithm 1 cover common cases but may miss edge cases such as vendor-specific extensions with non-standard URI patterns, coded values embedded in narrative text, or complex nested extensions. Real-world deployment will require ongoing refinement of canonicalization rules.
• Threshold selection: The hysteresis thresholds (\(\tau_p, \delta_p\), etc.) must be tuned for each deployment context. Too-aggressive thresholds cause instability; too-conservative thresholds miss meaningful changes. Adaptive threshold selection based on observed variance is an area for future work.
• Identity matching risks: False positive patient matches (merging different individuals) can have serious consequences for patient safety and privacy. While the adjudication workflow mitigates this risk, the matching model must be carefully validated for each deployment context.
• Terminology licensing: Some terminology mappings (e.g., commercial mappings between SNOMED CT and ICD-10-CM) may be subject to licensing restrictions that limit redistribution. The overlay must respect these restrictions and may need to support multiple mapping sources with different licensing terms.

9.3 Future Work

Several directions for future research and development are promising:

• Federated learning across endpoints: With appropriate privacy protections, the overlay could enable federated learning of matching models, terminology embeddings, and profile similarity metrics without sharing raw data.
• Temporal profile analysis: Extending profile descriptors to capture temporal patterns — how profiles evolve over time, periodic changes (e.g., quarterly reporting requirements), and trend detection — would enable proactive harmonization before drift causes integration failures.
• Automated remediation: When drift or mapping failures are detected, the overlay could automatically generate and test candidate remediation patches, accelerating the self-healing cycle.
• Multi-language support: Healthcare data increasingly includes multi-language content (e.g., patient-reported outcomes in multiple languages). Extending profile analysis to handle language variation would broaden applicability.
• Integration with clinical NLP: Combining structured FHIR analysis with clinical note processing (as in the Semantic Classification Engine) would enable harmonization of both structured and unstructured data.

9.4 Broader Implications

The DPID concept has potential applications beyond healthcare interoperability. Any domain where data producers exhibit systematic variations in how they represent information could benefit from content-addressed profile fingerprints. Examples include:

• Financial data exchange where institutions use different message formats and code systems
• IoT sensor data where manufacturers encode measurements with different units and metadata
• Scientific data repositories where research groups use different metadata schemas

The combination of observational profiling, content-addressed identifiers, and governed artifact lifecycles provides a general pattern for achieving semantic interoperability in heterogeneous data ecosystems.

10. Conclusion

This paper has presented a FHIR-native harmonization overlay that addresses the persistent challenge of semantic interoperability in healthcare data exchange. The overlay's key contributions are:

1. Data Profile Identifiers (DPIDs): A decentralized primitive for content-addressed fingerprinting of observed FHIR profiles. DPIDs enable endpoints to be compared, clustered, and monitored without requiring a central authority or prior coordination. The canonicalization procedure ensures stability under non-semantic variations while remaining sensitive to meaningful changes.
2. A formal profile space: A mathematical framework for representing observed FHIR profiles as descriptors combining structural path information, terminology usage, and value distributions. The similarity metric enables clustering and drift detection, supporting both exact and approximate profile matching.
3. Federated identity with evidence preservation: A probabilistic matching framework that adapts blocking strategies based on observed profile characteristics and preserves all linkage evidence for audit and adjudication.
4. Governed harmonization artifacts: A staged rollout lifecycle for profile family assignments, terminology crosswalks, normalization transforms, and identity policies, with automated quality gates and rollback capabilities.

Experimental evaluation on simulated endpoints demonstrates that DPIDs achieve 100% stability under non-semantic perturbations while correctly detecting meaningful semantic changes when they cross hysteresis thresholds. The ablation study confirms that canonical URI normalization is essential for content-addressed profiling.

The overlay is designed to complement existing FHIR infrastructure rather than replace it. It can connect to any conformant FHIR server, integrate with established identity systems and terminology services, and operate alongside production applications without requiring modifications to source systems.

As healthcare networks continue to grow in scale and complexity, the need for systematic semantic harmonization will only increase. The overlay provides a foundation for building interoperable health data ecosystems where applications can consume data from multiple sources without repeatedly reinventing endpoint-specific integration logic. By making semantic interoperability a governed, auditable, and continuously improving capability, we can accelerate progress toward the vision of learning health systems that derive knowledge from diverse data sources while maintaining patient safety and privacy.

Appendix A: DPID Canonicalization Examples

This appendix provides concrete examples of the canonicalization process for common FHIR variations.

A.1 URI Normalization Examples

A.2 Array Ordering Independence

Original JSON:

{
  "coding": [
    { "system": "http://snomed.info/sct", "code": "73211009" },
    { "system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "I10" }
  ]
}

After canonicalization (sorted by canonical representation):

{
  "coding": [
    { "code": "I10", "system": "http://hl7.org/fhir/sid/icd-10-cm" },
    { "code": "73211009", "system": "http://snomed.info/sct" }
  ]
}

A.3 Extension Flattening

Original JSON:

{
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/patient-race",
      "valueCoding": { "system": "urn:oid:2.16.840.1.113883.6.238", "code": "2106-3", "display": "White" }
    },
    {
      "url": "http://hl7.org/fhir/StructureDefinition/patient-ethnicity",
      "valueCoding": { "system": "urn:oid:2.16.840.1.113883.6.238", "code": "2186-5", "display": "Not Hispanic or Latino" }
    }
  ]
}

After flattening (extensions become pseudo-paths):

{
  "extension[http://hl7.org/fhir/StructureDefinition/patient-ethnicity].valueCoding.code": "2186-5",
  "extension[http://hl7.org/fhir/StructureDefinition/patient-ethnicity].valueCoding.display": "Not Hispanic or Latino",
  "extension[http://hl7.org/fhir/StructureDefinition/patient-ethnicity].valueCoding.system": "urn:oid:2.16.840.1.113883.6.238",
  "extension[http://hl7.org/fhir/StructureDefinition/patient-race].valueCoding.code": "2106-3",
  "extension[http://hl7.org/fhir/StructureDefinition/patient-race].valueCoding.display": "White",
  "extension[http://hl7.org/fhir/StructureDefinition/patient-race].valueCoding.system": "urn:oid:2.16.840.1.113883.6.238"
}

Appendix B: Glossary

Frequently asked questions

What is a Data Profile Identifier (DPID)?

A DPID is a content-addressed fingerprint of the stable profile signature derived from observed FHIR instances. It is computed as a base64url-encoded SHA-256 hash of a canonicalized signature, so semantically equivalent profiles produce identical DPIDs regardless of superficial variation such as array ordering or URI formatting.

Because DPIDs are content-addressed, endpoints can be compared, clustered into families, and monitored for drift without a central authority or any prior coordination between organizations.

How does the overlay achieve semantic interoperability between FHIR systems?

It observes the de facto data shapes and terminologies at each endpoint, fingerprints them with DPIDs, and clusters similar endpoints into profile families. It then publishes governed harmonization artifacts — terminology crosswalks, normalization transforms, value-set alignments, and identity policies.

Downstream consumers can apply one consistent interpretation across many sources instead of rebuilding endpoint-specific ETL, mappings, and identity resolution for every new integration.

Does the harmonization overlay move patient data or modify FHIR servers?

No. The overlay operates as a non-invasive sidecar that reads from FHIR servers over standard REST APIs and never modifies them — no privileged database access, schema changes, or server replacements.

The control plane stays non-PHI, carrying only identifiers, hashes, and references rather than raw clinical data, and all artifacts and learning are tenant-scoped by default, with cross-tenant federation enabled only under explicit consent.

How are harmonization changes rolled out safely?

Every artifact is versioned and immutable and progresses through a staged lifecycle: draft, shadow, canary, active, deprecated, and retired. Promotion is gated by structural validation, test-suite passage, shadow-evaluation fidelity, canary SLOs (latency under 100ms p95, error rate under 0.1%), and fairness checks.

Because artifacts are immutable, rollback is as simple as repointing to a previous version, and monitoring can trigger automated rollback when metrics degrade.

References

1. HL7 International. FHIR Release 4 (R4) Specification. https://hl7.org/fhir/. Accessed: 2024-01-15.
2. Office of the National Coordinator for Health IT (ONC). Trusted Exchange Framework and Common Agreement (TEFCA). https://www.healthit.gov/policy/tefca. Accessed: 2024-01-15.
3. U.S. Electronic Code of Federal Regulations. 45 CFR Part 172 — Trusted Exchange Framework and Common Agreement. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-172. Accessed: 2024-01-15.
4. Office of the National Coordinator for Health IT (ONC). United States Core Data for Interoperability (USCDI). https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi. Accessed: 2024-01-15.
5. Integrating the Healthcare Enterprise (IHE). PIXm: Patient Identifier Cross-reference for Mobile (Technical Framework Supplement). ihe.net (PIXm supplement PDF). Accessed: 2024-01-15.
6. Integrating the Healthcare Enterprise (IHE). PDQm: Patient Demographics Query for Mobile (Implementation Guide). https://profiles.ihe.net/ITI/PDQm/. Accessed: 2024-01-15.
7. Integrating the Healthcare Enterprise (IHE). PMIR: Patient Master Identity Registry (Technical Framework Supplement). ihe.net (PMIR supplement PDF). Accessed: 2024-01-15.
8. HL7 International. Interoperable Digital Identity and Patient Matching Implementation Guide. https://build.fhir.org/ig/HL7/fhir-identity-matching-ig/. Accessed: 2024-01-15.
9. HAPI FHIR. Master Data Management (MDM) Module Documentation. hapifhir.io/hapi-fhir/docs/server_jpa_mdm/mdm.html. Accessed: 2024-01-15.
10. Smile CDR. Master Data Management (MDM) Documentation. smilecdr.com/docs/mdm/mdm.html. Accessed: 2024-01-15.
11. InterSystems. InterSystems EMPI (Enterprise Master Person Index). intersystems.com (HealthShare EMPI). Accessed: 2024-01-15.
12. I. P. Fellegi and A. B. Sunter. "A theory for record linkage." Journal of the American Statistical Association, vol. 64, no. 328, pp. 1183-1210, 1969.
13. P. Christen. Data Matching. Springer, 2012.
14. Firely. Simplifier.net — the FHIR collaboration platform. https://simplifier.net/. Accessed: 2024-01-15.
15. Firely. Forge — Profile Editor for HL7 FHIR. https://simplifier.net/forge. Accessed: 2024-01-15.
16. Lantana Consulting Group. Trifolia-on-FHIR (Retired) — FHIR IG Tool. lantanagroup.com (Trifolia-on-FHIR). Accessed: 2024-01-15.
17. O. Bodenreider. "The Unified Medical Language System (UMLS): integrating biomedical terminology." Nucleic Acids Research, vol. 32, no. suppl 1, pp. D267-D270, 2004.
18. D. Ghosh and R. Sharman. "Self-healing systems — survey and synthesis." Decision Support Systems, vol. 42, no. 4, pp. 2164-2185, 2007.
19. D. Russo. "Navigating the complexity of generative AI adoption in software engineering." ACM Transactions on Software Engineering and Methodology, vol. 33, pp. 1-50, 2024.