FHIR comes up in almost every health IT conversation, from EHR certification to payer APIs. Below are the questions health IT teams ask most, each answered on its own. For how FHIR compares with HL7 v2, and what a FHIR implementation involves end to end, see our healthcare interoperability solutions page.
1. What is FHIR?
FHIR (Fast Healthcare Interoperability Resources) is a standard from HL7 International for exchanging healthcare data through web APIs. It breaks health information into small, structured units called resources, such as a patient, a lab result, or a medication, which systems can request and update over standard HTTP. It is the standard behind most US regulatory API requirements for EHR vendors and payers.
2. Which FHIR version should we build on?
Most production systems in the US run FHIR R4 (version 4.0.1), and the main US implementation guides, including US Core and the Da Vinci guides, are built on it. R5 was published in 2023 but has seen limited adoption. R6 is still going through normative ballots, and final publication is not expected before mid-2027. For regulated work today, R4 is the practical choice.
3. What is a FHIR resource?
A resource is the basic building block of FHIR: a defined structure for one kind of healthcare information, such as Patient, Encounter, Observation, or MedicationRequest. Each resource has a set list of elements, a unique identifier and a URL, and can reference other resources. FHIR R4 defines more than 140 resource types, though most implementations use a small subset of them.
4. What is a FHIR implementation guide?
An implementation guide is a set of rules that narrows FHIR down for a specific use case or country. Base FHIR is deliberately flexible, so an implementation guide states which resources to use, which elements are required, which code systems apply, and how systems should behave. Two systems that follow the same guide can exchange data far more reliably than two that only follow base FHIR.
5. What is US Core?
US Core is the baseline FHIR implementation guide for the United States, built on FHIR R4. It defines how to represent the data classes in the United States Core Data for Interoperability (USCDI), such as patient demographics, problems, medications, allergies, and lab results. Certified EHR APIs are tested against it, and most other US implementation guides build on its profiles. New US Core versions track new USCDI versions.
6. What does SMART on FHIR mean?
SMART on FHIR is a framework for securely connecting apps to FHIR data. It uses OAuth 2.0 and OpenID Connect to let a patient or clinician authorize an app, and defines how an app launches from inside an EHR with the right patient context. Its Backend Services profile covers system-to-system access with no user present, which payer and bulk data exchanges rely on.
7. What is FHIR Bulk Data export used for?
FHIR Bulk Data export, often called Flat FHIR or $export, retrieves data for a whole group of patients in one request rather than one record at a time. Results are returned asynchronously as NDJSON files. It is used for population health, analytics, quality reporting, and payer data exchange, and it is required under ONC certification and under the CMS interoperability and prior authorization rule.
8. Is FHIR mandatory in the US?
For some organizations, yes. EHR developers certifying under the ONC Health IT Certification Program must offer a standardized FHIR API for patient and population data. Under the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), Medicare Advantage, Medicaid, CHIP, and Qualified Health Plan issuers on the federal exchanges must run FHIR-based Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs, with most API requirements starting January 1, 2027.
9. How does FHIR relate to the information blocking rules?
The information blocking rules, from the 21st Century Cures Act, prohibit health care providers, certified health IT developers, and health information networks from practices that unreasonably interfere with access to, exchange, or use of electronic health information. FHIR APIs are the main standardized route for that access, so a slow, restricted, or unusually priced API can raise information blocking questions. The rules include specific exceptions, and legal review should decide how they apply.
10. What does FHIR conformance testing involve?
Conformance testing checks that a FHIR system follows the specification and the implementation guides it claims to support. It covers resource validation against profiles, required search parameters, terminology bindings, and security behavior. Common tools include the HL7 FHIR Validator and Inferno, the open-source test suite used for ONC certification of FHIR APIs. Testing against real, messy production data matters as much as passing the test suite. A pre-go-live FHIR API checklist helps catch these gaps early.
11. What makes FHIR data mapping difficult?
Mapping is usually the hardest part because source systems rarely store data the way FHIR expects. Local codes have to be translated to standard terminologies such as LOINC, SNOMED CT, and RxNorm; required elements are often missing, and important details sit in free text. When data comes from several systems, the same fact may be recorded differently in each, and those conflicts have to be resolved before it is exposed. This is the gap between FHIR compliance and true interoperability.
12. How long does a FHIR implementation take?
It depends on scope and data quality. Exposing read-only US Core data from a single, well-maintained EHR can take a few months. Payer APIs under CMS-0057-F, bidirectional exchange, or data spread across several systems usually take considerably longer. The largest variables are data mapping, terminology work, and conformance testing, so a short scoping review of source data is the most reliable way to estimate time.
13. Who owns FHIR work inside a health organization?
Ownership varies by organization type. At health IT vendors, FHIR work usually sits with product engineering. At providers, it typically sits with the integration or interoperability team inside IT, working with clinical informatics on data meaning. At payers, it often sits with a regulatory API program tied to CMS deadlines. In every case, compliance and privacy teams need a defined role in access decisions.
Related reading
Closing
Planning a FHIR API or a CMS-0057-F project? Talk to our interoperability team.
Latest posts by Priti Prabha (see all)
- FHIR Implementation FAQs: 13 Questions Healthcare IT Teams Asks - November 3, 2026