An HIE Journey to Improved Data Quality for HEDIS®

Carol Macumber:
My name is Carol Macumber. I’m the EVP of Client Services here at Clinical Architecture, and it is my great pleasure to introduce our next speaker, Jason Buckner, the Chief Information Officer at Manifest MedEx. Jason has been at the forefront of the nonprofit health information exchange industry for over a decade. His previous roles include leadership positions at North Carolina Health Connects and the Health Collaborative where he utilized his broad technical experience in interoperability, informatics, and analytics to help improve healthcare. Jason has served on multiple national committees, including the eHealth Exchange Coordinating Committee. He is also an avid biker and loves knitting. No, just kidding. I wanted to throw a little something a little personal in there, and so it is with a great pleasure to hand it over to Jason.

Jason Buckner:
Kudos to Clinical Architecture. I’ve worked with this company since 2010 or so, so I’ve known John and Charlie for a number of years and they’ve always been great partners of ours. And I’m a native Hoosier from Indiana, so kudos to the Indiana based companies. I’m very far away from Indiana these days, and I work for Manifest MedEx, which is a health information exchange in California. We operate only in the state of California. You can see our mission here is strictly focused right on the Triple Aim. It depends on how you want to measure. We are either the largest or the second largest health information exchange in the country. California is always doing battle with New York, and that would be the ones that are comparable to our size. We have data on over 38 million Californians. This is claims data from health plans. It’s clinical data from labs, from practices, from large health systems, and that populates into our platform.

To give you an idea of scope, we deliver over 2 million ADT notifications every single month to folks. So these are care coordinators, these are health plans, these are practices receiving this in important data. California has a pseudo, what I’ll call a pseudo requirement to exchange data in the state. It’s called the data exchange framework. We are a qualified HIO, so sort of like the QHIN, if you will, of California Data Exchange Framework. Not sure why they couldn’t use the same name. Like many HIEs, we go the last mile. If you don’t go the last mile as an HIE, you’re not really going to make it. And so that’s why we’ve incorporated data from over 70 EHRs, some of those built by physicians and operated by them. We are newly onboarded to Teka. So we are excited about joining the eHealth Exchange QHIN and something I’ll talk a little bit more about here that’s relevant to this topic. We have NCQA validated data streams since 2021. You may have heard of this as the data aggregator validation program. Do not use the words DAV, I promised Wendy we were there since the early adopter program in 2021. We’re getting ready to go through the program again here starting in July, the July cohort. It’s really, really important to the data quality topic we’ll hit today.

So we’re going to focus data quality today, not on the big global picture of all of the aspects about data quality. We’re really going to target into value for health plans and specifically for HEDIS. And so the services that MX provides health plans are really the two different buckets, right? There’s HEDIS relevant data and then there is risk adjustment based services. And so under the focus, there’s really two buckets of data that we can provide to a health plan. One is under the data aggregator validator program. And this is highly, highly beneficial to a health plan for a couple reasons. The primary reason is the burden of primary source verification falls to us and not the health plan. So when they report their HEDIS measures and the auditors come in, they do not have to go do a chart chase chart chases take time. They’re expensive plans have to outsource with the organizations.

So we really take that burden on for them and they want as much data under that program as we can give them. So we’re always trying to increase our percentage of data in there. Not everybody gets validated. That’s just a fact of life. We have new organizations, organizations with not the best data quality, and so we still provide other data to plans. It’s just subject to audit under that HEDIS. And then the last piece is we also provide data for risk adjustment. And we’re thinking about clinical architecture to help with this space, but we’re going to focus first on the HEDIS related data. So the data quality issues around HEDIS that we hear continually and continually from plans is, I need to close care gaps. I need to increase my HEDIS reporting numbers. I need better data for care coordination.

