Bulk FHIR in the Real World: Trially's CEO Kyle McAllister Shares What Works

A conversation with Kyle McAllister of Trially on what it actually takes to connect to health systems at scale

Bulk FHIR Applications Community - Trially CEO Kyle McAllister. From the Bulk FHIR Applications Community series, hosted by Brendan Keeler.

Bulk FHIR was supposed to make it straightforward to pull large volumes of clinical data out of electronic health records (EHRs) using a single, standardized interface. The reality on the ground is messier. Few companies have tested that promise as broadly as Trially, which connects to a dozen or more EHR platforms to find patients who qualify for clinical trials. We sat down with Trially’s Kyle McAllister to talk through where Bulk FHIR shines, where it breaks, and what would have to change for the standard to live up to its potential.

Let’s start with Trially. What does the company do, and where does Bulk FHIR fit in?

At our core, we read patient charts at scale and match people to the eligibility criteria for clinical trials. To do that well, we need a broad, population-level view of each health system’s patients — medications, encounter summaries, clinical notes, scanned PDFs, chart summaries, the whole picture. It isn’t enough to look at one patient at a time; we need to evaluate entire populations.

That’s exactly why we chose Bulk FHIR. FHIR (Fast Healthcare Interoperability Resources) is the modern standard for exchanging health data, and the “bulk” flavor is designed to move data for whole populations rather than a single record. The big draw is that it’s supposed to scale across health systems without us having to build custom engineering for every site. Today we’re connected to somewhere between 12 and 15 different EHR systems, which makes us one of the more scaled implementations in this community.

How does the real-world implementation compare to the standard on paper?

The baseline specification itself is solid. The problem is that real-world implementation varies wildly from one vendor to the next. We can make the exact same Bulk FHIR call against two different systems and get completely different behavior.

And the variation runs deeper than the vendor level. Even within a single vendor, the way an individual practice has configured its system can make a connection effectively impossible. On paper, nearly every vendor advertises FHIR APIs on their website — but whether you can actually connect and get usable data is a different story entirely.

I describe it as death by a thousand cuts. You hit a 404 error when you try to trigger an export, or a required header is missing, or there’s some practice-level configuration issue that nobody can quite explain. We’ve even had support teams at certain EHR vendors tell us outright, ‘Don’t use our FHIR API — it’s not configured well.’ When the integration effort is that unpredictable, it becomes genuinely hard to commit to timelines with our own customers.

You’ve flagged unstructured data as a particular gap. Why does that matter so much?

So much of what’s clinically meaningful lives in unstructured content — the notes, the narratives, the scanned PDFs. Some EHRs expose that material, but coverage is very spotty, and the requirements for the document endpoints that deliver it vary widely from vendor to vendor.

This used to be a nice-to-have. With AI, it’s become critical. AI is what unlocks the value buried in unstructured documents, so the gap between systems that expose that content and systems that don’t is widening in importance. On top of that, every new EHR we onboard still takes meaningful integration work — prior experience with other systems only gets you so far.

Are there any EHRs that get it right?

Yes, and we’re happy to give credit where it’s due. Athena is consistently reliable. We can typically connect within days, the data is relatively consistent, and their proprietary API actually fills in some of the gaps left by the Bulk FHIR spec itself. The customer service experience has been great, too.

Modernizing Medicine is the other standout — reliable, easy to connect to, and their proprietary API is similarly accessible. When a new customer comes to us on either of those platforms, it’s a green light. We know the integration is going to go smoothly.

If you could change the rules, what would you ask regulators for?

My top ask would be to mandate coverage of unstructured data — the document endpoint — in regulation. AI has made that content more valuable than ever, and the structured data resources alone simply aren’t sufficient for what we and others are trying to do.

A close second would be stricter conformance testing for vendors that claim Bulk FHIR compliance. Right now there’s too much daylight between claiming support and actually delivering it. I’d also put better access to appointment data high on the list — my understanding is that recent USCDI updates already move in that direction, which is encouraging. (USCDI is the United States Core Data for Interoperability, the federal list of data elements that systems are expected to share.)

When FHIR doesn’t work, what do you fall back on — and what’s ultimately at stake?

When a FHIR connection fails, we get creative. We’ve used VPN tunnels, SFTP file transfers, and large CDA document pulls as fallbacks. (A CDA is essentially a standardized clinical document export — an older approach than FHIR, but it works.) Some of those implementations dragged on for months before we finally cut over to a fallback method.

It’s worth remembering why this matters. For a lot of patients, a clinical trial isn’t just research — it’s care. A stage four oncology patient may have no other option left. So when a FHIR connection silently fails, it’s not an abstract technical inconvenience. It directly blocks a provider from enrolling an eligible patient who needs that trial. That’s the real cost of these integration problems, and it’s why getting the standard right is so important.