FHIR at the Platform Boundary
Patterns for normalizing clinical data while keeping source provenance, security, and schema evolution intact.
Interoperability is less about accepting a resource and more about preserving meaning while systems disagree.
EXECUTIVE THESIS
FHIR interoperability is the preservation of clinical meaning across systems that disagree. A robust platform keeps canonical resources, source provenance, product read models, consent, and correction workflows separate but traceable.
Keep provenance visible
Normalize for product use, but retain source identifiers, version history, validation results, and mapping decisions so every derived fact can be traced.
Secure the workflow
Apply tenant isolation, least-privilege scopes, audit trails, and purpose-aware access at the platform boundary—not only in the user interface.
Separate canonical from convenient
The canonical FHIR resource should preserve clinical meaning and version history; product read models can be optimized for care-manager screens, search, or analytics. Keeping those concerns separate prevents UI needs from silently corrupting the interoperability contract.
Design for consent and correction
Healthcare data changes after ingestion. Model revocation, corrected lab results, merged patients, and source-system deletes as first-class events. Derived stores need a traceable way to invalidate or recompute every downstream fact affected by that change.
SYSTEM DESIGN
Decision framework
Preserve the source record
Store source identifiers, resource version, validation results, mapping decisions, and ingestion time. Every normalized field used for care or analytics should be traceable to the original clinical statement.
Separate canonical and convenient models
FHIR resources protect semantic interoperability; denormalized read models optimize search, timelines, and care-manager workflows. Product convenience should not silently rewrite the canonical clinical record.
Apply purpose-aware access
Tenant isolation, scopes, consent, break-glass access, and audit evidence belong at the platform boundary. Hiding a field in the interface is not an authorization control.
FROM DESIGN TO DELIVERY
Implementation playbook
- 1
Validate on ingress
Check profile conformance, terminology, references, identifiers, and tenant context. Route invalid resources to a visible remediation queue instead of quietly dropping fields.
- 2
Normalize with provenance
Map into the canonical model while retaining source extensions and confidence. Publish versioned change events so downstream consumers know whether a fact was created, corrected, merged, or revoked.
- 3
Build workflow projections
Create purpose-specific indexes for member search, clinical timelines, gaps in care, and analytics. Rebuild projections from canonical events so schema changes remain recoverable.
- 4
Exercise correction paths
Test patient merges, corrected labs, consent revocation, source deletion, and late-arriving encounters. Verify that every derived view is invalidated or recomputed correctly.
Production review
Use these two lists during architecture review, readiness assessment, and post-incident learning.
COMMON FAILURE MODES
- Treating successful JSON parsing as interoperability
- Losing provenance during normalization
- Using one denormalized database as both clinical truth and product view
READINESS CHECKLIST
- Profile and terminology validation
- End-to-end provenance and version history
- Tenant, consent, and purpose-aware policy
- Rebuildable product projections
- Correction, merge, and revocation tests