There are a litany of data quality issues that we experience. The three number one that we get are, there’s a local code. There’s no code or the code in the description. They just don’t jive, right? There’s something wrong here. This doesn’t make sense. So these are not incredibly complex problems per se, but they’re persistent. They’re consistent with many, many data feeds that we get. So first, I’ll tell you how we approached solving this problem in ways that did not work. So the first thing we did was we were very naive and we said, Hey, you know what? Let’s just call these guys. Let’s call Dr. Smith’s practice and ask him, Hey, can you please start getting your labs in LOINC code for us? That would be really great. As you can imagine that basically move the needle. Zero practices are scrambling. They don’t have a lot of time for resources.

They’re not going to put this effort in just out of the kindness of their hearts. The second thing we did that moved the needle just a tiny bit was through incentive plans from health plans. So health plans would provide a financial incentive to a practice if they increase their data quality. And that helped a little bit because the practices, there’s a direct carrot there and it’s in terms of dollars, it didn’t move the needle as much as we thought it would though there’s still a huge gap. So we said, okay, trying to outreach to the provider to improve the data quality is only going to get us so far, and it’s nowhere near what the health plans wanted. So we said, Hey, called up John Wilkinson, great guy, and said, what can you guys do for us at Clinical Architecture? So we partnered with them and we implemented their software in our environment in AWS last year.

We designed an integration between our core HIE platform, which is InterSystems HealthShare. They’re here somewhere. And we gave them a huge backlog of data over 1.6 million pieces of data that they could take to feed and start intelligently mapping the software. And the intended use of this is while there’s a great company, the software is not free and our resources are not free. So our intent here is to offer health plans uplifted data at a fee. So if you don’t want us to map the data, that’s fine, we’ll give that to you as a health plan under your current agreement. But if you want us to take the extra step of improving the data, you’re going to have to pony up on that. And then we are pursuing this mapping under the Data Aggregator validation program with NCQA this July. So after we get through that process, hopefully everything goes swimmingly, we pass, then we can use that data starting next year.

Alright, the data, I’ll orient you to this chart because it didn’t make sense to me at first. Total terms are all of the unique terms that we fed into. So medical, the software at clinical architecture. So we’ve fed it, 411,000 unique diagnoses. The mapped ca mapped is automatically mapped by the software. So we sent in 411,000 diagnoses, 391,000 of those were mapped by Clinical Architecture automatically. Now the way that I think about this, if anybody uses a master patient index, is the same kind of concept. So there’s a threshold and if the software says it’s met the threshold, it will automatically map it. And we work with Clinical Architecture to say, okay, here’s what we want the threshold to be. Sometimes we’re a little bit more conservative on a domain, sometimes we’re a little bit more liberal. It just depends on the use case. The suggested map, the next column means that the software said, I think it’s this code, but I haven’t passed a particular threshold. So I’m going to put that in a queue for you to review. And then you can have a clinical informaticist review it. You could send that data back to the source and say, Hey, you sent us this local code. We think it’s a hemoglobin A1C with this code. Can you verify yes or no? If that is accurate. So there’s a variety of ways that you can work that queue. And then the last column is, Hey look, we just didn’t know what to do with that data.

So what was shocking to me, I’ve been working in this space for a long time and my experience was the thing that’s the most mature in clinical data from my experience was L, right? I knew about the re street institute and I knew that L had been around. Anybody know when the first version of L was released, 1999. It is incredibly mature. They’ve released so many new versions of loic, it’s widespread usage. It was in meaningful use. It’s pretty much everywhere you think it’s pervasive. And when I saw these numbers, I was like, well, even with a mature standard, we’re still not getting really good data. So on the results here, you’ll see 20,000 out of the 54,000 didn’t have a proper link code. So we had the software map though, so that was really good. If you really want to do some interesting digging into history, I was like, oh wait, diagnoses have been around a lot longer.

So I looked that up. 1893 is the first instantiation of what became ICD. So it’s kind of neat if you’d look that up. If you’re going bored one day, can’t go to sleep. So anyway, these are the domains that we looked at. They’re not all relevant to rate. Allergy rate is not so much relevant to HEDIS. We still felt like it was important to get those mapped. They came out of the box. It wasn’t like an extra charge from clinical architecture for those. So those are all the domains that we mapped. So in the biggest gains of automatic mapping, and we love automatic mapping because it doesn’t require a human, we don’t have to do anything, diagnoses, immunizations and problems. If you tell that to a health plan, they’re like, sign me up. Diagnoses are key. You can move somebody into the denominator or out of the numerator with some of these.

