FHIR R4 — The Production Standard
R4 endpoints are required by the 21st Century Cures Act and most national health exchange programmes. It is the version your systems must support today and will dominate through 2027.
FHIR Is the Standard. Is Your System Ready?
We implement FHIR R4 and R5 — server-side and client-side — for health systems, payers, and digital health companies.
Book a Technical Consultation
Talk to our integration team about your FHIR implementation. We reply within 24 hours.
Trusted by startups and global leaders
What the FHIR Landscape Looks Like Right Now
R4 is where you must be today. R5 is where select use cases are moving. R6 is on the horizon. A sound implementation strategy is designed with all three in mind.
FHIR R5 — Forward-Looking Use Cases
Published in 2023 with 55+ new resources for patient engagement and care coordination. Adoption stays limited by its trial-use status — valuable for specific subscription and medication use cases.
FHIR R6 — On the Horizon
Expected late 2026. Some teams are skipping R5 to move R4 → R6 directly. We design every implementation with a migration path so R6 does not force a rebuild.
What We Build and Implement — Server-Side and Client-Side, R4 and R5
We implement FHIR for health systems, payers, digital health companies, and anyone who needs their systems to talk to the modern healthcare data ecosystem.
A production-grade R4 server on your data — exposing Patient, Observation, Condition, MedicationRequest and more with correct profiles, search parameters, capability statements, SMART on FHIR auth, and Bulk Data Access export.
The client layer that retrieves, validates and transforms data from Epic, Cerner, Athena, ABDM and HIE endpoints — including SMART launch flows, vendor-variation handling, retry logic, and mapping to your internal model.
Topic-based subscriptions for real-time notifications, enhanced medication definitions, and improved care coordination resources — implemented with R6 migration awareness so you do not rebuild when it arrives.
DSTU2 → R4, R4 → R5, or proprietary vendor APIs → standards-based FHIR. With Oracle Health ending DSTU2 support, migration is no longer optional — and we handle it without disrupting clinical workflows.
US Core, UK Core, AU Base, India ABDM, UAE national profile, Saudi MOH — implemented to the national IG, not just base FHIR, so your system actually interoperates with the health exchange in your market.
The Gap Between Having FHIR and Having FHIR That Actually Works
FHIR is well-specified. Implementation is still hard. This is where most organisations struggle — and where the real engineering decisions live.
Every EHR Vendor Implements FHIR Differently
Epic and Cerner are both FHIR R4 — yet differ in exposed resources, authentication, profiles, and extensions. Client code that works against one endpoint rarely works against another without adjustment.
Legacy Data Does Not Map Cleanly
A 30-year-old hospital holds data in terminologies that predate FHIR by decades. Mapping it to FHIR resources without losing clinical meaning takes deep knowledge of both the source data and the resource model.
Security and Consent Are Not Optional
FHIR endpoints must implement SMART on FHIR authentication, scoped access control, and consent management correctly. A server that returns data without proper access controls is a breach waiting to happen.
Production Scale Is Not a Demo
A server handling 100 test queries behaves differently from one handling millions of production requests. Indexing, query optimisation, bulk export, and subscriptions at scale are decisions invisible until real load hits.
What a Complete FHIR Implementation Includes
A FHIR server or client is not just an API. A production-ready implementation includes the parts that only matter once real systems integrate against you. Hover or tap a stage to see what it involves.
-
Capability Statement & Search Parameters
Capability Statement & Search Parameters
Accurate capability statement covering your supported profiles, plus correct search parameter implementation for every resource.
-
Pagination & Conditional Operations
Pagination & Conditional Operations
Correct pagination and conditional create/update/delete — no shortcuts.
-
Subscriptions for Real-Time Events
Subscriptions for Real-Time Events
Push-based event notifications to connected systems — no polling required.
-
Terminology, Provenance & Audit
Terminology, Provenance & Audit
Code validation against SNOMED-CT, LOINC, ICD-10, and RxNorm, with provenance and audit tracking.
-
Conformance Testing & Monitoring
Conformance Testing & Monitoring
Conformance test suite plus monitoring that alerts you when a connected system breaks your integration.
Who This Is For
We build FHIR infrastructure for the organisations the modern healthcare data ecosystem runs on. Hover a card to see how we work with each.
Health Systems & Hospitals
Payers & Health Plans
Digital Health Companies
Government Health Programmes
National Profiles & Standards — Implemented to the IG, Not Just Base FHIR
National implementation guides define which resources and profiles must be used for interoperability in each regulatory context. We implement to those profiles, plus the security, terminology and exchange standards a compliant FHIR deployment depends on.
National IGs
Regional Implementation Guides
The profile your market actually requires for national health-exchange interoperability — implemented correctly, not just to the base specification.
Security
SMART on FHIR & Access Control
The full SMART framework — OAuth 2.0 authorisation, scoped access tokens, patient- and user-level launch contexts, token refresh, and consent management.
Terminology
Code Systems & Validation
Terminology service integration so codes validate against the standard vocabularies clinical data depends on.
Versions
FHIR Versions We Implement
R4 for production today, targeted R5 where it earns its place, and R6 migration awareness designed in from the start.
Exchange
Networks & Bulk Data
Connection to national exchange infrastructure and large-scale population data export via the Bulk Data Access specification.
Regulation
Regulatory Drivers
The mandates that make FHIR non-optional — implemented to the requirement, not approximated.
The FHIR Stack We Build On
Production-proven FHIR servers, the standards a compliant deployment depends on, and regulated-cloud infrastructure with HIPAA BAAs in place — selected for the systems you need to connect to, not a fixed toolset.
H
HAPI FHIR
M
Microsoft FHIR Server
G
Google Cloud Healthcare API
A
AWS HealthLake
F
Firely / Vonk
H
HL7 FHIR R4
H
HL7 FHIR R5
H
HL7 v2 & v3
D
DICOM
C
CDA / C-CDA
B
Bulk Data Access
S
SMART on FHIR
O
OAuth 2.0
S
Scoped Access Tokens
C
Consent Management
A
AES-256 Encryption
S
SNOMED-CT
L
LOINC
I
ICD-10
R
RxNorm
T
TEFCA / QHIN
C
CommonWell
C
Carequality
D
Direct Trust
I
India ABDM
A
AWS GovCloud
A
Azure Health Data Services
D
Docker / Kubernetes
T
Terraform
M
Monitoring & Alerting
The Healthcare Data Ecosystem Is FHIR. Your Integration Should Be Too.
R4 today, R5 where it matters, R6 on the horizon — server-side and client-side. Book a consultation with our interoperability team and we will tell you what a correct, production-ready FHIR implementation looks like for your systems.
Book a FHIR Integration Consultation
Award-Winning AI Development & Consulting
100 Fastest Growth Companies
Global Spring Winner
Top App Development Company
AWS Partner Network
Google Cloud Partner
Highly Rated on Trustpilot
Verified Agency
Top App Development Company
ASSOCHAM Member
Frequently Asked Questions
[ 1 ]
Should we implement R4, R5, or wait for R6?
For production deployments today, R4 is the correct choice. It will dominate through 2027, and the 21st Century Cures Act, TEFCA QHINs, and ONC-certified EHRs are all based on it. If you have use cases that genuinely benefit from R5 — particularly subscriptions or medication management — we can scope a targeted R5 implementation alongside an R4 foundation. We design everything with R6 in mind to minimise the eventual migration.
[ 2 ]
How do you handle variation between different vendors' FHIR implementations?
We maintain an integration library documenting the specific behaviours, extensions and profile variations of major EHR vendors — Epic, Cerner, Athena, Meditech and others. Your FHIR client is built against the actual behaviour of the systems you need to connect to, not just the specification. Variations are handled explicitly rather than discovered in production.
[ 3 ]
What does SMART on FHIR actually require to implement correctly?
SMART on FHIR is an OAuth 2.0 profile for healthcare. A correct implementation includes the authorisation server, scoped access tokens that limit data access to what the requesting app is authorised to see, patient- and user-level launch contexts, token refresh handling, and the launch endpoint that gives EHR-embedded apps context about the current patient and user. We implement the full framework, not just the token exchange.
[ 4 ]
How long does a production FHIR implementation take?
A focused R4 server for a specific use case — a patient data API for a digital health app, or a payer member data endpoint — typically takes 8 to 12 weeks. A full health-system FHIR infrastructure with multiple resource types, bulk data export, SMART on FHIR, and national profile conformance is a larger engagement, scoped during a discovery phase.
Global presence