Overview
When providers suspect an adverse reaction to a drug or vaccine, they're required to notify the FDA. Traditionally, that meant typing patient demographics and symptoms into a website on fda.gov. Manually. The VA decided that wasn't good enough. Using FHIR APIs, they now auto-submit adverse event notifications, bypassing the manual process.
Fast Healthcare Interoperability Resources (FHIR) is the standard behind that shift: a RESTful API that lets healthcare systems request specific patient data instead of copying entire records between organisations.
Whether you're evaluating FHIR for your health system or building on it as a developer, here's how it works in production, and why the VA moved faster than anyone expected.
What the VA and FDA Built with FHIR
The system is called Project BEST. It runs on eHealth Exchange and it's one of the nation's largest health data networks. This now handling over 25 billion transactions annually and uses FHIR APIs to connect the FDA with provider records, including the VA across 46 states.
Project BEST supports two models:
The poll model. The FDA learns about an adverse event and needs more patient data. It sends a FHIR API request through eHealth Exchange, which queries its network of healthcare providers, bundles the relevant clinical records, and returns them to the FDA. Request, response, done and no manual data entry, no faxes, no delays.
The push model. The VA went a step further. Instead of waiting for the FDA to ask, the VA automatically submits adverse event notifications via FHIR the moment they're identified. Proactive rather than reactive.
"The VA is a huge behemoth — it's the largest health system in the United States, government owned and operated. And I tell you, they implemented this faster than any little startup I've ever seen."
Jay Nakashima, President of eHealth Exchange
Project BEST runs through the eHealth Exchange Hub, powered by InterSystems IRIS for Health and InterSystems HealthShare, delivered as InterSystems cloud-hosted managed services.
But here's what makes Project BEST more than a one-off success:
"This is a repeatable pattern that we could use for other public health use cases, for payer-to-provider exchange. The list goes on and on." - Jay Nakashima
The network was built for provider-to-provider exchange. Project BEST repurposed it for public health. The pattern works wherever data needs to flow between organisations that don't share a system.
What Is a FHIR API?
HL7 FHIR is a healthcare data standard developed by HL7 International, and Jay Nakashima defines it plainly:
"FHIR is just a more modern API that's not plug and play, but as close as we're going to get in the next 20 years." Jay Nakashima organizes health information into modular data models called resources, such as Patient, Medication, Observation, Encounter. Each of thesea re accessible via a RESTful application programming interface (API) built on REST principles. GET retrieves data. POST creates a new resource. PUT updates an existing one. DELETE removes it. Requests and responses use JSON or XML format, with standard HTTP status codes indicating success or failure.
A FHIR API request looks like this:
GET https://fhir.example.com/Patient/12345/MedicationRequest
"You're not copying healthcare data around the country. In this case you're saying: 'FDA wants to know about Don Woodlock. Let's grab those records.'" - Don Woodlock, President of InterSystems
Old interoperability was copy-and-paste, data was duplicated from labs to EMRs, from one organisation to another. FHIR replaces that with request-response, and the precision matters:
"I don't need the equivalent of 300 pages of information on patient Jay. I just need his lab results." - Don Woodlock
Systems request exactly what they need. That precision reduces overhead, improves accuracy, and limits unnecessary exposure of patient data.
Platforms like InterSystems IRIS for Health provide native FHIR server capabilities, enabling healthcare organisations to expose clinical data as FHIR resources without rebuilding their underlying systems. For developers, that means a standards-compliant FHIR endpoint backed by a data platform that already handles HL7 v2, CDA, and FHIR side by side.
SMART on FHIR and the Open API Ecosystem
FHIR interoperability isn't limited to organisation-to-organisation data exchange. SMART on FHIR is an open specification that lets developers build health applications that run across different EHR systems using OAuth-based authorisation to control data access. Its creators call it an "app store for health": substitutable applications that work with any SMART-enabled electronic health record.
FHIR is built on web standards developers already know; REST, JSON, HTTP. No proprietary healthcare middleware required. That accessibility has driven adoption across the healthcare industry. Combined with SMART on FHIR, developers build once and deploy across multiple health systems. And as AI agents begin connecting to healthcare tools, FHIR provides the standardised data layer those agents need to operate safely.
Regulation reinforces adoption. The Office of the National Coordinator for Health Information Technology mandates FHIR APIs in certified EHR programs. The 21st Century Cures Act requires secure, app-based patient access. And CMS-0057-F requires payers to implement FHIR-based prior authorisation APIs by January 2027, with operational requirements starting in 2026.
InterSystems HealthShare aggregates data from disparate healthcare systems; EHRs, labs, billing platforms, patient portals, into a unified patient record, giving FHIR APIs and SMART on FHIR applications a coherent layer for standardised data exchange.
Getting Started with FHIR
FHIR adoption isn't automatic across the healthcare industry. Many older systems lack native FHIR support. Implementations vary between EHR vendors. And sharing data through FHIR requires careful management of privacy, security, and patient consent.
Three practical starting points:
- Start with a defined use case. Project BEST succeeded because it solved adverse event reporting, which was a specific problem, rather than trying to FHIR-enable everything at once.
- Assess your integration infrastructure. Can your systems expose data as FHIR resources today? If not, an integration engine that handles protocol translation is the first investment.
- Partner with vendors who support FHIR natively. The gap between “FHIR-compliant” and “FHIR-native” matters, native support means fewer translation layers and fewer failure points.
