Solving Your Interoperability Issues: How to Integrate Data and Not Break the Bank

In our recent webinar through the VBC Exhibit Hall, Healthjump’s Director of Product Delivery, Laura Stewart, shared her tips on how to best go about solving your interoperability issues.

Formerly from Cerner, she has over a decade of experience accessing data from EHR systems. Watch our recorded webinar below to learn how to evaluate vendors on data consistency and completeness, keep a project on track and on time, and proactively plan for data drifts.

Download Slides

Healthjump’s data management platform is designed for adaptability, no matter what issues or changes your value-based care organization faces.

Contact our team of data experts to learn more about what we can do for you!

Full Webinar Transcript Below:

Garrett Schmitt:

Well, good afternoon, everybody, or good morning, depending on where you are. My name is Garrett Schmitt and I am the managing editor for VBCExhibitHall.com. I'd like to welcome you all to today's live webinar, hosted by Healthjump, and it is titled: “Solving Your Interoperability Issues: How to Integrate Data and Not Break the Bank.”

I'm really excited to hear from Laura today, which I'll introduce in a moment, we've got a really, really great, I had a sneak peek beforehand, so we've got a really great presentation for you guys today. 

A few items of note before we get started, everybody has joined today in listen-only mode, so it's not like a zoom call where we can see you and hear you, your mic has been muted, so don't worry about that. 

However, we do want to hear from you. So, during the webinar, at any time, we want you to ask a question if you feel like there's anything that you want to know more about, and we have a Q & A session towards the end that we're gonna get to as many questions as we possibly can during the allotted time.

With your attendance module or attendee module, you have a little area where you can ask a question there, so, please do that. Again, at any time, you don't have to wait until the Q & A in order to do it, and if we are not able to get to your question because of lack of time, we'll make sure to answer it via email afterward. So, even if we're out of time in the last few minutes, please ask your question and we'll get to you. 

Then finally, today's session is being recorded. So, what's gonna happen is after we're done I'm going to send everybody, all the registrants, a recording or a link rather to the recording and that'll be also where you can download the slides. So, if you needed to step out early for the last couple of minutes, you know, that's okay, we're going to get these over to you as soon as possible. And then we'd love to hear your feedback or anything else that you would like to hear as a result.

So without further ado, I'd like to turn it over to our presenter today, Laura Stewart, who is the Director of Product Delivery with Healthjump. So, welcome, Laura.

Meet Laura Stewart

Laura Stewart:

Great. Thank you, Garrett, and thank you everyone for joining us today for this important conversation. It's something near and dear to my heart. 

Just a little bit about me so you know, kind of who you're spending your time with this afternoon. I spent over 12 years at Cerner in leadership capacities, when I started my career in healthcare. How I kind of ended up in the data space of healthcare was I was an EHR implementation project manager, and oftentimes the interfaces were the barrier to entry to go live. Somehow I always ended up on projects that had that. And so, I quickly realized that you know, I needed to support the consultants and engineers that were working on my projects. And so I started diving in and learning with them. And then over time, I became more and more curious, and that kind of led me down my career path of managing many different groups at Cerner.

When I left Cerner, I was managing a large data migration team in their dating engineering consulting services group. It was just over a hundred people and that team was responsible for all data strategies for moving bulk data in and out of Cerner's platforms from the HS product suite to Cerner millennium.

So, my team is responsible for maybe hundreds of petabytes of data every year, across all of the customer bases, including VA. Most recently, I joined Healthjump last year, and I came over here because I met the founders and really, really thought that the platform that they had built had a huge amount of potential, and wanted to be a part of that journey.

So today my team manages over a thousand active integrations for our customers every single day. 

So, what we're going to kind of cover today is walking through various data use cases, and then defining how you pick the right technology to solve for those use cases, and then making sure that you've got good plans in place for data consistency and completeness in terms of onboarding new practices or facilities.

Then what do you do once they go live as well, and if you can kind of check off those boxes when you're thinking about interoperability-type projects, you're going to have a much better success rate of keeping that project on track and on time and within the budget constraints that you have.

So like I said, you know, the first thing is thinking about the use case, and so I try to tell people that you really have to think about what are you trying to solve. So, I'd like to know today, from a polling question, which Garrett's going to bring up, "What best represents, the need that you're trying to currently solve?"

Webinar Polling Question #1

Garrett Schmitt:

