Hooked on FHIR: A Platform, App, Microapp Approach

News | September 10th, 2019

Working at the intersection of health tech and payment model reform is a bit like building a house – everything takes longer than expected and costs more than budgeted. If we look back on the journey towards interoperability, it has been punctuated by hype, delays, and debate. The same can be said for the drive towards value-based care. Those original pioneer ACOs feel like a lifetime ago. Didn’t we all think we would get to the end of this road a lot faster?

Adoption of FHIR (Fast Healthcare Interoperability Resource) as the API standard for healthcare data exchange follows this same pattern. For those of us who have been involved since early days, it feels like the adoption cycle has been counted in dog years. But wow, is it spreading like wildFHIR now!

Thanks for Steven Posnack with ONC for this visual overview of where we’ve come from.

There’s no more doubt that FHIR is THE API standard in healthcare. Now it’s a question of what our industry and entrepreneurs will do with it. The energy, creativity, and conviction flowing into this sector was palpable at FHIR Dev Days. Here are my key takeaways

FHIR: Far Harder in Real Life (clever, right? Credit to David Hay)

Implementing FHIR is much harder in real life than in a sandbox for an innovation project.

This was the topic of my talk at DevDays: the experience of rolling out a SMART on FHIR app across four commercial EHRs. There’s tension in the balance when our vision of what’s possible meets up with the current implementations of FHIR supported by commercial EHRs. For instance, clinicians would often ask about the ability to write back risk scores and analytics into their EHR from SMART on FHIR apps, while most commercial EHRs severely limit write capabilities. I’m also often asked for the ability to push alerts directly to the EHR inbox, or to write orders directly to the order queue. Clinicians are looking for ways to do the right thing for patients faster, with fewer clicks.

At Rimidi, we’re committed to giving clinicians the data, insights and decision support they want in their workflow. It just takes a lot of creativity and persistence to make it a reality today.

Quality Measures and Clinical Decision Support Go Hand-in-Hand

Quality measures and clinical decision support (CDS) are two sides of the same coin — not two separate initiatives. While population health platforms and initiatives are a great start to improving quality, they fall short when it comes to connecting metrics and gaps in care analysis to clinical action. In other words, they present a problem, without providing an actionable solution. CDS tools take the next step to drive the actions necessary to impact individual patient outcomes, and, therefore, population metrics.

At DevDays, MITRE and NCQA jointly presented on the impact of FHIR on quality measurement. This quote from the presentation struck me, as it’s what we’ve been building towards at Rimidi for the past couple of years: “Quality measures that are based on practice guidelines, and you can act on those guidelines at the point of care — that’s the future of quality measures.” This may sound obvious, but it’s far from reality in today’s clinical and quality reporting workflows.

Currently, quality teams generate reports that are shared with clinicians at some interval – weekly, monthly, quarterly. Clinicians may have access to the population health platform themselves but often don’t have the time to spend navigating the data and dashboards themselves. The hope is that these reports will generate some clinical action either by a dedicated care team or by the clinician at the point of care. There’s a lot of friction in making that happen and that’s where we find friction in quality initiatives. What NCQA, Mitre, and Rimidi are building towards is a future state where this is all one system, one data model, and there’s alignment behind one set of objectives.

Merging quality metrics with in-workflow decision support will remove the burden of quality reporting as a separate activity from clinical decision making.

Implementing Point-of-Care Clinical Decision Support

One of our core goals at Rimidi has been to bridge this gap from understanding population outcomes, to point-of-care decision making. We have implemented clinical decision support cards that are based off of the latest evidence, clinical guidelines, and client protocols, yet unique to each patient based on their data. For example, a patient with poorly controlled diabetes as well as diagnosed atherosclerotic cardiovascular disease might benefit from an SGLT-2 or GLP-1, whereas a different patient with poor diabetes control but no heart disease may be more appropriate for basal insulin therapy.

Right now, the cards pop up when a clinician launches the Rimidi app and clicks into a specific patient. In the future, as FHIR implementations mature across EHR vendors, the cards will surface automatically in the patient’s record. Embedding these clinical decision support cards within the existing workflow will speed the adoption of effective, evidence-based therapeutics, as well as offer insight into prescribing behavior (e.g. is the therapeutic cost prohibitive? Is it contraindicated?)

Best case? Clinical decision support cards will immediately improve patient outcomes. Alternatively? They’ll uncover reasons why there such a disconnect in the U.S. between the amount we spend on care, and the outcomes we achieve and allow us to focus on addressing those factors.

If this is a topic you’re interested in, I’d love to talk further. Please feel free to connect with me on LinkedIn, or email me at Lucie@rimidi.com.