CDex, PDex & the Symphony of Healthcare Data Exchange

Jocelyn Keegan: Good afternoon. I’m Jocelyn Keegan. I’m the program manager for the Da Vinci Project under HL7, which is one of the original FHIR® accelerators. We’re going to talk a little bit more about that today. I actually am a strategy consultant in my day job. Don and I are going to have a really informal, unstructured conversation with you today about, I’d say the promise or the reality of what’s happening coming out of the FHIR accelerators and the establishment of a number of the standard implementation guides in particular. We’re going to talk a little bit about maybe the lesser known, less talked about clinical data exchange and payer data exchange because its cousin prior authorization is getting all the attention. So why don’t you go ahead and give folks a little bit of background.

Don Rucker: Yes, thanks. Yeah, Don Rucker, Chief Strategy Officer at 1upHealth. Some of you may know me from my days at ONC and obviously we’re very pumped about FHIR and HL7 and the whole ability to actually start computing in a simpler and more accurate way.

Jocelyn Keegan: So I think our goal today is really to talk about how we’re going to derive real value from the implementation of these FHIR® APIs sort of writ large, right? This investment that we’re making. Don was an integral part I think really of moving forward the FHIR roadmap and his time at ONC is one of the very early supporters of Da Vinci and the concepts that we were producing within Da Vinci, and he now is back in the private sector. And I think that we want to talk today really about, we’ve got rules, we have a regulatory framework in place, we have these emerging implementation guides, and I think maybe it’d be helpful to talk a little bit about the, why do we think it’s important that we’ve digitized this information and where we’re headed to now that we sort of are getting to this base level of FHIR adoption. And if you can give folks a little color on how this fits in with the ONC rule set as well.

Don Rucker: Yeah. So just a quick thing on CDex and PDex. It sounds like some kind of plastic, was it polyethylene or something you might’ve studied in chemistry if you spent some time there, but think of CDex and PDex and the CARIN Alliance work as the pipes of getting data at volume and accuracy. So the CDex clinical data exchange is getting data out of the EHR in a standardized way and PDex is getting clinical data from the payer side. The data payers may have in a standardized way and that matches up against the CARIN alliances claims data from payers. And so if you look at all three of those things now you finally have the clinical information from as many sources as possible that you’re going to need for quality measurement, for risk adjustment, and pretty much anything that CMS is going to require of MA plans, right? As folks know, we have this huge issue of what’s the value we’re getting in MA plans, a lot of politics, a lot of stuff. And so, it’s going to be data intensive CDex and PDex are the fuel to make those things possible, and then the add-ons like prior auth.

Jocelyn Keegan: Yeah, and I think that one of the things that we were talking about sort of in prep for today’s conversation is when you think about sort of this idea of FHIR and FHIR APIs being openly available, we now know that the EHRs are on the hook to have an active and progressively advancing version of dataset that’s going to basically make the data be free and available. And we now have a similar set of requirements on the payers to be able to share that same data, not just with patients now, but with providers and with other payers. We’re getting to this meat of this critical mass of data that’s being shared, but the implementation guides, and I think that one of the reasons we chose to talk about this topic in general is that there’s so much information sort of baked into and the work that’s gone into the creation of these guides that really is about that step beyond just the connect aspect of getting data from one place to another, but really starting to think about workflow and provenance and the source of the information.

And so the reason that there’s two separate guides to do this is that it matters what the source of the information is and it allows even the business analyst versus the technical resource that’s going to be standing up and starting to use and build these APIs. This ability to be able to get to, really understanding how and why the data is available, where it’s available, what data is available, and the context around the data, which that’s nuance. That’s really important. When you’re actually sort of in your seat trying to figure out how am I going to share this data, not just once with one trading partner, but over and over again in a scalable way. And that really gets at the heart of, I’d say why we IG is to be able to really take the business knowledge and the architectural knowledge out of the people building the guides so that we’re not arbitrarily doing things differently when somebody decides to stand up their version of how they’re going to share data from a clinical perspective.

I think that this is really important as we start to look at actual individual use cases that you want to get to and business problems you’re trying to solve within your business. I was using an example in part one of our prep sessions of one of our implementers, one of the more advanced provider organizations that’s based out on the west coast. Providence Health just did an update to the Da Vinci community last week where they know long-term getting to the quality conversation that Don was just talking about, that they needed to be able to solve for sharing quality information, getting out documents, getting to the individual resources and the data to be able to be shared. And that allows you to create these little recipes that you can repeat over and over again and that we’re not all starting from scratch with our recipes.

Don Rucker: Yeah, reading implementation guides, it sort of looks dry. Is it one-to-one, is it one to many, all of that kind of stuff. But I would actually encourage you to read implementation guides as a roadmap to the information you should be thinking about, right? Don’t think of it – They’re written to write an API to compute, but think of it as a cheat sheet. Now you’re all too young, but when I was in college, we had something called Cliff Notes. So, if there was some long book of one of the tomes of Western Civilization and it was a little long to read and you might’ve had a hangover and you didn’t get around to doing the homework, you could go for, I think back then maybe it was $2. Now I’m really dating myself and buy the Cliff Notes of that.

Jocelyn Keegan: Yes, it definitely dated you.

Don Rucker: The IGs are actually the Cliff Notes for healthcare informatics. If you look at the topics, you look at the organization, if you’re a data analyst, you can actually get an incredible queue sheet of things to think about. So use them as a cheat sheet as well as so you don’t have to be the API programmer to use an IG.

