Why FHIR R4 certification does not equal FHIR interoperability, the specific data availability and write-back gaps that derail integrations, and how to build for what health systems actually produce.
It Just Did Not Contain What We Needed.
FHIR R4 certification ensures format compliance not populated fields, reliable queries, or working write-backs.
Custom extensions, optional fields, and vendor-specific SMART on FHIR behavior often turn “standard” integrations into months-long custom builds.
Fields you need in MedicationRequest, Observation, and Condition are marked optional in the spec and frequently unpopulated in production. The API is compliant; your use case is not served.
Epic and Oracle add proprietary extensions for clinically important data. Extensions are non-portable across vendors, so 'works on Epic' does not mean 'works on Oracle.'
Write-back requires EHR workflow integration, permission configuration, and conflict resolution. Typically 2–4x the timeline of read-only — and not optional for most clinical use cases.
Run FHIR queries against the customer's production-equivalent environment before architecture. Identify unpopulated fields and design fallbacks before writing client code.
Isolate vendor-specific extensions in a translation layer so application code stays portable. Adding a new EHR adds extensions, not rewrites.
Workflow integration, permissions, and conflict resolution are part of architecture, not a Phase 2 epic. Write-back drives 2–4x the read timeline; budget it explicitly.
Pre-build data availability checks make the unpopulated-fields problem visible before architecture, not after a year of development.
No. Certification confirms format compliance. It does not confirm whether the data elements you need are populated, whether write-back works, or whether queries perform reliably under your load patterns.
Payer FHIR APIs appear alongside EHR FHIR APIs. PA automation now reconciles two separate FHIR implementations that may not match for the same resources — adding integration work, not removing it.
Write-back requires EHR workflow integration with clinical review processes, user permission configuration per customer, and conflict resolution for concurrent edits. Typically 2–4x the timeline of read-only integration.