Okay, Laura, I don't know if you're able to see this from your presenter view, but I put this up on, on the screen, so we'll give just a couple more seconds for everyone to respond. 

We've got some answers coming in here and then I'll show everyone the results.

Laura Stewart:

Great.

Garrett Schmitt:

Looks like we've still got some movement here, so I'll let it go for just a [Garrett fades out].

Okay, it looks like we've got most of the answers in, so I'm going to go ahead and close this out now and I'm going to show the results. 

Laura, are you able to see this on your end? 

Laura Stewart:

I can. Yep. 

Garrett Schmitt:

Okay, great. 

Laura Stewart:

Fantastic. 

So it looks like the majority of folks are trying to solve ACO and value-based care, which [audio skips] data needs, followed by patient care application-related needs, and then analytics reporting, and the smattering of research and maybe some other edge use cases.

So we'll spend a good chunk of time today talking about value-based care data needs, and hopefully, you'll leave the presentation with your framework in terms of how do you think about solving your specific puzzle. 

What are the Health Data Use Cases?

Laura Stewart:

So when we think about starting with the use case in mind, I have a framework that I like to sit down with folks to walk through that basically covers seven components, and that's going to really kind of frame up what are you trying to do, and then you can go think about the technology to solve it.

Oftentimes, especially in IT, I think most folks are very keen about jumping to technology first, without really thinking through what is it that you're really trying to accomplish. 

So starting with the direction of the data, do you just need to pull or extract data out of a system and that data journey maybe stops at a data warehouse or, you know, a reporting type system, or do you need to pull it out and send something back into that same system or send something to another system?

Then, really you want to think about how often you actually need to get that data? People will often jump to real-time, but in many cases, real-time might be overkill and maybe even more expensive, more costly to maintain if you don't actually need it. So really think through is this a one-time data extraction? Maybe it's, you know, something for a data archival for a system that is being sunset. Is it something from a reporting standpoint that maybe you only need quarterly, monthly, or weekly? Or do you need it more daily or near real-time, but not necessarily real-time. 

So, make sure you understand what that means for you and your organization for what you're trying to solve.

Are the EHR Systems Supported by Current Standards?

Then, the next thing that I like to tell people to think about is, you know, is the data that you really need actually supported by a standard that's out there today? So either HL7 or fire-based standards. 

Oftentimes what we see at Healthjump is the answer’s probably “partially,” and there are many reasons for that. In terms of adoption, you know, new things in fire, etc., you know, USCDI is still evolving and rolling out, and so you might not be fully supported there and you'll have to think through, if that's the case when we talk about the technology, do you need another plan in place for that. Even if it is supported, one of the things you want to think through is do you understand how your end users are using the EHR. 

Now in the ACO and value-based care world, the answer's probably not likely at least immediately, right? Because you've got, you know, hundreds of EHRs that you might need to connect to, to pull data out, and people document differently. There are a lot of, you know, ways that people actually enter data into a system, and there are a lot of ways that it's not supported in terms of interoperability because the EHR vendors build triggers based on what they think the appropriate workflow is.

So, you want to think about that when you think about your use cases, you know, are they documenting in a custom form or custom table they built specific to their workflows, etc., because it probably won't be supported by any kind of standard data movement that's out there today.

Who's Consuming the EHR Data?

Next, you want to think through who is the consumer of that data.

So, who ultimately is going to take that data and make some kind of action on it, and then you need to think before the data gets to them, what needs to happen to that data? So, do you need to cleanse that data in some way, some form? Do you need to map it to some kind of standard because you're pulling it from a lot of systems? Or map it to a custom file output for a payer site to ingest? So make sure you know what that means for you, or maybe you need to map it multiple ways and make sure you get that documented. 

Then, you know, what action is going to take place once the data is received? If you can kind of frame all that up, then you're kind of ready for the next step in terms of thinking about technology.

Determining Your Specific Health Data Use Case

Example #1: Patient Engagement

So we're going to walk through a couple of examples, just so you kind of see what I mean by, you know, framing up the use case. 

So the first example is a basic patient engagement example, so the user story would be something like: “I, as a practice, or facility want to notify patients of their upcoming appointments and send a post-appointment survey so that my patients receive the best, you know, service possible.”

