Welcome. FHIR is a very exciting clinical data standard that we think is going to transform the world. A lot of folks are working on it. And today we’re going to talk about what you need to think about and FHIR and doing so on scale. So interesting discussion. My name is Don Rucker. I’m a doc who’s been interested in informatics for a long time. Many of you may know me as a former national coordinator. I’m pleased to be chief strategy officer at 1upHealth. And today I’m extremely pleased to be talking with Ricky Sahu, who is the founder of 1up, but more importantly has really over the last number of years done some amazing work thinking about how to bring FHIR to life. And we’ll try to avoid puns some may accidentally slip in. So, Ricky, you want to talk a little bit about what makes FHIR powerful in your mind?
Yeah, I mean, FHIR is one of these technologies that’s come to the healthcare industry over many years of iteration. And what’s really happened is it’s been that tech that’s brought the learnings and decades of lessons from the software tech industry into healthcare. And it’s really been the first language that’s been universally spoken by payers, providers, app developers. Now it’s entering in pharma, patients are interacting with it. So you can think about this as this unifying infrastructure for the healthcare industry that’s bringing the latest technologies from the most creative organizations in the world to healthcare and it’s unleashing a whole lot of potential. And what we’re really going to be talking about today is the scale that FHIR brings and what you need to do to operate at that level, which will unlock a bunch of interesting possibilities today.
You’ve written code that has now converted billions, if not trillions of clinical data items or fields into FHIR. How do you think about that data conversion? I mean, is it alchemy? Are you taking lead into gold? How do you think about that little reference to the middle ages there for historians?
Yeah, sometimes it feels that way, right, because… And it’s not just me. There’s a whole team at 1up that’s been doing amazing work. But yeah, sometimes it feels that way because you are interacting with this data from previous iteration of technology, where there are large sets of flat files or column like tabular data stores that have housed a lot of operational data and you’re bringing it into the world today where people are interacting with APIs, they’re interacting with one resource or one data point at a time. They’re reading and writing from it. They’re also then putting it into analytic environments that you can run queries and aggregations off of it. So there is a lot of nuance that’s required when you are taking data from, now we’re working with about 50 health plans, and taking these disparate data sets, these bespoke creations of theirs and all converting it into the same language.
I mean, it’s a bit of like building a Babel Fish where you have to take all these different languages or formats of data and transform it all into one canonical language. And there have been a bunch of challenges that we’ve faced. One big one is that there is this problem of a lot of data that needs to flow and with regulatory requirements, as you’re familiar, everyone has the same date. Right. So you can’t do what you would normally do, which is schedule things over time, keep data load consistent. Instead, you have to figure out how things can elastically scale up and scale down. So what we found that’s been super helpful in data transformation and conversion, as well as operating core FHIR infrastructure is use, again, technologies that have been created by tech companies in Silicon Valley, like serverless and make that really easy to use in the healthcare industry.
One of the, I think, exciting things that I know when I was involved at ONC and National Center for Vital and Health Statistics was how do we get financial clinical data together? We’ve talked a lot in American healthcare about value and calculating value, but it’s really sort of a fool’s errand, if you actually can’t figure out how to combine what you’re getting with what you’re paying. I mean, it’s just sort of a little bit of a non-starter ultimately. How do you see FHIR and the combo of claims and clinical data? I mean, how do you think about that?
That is an amazing topic. FHIR is really the first time claims and clinical have ever come together in the same format. You know, prior to FHIR you had HL7, largely for the claims data… I mean the clinical data. And you had these 837s, these EDI formats for claims data. And you did have systems that were kind of kludgy putting them together in some home built data warehouse or in some proprietary data format. But FHIR is the first time that’s happened at a national level where literally every proven large provider or organization is required to speak the same language, have their data formatted in this way and make it available to others and similarly, the payers.
And what is interesting with FHIR is that there are these now common resources that you can share between the claims and clinical data. Right. There’s one representation of the patient resource. There is one representation of an encounter, one representation of a medication or a lab or a procedure. And similarly the explanation of benefits or the coverage resources that are more so explaining the financial data are bringing that side of the picture together with the clinical. So now what you can do is do exactly like you’re saying, you can create these inferences on the financial aspect of a patient’s health history against the clinical aspects and start looking at, Hey, if a provider prescribes medication A, is that medication actually dispensed?
The provider only sees the prescriptions. The payers only see the dispenses. With FHIR you can finally see both. And what you can do is if those two organizations are talking to one another, you can basically see the gap in the dispenses from what was prescribed. And if you have something really important, like maybe some diabetic medication that is not picked up by the patient, that’s going to likely lead to your very high cost down the road. So with FHIR, you can finally bring those two worlds together and take action on the insights that can be gleaned from that combination of data.
One of the things that I know we’ve talked about at other points is the ability to represent these data fields in atomic FHIR resources so you can do almost any calculation. Right. I mean, you’ve just given one example, but essentially any calculation about how you want to interact with patients can be done by atomic FHIR resources. Do you want to talk a little bit about how you think about getting the data into that format, the process of doing it, what some of the considerations are of doing that at scale, not just take one file and stick it somewhere, but really doing it over a million patients or 2 million patients?
Yeah. So leading up to July 1 and still now, as we onboard new customers and health plans, what we’ve been doing is been basically processing millions of resources. And we have had to build tools that really make that easy for us. So we have some tools that are open source that we use called NiFi that has been built by the NSA to process at scale millions of records in minutes and seconds that we use. But then we’ve had to augment that with FHIR specific processors so that you can really take data that is being sent from these population level systems and transform them into FHIR. And what that takes is there is a lot of nuance with medical coding terminologies, where you have to understand, Hey, this code maps, that code, what are valid resources, how to structure those, doing those on the fly.
And then the industry with CARIN and Blue Button have introduced more specific validation on what data types are actually present at the attribute level. So making sure we map those and then validate that happened is also a pretty big lift. And for those sorts of things, we had to build our own tools one, which is what we call data ingest and mapping framework. And we’ll have a whole talk about that later. But at a high level, what that does is it takes these flat files that we get either daily or more frequently from our customers and it scans through them and maps different columns to the hierarchical structure of FHIR resources. And that requires joins and aggregations throughout the process because FHIR is highly… There’s a lot of duplicative information in there. It’s not like a normalized data structure because of its hierarchical nature. So when you have things like patient IDs or names, or display texts that has to be pulled in from many different sources. So we have processes in this data ingest mapping tool that allow us to do that at scale and more repeatedly.
Right. So then that basically gives you huge advantage because then you actually have quality data as opposed to stuff that you have to work out every time you want to use the data on the back end.
Yeah. And what really helps us with quality is that we’ve done this now for about 50 health plans and in doing so we’re able to look at aggregate data at certain plans and look at the distribution of that information relative to others. So for example, what you can do is if you have a list of first names at one plan and a list of first names at another plan, you can look at the distribution and maybe the first one is John and the next one is Sally and so forth. But in another customer that distribution is more like Smith, and Johnson, and Ramirez or whatever, and you look at that and compare it to the average distribution that you’re getting for these attribute level mappings, you might see that, Hey, there’s a big difference between this distribution and the average. And because we’ve done this many times, we can use that past historical information to better identify gaps with data quality, which is a huge competitive issue.
Yeah, that’s a big issue. I think one of the other things that in my experience has been very powerful about FHIR, obviously for us to have a functioning healthcare system, which in the US, we all know we’ve had a lot of challenges with, we really need this population level interoperability, not just individual patient. You know, you move, you get your care here and you get your care there, not this one at a time type of thing, because we just need to really rethink things on a more fundamental computational basis. The intent of Congress with the Cures Act was really to do this in a standardized way so that new apps, new tools could really be built and free up this data.
I think one of the things that has intrigued me and obviously why I joined 1up was the fact that we’re doing this in a FHIR standard, HL7 based standards way as opposed to putting in proprietary little shortcuts that maybe help on getting thing in or helping the demo but don’t really free up the data for anybody who wants to use it. Do you have a sense of doing FHIR as standardized type of approach as opposed to doing a more bespoke interoperability vision of FHIR?
Yeah. So as an organization we’ve always been FHIR first and what’s interesting now is we’re having conversations with other customers and they are saying that their strategy is FHIR first too. And what that means is that we have no intermediary data format or structure that we have to translate from in order to give you your FHIR data out. And that’s huge from a computational perspective because if you’re doing that for every single interaction, then every interaction is going to be X number of hundreds of milliseconds delayed and that’s going to lead to worse performance downstream for any apps. And if you’re building this as the foundational layer, you really care about the milliseconds. And when you’re thinking about the population level, right, FHIR was initially intended, and all the regs were initially intended for making access to this data one patient at a time. And that was great start, you have to start somewhere.
Although it has the capability to support population level interactions, it’s really not built for that. And we could have built our own for proprietary data format optimized for population level interactions as well, but instead what we did is said, okay everybody knows FHIR. Everybody’s going to have to speak FHIR. Previous data warehouse solutions had their own esoteric data schema and companies sold in healthcare because they had their best healthcare data model. That was the selling point. And now FHIR is that healthcare data model. So instead of reinventing the wheel there, what we decided is to say, okay, let’s look at, literally look at the bits on the disc. Right. That’s what matters when it comes to computational speed and interaction with this data, and you can take FHIR data and structure it in many different ways. Right.
You can have one resource at a time as like a key value store, which we have. You can have one attribute at a time as an inverted index, which we also have, or you can have column or data stores where all the data for one column is stored together, which we also have. And basically our approach was to structure data based on the use cases that you needed to operate. So the healthcare data is massive but data storage is now cheaper than it’s ever been. So basically what we thought is, okay, we’re going to duplicate this data, keep it in sync, in real time, but make it possible for the end user applications, whether they be one patient at a time population level, anything in between have the data in the format that was best suited for that problem. So that’s ultimately what we’ve come to.
Yeah. One of the things, obviously, in working with HL7 and leveraging the FHIR one at a time APIs to get that data right, and the data conversion in the electronic medical record, to get that in a way that we look at a population as the Bulk FHIR standard, that allows you to extract that data, it’s really a batch mode API standard, and then analyze it in the different ways that you talked about. What are your thoughts on Bulk FHIR and how you see that? I’m going to preface it. I hope it’s a positive answer because at least from agency point of view and a clinician point of view, it strikes me that Bulk FHIR is one of the best ways we have to really compare providers and analyze performance in the delivery system. We’ve never had computational ability to do that over populations and providers and approaches. With that bias preface, what’s take?
Yeah. Well, obviously I think there’s a ton of potential made available through Bulk FHIR. And the OMC, CMS, HHS have done amazing work to really move that forward. Both from a regulatory perspective and from a funding perspective. A few years ago there was this Bulk Data LEAP Grant where we worked with Boston Children’s to basically take this concept of Bulk Data and productionize it and put it into real practical use cases. And that’s really the time where I realized the power of Bulk FHIR export, which was coming back to the claims plus clinical together. One of the biggest problems at BCH and many other health providers and health plans have is quality reporting and other value based care measures. So what they were doing is they had entire teams of analysts that would take their own clinical data from their EHR, put it into their data warehouse in a bespoke format, have to deal with all the data conversion that led up to that and then again, other teams of analysts that would write queries to the specifications of the health plans that they then reported to.
And the BCH team only had their own view of the data. They only had the clinical data from their EHR. The payers like Tufts and Aetna, and Massachusetts Medicaid only really had their clinical… I mean, the claims data that they saw. And this claims and clinical never really came together. So the idea that we explored in that grant was to take that clinical data and the claims data and bring it together in this kind of Switzerland, like world, which was part of the technology that we open sourced, and was to be able to interact with those simultaneously on those same measures.
And what was cool is you could do things like run this measure on the clinical data only you’d get, whatever 25%, 50% of the population met that measure. Then you run it on the claims data only, and you get another number maybe 40%, but when you combine it, maybe you get to 50% or 60%. So that sort of clarity literally affects millions of dollars of reimbursement for health plans and providers and could not be done without the standards like Bulk Data being used to say, bring this claims and clinical together, share all the data in one place and then run containerized compute algorithms on that data to figure out quality or measures or performance.
Great. Thanks. Well, hopefully we’ve painted an interesting picture of using international standards and the modern technologies of the cloud, of serverless computing, of rigor in thinking about the architecture of these things to do absolutely fantastic and novel things in healthcare. This will be the first in the series of talks. We’ve just touched the surface of some of the details here and the devil, as they say, is in the details. So thank you very much.
In this video, Dr. Don Rucker, 1upHealth’s Chief Strategy Officer and Former National Coordinator for Health IT, sits down with Ricky Sahu, Founder of 1upHealth, to discuss scaling with FHIR. This is Episode 2 of Dr. Rucker’s Youtube Series, Transforming Healthcare Data.
At 1upHealth, we’re the healthcare industry’s most complete FHIR data platform. Along with our managed platform, best-in-class tools, and FHIR APIs, we provide scalable, serverless, and secure solutions to support your business programs, workflows, and analytics.