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 the integration going live.

And post, so are they going to take a huge backload of that data in and run through automated QC scripts? Do you have to write them on your own? Is it all on you to validate? What does that look like? If they are running scripts, do they allow you to add to them so that you have additional validations that are important to you? Are they willing to share those with you in the sales cycle? 

Those are some of the things that you definitely want to be asking. We here have standard QC scripts that we start with. We have over 50 scripts in our standard library that round on every integration we do, and we work with our customers to add additional ones as needed to ensure that we have high data quality.

So some of the things you want to think about are: Are you going to actually fix stuff or are they just going to tell you stuff is broken? Who's going to fix it? Things like that. 

So here we do two things. We look for errors and extracts. 

So did we look for volume trends? So if you're getting 200 encounters a week, and all of a sudden in the, you know, extract backload there are several weeks that have significantly less than that, we go actually back to the source and investigate that at Healthjump to make sure it's truly that case that that's there or things like, what percentage of blood pressures exist on encounters that are telehealth visits, and so on and so forth.

So make sure you've got a good plan for that. Then we also do a set of informing. So sometimes you'll see some EHRs out there, especially in the ambulatory space, don't always have the best business rules on the product. So they'll allow end users to do some funky stuff. 

So for example, you know, when resolved data on analogy before an onset date, where clearly someone just, you know, put the dates transposed into the system and the system didn't stop them from doing that. So, how are they going to inform you of all those types of things so that you can take action with the clinic if needed to resolve them? Then once it's live, what kind of monitoring is going to happen on that connection?

So is it up to you to log in every day and make sure there's nothing wrong with it and open up a ticket or is the vendor going to do proactive monitoring for you and work through any failures on your behalf before, hopefully, you ever notice them? Which is, the approach we take at Healthjump.

EHR Integration Vendor Involvement

Then lastly, when you think about the use case in terms of vendor involvement, you know, what those vendor relationships look like with the data partners you're evaluating. 

Oftentimes we see customers here that have, you know, 30, 40 different EHR systems that they need to get data out of and you want to make sure the data partners you're evaluating to pull data, have those connections, and they're already live. You're not going to be part of their development, backlog timelines, or if you are, you know, what they are upfront so you can plan around it and start maybe connections that they already have, you know, supported standard out of the box while they're working on development work for net new connections for you, so that you've got a good plan in place to get data live quickly.

Webinar Polling Question #3

Now our last polling question it's going to bring up here is: “What price are you paying for an integration per year currently today?”

Garrett Schmitt:

All right. We've got most of the answers in here and obviously, this is confidential information that won't be shared. 

Laura Stewart:

Yeah, absolutely.

Garrett Schmitt:

It is just for us to get an idea.

Okay, We are giving everyone about five more seconds. 4, 3, 2. 1, here we go, and I'm going to show the results.

Laura Stewart:

Okay, A little bit everything too. Unfortunately, all on the large side too. 

Garrett Schmitt:

Yeah. Appears to be.

Laura Stewart:

So I think we're all in the right place. It's unfortunate to see that many of you are paying upwards of 12 or more thousand dollars a year for your data integrations.

Evaluate the Cost of Obtaining Electronic Health Records from a Variety of Vendors

You know, I always think that the platform really makes a difference, so, you know, technology is what drives efficiencies and engineering resources because of how talented they are, they are expensive to have, so when you think of, you know, vendor selection we definitely encourage folks to think about, do you have a predictable cost model?

So I see vendors out there that, you know, have maybe a fixed setup fee and reoccurring monthly fee, which is a fairly predictable model.

We see vendors out there that have purely professional service fees. There are fee for service, so you have no idea how much you might ultimately be spending.

Then we also see out there, you know, more of a fixed fee, just setup model and you own the support. So all of those things are definitely things you want to think about.

Ultimately, if you can find a vendor that has connections to the data that you need already from a vendor EHR or practice management system standpoint, out-of-the-box extracts, a good process for data onboarding that can deliver, you know, a plan upfront. How they're going to do that, what are each step along the way? How long did each of them take? 

You're going to hopefully see that cost slide more to the $5,000 or under $5,000 range, and hopefully, you know, some of the stuff we walked you through today will kind of help frame that up to get you there as you go continue through your data journey.

