Healthcare’s most popular standard, brought to you by HBO
“The night is dark and full of terrors.”
Digital health developers looking at integration
I come to you in this newsletter to bring you a tale of legendary proportions, an epic fantasy with a vast array of characters of dubious backgrounds, unclear motives, and competing priorities. All seemingly strive for a better world, rallying the masses to their cause and to their banners. Powers only dreamed of by prior generations have been awoken, bringing fortune and glory to some.
I speak of course of the rise of healthcare’s most popular new standard: Fast Healthcare Interoperability Resources.
Awaiting the fearless reader who ventures on below is an epic saga of how FHIR is like the world of Westeros, how you should think about FHIR, and a simple framework to plan out an integration strategy (FHIR or otherwise) to help your digital health company thrive.
Note: If you like FHIR (or even just APIs), come work with us at Zus! We’re going to be doing all sorts of fun FHIR things, in addition to best-in-class developer experiences. The team rocks, it’s a lot of fun, and we’re fixing some really big problems.
One of the most asked-for topics from readers is to explain FHIR. It’s new, it’s modern, and it’s exciting. It’s seemingly the answer — the ultimate good — that has come to save the world of healthcare technology and fix all problems. It’s not surprising that’s the narrative that is often told and heard — stories with clear heroes and villains are easier to tell.
However, the world is not a series of pure black and white, good and bad, right and wrong. It’s filled with nuance and subtle shades of truth dependent on experiences, wants, and needs. The world of George R. R. Martin was so compelling because it wasn’t the standard fantasy trope — it portrayed a dynamic set of relationships, with each participant often in conflict due to their unique incentives and perspective. In that way, it looked and felt like the human experience (sans dragons) — at least until Benioff and Weiss took the reins and clumsily jammed it back into the normal fantasy framing while gleefully inserting violence and sex scenes.
Thus, this analogy comes to life. FHIR and the world of Game of Thrones (pre-B&W) both have nuance and shading that depend on your perspective, your wants, and your needs. Neither operate in absolutes, so understanding where you sit in the universe is vitally important to survival and success.
“When you play the game of digital health, you win or you die. There is no middle ground.”
Cersei, a ruthless capitalist
Young healthcare companies need a couple things.
- They need to solve a real problem (surprisingly more rare than it should be).
- They need to understand who they’re selling to (providers, payers, employers, patients, or pharma).
- They need to know how to best reach and work through that audience’s buying process.
- Most painfully, once they’ve figured out all of the above, they often need to determine a viable strategy to integrate or interoperate with other systems in order to actually appeal to their customer.
This is a gauntlet few survive. So I was super excited to be invited to speak to On Deck’s first healthcare-specific cohort on the topic of FHIR this past month — both to help those nascent companies in their journey and also as a forcing function to put down some thoughts for an oft-considered (but consistently procrastinated) topic for me.
Note: The full deck is here as well if you prefer slides over video.
https://youtu.be/fxnR1xM_G-A
There’s a lot beyond just FHIR in that presentation (it’s an hour of content, of which only a bit is summarized below), so I recommend checking it out for the full multimedia experience.
FHIR is a standard for communicating data designed with modern API principles (for a deep dive on the topic, I recommend SmileCDR’s Intro to FHIR). As a result, it has distinct advantages over legacy standards and alternative formats. Some things I like about FHIR:
- It’s popular. The community is active and vibrant. Overall, adoption has been swift for many use cases, especially compared to HL7v3.
- It has open documentation. This shouldn’t be a differentiator, but so many standards and API docs are still gated or even paid, walled gardens (I’m looking at you, NCPDP and X12).
- It’s an excellent, feature-filled API specification. There’s a lot to love about it in terms of what it could potentially do: self-describing specifications and profiles, automated app registration, various accelerators focusing on advanced features.
- It’s query based. Given RESTful queries are a familiar paradigm for data exchange, developers are familiar with query oriented APIs. HL7v2, notably, was not great for queries.
- It’s easy to store in a database. It’s a serviceable data structure for storing information given its resource orientation. HL7v2 was not. When you can store information in the same format as you send it, there’s arguably less translation and less lossiness.
But it’s definitely not a magic wand. Understanding the flaws, gaps, and gotchas is necessary to avoid pitfalls and wasted energy.
- Adoption does not mean rip-and-replace. FHIR’s adoption has been heaviest in greenfield scenarios (patient authorized exchange, provider app querying). However, without regulation, it’s not likely that FHIR will be used universally and displace HL7v2 for lab workflows, X12 for claims processes, etc. Existing regulation (ONC Cures) doesn’t do this, although many convince themselves it does. Check out the discussion here for more perspectives.
- There’s an adoption mirage. Much of what you might read in the FHIR specification and say “Wow, I’m pumped to use that” isn’t actually available in the wild. Some EHR vendors like Epic and Cerner are going beyond what’s required for compliance in terms of resources, but many simply implement the bare minimum (USCDI). Advanced features like CDS Hooks for clinical decision support, FHIRCast for context synchronization, bulk FHIR for the large data exports that analytics or pharma apps need, or FHIR subscriptions or messaging for push / event driven workflows can’t be expected across vendors.
- Use case matters. Your trust paradigm (the legal basis by which you exchange data) drastically influences how useful FHIR is to you right now. If you’re building a consumer facing application, you’ll be dealing with a lot of FHIR, but only pulling USCDI. If you’re a provider organization looking to exchange with other covered entities, you’re still mostly looking at CDA, X12, and NCPDP. If you’re building a provider application with a BAA, you may have lots of FHIR available (Epic, Cerner) or you may have none (most EHRs).
- There’s variability across vendors. Even if a workflow is supported by an EHR vendor via FHIR, there’s a lot of variation in terms of how that workflow might be architected. This means you’re still creating EHR-specific variations in order to integrate. For instance, when choosing how to expose scheduling availability and allow applications to schedule into the EHR, four of the top EHR vendors did it all differently. Likewise, there are 11 (!) different ways to do an orders and results workflow. So even if systems do look to proactively migrate from HL7v2 to FHIR for lab workflows, a possibility of variation remains.
The FHIR Choice
“Chaos isn’t a pit. Chaos is a ladder.”
Lord Baelish, an aspiring digital health founder
“Well shit, Brendan, this is more complex than I bargained for,” you’re probably thinking. And you’re not wrong. Healthcare integration is a hard problem due to its fragmented and highly decentralized nature, the complex set of players, roles, and workflows, and the baggage of decades of interoperability history.
FHIR is a huge leap forward and drastically simplifies the life of someone creating and building in healthcare. It’s only going to continue to help in that regard over time. But it does not fix outright the fragmentation and entropy of standards and formats we see today; it exacerbates that problem by adding new varieties of standards into the equation. Rather than despair, though, we can lean into this problem and seize victory from the jaws of defeat.
Success as a digital health company requires knowing who you are, what problems you solve, and the MVI (minimum viable integration) you need to solve that problem and sell to your customers. To do that, follow these easy steps:
Step 1: Who are you?
Categorize yourself into one (or more) of these buckets:
Here are some examples, if it helps
Step 2: What’s available to you?
As noted earlier, your trust paradigm drastically influences how useful FHIR is to you right now. That’s important to understand as you plan your integration strategy
Step 3: Keep it simple
Once you’ve categorized your company/product, there’s some divergent possibilities.
Provider Software
If you’re a BAA-style app selling to providers, you have highly variable data needs to facilitate your workflow, so you’ll want to:
- Define your workflow and map it to the data flows you’ll need to exchange with the EHR
- Assess your market and understand what EHRs your customers and prospects are using.
- Map your data flows to the most common inputs and output formats, likely a mix of FHIR, HL7v2, proprietary APIs, or flat files.
It’s highly valuable to come up with a tiered approach to connectivity, where your product has advanced features dependent on higher points of integration at higher price points. For instance, perhaps your cheapest tier has no integration, your second tier has basic demographic synchronization, and your premium product offering has full bidirectional data flow. This will align expectations with your healthcare organizations, as each additional interface or API drastically increases the complexity, work, and time necessary to get live and may also increase the healthcare organization’s costs.
Provider Organization
If you’re a digital health provider organization, your integration needs are luckily more straightforward, as the use cases are pretty much the same whether you’re a virtual diabetes clinic, a DTC teleprovider, or a concierge primary care organization. Virtual first care must integrate with payers for eligibility and claims, send prescriptions to pharmacies, pull medical history from disparate sources, and send labs and referrals to other provider organizations.
Your choice of EHR may help with this. You may use various API on-ramps and aggregators to build out your own sidecar application to fill in the gaps. You will still deal with a dizzying array of standards — X12 for payers, NCPDP for e-prescribing, CDA for nationwide clinical data, and HL7v2 for labs.
Prioritize and focus on the key exchanges you need to succeed.
Patient Application
As a consumer application, you’ll be aggregating via patient authorized endpoints. Your life is the simplest by default. Most of these will be FHIR: ONC Cures-driven patient portal data and payer data from the CMS Final Rule. But some may be proprietary APIs, such as consumer device data endpoints.
Step 4: Get help
This integration and interoperability shit is undoubtedly, unconditionally, and unceasingly hard. It’s also most likely not what you want to spend your time on, and certainly not what you want to be your core competency.
Luckily for you, this is the sole reason that vendors exist — to solve problems you don’t have the experience, time, or will to solve. There’s a broad array of vendors out there, each solving different types of integration and interoperability problems. Some are playing with FHIR, others are speaking FHIR natively, and some are doing things with their own API. Ultimately, the whole point of an API (standards-based or otherwise) is to enable developers and systems to connect and build with as little friction as possible. If a particular FHIR API does that for you, you should use it. If a vendor API does that, you should probably use it too.
Everyone loves a good choose your own adventure, right?
If you’re a virtual first care / digital health delivery organization (the middle column), we at Zus Health would love to chat with you more to understand your problems and help you solve them, if you’re up for it.
Closing
“If you think this has a happy ending, you haven’t been paying attention.” Ramsay Bolt-on Application
This is indeed not a happy ending. Building in healthcare is tough. We don’t have the luxury of massive consolidation to one or two vendors, as found in other industries. Just like Westeros, it’s an incredibly fragmented, heterogeneous landscape that is dangerous to its startup citizens.
While FHIR seems like the savior, we now know that’s not a guaranteed outcome. But whether FHIR ends up being Robb Stark (lots of promise, petered out in the end), Jon Snow (big impact, exiled eventually), or Daenerys (hero turned villain), you can survive and even thrive.
Good luck.
Big thanks to Gabe Strauss (aka our behavioral health PM overlord), Garrett Rhodes (aka the payer integration whisperer), Jonathan Pitocco (aka the Sword of Healthcare Workflows) and Colin Keeler (aka Lord Just IPOed) for their fantastic suggestions and editing.
More FHIR resources after the break:
Additional Resources
General
- Documentation — Very detailed documentation on FHIR. Take it with a grain of salt, though, as features and capabilities described in the spec aren’t always available with the EHR vendor you may aim to work with.
- Community– A great Zulip (pseudo-Slack that’s free) to ask questions and interact with the community.
- FHIR Blogs– Lot of perspectives about FHIR to be had here.
Video
- SmileCDR’s Intro to FHIR — As mentioned before, the best primer on the basics of FHIR.
- Josh Mandel’s intro videos — Lots of learning to be had here from Josh, Chief Architect at Microsoft and Extremely Smart Dude™
- Gino Canessa’s intro videos — Similar learning from Gino, an experienced engineer at Microsoft
- Nick Hatt’s videos (1, 2, and 3) — Some more FHIR lessons from Nick, my former colleague at Redox and one of the best engineers I know
Practice
- FHIR Exercises– Some basic FHIR drills to get familiar
- EHR Sandboxes — Sandboxes like fhir.epic.com, Cerner CODE, Allscripts ADP, or Athenahealth’s FHIR are a great way to understand and play with what’s actually supported in the wild.