And there’s turns into significant financial dollars for the plan on some of those measures. So these are really, really important. And then on the suggested mappings, the highest were allergies, labs, and medications. So last slide, I think I spent the day at the AI pre-conference forum and there was a lot of talk about transparency. And so I’ll kind of map that here with code traceability as well. And that is if you’re going to change a clinical value, and we’re not a provider, right? We are an aggregator of data. If you’re going to change a clinical value, you really need to do two things. One is you need to retain provenance. So you have to trace and always include. So every step along the way, we provide the original code and the map codes side by side so that those folks can see that it’s really, really important.

It’s extra work, but it’s important to do. On the transparency side, the thing that I love about clinical architecture software is I was talking to NCQA and the auditors and they said, look, you can map. You have to show your work. It’s really all about showing your work. And the thing I love about this piece of software is you can go into the software and say, okay, show me a map that you did and I want to know the algorithms that led you to that decision. And it will say, I used three algorithms. I had a confidence level with this one, a different with this one. And it got us over the threshold. And if you can’t show your work, this is super relevant to all the discussions in AI as well, you’re going to be in trouble. You’re going to ask some really hard questions by folks when you modify some of the data.

So that was really important. From a data flow perspective, we chose what’s called a late binding approach. And that just means that we’re changing the data or mapping the data right before it goes out the door. So we don’t change it as it comes to us. We only change it as it’s about to leave us. And that’s because we wanted to A, offer this as a fee-based service. So not everybody gets the uplifted data. And B, some folks have said, I appreciate that you can do this and please, I just don’t want it. It’s too much risk exposure for me. So it allows us to do it on a case by case basis. So we use InterSystems. HealthShare is our core platform. They’ve got this data model called the SDA, sort of like a much more lightweight XML version of a CCDA, if you will. Clinical Architecture had already built an integration with that format.

So we send the SDA over to Pivot, which is a piece of software that manages all the API integration with Symedical. And then Symedical takes, it does, its mapping all its magic and it ships it back to us as an SDA, we speak SDA at mx, that’s what our vendor produces. We take that, we’ll convert it to whatever it needs to be. So it may be into the DAV CCDA format. We could convert it to FHIR, we can convert it to a flat file, we can convert it to really anything that the customer wants. And that’s the basic data flow. So far we have not experienced any performance issues. It’s been very performant. Once the mappings are done, it’s really, really smart. The hard work is getting those mappings built and reviewed and approved. And I think that is it. I’m happy to take any questions.

What year did you do the mapping? It was 20. It was 2023 slash 2024. Oh, yeah. Yeah. We saw a lot of map terms in California. The data exchange framework actually requires USCDI V2. It was ahead of TEFCA and federal. So we were supposedly getting great USCDI V2 data. It turns out we weren’t, right. You have to pull the covers up on the data to really see what’s coming in the door. Alright? The data that comes to us, the data that comes to us is typically HL7 or CCDA, little bit of FHIR, but folks are not quite ready so much for that. So yeah, so that’s a great question. The question was about protected data and there’s a whole litany of different types. I will tell you 42 part two, we just don’t accept it. So we say do not send it to us.

However, California has a unique law assembly bill 3 52 passed and it says you cannot share abortion, abortion related services and a couple other categories of data outside of the state of California. It’s happened when Roe v Wade turnover rate. And so it’s a really important law and we are not informaticists technologists. And so we worked with clinical architecture to say, can you come up with all of the codes that represent these categories? And they built that code list for us, and we will filter those codes out of data that leaves the state of California. So, hey, thanks for sitting through this. I know everybody’s busy. And get your walking shoes on. It’s only day one. Thank you.