Consider Practice and Facility Involvement in Your EHR Integration Journey 

So, just a quick soundbite and then we'll take lots of Q & A.

You know, you definitely want to make sure your process is friendly to the practice or facility that might have to be part of the setup. So think about their involvement too.

You want to be able to measure your project plan in days not months, and I think a lot of you have already figured out just based on our polling that, you know, we can't always rely on standard interoperability to get what you need to be done, and so those are some of the things that we think are, you know, key to our success, you know, as a company here at Healthjump and definitely are things that you should think through as well as you continue your integration journey, and with that, I think we've got 20 or so minutes for question and answer.

Healthcare Interoperability Q & A 

Garrett Schmitt:

Okay, great. 

Well, this was a fantastic presentation by the way, and we do have a lot of questions that came in. So we'll get to as many of these as we can. Again, if we're running out of time at the end, please continue to ask your question, because we'll make sure to get back to you afterward.

So without delay, let's dive into some of these questions in no particular order here.

The first question is: “What are you seeing as the next big demand for data?”

Laura Stewart:

Sure. So I would say I've seen a lot of diving a layer deeper in terms of data. So we see a lot of people pull really standard stuff. But now we're starting to see, okay, I've got the rheumatology down the street practice and they have a custom, you know, form that they're documenting, you know, pain joints scores on, etc., can you pull that back out and model it into a standard model. So we see a lot of questions at Healthjump around the expansion of data models and how can Healthjump help expand and support a data model for our customers, and that's kind of where we're seeing this training is a layer deeper from the standard stuff that's kind of in USCDI or fire specs is, you know, that layer deeper where, you know, that real specialty care takes place where people are trying to uncrack and get out of a system.

Garrett Schmitt:

Okay, great. Moving right along, because again, we do have a lot of questions here, so we'll get to as many as we can. 

“How do you go about getting data out of new EHRs that you have extracted from before?” 

Laura Stewart:

Sure. So, our process back here at Healthjump is we first get connectivity set up. So we work with our customers to select a pilot, we get database connectivity set up, and we do a data mining process. So we go in and we go evaluate where all the tables are that have the data that, you know, we're trying to get out of the system, and then we go and do an extraction writing process in terms of writing those extractions.

So we have a kind of standard code model for how we write those extractions, so they're the most performant as possible. So when we're doing any extracts, we have any performance-related impacts on the end users that are using that system, and then we talk to our customer about, okay, when do we want to actually run these? So we make sure that we're not colliding with any operations jobs that might be running at night or during the day, etc., or peak times. So we work through that and then we go through some of that QC we talked about earlier, only, you know, the first time we do a new system, we go further in depth.

So we do a lot of chart-to-data validation on top of our standard QC scripts. We have our customers look at it as well, and then when everybody feels good about it, that's when we turn it on for standard delivery output, whatever that might be, and, you know, the next one we do, we did that same kind of rigorous validation 2 to 5 times so we get different practices, our facilities with different customers. 

So we really know that our out-of-box extracts are really strong to start with before we mark something GA. So we do several pilots when we take a new system live.

Garrett Schmitt:

Okay, great. And forgive me in advance if any of these are repetitive questions, you can just say that in your answer if I'm asking something that you've already spoken to. 

The next question is: “What is meant by bulk data for fire?”

Laura Stewart:

Sure. So bulk data extracts are something that most vendors are starting to support.

Usually, they were originally kind of meant, from my understanding, to facilitate someone leaving the system, and so you get a big file output, and then you have to kind of go make sense of and ingest it. So it's not really meant for, you know, kind of real-time or frequent polls, etc. It's meant for big polls for, you know, what kind of one-time use cases.

Garrett Schmitt:

Great. The next question is: ”Patient care application, is that the same as various EMR systems providers use?”

Laura Stewart:

So normally when I think about a patient care application, it's something that probably bolts onto the side of it in EHR. So we see and work with a ton of other tech companies here at Healthjump where they've hired us as a data partner to pull data out, to power something.

So the patient engagement use case example, we kind of walked through, we have a couple of customers that that is their business, that's what they do, and they do it really well, and they provide that kind of extra service where maybe the EHR vendor doesn't have something in place for that today or what they have just is for what the practice or facility needs.

Garrett Schmitt:

