Compliance-first delivery
Standards-compliant FHIR, done right the first time
FHIR is the modern, API-based standard for exchanging healthcare data and the foundation of US interoperability requirements under the 21st Century Cures Act and USCDI. But a FHIR endpoint that returns JSON is not the same as one that interoperates: profiles must be followed, terminology bound correctly (SNOMED CT, LOINC, RxNorm, ICD-10-CM), search parameters supported, and authorisation handled through SMART on FHIR. Getting any of those wrong means failed EHR app reviews, rejected certification tests or apps that only work against one sandbox.
We design FHIR resource models and CapabilityStatements, constrain resources to US Core profiles, and build SMART on FHIR apps with EHR launch and standalone launch flows using OAuth 2.0 and OpenID Connect. For population-level data we implement Bulk FHIR ($export) pipelines, and for point-of-care decision support, CDS Hooks services. Every resource is validated against its profile in CI before release. Most organisations still run HL7 v2 alongside FHIR, so we bridge the two using our HL7 and EDI integration practice and Mirth Connect channels; the trade-offs are explained in our HL7 vs FHIR guide.
You end up with conformant APIs or apps that work against real EHR endpoints such as Epic, Oracle Health and athenahealth, deployed on HAPI FHIR or a managed cloud FHIR service, and built with HIPAA-aligned security. Patient-facing apps can be built by our mobile development team on the same APIs.
- FHIR R4 APIs, resources and CapabilityStatements
- SMART on FHIR apps with OAuth 2.0 and OpenID Connect
- US Core and USCDI profile conformance with correct terminology
- Bulk FHIR ($export) and CDS Hooks services
- Profile validation in CI before every release
What's Included
Everything you need, delivered by a senior, security-first team.
FHIR API Development
Design and build conformant FHIR R4 REST APIs with custom search parameters and CapabilityStatements.
SMART on FHIR Apps
Provider- and patient-facing apps with EHR launch, OAuth 2.0 scopes and OpenID Connect.
US Core & USCDI
Constrain resources to US Core profiles with correct terminology (SNOMED CT, LOINC, RxNorm, ICD-10-CM).
Bulk FHIR Export
$export pipelines for population health, analytics and payer-to-payer data exchange.
CDS Hooks
Real-time clinical decision support triggered inside the clinician workflow.
HL7 v2 to FHIR
Bridge legacy HL7 v2 and CCDA data into FHIR resources with validated mapping.
Conformant FHIR APIs and SMART on FHIR apps
FHIR (Fast Healthcare Interoperability Resources) is the modern, RESTful standard for healthcare data and the backbone of US regulatory interoperability under the 21st Century Cures Act. A FHIR endpoint only delivers value when it is genuinely conformant: correct resource profiles, terminology bindings, search parameters, security and an accurate CapabilityStatement. We build FHIR APIs and apps that pass validation and interoperate with the systems your users actually run.
What we build with FHIR
- FHIR R4 REST APIs — resource models, search parameters, operations and a conformant CapabilityStatement.
- SMART on FHIR apps — provider-facing (EHR launch) and patient-facing (standalone launch) apps secured with OAuth 2.0 scopes and OpenID Connect.
- US Core and USCDI conformance — resources constrained to US Core profiles with SNOMED CT, LOINC, RxNorm and ICD-10-CM terminology.
- Bulk FHIR ($export) — population-level extracts for analytics, quality reporting and payer exchange.
- CDS Hooks — clinical decision support surfaced inside the clinician workflow.
- HL7 v2 and C-CDA to FHIR — converting legacy feeds and documents into validated FHIR resources, often through Mirth Connect.
Platforms and EHRs we work with
We build on HAPI FHIR and managed cloud FHIR services — AWS HealthLake, Azure Health Data Services and Google Cloud Healthcare API — and integrate with EHR FHIR endpoints from Epic, Oracle Health (Cerner) and athenahealth, as well as OpenEMR.
Choosing a FHIR server
| Option | Strengths | Consider |
|---|---|---|
| HAPI FHIR (self-hosted) | Open source, highly customisable, mature validator | You operate, scale and secure it |
| AWS HealthLake | Managed, integrates with AWS analytics | AWS-specific; check feature coverage |
| Azure Health Data Services | Managed FHIR, DICOM and MedTech services | Azure-specific; check feature coverage |
| Google Cloud Healthcare API | Managed FHIR, HL7 v2 and DICOM stores | GCP-specific; check feature coverage |
How a FHIR project runs
- Use cases and implementation guides — which resources, profiles (US Core, Da Vinci, others) and scopes are needed.
- Data mapping — from your source systems to FHIR resources and code systems.
- Build and secure — APIs, authorisation server, consent and audit logging.
- Validate — FHIR validator and Inferno-style test suites to check conformance before partners connect.
- Operate — monitoring, versioning and documentation for developers using your API.
Common FHIR pitfalls
- Returning resources that look like FHIR but fail profile validation.
- Missing or wrong terminology codes, which breaks downstream use.
- Overly broad OAuth scopes that expose more data than the app needs.
- Treating FHIR as a replacement for every HL7 v2 feed overnight — read HL7 vs FHIR: A Practical Guide.
Built for Cures Act and HIPAA requirements
Standardised API access to USCDI data is a core requirement of the ONC Cures Act Final Rule. We design FHIR APIs and Bulk FHIR capabilities to align with those requirements, and because we also help clients with HIPAA, GDPR and SOC 2 compliance, the implementation is secure end to end, not only standards-valid. For broader interface work see HL7, FHIR and EDI integration.
How We Build With FHIR
Requirements
Use cases, target EHRs, regulatory drivers and the implementation guides that apply.
Model
Resource profiles, terminology bindings, search parameters and security scopes.
Build & Validate
Implement APIs or apps with automated profile validation and EHR sandbox testing.
Deploy & Support
Production deployment on HAPI or cloud FHIR services, monitoring and ongoing support.
Frequently Asked Questions
HL7 v2 is the long-established messaging standard using pipe-delimited messages such as ADT and ORU, while FHIR is a modern, RESTful, resource-based standard using JSON or XML over web APIs. Many organisations run both, and we bridge HL7 v2 and C-CDA data into FHIR.
SMART on FHIR adds an OAuth 2.0 and OpenID Connect security and app-launch layer on top of FHIR, letting third-party apps access EHR data with scoped permissions. We build provider-facing (EHR launch) and patient-facing (standalone launch) SMART apps.
Yes. We constrain resources to the US Core implementation guide, apply the required terminology bindings and search parameters, and validate resources so your API supports USCDI data requirements.
HAPI FHIR, AWS HealthLake, Azure Health Data Services and Google Cloud Healthcare API, and we integrate with EHR FHIR endpoints including Epic, Oracle Health and athenahealth.
We start with a fixed-price scoping phase to confirm use cases, profiles and data sources. Build is then priced per phase. A focused API or SMART app can be delivered in a matter of weeks to a few months depending on data mapping and validation effort.
Book a free consultation. Share the use case, partners and any implementation guides you must meet, and we will propose a scoping plan.
Ready to get started with FHIR Interoperability?
Book a free consultation — we'll map a secure, practical path forward.