For healthcare product teams, platform engineers and health-data leaders
We build FHIR data platforms on managed cloud FHIR stores and open-source or commercial FHIR servers. Ingestion from HL7 v2, C-CDA and databases, US Core profile validation, SMART on FHIR access, Bulk Data export to your warehouse and the operating model, delivered as one working platform rather than a provisioned endpoint.
Plan your FHIR data platformBook a 30-minute call with our FHIR platform lead
Healthtech companies, payers, provider groups and digital health platforms. Updated September 26, 2026.
HL7 v2, C-CDA, CSV and database sources mapped to FHIR R4
US Core profiles, terminology and identifiers in the FHIR store
REST API, search, SMART on FHIR scopes, consent and audit
Bulk Data NDJSON to BigQuery, Snowflake or Databricks
Illustrative workflow · scope tailored to your environment
The short answer
We choose between a managed FHIR store (AWS HealthLake, Azure Health Data Services, Google Cloud Healthcare API) and a self-run or commercial FHIR server (HAPI FHIR, Medplum, Aidbox) against your workload, then build the platform: ingestion and conversion to FHIR R4, US Core validation, SMART on FHIR authorization, Bulk Data export for analytics and a tested operating model. Our open-source headless EHR on FHIR R4 passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient tests in Inferno.
Read our FHIR data store comparisonStart with the real problem
The cloud console creates a FHIR store in minutes. The platform work is everything around it: mapping source data to resources and profiles, resolving identifiers, enforcing access and consent, keeping search fast, exporting for analytics and running upgrades and recovery. We scope and deliver that work explicitly so it does not fall between the cloud service, the source systems and your application.
What we build
Each build names the standard, the store and the output your team reviews.
AWS HealthLake, Azure Health Data Services FHIR service or Google Cloud Healthcare API FHIR stores, configured with profiles, identity, private networking, audit logging and infrastructure as code.
Create a FHIR store on Google CloudA FHIR server you run, with custom operations, search parameters, subscriptions, multi-tenancy and persistence tuned for your query patterns.
HAPI FHIR performance tuningA FHIR R4 API in front of your current clinical database, mapping tables to resources without moving the data, for patient access, payer or partner APIs.
FHIR facade architectureHL7 v2 ADT and ORU and C-CDA documents converted to FHIR R4 with Azure $convert-data templates, Mirth Connect or custom mappers, validated against US Core before write.
HL7 v2 to FHIR migration guideBulk Data $export to NDJSON, streaming export to BigQuery, SQL on FHIR view definitions and loads into Snowflake or Databricks for population analytics.
Healthcare data engineering servicesOAuth 2.0 and SMART scopes, patient and practitioner launch, consent enforcement at the API, AuditEvent and Provenance on every write.
FHIR integration servicesYour starting point
You need a FHIR backend for a new product or API program and want the store chosen against real requirements, not a vendor default.
Records live in an EHR, a legacy database or HL7 feeds, and the platform needs them as validated FHIR resources with provenance.
Search is slow, costs are unclear, or the platform must move, for example off Azure API for FHIR before its 30 September 2026 retirement.
The Engineering Engagement
Workstreams are selected around your priorities. Each comes with an output your team can inspect, test and own.
Compare managed and self-run options against FHIR version, operations, search, tenancy, region, identity and cost.
Select US Core and program implementation guides, load StructureDefinitions and ValueSets, and define identifier systems.
Convert HL7 v2, C-CDA, CSV and database records to FHIR R4 with provenance and a rejected-record path.
Implement SMART on FHIR scopes, user and system clients, consent enforcement and audit logging.
Tune search parameters and indexes, load-test common queries and set up Bulk Data export to analytics.
Monitoring, backup and restore, upgrade path, release process and cost visibility for the chosen store.
Compare your options
Six common foundations for a FHIR data platform. Confirm current versions, quotas and regions in each vendor's documentation during architecture review.
| FHIR store | Hosting model | FHIR versions | Strengths | Plan for |
|---|---|---|---|---|
| HAPI FHIR JPA server | Open source (Apache 2.0), Java, self-hosted on your database | DSTU2 to R5 | Most widely used open-source server, full control, custom operations and interceptors | You run the database, tuning, upgrades and security patches |
| Google Cloud Healthcare API | Managed FHIR stores in Google Cloud datasets | DSTU2, STU3, R4 | Streaming export to BigQuery, Pub/Sub notifications, built-in de-identify operation | Google Cloud only; store configuration and quotas per project |
| AWS HealthLake | Managed FHIR data stores on AWS | R4 | NDJSON import and export from S3, SMART on FHIR support, integrated medical NLP | Supported search and operations subset; one FHIR version per data store |
| Azure Health Data Services FHIR service | Managed FHIR service in an Azure workspace | R4 | $convert-data for HL7 v2 and C-CDA, $export, Microsoft Entra ID access | Azure API for FHIR retires 30 September 2026; plan the migration |
| Medplum | Open source, TypeScript; self-hosted or Medplum hosted | R4 | Headless EHR toolkit with bots, subscriptions, access policies and React components | Adopts Medplum's application model alongside the FHIR API |
| Aidbox | Commercial FHIR server on PostgreSQL by Health Samurai | R4, R4B, R5 | SQL on FHIR views, profile validation, multi-tenancy, direct SQL access | Commercial license terms for production use |
Your cloud or vendor agreement, including its BAA, sits with the vendor. We sign a BAA with you for our work with PHI.
Expertise is in the decisions
A managed store removes database operations but limits custom operations and search. A self-run HAPI, Medplum or Aidbox server gives control and moves upgrades, patching and recovery to your team.
A FHIR store serves applications through a live API. Population analytics belong in a warehouse or lakehouse fed by Bulk Data export or SQL on FHIR views.
Load US Core and program profiles before the first write. Retrofitting validation onto stored resources means reprocessing the data.
Define identifier systems per source and a matching approach before merging records. A wrong merge in a FHIR store is expensive to undo.
Choose a store per tenant, a partition per tenant or compartment-level access, and confirm the regions each option supports.
A Consent resource records a decision; the API still needs code that enforces it on every read and search.
You hold the cloud subscription, vendor licenses and their BAAs. We design and build within them.
EHR vendors and source owners grant exports, feeds or database access. We prepare the technical requests and test them.
Clinical owners approve mappings with clinical meaning, such as problem lists and medication reconciliation rules.
Product screens built on the FHIR API are scoped with our EHR and product engineering teams.
Timeline
Typical durations for a first production-ready FHIR platform. Source access and profile decisions set the pace.
2 to 3 weeks. Requirements, store comparison against them, profile selection and the access model.
3 to 5 weeks. Environments, infrastructure as code, profiles, identity, SMART clients and CI/CD.
4 to 8 weeks. Source mappings, validation, provenance, search tuning and Bulk Data export.
2 to 4 weeks. Load, recovery and security testing, runbook and handover.
Delivered work
Client names are withheld; each is a real engagement. Our open-source FHIR work is public on GitHub.
A headless EHR with a FHIR R4 API, Bulk Data export and SMART App Launch that passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient tests in Inferno on 11 June 2026.
FHIR servers for Coverage Requirements Discovery, Documentation Templates and Rules and Prior Authorization Support, tested with the Inferno test kits.
Scheduling, charts, care plans and billing built with a Medplum FHIR server as the only backend. Keycloak single sign-on is bridged to Medplum with PKCE and OAuth token exchange, and bookings use FHIR batch transactions so Appointment and Slot change together.
An openEHR clinical data repository deployed on Kubernetes with identity, a master patient index, template validation before data lands, researcher roles and cohort export to FHIR or openEHR.
From discussion to delivery
Resources, operations, profiles, tenancy, region and the consumers of the API and the exports.
Load representative synthetic data, run the key searches and access paths, and confirm the choice.
Ingestion, validation, authorization, export and observability, released through CI/CD.
Recovery tests, upgrade plan, runbook and a support model your team can own.
We agree the scope, dependencies, acceptance criteria and commercial model before implementation. Your existing team can stay involved throughout.
Find the right starting point ↗It is a FHIR store or server plus the engineering around it: ingestion and conversion of source data to FHIR resources, profile and terminology validation, SMART on FHIR authorization, consent and audit, search performance, Bulk Data export for analytics, and the operating model that keeps it running.
The terms overlap. A FHIR server implements the FHIR REST API and persistence, such as HAPI FHIR, Medplum or Aidbox. A FHIR store is the managed-cloud term for a FHIR data store inside Google Cloud Healthcare API, AWS HealthLake or Azure Health Data Services.
Choose a managed service when your team wants the cloud provider to run the database and its supported operations cover your needs. Choose HAPI FHIR or another self-run server when you need custom operations, search behavior, deployment location or full control, and can own upgrades and recovery.
The best fit usually follows your existing cloud and analytics stack. Google Cloud Healthcare API pairs with BigQuery streaming export, AWS HealthLake with S3-based NDJSON import and export, and Azure Health Data Services with $convert-data for HL7 v2 and C-CDA. We compare them against your required resources, searches and regions.
Yes. Microsoft retires Azure API for FHIR on 30 September 2026, and new deployments have been blocked since 1 April 2025. Workloads move to the Azure Health Data Services FHIR service; we plan and execute that migration with export, import, reconciliation and client cutover.
Yes. We build on HAPI FHIR, Medplum or Aidbox, or write a purpose-built server where requirements justify it. Our open-source headless EHR exposes a FHIR R4 API with SMART App Launch and passed 47 of 47 ONC (g)(10) SMART App Launch standalone patient tests in Inferno.
We map each source to FHIR R4 resources, validate against US Core or your profiles, preserve source identifiers and Provenance, and load through transaction bundles or the store's bulk import. Every load is reconciled to source counts, with rejected records routed for review.
Usually not as the analytics engine. A FHIR store serves applications; analytics runs best in a warehouse or lakehouse fed by Bulk Data $export, BigQuery streaming export or SQL on FHIR views.
We choose between a store per tenant, partitions or compartment-based access based on isolation and cost, and deploy in the regions your contracts require. Access rules are tested per tenant before go-live.
The service provides eligible infrastructure under the vendor's BAA. Your configuration, access control, audit, consent enforcement and procedures complete the picture, and those are what we build and document. We sign a BAA with you for our work with PHI.
A first production-ready platform typically takes 11 to 20 weeks: 2 to 3 weeks of architecture and store selection, 3 to 5 weeks of foundation, 4 to 8 weeks of ingestion and APIs and 2 to 4 weeks of hardening.
The number and format of sources, profiles and custom operations, tenancy and region requirements, search and export volumes, the managed or self-run choice and the operating support you need. We estimate after the architecture phase.
A useful first conversation
Tell us what exists today, who uses it and where the workflow breaks. We’ll discuss the scope, access dependencies and the next practical step.
A product overview and a de-identified workflow are enough to start. No patient records or credentials are needed.
These are independent reference sources, not endorsements. Applicability, platform access and current requirements are confirmed for your project.
