FHIR APIs may promise a more standardized approach to healthcare data exchange, but moving data at scale still requires significant engineering, governance and collaboration.
That was the takeaway from a Civitas Networks for Health 2026 Annual Conference session detailing how Idaho Health Data Exchange (IHDE) and Orion Health tackled a bulk FHIR project involving approximately 429,000 payer members and 3.4 million API calls.
The project began with what sounded like a relatively straightforward request: A payer partner wanted a bulk FHIR dataset it could use for analytics.
But IHDE Executive Director Jesse Meldru said the organization had already watched another payer struggle with the technical complexity of consuming the data itself. Rather than repeat that experience, IHDE took on more of the integration burden and ultimately delivered the data in a format the payer could readily use.
That approach reflects how Meldru views the HIE’s role: not simply as a conduit for data, but as a “trusted third-party intermediary” capable of absorbing complexity for its customers.
When Scale Changes the Equation
With over 400,000 members, even standard APIs presented engineering challenges. The project required more than 3.4 million API calls and approximately 50 hours of continuous data pulls. Teams had to manage short-lived security tokens, multiple parallel workers, failed processes and the risk that pulling data too aggressively could overwhelm the underlying infrastructure.
The teams eventually developed a “heartbeat” monitor that detected slowing response times and automatically reduced the workload before the system became overloaded.
Security and governance added another layer.
IHDE used patient matching to restrict the extraction to members on the payer’s roster rather than its entire patient population. The team also discovered that roughly half of the members had lost eligibility during the relevant period, requiring it to remove clinical information generated after each member’s eligibility cutoff.
FHIR Isn’t Necessarily the Final Format
Getting the data out was only part of the challenge. Raw FHIR R4 data arrived as nested JSON, which proved cumbersome and expensive for the payer’s analytics environment. The team ultimately converted the data to Parquet, a format better suited for large-scale analytics.
The lesson was not that FHIR failed, but that interoperability does not end when data conforms to a standard.
As one panelist put it, payers may want FHIR one day, Parquet the next and CSV after that. “We always thought that FHIR was going to solve this interoperability problem with the payers. It’s not even close.”
IHDE also enriched the dataset with information not readily available through the FHIR APIs, including blood pressure readings extracted from HL7 messages and provider identifiers matched against registry data.
For HIEs, the experience points toward an expanding role. As healthcare organizations gain access to more standardized data, their challenge increasingly becomes making that data secure, usable and fit for a specific business purpose.
In other words, APIs may provide the connection. Making interoperability work at scale still requires someone to handle the last mile.