Jocelyn Keegan: I think this is a really important point and coming out of VIVE and now at HIMSS, as we were sitting and chatting before we got on stage today, I think that one of the things that we look at is we sort of have our informaticists that are working in hospital settings or working as strategy folks like Don, or inside of payer organizations doing really med review, UM things like that. And then we have our technical resources, our architects, but there really is this sort of generation of folks that we need to be growing and building from an industry perspective. And this idea of the collective knowledge that’s built into something like an implementation guide I think is really critical. Don, can you talk a little bit maybe about just the idea of what the benefit is of getting to these reusable APIs from a business process perspective and sort of a power of getting beyond that sort of point-to-point connection?

Don Rucker: Yeah, I think you look at the big picture here and the big picture is basically FHIR and RESTful APIs. That’s the big picture that we’re looking at, that’s what’s going to be robust. It’s what the entire rest of the internet uses. And so that’s where we’re going. There’s some jigs and jags along the way, but the world is going to have these point to point things. We know that CMS is in the process of building a directory of all of the endpoints. So you won’t actually need to spend a lot of energy on that. Most of you already know all of the endpoints for your counterparties. And then the question is how do you get out of the world of faxes? How do you get out of the world of these really cumbersome, low bandwidth, highly expensive types of things? When I was at Ohio State, the biggest IT help center was the fax machine that had run out of paper.

So every nursing unit would have a fax machine with 5,000 pieces of paper and they’d get a record 250 pages of a fax. And we’ve all talked about the fax in the past, but what you need are individually computable data fields. That’s really the mother load of change. Right now. We have a very hard time doing that. Our quality metrics are highly isolated, and don’t reflect the totality of care at all. And so how do you get into computable data and it’s not a document, right? Again, we know documents were in the 1990s, so that was Yahoo and it was a really, really big thing when Jeff Bezos, can I really put my credit card into this computer? What will happen? It’s individually computable data fields and that’s what CDex and PDex and FHIR are all about. So encourage you all to spend time on them.

Jocelyn Keegan: So I think this is a really important point, and when we think about the shift from an industry perspective out of this paradigm of documents right, and we’ve got digitally created clinical – CCDA files today that sort of predominate workflows like, quality. When we think about this ability to be able to do this shift and to get to the point of creating an ecosystem and the promise of being able to have that reusability of the information, one of the things we were reflecting on in our prep session was – we are a highly siloed industry today. Even within individual organizations, the quality department is separate from the risk department, is separate from the utilization department, is separate from the claims department. Is often that there’s two waves of change that are happening. I think that there’s that realization of how do we make this information that candidly payers and providers are drowning each other, sharing and resharing over and over again, and how do we unleash the ability to get to this sort of base set of data and people we see advancing organizations really being able to master their own information and reuse the information, especially those folks that are in a high risk contracts together.

But that’s great. From sort of the point-to-point perspective and getting people sort of across that maturity curve, can you reflect maybe a little bit on at the population level and starting to be able to unleash that compute power at the population level and the benefit of doing this centralized within an organization as opposed to each of the individual functional areas creating and emassing their own content over and over again?

Don Rucker: So one of the things that we used the Cure’s  Act for was the Bulk FHIR data standard. I dunno how many folks here have heard of Bulk FHIR, but it is a batch mode API to allow you to look at all the data on a population of patients. And so the thinking there was sort of interesting. This is a project that Ken Mandl at Boston Children’s was the leader on and the originator of, and the concept was very simple. The Cure’s Act APIs required certain data fields to be in FHIR. So just the basics, well, if the EHR has already made the effort to convert it into FHIR, why wouldn’t we want that same data on a population? Why would we only want onesies? And so Bulk FHIR, which is also an HL7 IG, is the way to get data on a population. So for those of you who want to do population health, just keep a close look on that. It’s moving pretty rapidly, the number of people who are doing this now in the early stages is huge because it’s so important.

Jocelyn Keegan: I would encourage folks, if you haven’t sat in, between now and Thursday, there’s going to be probably six or seven more presentations that talk about real world adoption of these FHIR implementation guides. I think maybe just in closing, we’ve got about five minutes left. I think that if we maybe get a little bit more specific about some real world experiences. I think the bulk example with Ken is really important, but if we look at, I’ll use an example of one of the uses for PDex is payer-to-payer. And so when it first came out in the original rule, the first time we saw it, the rule that shall not be named, that got pulled back in. We sort of had this sentiment that payer-to-payer was a payer workflow and it was supporting just payers. And I had one of my providers that’s one of our early adopters in Da Vinci sort of speak up on one of our governance calls and said, so wait a second, no payer-to-payer is not about just payers helping payers as a provider organization.

If the payer that owns that patient right now and has a relationship with that patient can get the information from the previous payer, the amount of burden you’re reducing off of my provider team and off of that patient and ensuring continuity of care for that patient is critically important. So even this ability on a onesie twosie basis or at a bulk level as plans are moving from companies are moving from one plan to another, or individual patients are moving from one plan to another. This ability using these guides to be able to pull that patient forward is critically important to be able to get the care that we need, the continuity of care and reduce not just burden between the payers, but also on the provider and the patient as well. Maybe just to wrap us up, if you could think of another example that real world adoption of these guides is really helping. I think that would be great, and then we can move to questions. 

Don Rucker: Yeah. Well, I think one of the earliest ones is honestly going to be quality measurement. Just when you get right down to it, there’s so much money involved in HEDIS and Stars. NCQA is doing things there. CMS is doing things there. I would just close by saying payer-to-patient, payer-to-provider and payer-to-payer are all almost identical payloads. There’s a little bit of a difference, and that’s really the power of these CDex and PDex is that you have these standardized payloads, right? You’re not reinventing for every use case. That’s the whole power of this.