Favorite Ideas from FHIR DevDays 2021
"For a lot of US states, these FHIR APIs are going to be the first public ones they even have"
I went to FHIR DevDays (Virtual) this week. DevDays is a talk-oriented conference on the latest and greatest in the health data engineering space (obviously FHIR). Being a developer focussed event, I was excited to attend for the first time as someone who thankfully has never had to maintain an X12 system.
FHIR is the future of health data and health information systems. Eventually, it will become the superset reference/co-ordinating point even for previous standards because of stream processing improvements and functional programming innovations on mapping previous schemas to new ones.
Here are the best ideas I found.
FSH/SUSHI
It was almost embarrassing to find out about FSH/SUSHI. FSH is FHIR Shorthand.
We’ve been manually prototyping a FHIR Profile at Automate. We’re hoping to co-ordinate the development of an Implementation Guide for interoperable pulmonary function tests (we’re looking for collaborators on this).
FSH is an amazing tool because it is so distinctly part of “text culture” programming. Text culture means CLI over GUI, *nix, vim, markdown. With a simple, but feature-rich set of expressions you can generate valid JSON-formatted FHIR Resources without any of the tedium of having to write JSON.
I think this is going to significantly advance the addressable audience for FHIR Profiling in the first place, and is especially a startup friendly tool. Keep in mind that competing projects like the GUI-based Forge charge license fees for commercial use.
Did I mention the reference implementation is written in TypeScript? Thanks to Chris Moesel and Mark Kramer for their talks on this.
Subscriptions in R5
Honestly, hearing Gino Canessa about Subscriptions in R5 was like being at a normal industry-agnostic tech conference. It sounded modern and focussed on an important area: stream processing.
During my time at Ticketmaster, post-Universe acquisition, they invested significantly in stream processing to fix decades of other bad systems design decisions. I’m convinced this is an important development in system maturity and will have important consequences. According to McKinsey , ACOs for example spend up to 1.5% of the total cost of patient care on analytics systems.
Gino’s slides are publicly available here.
GraphQL Advocacy
I invested significant engineering resources into GraphQL during my time leading tech at Universe (I wrote about that here). GraphQL type definitions are formally part of R4, but hearing a couple of conversations (including the pubtalk I got to impromptu host) about GraphQL has me thinking on other use cases.
Matt Bourne presented a talk on consuming FHIR through a project called GraphQL Mesh (JavaScript, of course - a theme). I was very surprised to hear that a FHIR connector already exists.
Matt’s advocacy for GraphQL was on point:
The underlying challenge I see is that our industry is that we’re not creating enough new and engaging applications with the world of rich data our systems actually hold. This has a huge real impact on the cost of care and patient health.
GraphQL provides an excellent way to smooth out a lot of the difficulty in learning FHIR [to new developers].
I’m excited for this space to mature, and for better GraphQL on FHIR developer tools to exist in the near future.
Health cards, health cards, health cards
I’m not sure if “vax passes” will actually work out. Maybe.
But health cards definitely will. They’re an amazing intersection between decentralized web technologies (like W3C’s Verified Credentials project) and health data. During DevDays, Josh Mandel gave a great overview of the project in the context of immunization records.
Coincidentally, Apple launched their support for health cards during WWDC on the same day. This is a huge deal.
Computable schema mapping
Nikolai Ryzhikov’s Isomer presentation was phenomenal (slides here).
Isomer is an “Almost "academic" bidirectional mapping language”. Nikolai joked (I think?) at the beginning of his talk that it had been rejected and only saved at the last minute by a cancellation.
Honestly, if it’s true it speaks poorly to either his pitch or their judgment because it was the best overall “hard tech” talk of the entire conference. Hopefully Nikolai will be able to present it to a broad audience because the ideas in it definitely appeal to the functional programming community at large.
Healthcare has unique problems with schemas. We have generations of data schemas, versions, protocols, systems, and local and regional decisions for all of it layered on top. Nikolai presented a way of generalizing a solution to the task of transforming health data messages (or any message) in a bidirectional way with no data loss through a fixed set of opcodes and a stack of those operations in a log.
I’m super excited to see him release the source because this idea combined with stream processing and the decentralized ideas in health cards form the foundation for generalized computability of health data.
Thanks for reading. If you’re interested in building health data systems, I’m hiring for that.