So that kind of workflow you would be thinking about, you know, hey, I need to extract, you know, the appointments and the demographics and the encounters once they've occurred, so I know that they happened, and then I'm going send it on to the patient. So user phone numbers to send that reminder or survey after the appointment, probably want to send this out every day.

You might be able to get away partially with standards, you know, the patient's ultimately going to consume, you know, that information that you're sending to them, and there might be quite a few transformations that you might want to take place. So there are a lot of different appointment types, typically that are built in systems, and you might want to actually normalize those all to, you know, a common type set. 

Same with different languages. You definitely want to know what language that patient's, you know, primary language is so you communicate to them the right way, and you know, what the phone types are, is it their cell phone? Is it their home phone? What's their primary method of contact? So you get that in front of them in a way that they're gonna respond to it and see it.

Then lastly, what you want them to do is, if they confirm their appointment, if they show up, or they take action to reschedule it, and that they actually complete your, you know, post-appointment survey. So you can take action on that feedback. 

Example #2: Extracting Clinical Data

The second example might be something to the effect of, you know, you as a practice might want to extract clinical data, and, send evidence-based care plans back for high-risk pregnancies. 

So a little bit more complex of a workflow, to do that. You're gonna need to get basically everything about a patient's chart out, and you might even want to target only specific patient's charts where maybe they have a certain diagnosis or problem on their problem list, to calculate the right patient cohort there.

Then, you might want to display back suggested care plans that are applicable for that patient based on their scenario. So this could be depending on what you're, you know, you're doing, a daily thing most likely, or maybe more of a near real type thing or real, most likely, workflows and standard base specs are not going to get you all the way there, especially when you just start talking about pregnancy histories, etc., that can be documented in many different ways. Often not available in triggers from my experience with lots of EHR vendors, and then you want to get something back in front of the provider.

How you do that, might not actually be, you know, a traditional right back type method into a database. We'll kind of talk about that in a bit. Then from a transformation perspective, you definitely, probably want to get all of this data into some kind of standard data model, so that you can make sure that you have efficient, you know, machine learning or routines on top of the data.

So you're sending back the care plans at the right time based on that patient's journey. Then ultimately, of course, you want that physician to take action on the information you have sent them back. 

Example #3: Value-based Care Needs

Lastly, just to wrap your mind around our last use case that we're going to deep dive on today, we have, you know, value-based care needs, right?

The basic goal here is to, you know, extract pretty much everything and get it into a format that you can use it to then do reporting on, right? And provide insight back to clinicians for care gaps. Then ultimately, hopefully, you know, have a successful submission to appear, for your payment model, in the right, you know, reporting period timeline.

So this is really a daily or near real-time data feed. Your standards probably aren't again, going to get you everywhere because you're going to have lots of practices that probably aren't using standard workflows. Therefore, those triggers aren't going to necessarily trigger data out if you set up a fire connection or HL7 connection, and then, you know, the consumers of that data, are you? So provider of clinicians, and you know, ultimately the payer. 

So typically what I see people do, is they get all the data, they'll map it to a data model, and then do some nomen clay trim mappings, and mappings back out to the specific pair outputs so that they can send the files and have them, you know, be received and ingested appropriately on the other end.

Here too, the provider might need to take reviews on the data and, you know, insights so they can take action in an ideal state, and then ultimately, you know, the final action is the payer sending back payment.

So if you can frame the use case up, then you can kind of talk through technologies that support various use cases. 

Webinar Polling Question #2

So I'd love to hear from everybody on how you're currently doing integrations today.

Garrett Schmitt:

Great. I've put the question up. So, if everyone wants to go ahead and submit your answers, we'll give it a few more seconds.

Okay. I'll do about five more seconds here. We've got a couple of answers still coming in.

All right. Looks like all the answers have come in. So I'm going to go ahead and close this and put up the results.

Laura Stewart:

Okay. A little bit of everything. That's kind of what I expected to see. So, yeah. Thank you for sharing. 

We'll dive deep onto all of the technologies next. So we can kind of talk about lessons learned from each, and kind of what we see in today's world. 

Healthcare Interoperability: Build vs. Buy

So when we talk about technology here at Healthjump, and when I used to advise customers at Cerner, where really, it's a conversation around a lot of times, folks will be having in their head: “Can I build or buy?”

It's the same thing that I used to do the other role ahead at Cerner as well when I looked at technology too, you know, what is the security around the data movement, and what does that platform really look like? How does the project actually work in terms of data onboarding and QA of that data, so that you ensure that you're not just taking, you know, garbage out and putting it in somewhere else.

