FHIR Vendors Directory: Compare FHIR Platforms, Integration Companies and Developers

‘FHIR vendor’ is a loose label. It covers companies selling very different things, and mixing them up is the most common reason shortlists go wrong. In this directory every listing carries one of four vendor types, so you can compare like with like.

Many real projects combine two of these, for example a cloud FHIR service plus a development partner to build the mapping and apps around it. If you are new to the standard itself, start with what FHIR is and how it relates to HL7 v2 and CDA.

• Regulatory deadlines. Certified health IT developers and CMS-regulated payers must expose FHIR APIs on fixed timelines (ONC certification criteria under the 21st Century Cures Act, and the CMS Interoperability and Patient Access and Interoperability and Prior Authorization rules).
• EHR connectivity for a product. A digital health app that has to read or write data in Epic, Oracle Health, athenahealth or another EHR usually needs either an integration platform or a team that has been through those vendors’ onboarding before.
• A new clinical data layer. Consolidating data from several source systems into a FHIR repository for analytics, care management or patient access.
• Modernizing HL7 v2 or proprietary interfaces. Migrating feeds to FHIR without breaking downstream consumers; see our FHIR migration service overview.

If your need is narrower, the specialist hubs may be a quicker starting point: FHIR integration companies, FHIR server providers or SMART on FHIR developers.

The best fit depends on your use case, not on a vendor’s size or marketing. These criteria separate capable vendors from the rest:

• FHIR version and IG coverage. Ask which FHIR versions are supported in production (R4 is the dominant version for US regulatory work; see R4 vs R5) and which implementation guides, such as US Core, SMART App Launch and Bulk Data Access, they have actually implemented.
• Evidence of conformance. A published CapabilityStatement, results from the ONC Inferno test kit where relevant, and sample requests you can run yourself.
• EHR experience that matches yours. Experience with a specific EHR’s onboarding, scopes and quirks matters more than a long logo list.
• Security model. OAuth 2.0 and SMART scopes, audit logging, encryption, tenancy isolation, and how PHI is handled in non-production environments. Our FHIR security guide lists what to ask.
• Operational ownership. Who monitors interfaces, handles EHR upgrades and fixes mapping errors after go-live.
• Exit path. Whether your data and mappings can be exported in standard FHIR if you change vendors.

• Claims of being ‘certified by HL7’ or ‘FHIR certified’. HL7 International does not certify products for FHIR conformance; ONC certification applies to health IT modules against specific criteria.
• No ability to show a running endpoint, a CapabilityStatement or a sandbox demo.
• Fixed quotes before anyone has asked which EHRs, which resources and read or write access you need.
• Implying a partnership or special access with an EHR vendor that cannot be verified on that vendor’s own developer or marketplace pages.
• Proprietary data formats behind a thin FHIR facade, with no clear export path.

Listings are not rankings. Vendors appear in the order set by your filters, and every profile shows whether its details are vendor-claimed or editorially reviewed, plus the date it was last reviewed. Sponsored placements are always labelled as sponsored and never change a vendor’s verification status. The full rules are in our editorial policy.

To narrow a long list quickly, use find a vendor to describe your project, or compare vendors side by side. If your company is missing, you can submit a vendor listing.