Great. The next question is:  “Would you like to cover how to get data from remote data capture, like HCC scoring HRA into the provider's EHR without having to integrate to every EHR vendor?”

Laura Stewart:

Sure. It's definitely something that you could do with a beacon-type product and get it in front of everybody so that they can see it.

So if that's something you're interested in, we'd love to talk to you afterward. We'll give you an email address, and you can reach out to us, but we have essentially a product that our customers send that stuff back in. So, you know, you can look at the scores, send them back, and get them in front of folks that need to know where they're at from a scoring perspective.

Garrett Schmitt:

Yeah. Great, very good. The next question is: “As users define some data fields differently, how do you standardize data input by definition?”

Laura Stewart:

Yeah. That's where a lot of the magic happens. The river meets the road. That's a fair question. We actually have our own kind of proprietary standard data models at Healthjump that are fairly robust.

We've been using them for many, many years, and we've got, when we do our, you know, kind of new system development, we have kind of a governance process where we go through and make sure we have everything mapped to the right place when we run through that QA.

So we always start with our standard model map to that, and then from a customer perspective, there are other things outside of our standard model that our customers want to see, and we work with them on those customizations to add them back in, and then, of course, we're always out there, with our ears to the ground and planning for updates to our standard data models.

We have a process to request updates that go through our governance committee, and then we go ahead and plan and make those updates. So we are evolving our standard data model as well over time.

Garrett Schmitt:

Great. The next question is: “What are the main factors that determine the cost?” 

Laura Stewart:

So it's time and time is money, right? So if you can find a partner that can take stuff live quickly, they're probably not going to be as expensive as someone that is proposing a 6-month project to you, and usually, a byproduct of taking something live quickly is a byproduct you're having the right technology behind it.

So, when you're looking at platforms and things like that if they have a good platform you know, you don't need as many people, and FTS to support the platform, right? So inherently a lot of times the cost is cheap, and that's kind of how we frame it up, back here. 

So we have a small team of 15 people on our delivery side and that includes our engineers and customer success managers and myself, and yet, you know, we support, you know, over a thousand integrations daily live and new integrations coming onboard and, hundreds of them every month. So we are small but mighty and we're mighty because we have an efficient platform that does a lot of things that would not be automated in a lot of other vendors' platforms from a data perspective.

Garrett Schmitt:

Great, and these next two questions, if these aren't able to be answered right now by you, I'm sure you guys will follow up via email afterward, but I'll go ahead and ask them. “What, and this one is, what proprietary vendors do not allow bidirectional data without approval?” and, “what success have you had with epic?” 

Laura Stewart:

Sure. 

Garrett Schmitt:

I don't know if, again, you're able to answer these questions, but let me put them out there.

Laura Stewart:

So, I'd love to understand the vendors that you're working with in terms of bidirectional because that really can be a vendor-specific answer in terms of what do the vendors do.

In terms of epic specifically, epic is one of those vendors that a lot of people will tell us they do have challenges with. We today do all of the direct extracts. So we'll connect to the clarity reporting database and, and grab data out. Um, we don't currently from our customer standpoint, have anybody that is trying to send data back into epic in terms of true direct rights back into epic.

So that's something we haven't solved before, but epic does have a, you know, their app orchard store, which we're part of, and we have the ability to go do that work. We just don't have anybody live on it today. So, those are things you probably want to look for is, you know, how do they get the data initially out?

And then if you're looking to get data back in front of people, are they an approved vendor that has gone through the app orchard approval process so that they can actually do that? 

Garrett Schmitt:

Okay, great. The next question here is: “As a physician or launching an ACO reach program with a diverse Confederation of physicians and care delivery partners, all operating independently today, how quickly can we get all data centralized?”

Laura Stewart:

Yeah, we get that question a lot, especially this time of year. So, you know, we, you know, have some new customers that we're working on onboarding right now where, you know, we'll take, you know, between 100 and 200 connections for before the under the year. So if you've got, you know, good connections in place, and a project manager on your side, that's ready to go, you know, you can take them up pretty quickly if you've got the right data partner.

