DevDays 2026 recap: what’s changing in the world of FHIR

The 2026 edition of HL7 FHIR DevDays wrapped up in Minneapolis a couple of weeks ago, and for the first time in years, I came home without a long list of “have you seen this new FHIR feature” conversations.

Not because nothing interesting happened. It’s because the interesting part was somewhere else entirely: artificial intelligence (AI) is starting to change how FHIR actually gets built.

AI is changing how we build with FHIR

For years, a handful of vendors, us included, put in the work to turn the FHIR standard into production software. That took time, and it took teams. In our case, that’s meant about fifteen years contributing to the standard itself and building open source tooling around it.

That groundwork is exactly what AI now has to work with. People are pointing AI models at that existing open source code and the specification itself and effectively saying, I need a subset of it for a specific use case: generate the software for me.

Take Clinical Quality Language (CQL) and Digital Quality Measures (DQMs). We’ve debated for years whether they’d actually take off. That question feels settled now, DQMs are everywhere, and what’s shifted is less about whether CQL wins as a runtime language than what it’s used for.

For example: CQL doesn’t have to run natively inside your decade old system to be useful. It can be a source language, a kind of specification, something an AI reads and translates into whatever your existing software already understands. You don’t need to build a full CQL engine, and you are fixing a different problem than the one we thought we were solving five years ago, with more ways of getting there than we had before.

Underscoring the value of these kind of events, and the free flow of ideas, Evan Machusak (who we collaborated with on our .NET CQL engine during his time at NCQA and is now at Optum) disagreed. His take was that AI’s are not yet powerful enough to make this work correctly for all use cases, and showed us a more classic approach using relational algebra to make CQL work at scale.

Why FHIR matters more, not less

We saw a related shift in the Student Track. What stood out to the judges wasn’t that students got smarter. It’s that AI is letting people without years of FHIR expertise build things that are, in their own words, almost marketable, and something that could genuinely become a product in its own right.

I think that’s also why FHIR matters more, not less, here. AI works best against a structured, verifiable target, a codified list of conditions, and a payload you can actually validate. We heard the same sentiment come through in the 2026 State of FHIR report that we run every year with HL7 International (you can check out our key findings here).

It’s the same reason vibe coding something from zero tends to come out a little mushy, while starting from a well specified requirements document, or an existing base you’ve built by hand over the years, gives AI real scaffolding to work from and produces far better results.

My two talks: .NET SDK 6.0 and terminology

Beyond all of that, I had a couple of sessions of my own this year, on the FHIR .NET SDK 6.0 and on our terminology service work. Different topics, same underlying problem. A lot of the real engineering isn’t in the parts you build yourself, it’s in everything around them: data that shows up looking nothing like you expected, and code systems and servers that live outside your walls.

Our .NET SDK 6.0 has been public for a year now and is running inside Firely Server itself. Its major feature is how it handles data it doesn’t recognize, unknown elements, incorrect types, misspelled primitives, by routing anything unexpected into an overflow structure instead of failing outright, with almost no data loss (even from imperfect input).

Not the sexiest topic perhaps, but with our SDK being downloaded about 140 million times (plenty of automated builds), including through Microsoft’s own FHIR products, a lot rides on getting the boring parts right.

Terminology is the same kind of problem in a different shape. We built out more complex terminology handling for the Centers for Medicare and Medicaid Services (CMS) this year, and I shared some learnings.

My key takeaway was that terminology always has one more layer of complexity that you never thought about, especially once you get into corner cases. My advice to anyone starting that kind of work: don’t build a terminology server yourself, buy one. It’s not a lesson you learn once. It’s one you keep re-learning.

The keynote that stayed with me

That was a keynote from our CEO, Martine Berden, and Oura’s Clinical Director of Women’s Health, Chris Curry, on making wearable data actually interoperable, and on why the menstrual cycle, already classified as a vital sign, still doesn’t get treated as one in most systems.

It’s also not a slippery slope argument, where including one thing means you have to include everything. It’s specific, and it’s essential enough to women’s health that it’s genuinely surprising it hasn’t been treated as a vital sign already.

All in all, another great DevDays. One of the things I still love about it, sixteen years in, is that the whole community, competitors included, still shows up to share information rather than just pitch products. That kind of openness could easily have eroded by now, with sixteen years of commercial pressure behind it, but it hasn’t. What’s changed is the pace. It’s a little crazy how much became possible in a year, and I’m already curious what we’ll all be talking about at the next one.