In today’s healthcare IT world, there’s a whole lot of talk about interoperability — and unfortunately, there’s also a whole lot of misunderstanding, says Chuck Christian, VP of Technology and Engagement with the Indiana Health Information Exchange. He believes that if the industry wants to make real strides in achieving this Holy Grail, it’s time to start clearing the air.
Recently we spoke with Christian, who has more than 20 years of CIO experience under his belt, about the difference between what’s being reported about interoperability and what’s really happening in the trenches. We also discuss the most common requests IHIE receives from providers (and how they’re working to fulfill them); how his organization is leverage the knowledge of students to de-identify data; the discussions he believes CIOs need to have with vendors; and why, all things considered, he’s still optimistic about the future of healthcare IT.
- IHIE’s key priorities in 2018
- Physicians’ most common requests
- Leveraging HIEs to avoid duplicate testing
- Clinical repositories: “It’s a way to electronically tap physicians on the shoulder.”
- FHIR’s potential
- Meeting members’ needs: “They’re all trying to solve similar issues.”
- Challenges with social determinants — “There’s no standard code set”
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
When that lab that comes from a reference laboratory comes to us, we can take a look at the result to make sure that it has the appropriate LOINC coding and then move the medical record number into the transaction, so that when we send it in to their EMR, the EMR knows what to do with it.
It’s a way to electronically tap the physician on the shoulder and say, ‘excuse me, but this patient has had this very study two weeks ago, or three weeks ago, or within a defined time frame. Would you like to look at it?’ It can avoid the cost of the study, but also avoid irradiating the patient unnecessarily.
It is a partnership that we have to work at in order to make sure that the requirements they’re asking for are something we have the capacity to do, since we write our own code and do our own development.
They all are trying to solve very similar issues around the impacts of regulatory change, value-based purchasing, and the new reimbursement methodologies that the payers and the federal government are coming out with. And more and more of those are requiring more data about the patient populations than what that healthcare organization may have within their EMR.
Gamble: Hi Chuck, thank you for taking time to speak with us. It’s great to be able to get your perspective on what’s going on in the industry.
Christian: Thanks very much, always glad to offer what little I know.
Gamble: Let’s start with something that you do know, the Indiana Health Information Exchange. Can you talk about what’s new with the organization, and what are some of the things that are really top of mind right now?
Christian: We’re looking at what we need to do next to continue to add value to our members. We’ve had a couple of really interesting projects that we’ve done this year. One of the things is, from the very beginning, clinicians said they didn’t have access to data. When the clinical data repository was stood up a long time ago, they had access to it and they were able to get to it, which they were very thankful for.
Then it was, ‘now I have an EMR. This is my workflow, and I don’t want to log into something else.’ So we were able to provide a single sign-on where they were looking at a patient within their EMR and they could click a button and it would open up their view of the longitudinal patient record in a patient context. So they were actually looking at the same patient they were seeing in an EMR, and they said, ‘that’s great.’ Then after a while, they said, ‘You know, I really would like to see the data within my current workflow in the EMR.’
That’s where we are today. We’ve come up with a couple of different ways of doing that, and we’re working at the speed of our members. We have one member who asked us to provide a pretty comprehensive amount of data so he could feed his clinically integrated network so that when a patient gets registered in their system because of the data governance, they have access to the data. And so we can hand them a data file that they can incorporate into their platform and provide that to their analytics people, to their clinicians, to whatever they need to do within their clinically integrated network.
The other thing we’ve able to do is look at lab results. You know how difficult it is to take a lab result done somewhere else and move it into the workflow and have it stored inside an EMR, because a variety of identifiers are just not there. We’re working with one of our larger health systems in Indianapolis because we’ve pretty effectively matched the patient population. When that lab that comes from a reference laboratory comes to us, we can take a look at the result to make sure that it has the appropriate LOINC coding and then move the medical record number into the transaction, so that when we send it in to their EMR, the EMR knows what to do with it. They will actually put it within the workflow of the rest of the labs they receive so that the physicians can see the labs from outside and inside the organization.
Last but not the least, one thing physicians ask us is, don’t give me a basketful of data and expect me to wade through it like a CCD.’ The other thing they say is, ‘tell me what I don’t know but don’t make me go look for it.’ One of the things we’ve done with that same large health system is a pilot using the FHIR protocols to see if this would work within their Cerner platform. We worked with the ER physicians and said, ‘what five pieces of information do you always want to get about a patient who walks in the emergency room with chest pain?’ They picked the chest pain protocol — we didn’t. And so they gave us the standard five things they look for every time they see a patient that has a diagnosis or a chief complaint of chest pain.’
And so when the patient gets admitted in the emergency room with that chief complaint, we go into our data repository and fetch those five pieces of information, regardless of where that information lives. It could be done at one of five different facilities or maybe one facility. The way it works with this implementation (and it can be done a variety of different ways) is there’s a button on the screen, and the physician can click on it and they can see those five pieces of information. And if they want to, if they’re going to use that information for clinical decision-making, they can incorporate that into the EMR and make that part of the patient’s permanent record.
There are other ways that we can do this as well, but the really nice thing about using a standard process is that we can now look at other chief complaints or other ways of determining what are the standard things doctors always look for when a patient comes in with a specific chief complaint. We’re fulfilling those two requests for physicians — we’re not giving them extraneous data they have to wade through, and we’re telling them what they don’t know.
One of the other ways that Health Information Exchange can have an impact upon the total cost of care is to avoid the duplication of testing. We can use those same techniques, for example, if a physician is about to order an MRI or a CT or other expensive test, the system will know what they’re about to do and can go and look in this lake of data to see if the patient’s had that procedure anywhere else. It’s a way to electronically tap the physician on the shoulder and say, ‘excuse me, but this patient has had this very study two weeks ago, or three weeks ago, or within a defined time frame. Would you like to look at it?’ It can avoid the cost of the study, but also avoid irradiating the patient unnecessarily.
There are many, many instances where physicians have postponed or cancelled imaging studies because they looked in their clinical data repository and found that the patient had recently had that study. We had one incidence where there was a young man having difficulties with a chronic situation, and he was in six emergency rooms in six weeks and had five different CT scans. The sixth physician flagged it — he looked and saw all those studies had been done, and he actually used those other studies to help diagnose the young man and provide a better level of care. For me, that’s the ultimate: presenting information that will have an extremely positive and more timely outcome for the patient.
Gamble: In terms of the pilot you did with the ER docs with the five criteria for patients with chest pain, is that something you’re looking to expand based on the results?
Christian: Absolutely. We just brought that live recently. We want to look at things like performance. We want to look at physician use and habits and those type of things. And so we’re working with the Regenstrief Institute and several of their informaticists and ER physicians to take a look at this. The really nice thing about using a standard like FHIR is that, in theory — and we haven’t done it yet — we could move it to a different EHR platform and do the same thing, but the presentation of those results inside the EMR will be a little bit different, I believe, depending upon if you’re using Allscripts or Epic or Cerner or one of the others. So, we’ll have to take a look at that. But it has been an extremely interesting and fruitful collaboration through a large group of individuals.
Gamble: Right. There are always a lot of questions surrounding FHIR, and this seems like a very practical use for it that can yield some pretty quick results.
Christian: I think so, once the framework is there. That’s not to say that it’s going to be a cookie cutter implementation, but depending upon whether the resources are available, you can do quite a few different things using that same methodology around chief complaint as a trigger.
Gamble: Right. Now, you said something before that was interesting about how IHIE tries to work with the speed of our members, but you have a pretty big variety in terms of membership. Is that a challenge to try to meet the needs of different sizes and types of organizations?
Christian: Capacity is always an issue — what we can do and what they can do. It is a partnership that we have to work at in order to make sure that the requirements they’re asking for are something we have the capacity to do, since we write our own code and do our own development. There’s a pretty stringent process we go through to make sure all the standard processes are met, and the code is secure.
We have standard implementation and coding practices that we follow, but it also requires resources on the member’s side, because they know their data and their processes better than anybody else. There’s a significant level of testing that we will do, but we’ll also make it available to them to do ‘user exception’s testing’ so they can take it out on a maiden voyage in a validation environment where it’s not going to impact their production or their live environment, and make sure that it works the way that they thought it would.
I’m sure you’ve seen the old diagram of the tire swing, where what the folks that wanted it thought they were going to get was different than what the system engineer delivered. We’re trying to make sure we deliver, through a lot of conversation and testing, what they’re actually looking for.
Gamble: It seems like it’s an ongoing goal to make sure you’re getting a good representation of what the members’ needs are.
Christian: Absolutely. We have regular meetings with the grand majority of our larger customers, particularly here in Indianapolis, as well as others throughout the state as well. Our customer relationship managers are in contact with them all the time. Not every member organization has a list of things they’re working on, but it’s interesting to go out and have conversation with the variety of sizes of organizations that are our members, which go from very large health systems to critical access hospitals. They all are trying to solve very similar issues around the impacts of regulatory change, value-based purchasing, and some of the new reimbursement methodologies that the payers and the federal government are coming out with. And more and more of those are requiring more data about the patient populations — particularly those that are at risk — than what that healthcare organization may have within their EMR.
I think that’s the added advantage to the healthcare systems in Indiana and other states that have a robust health information exchange — they have a place to go and get that data; they don’t have to go and try to find that data themselves, and so they can better manage those patient populations.
Gamble: One of the things we’re starting to hear more about, and I’m sure you are as well, is the use of social determinants. Not everyone has access to the certain types of information, but it’s about aligning organizations to the right groups to be able to do that.
Christian: We’ve been talking to some of our members who are working on social determinants of care about where to find good resources around patient populations. At the SHIEC annual conference, we had a presentation by the group that started and is running the 2-1-1 out in California. They struggled themselves trying to find those good sources of data and information around the social determinants of health for the populations that are particularly at risk — and those are the ones that you can have the largest impact upon. Trying to find out that information and that data is difficult at best, because what we found, and what they found, is for a large majority of those organizations that are trying to go to this data, there’s no standard code sets for certain aspects of it, and so they all just create their own.
And so I think if we’re going to use that information in a broader sense, specifically around public health and research and analysis, we need to establish what the standards are going to be around how that data is actually coded, because it’s with the coding that we’re able to standardize the nomenclature across multiple settings from New York to California.