So for us, that means, you know, getting connectivity to those systems and then starting to pull data, and so it's really someone on your side to organize, reaching out to the physician partners and care delivery partners that you have out there setting up time with Healthjump to get an agent installed so we can get connectivity and start pulling data. And then Healthjump kind of picks it up from there and works with you directly and works through any QC and remediation and takes it live.

Garrett Schmitt:

Okay. Great. Then this next question, it may be kind of a hot take, but we'll see how you respond. It says: “The VA spent billions of dollars on Cerner's integrations for its facilities EHRs, and it has failed. VA is considering terminating Cerner completely, what could Healthjump do that a company like Cerner was not able to?”

Laura Stewart:

Ha, no that's fair. VA did spend a lot of money on a lot of things, and there's a lot of politics behind how that money is spent, both from a Cerner strategy proposal standpoint and the VA standpoint. But what I can say is, you know, from a data movement standpoint, the way that that is currently designed and orchestrated is highly complex and has a million fail points.

Part of that is they have a lot of partners involved outside of Cerner because they are federal contracts. They require, you know, third-party partner involvement, etc. The other thing of it is they have a lot of systems everywhere, stuff is going in and out of data warehouses, going in and out of their HIE.

So it's really complex, and you know, they're doing a slow rollout and so they have to keep everything in sync across all the systems that they're still on. Vista, which there are 120 of them, and then they have to keep millennium in sync too. So, there's a lot of challenges with that and it is really complex, but from a, you know, data migration perspective, the pieces that I was involved with, we did, we were able to design a pretty straightforward process with VA working with them to actually procure data from their data warehouse that already aggregated a lot of the data together and then flip it through normalization processes and then ultimately pick it up for ingestion at site goal live and then sync data back down in, you know, for our sites that weren't live yet where you had patients that were going to go see specialists and stuff at other VA facilities on a reoccurring basis.

But yeah, you're correct. They've had a lot of challenges. It's a huge rollout. Thousands of people are involved in it, and so, you know, it's a lesson learned though, when we talk about how many people are at the table, how many cooks does it need to get something done? If you have a vendor that you're bringing then bring the EHR vendors, etc., it takes time, and money, and it adds to the timeline and complexity.

Garrett Schmitt:

I think that's a great answer for a complex question and problem. 

The next question here is, and this may or may not be something you can address directly, but, “What is the per connection fee based on per physician, or I'm sorry, what's the per connection fee based on per physician or per beneficiary?”

Does that make sense? 

Laura Stewart:

Yeah, it does.

Here at Healthjump, it’s actually neither. So we charge a per database connection fee and then reoccurring monthly fee, and we'd love to get you more information on that if you want to reach out afterward.

Garrett Schmitt:

Awesome. Awesome. Great. Well, unfortunately, we are out of time, and so we're going to go ahead and wrap it up here, but I do really want to thank you, Laura, for a fantastic presentation, and you know, obviously, we've had a lot of great audience involvement here as well. There's definitely a lot of curiosity.

Thank you everybody for attending today. This was a wonderful session. As we close out here, I would like to encourage you all to visit the Healthjump exhibit booth on VBCExhibitHall.com and, Laura, if I could get you to go to that slide. 

Laura Stewart:

Oh, absolutely. Sure, here you go. 

Garrett Schmitt:

This is, you can kind of see what it looks like there, but what you'll be able to do there is to dive in a little deeper on what Healthjump is doing in the value-based care space and to interact with their team and learn a little bit more, again about their products and services there.

There are a lot of great resources on VBCExhibitHall.com. Also, the recording of today's session will be housed there in the library, as well as a lot of other webinars and resources there that you can find. So please check it out, again, VBCExhibitHall.com, and check out the Healthjump booth there.

Then finally, if you would like to reach out to Laura or to any of the Healthjump team after the presentation, please feel free to do that, Laura, if you could go to that last slide.

Xand Griffin, who is in marketing there would love to help you out and send you in the right direction. So you see her email on the screen there. 

So again, thank you so much for coming. This was a wonderful presentation. I will be reaching out to each of you individually afterward, early, later on, this afternoon with a link to where you can get the recording and download today's session. 

We'd love to hear from you any feedback, if there's anything else you want to hear about from either Healthjump or on any other topics, please let us know. We'd love to hear from you. 

Thank you all so much for attending and we hope you have a wonderful rest of your day. 

Laura Stewart:

Thank you.