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.
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.
Drop your details and we'll send FHIR R4 Implementation: Five Gaps Between the Specification and What Production Health Systems Actually Return straight to your inbox - no spam, unsubscribe anytime.
Talk through how this applies to your roadmap with our engineering leads - a working session, not a sales pitch.
Download White Paper