How are you going to monitor that integration post-conversion? Then, you know, lastly, in terms toward the cost, you know, what other vendors are needed to support whatever technology and path that you walk down in terms of, you know, procuring data? 

So when I think about build vs buy, and there are certainly good use cases for each, you really kind of wanna frame up at least a couple of key answers to some of these questions.

How Many Connections Across How Many EHR Systems Do You Plan to Complete in the Next Few Years?

So number one, how many connections across, how many unique systems do you plan on doing in the next two years? Um, so that, um, you really know what that volume looks like, cuz that's gonna drive down into. Even what, what systems you should even evaluate, how much are they gonna cost? How many FTEs, etc.

So make sure you get that number kind of vetted out with what you think that might look like from a forecast perspective. 

Data Domains and Timelines for Interoperability in Healthcare

Then the other thing you want to think about when you think about connections and unique EHRs is what data domains and by data domain, I mean, do you need allergy tests? Do you need labs? Do you need vitals, etc.?

The more data that you need, the more extracts that you need as well, right? So that also kind of plays into timelines, how much do you think you will ultimately need to spend if you're going to go build it in-house to support those connections from a product perspective?

So do you need to go buy an interface engine? Do you need to stand up a data warehouse structure or a data lake? What vendor are you going to use? Do you have existing relationships with Microsoft or AWS to stand stuff like that up? Do you need a support ticketing system? 

All of those components you definitely want to think through in terms of the total cost, from a product perspective, and then that can kind of back you into, you know, what products do you want to use? How many connections you need, then you can start thinking through how many FTS do you need to actually build and maintain your data integrations. 

So when you think about FTEs, you definitely need to think about how big of an engineering team do you need? How much time from your security officer? Do you need to be a part of the initial onboarding and continued support of your feeds? Do you have project management support in-house? Do you have support analysts that you're going to need to hire or have them in-house, and then do you have someone out there that can go partner with various EHR vendors, and create relationships as needed as well? 

Then you have to think about how you're going to train and grow, especially your engineering team. From my experience, you know, even if you hire someone with good clinical workflow, knowledge, prior experience, etc., unless they're going from a scenario in terms of platform, etc., it's still probably a good 3 to 6 months before they're independent, and so you want to build that upfront into your timelines, right? Then, you know, how are you going to actually train them? How do they, you know, how are you going to go about your SOPs for data money and things like that? Then how do you handle all the relationships with the vendors you're going to need? 

So think about all those things, and really ask yourself if you have the right stuff to support all of that if you're thinking about building in-house, and if you don't and you go towards buy, there's definitely a lot of questions you want to ask potential future data partners that you want to think through with them.

So from a technology standpoint, as you're evaluating potential data partners, you definitely want to ask how you’re going to do it, right?

So there are definitely advantages and limitations to each technology that's out there in the marketplace today. So I'm just going to quickly, kind of walk through them, so you can kind of wrap your head around what I've historically seen, so that you can ask the same type of questions, get, you know, updates on specific vendors, timelines, etc.

Advantages and Limitations to Current EHR Interoperability Technology 

So when we start with HL7, which is, you know, where everybody kind of usually will start asking questions about, it's definitely, you know, common industry knowledge. It supports bidirectional communication in and out of a database. A big drawback though is it could take weeks to just get connectivity up alone.

Typically you're going to have the EHR vendor involved. So there are a lot of extra costs that kind of get added, not only your cost to build the side but the interface or your data partner’s cost to build the side of the interface. Then, it might not support all the workflows that you need to pull that data back, and so you're going to look at, you know, on a quick side, a 3-month, kind of timeline to get an interface live. Really, typically, they're closer to 6 and sometimes even more than that, depending on what you're doing from a fire perspective. Also, you know, common industry specs and knowledge, there's definitely support for bidirectional fire.

The different fire calls though are going to be really dependent on the vendor, and what they support today, you know, everyone has to support, you know, the SCDI calls. But beyond that, it's going to be limited. Can you get claims data out? Can you get charged data? Can you actually send something back in?

That's really going to be EHR-dependent. So from an ACO perspective, you know, not necessarily a great way to go, because you're not going to be able to probably use it with every single ____, and even with all of that, you're definitely going to need the vendor. They all have developer partner programs, you have to sign up for them, you have to get vetted, you have to submit stuff into their testing environment, and then ultimately they'll approve your production release of it.

So when you're working with data partners, make sure that you ask them: “have you made it through the development partner program and have an application approved for production?” Because if they don't, that is an upfront development timeline lifecycle. That's probably 3 to 4 months. 

So to keep that in mind, sometimes we see CCD exchange come up in our conversations here at Healthjump, we try to steer clear of this as much as possible. There's just not a great way to exchange rich data sets, and so, you know, if you have a data partner that wants to send you purely CCDs, I would question them why they don't support other workflows or methods.

You definitely still going to need the EHR vendor involved, and it's a much shorter timeline, but you're actually going to get much less than if you had gone with an HL7 or fire integration direct database extraction is fantastic because once we have connectivity to the database that means that you literally can pull anything, and you can literally write anything back in and that it will support both bulk and incremental data polls. 

You can set that stuff safely to pull daily or even more frequently than that if needed here at Healthjump. We do it too without any vendor involvement needed, and you know, we can take a connection live in less than a week, front to back, and we'll kind of walk through what data onboarding looks like here in a second, so you can know the right question to ask there too… how do you get to that week timeframe, which is definitely going to improve your cost and get stuff live faster.

So, then lastly vendor APIs are out there too, that are proprietary. A lot of them have bidirectional, you know, calls as well. They might not be available though for every EHR out there, and if they are it's going to be a limited selection and it's going to look just like the fire path, where if they aren't already a supporting developer that could take a couple of months to get stood up, and then, once they are, you know, things could potentially go very quickly if your port data partner has a standardized path and process to pull data. So here at Healthjump again, that's about a week to pull QC and take a data integration live.

Finding the Right Fit for Your Healthcare Interoperability Needs 

Then lastly, you know, from an interoperability perspective, I would always view interoperability as getting data at the right place at the right time in front of whoever needs to use it, and then there are various methods to do that. 

Read-only insights might be a way to do that, so, there are data partners out there, including Healthjump that have ways to deploy something that sits with the EMR so that clinicians and other end users can see something in context of their workflow, but doesn't actually write to the database, which means you can go and deploy much, much quicker and get that out in front of thousands of users and sites and in less than a month.

So Healthjump's product that kind of sits in that space, we call it Beacon, and this is this example of what that looks like. 

So we provide the technology to our customers. If they want to get something back in front of a clinician or physician to send messages back in, so they could be something as simple as: “Hey, they haven't had an annual wellness check this year” you know, you want to close that care gap and send them that nice reminder, so it's right in front of them as they're going out throughout their day, and they can see that on patients, and we provide that to our customers to actually populate whatever they want on the card so that they can get that back in front of the end user to take action on it.

Next, you kind of want to ask: “What does the platform look like and how secure is it?” So when you're vetting data partners, you definitely want to ask what's happening under the covers. And if they say: “Oh, I use AWS” or “I use Azure,” and they can't actually tell you what services they're using or how that workflow actually works on the back end, that's probably a good sign that they don't actually have something fully built out, and you should press again. 

If you don't get it, I would move on, and find a vendor that actually is willing to share with you how data moves, both in transit and at rest in terms of encryption. So Healthjump is an AWS stack. We've got pipelines set up to scale, and that's how we support our thousand plus integrations that are live pulling data every day. We pull data back into our data lake and then we aggregate it back to a common data model and push that to our data warehouse, and that's kind of where we serve up that data to our customers.

So one of the things you want to think through is how do you want to consume the data back? Especially in the ACO use case, right? So, are they going to send you a flat file? Do you have some kind of unload process? Do you want to go retrieve it via API? Do you have webhooks sent to you? Do you want a different file format output like fire or HL7?

Make sure you know what is supported because your data needs, in terms of sending stuff out, might change over time. So you definitely want to find a vendor that has support for multiple data output formats, and that can support different frequencies as well. So as you're vetting people in the marketplace, make sure you are asking those questions, so you're finding the right fit for you.

Is the Health Data You’re Receiving from EHR Systems Usable?

The biggest thing that I see in the ACO space and value-based care space is getting data out is one thing, right? Getting data out that's clean and usable is completely another story.

And so you see a lot of garbage, you know, in, garbage out, and so you want to make sure that you've got a good understanding of how a vendor validates data pre-integration.