This transcription is provided by artificial intelligence. We believe in technology but understand that even the smartest robots can sometimes get speech recognition wrong.

Revolutionize your approach to interoperability. Visit ThisWeekHealth. com slash Rhapsody today and unlock your full potential.

Bill Russell: (Interview 1) Today we have a solution showcase and we are going to talk about integration. We have Drew Ivan, chief Architect at Rhapsody and marco. Is it Casale or Casele? Wow. System integration architect.

And then I sat down in the CIO chair and saw we had 1600 instances of applications. And I was like, oh my gosh, what just happened here? Like, this is much more complex. And I think everybody who comes into healthcare has that same experience of this is more complex than we imagined. And we're gonna dive into that.

Marco I'll start with you. You sent over this stuff and it was amazing to me. 425 million messages monthly. And I'm just curious, I mean, the diagrams I'm looking at, it looks like it's at the center of everything. From a business perspective what would the operational or financial impact be if this stopped working at this point?

And it's an emergency for us to get back up and running because, all, the systems depend on. Data flowing back and forth from our Epic EMR to our clinical laboratory systems, our imaging systems, pharmacy, cardiology, just to name a few, some of our major systems that would be greatly impacted.

Patient care would be greatly impacted above all.

Bill Russell: Well, I mean, you bring up the fact that you have Epic. I think there's some people who would think, well, you have Epic. Why do you have the need for this? Doesn't Epic like connect all those things? it seems to be, their strategy is to make sure you don't have systems outside of Epic.

But they still exist, don't they?

Our health Information exchange e-prescribing. So we have Surescripts that we work with. We have Department of Health, public health interfaces working with the CDC. So there's many other systems that that I would think any medical center or organization would've to deal with.

Bill Russell: so Drew, you get to work with a lot of different clients across.

The healthcare spectrum from your Rhapsody's perspective what are some of the most critical integration challenges that health systems are facing right now?

Drew Ivan: There's really two dimensions that create challenges. One is adding more and more systems to communicate with one another.

As much as Epic does, it doesn't do everything. And, a lot of patient engagement systems and analytics, artificial intelligence systems are starting to emerge. And the first thing they need to do is get the patient record from the

Each type of data that you wanna move around creates a new set of standards or subset of the standards that become relevant and and so, just the fact of connecting two systems together is not a static thing because it will evolve over time. Perfect example is social determinants of health.

For a long time in healthcare those were not even tracked at all. And then they became relevant. They emerged as an interesting. Thing to keep track of about patients. And then once some systems began tracking social determinants of health it was noticed that there was no way to transfer that data between systems.

And so those two dimensions are really the two things that we see customers trying to keep up with.

Bill Russell: So it is not just a mar of the plumbing. I'm reminded of that scene from Apollo 13 where they were running out of oxygen and they dumped all the parts on and they said, they had a circle and a square.

And they said, okay, we've gotta get this filter to work in this thing with only these parts. And it essentially was how do you get the circle to fit in the square? It's not a matter of just connecting these systems if we just get the data to flow, that's one thing, but the data doesn't get received on the other end.

something needs to happen in a lot of cases, doesn't it?

Drew Ivan: That's right. It's not like hooking stereo components together where the thing that gets the data knows what to do with it. There's an open question of once the data gets there is the meaning understood by that system that receives it?

Bill Russell: Tell me about these projects.

How do these projects kick off? Like, what is it usually like a business case? Like, Hey, we're bringing in some new things, we have to establish something new, or I mean, what, how do they kick off? And then how do you go about mapping out the requirements and making the connections between these systems?

Marco Casale: Right. That's a great question, bill. So for us, we have different governance committees within our organization, clinical governance. Business growth governance groups, research governance groups and so forth. So any request that comes in typically has to go through a governance body to be approved.

Key points of integration and stakeholders that are involved different parties that need to be included. It's usually one of the things that as an integration architect, I'm always advocating for, making sure that we have representation from all the parties.

because a common misunderstanding is always, well, it's an interface. It's just the interfaces, team's job to handle it. It's always, no, it's, we need ownership from the sending and receiving, whoever's taking care of, providing the data, understanding the workflow of how they're sending that data, and then the receiving system.

And in our case, we also manage the interfaces in Epic, so we're building them out there as well, especially if it's something that's going back into Epic. It's a little bit more effort.

Bill Russell: You mentioned public health and obviously during the pandemic, this became a sure. Significant challenge.

New York State department of Health probably was pretty swamped during the pandemic. And you didn't get to sit down with them on an a daily basis and say, Hey, we're gonna send you information this way. And they were sitting there going, oh yeah, we'll receive it that way.

I mean, you probably had to figure out what they needed and really send it to them the way they required it, I would imagine.

Marco Casale: Right. I mean, for me specifically I worked with our immunization registry from New York State and we had already set up our, immunization interfaces out of our Epic system to the Department of Health and a query response interface so that we could.

Or being added. There were different rules that the state was requiring of us or removing from us. One of them key thing was we no longer needed to collect consent or we had to turn off the consent logic in our interface because at during the pandemic, they wanted all information on the population.

Bill Russell: Drew I'm reading more and more about automation, AI automation specifically, but just automation in general. And as Marco was talking there I was thinking, man, I wonder how many man hours that would've taken, like to manually collect all that stuff and send it over.

That would've been. Just but we're, I think we're at that edge of the automation journey where things like this are gonna be the the glue in some cases, but definitely the source of data for these automations, if you will. And I'm wondering

what are you seeing and how are you thinking about this?

Drew Ivan: It's interesting to think about the pandemic as a technology accelerator, right? Because we had video conference calls before the pandemic, but once and even for virtual health visits, but once the pandemic hit, and that was really the only option it was a huge accelerator for video conferencing.

Doctor's appointments before the pandemic. But the problem was they were scaled for dozens or hundreds of messages a day, not for thousands and tens of thousands. So almost overnight the volume of messages increased a hundred fold or a thousand fold. And so a lot of those.

Integrations had to be re-architected to take into account the higher volume of messages. And I like where you're thinking that if we're faced with that problem today, would we be better positioned as a result of the more powerful automation tools that we have in place?

And so I think we have better experience with reacting to those types of situations. And one of the ways is through automation. We're doing a lot of research right now with how can ai. Assist our users with building interfaces. And I think the next stage is gonna be how can we assist with proactively managing those interfaces so that when something changes the system itself can react to that change and proactively make modifications so that there's less impact on humans.

I don't think we'll ever get all the way there to a magic machine that can just right, like a factory.

Bill Russell: Yeah. A health factory. Yeah. I, and I know there's people that, that yearn for that. I do not yearn for that because when I go to a hospital, I wanna be cared for. I don't wanna feel like I just stepped into a vending machine.

Just, to be able to set that up and send that over is kind of a nice automation,

Marco Casale: right? That's correct, yeah. And this was a new system that the state just required of us to connect to. I think it was about a year ago. And we're using Rhapsody to convert those a CSV, essentially a CSV file pipe to limited file.

I'll say for us, we have many of those. So we look forward to opportunities where we can use direct encryption. Through our messaging. But yeah, it was a little bit challenging to set this one up. I will say it wasn't standard for us.

Bill Russell: Do you still have point-to-point integrations? I mean, do they, I guess they still exist.

They have to still exist.

Marco Casale: Oh, with Epic, absolutely. Yes. We have point-to-point integrations out of our Epic system directly to other systems. Yeah. Well, the Surescripts, there's a whole spectrum of interfaces that we communicate with Surescripts for e-prescribing from our Epic system to our local pharmacies.

Right.

Drew Ivan: It gives the customer, our customer the hospital, a place that they own where they can transform data as it flows from system to system. If you try to do a point to point, connection between two systems. You have some limits. One limit is the the output of the sending system, and the other limit is the accepted inputs of the receiving system.

You have to have a place that you own where you're in control and and it gives you a place to be the traffic cop.

Bill Russell: Marco, I wanna talk to you about the maintenance and probably continuity recovery. We just talked through this point to point versus going through a platform.

Talk to me about the difference between maintaining those point-to-point interfaces versus maintaining through a platform. And then also talk to me about from a continuity perspective. Business continuity perspective the thought process and approach to those points of integration.

Marco Casale: Right. So with the point-to-point integrations, I think Drew, you said it so well in, in your description. Thanks. Yeah. The point-to-point typically are us coordinating with the two vendors. There isn't as much control that we have. Even though we manage the Epic interfaces, much of that is controlled by the vendor.

We're able to traffic cop as Drew, well put it, the data that's going in and out. And yes, there's maintenance and support that, that we're required to do. One of the things that we have is, obviously we run with on-call support from our team. And we designate for whatever the interface is, we determine what our SLA is.

Bill Russell: it's interesting to listen to this. I was noticing in the document some talk about the newer standards that are coming out. And Drew, I guess I'll go to you first. As you look ahead, how is healthcare integration evolving?

What role do these new standards obviously FIHR not that new anymore. It's getting older, I guess. But it's also playing alongside traditional HL7 v2 I mean, how is healthcare integration evolving?

Drew Ivan: Yeah. One thing we see is that when new standards come out, they don't replace the old ones.

Generation of standards was probably the document standards like CC, D and CCDA. Mm-hmm. And those served a different purpose. Instead of talking about events that happened in the real world, it was kind of a patient summary or a document that contained clinical information. And then fire came along and this was, I sometimes describe it as like the Goldilocks approach. Maybe the HL seven V two events are too granular. For sure. The CCD documents are too large, but fire APIs give you access in a modern way to, information at the right level of detail. You don't have something as granular as the HL seven events, nor do you need to take the entire CCD document to get just the piece that you're interested in.

I don't know what comes next. I know that what we're seeing is an emphasis on the content of the messages. So, obviously you can create a c That has almost no codes in it at all. It's basically blocks of text that, that are intended for a human to read.

Or you can put a lot of coding in there. SNOMED codes. Loin codes, C-P-T-I-C-D codes. There's no shortage of codes you can put in there. But you have sort of the same problem with coded information that you have with the interfacing itself. Everyone has chosen a different code set because it's

Bill Russell: So FIHR really interesting to me. You have U-S-C-D-I as well. I mean one of the limitations is the amount and types of data that you have actually have access to via fire at this point. And so when I talked to. Particularly, the startups and whatnot they sort of fret over getting information and how hard it is to get information.

And they're used to living in that the API call and JSON and that whole thing and then they get into healthcare and it sort of slows them down. Maybe it should slow them down. Maybe they're not ready to be in healthcare. We can have that argument at another time. But do you think that the U-S-C-D-I will.

Expand at a quicker pace or just continue to plot along at the pace it's going.

It's significant to, to note that they don't set any maximum amount of data that can be transferred. They only specify the minimum. But as with many regulatory events there's very little motivation to go beyond the minimum. So what you end up with. U-S-C-D-I is, they set the lowest common denominator standard, and then that's what everyone complies with because anything more is questionable value.

So yeah, some vendors obviously do have more data that they make available or more APIs than the strictly required ones. But until everyone supports those there's very little interoperability that can happen. So it is a tough position to be in. On one hand, you don't want to require too much data in the minimum standard.

On the other hand you're never going to raise the minimum if everyone sticks with it,

for investing in the new standards while maintaining the existing workflows?

Marco Casale: So that particular solution, I wanted to invest in basically content enriching the interface. And we had a situation where our encore clinical trials management system, the folks there essentially needed to have updates of patients sent to them, but They didn't seed their system initially because they weren't allowed to being a research system. They could only see their system with patients that were in studies. So therefore their system never had our full, master patient index loaded. And I was looking for a way of not having to build yet another database on my own.

And manually go into a tool within Epic to re-trigger the patient, which, we didn't want to give that tool out to everybody. It could be somewhat dangerous to just let anybody re-trigger messages. And so therefore I looked to develop just a simple webpage where the research folks could enter in what patient they wanted to re-trigger.

And then let Rhapsody go ahead and make a FIHR call to our Epic system to say, I just need the patient resource and let's convert that JSON into HL seven V two and send it on its merry way to Encore. And so that was the intent of the approach. And I've had it in place for a few years now and I think we were getting probably.

Bill Russell: Yeah. I wanna thank the two of you. I'd love to give, final thought from each of you. Just one takeaway about why robust healthcare integration matters for the patient and for that matter, for operational success within healthcare. You had the first word, Marco.

You'll go first and we'll give drew the last word on.

Marco Casale: Okay. From an operational perspective i'd say the main value is that all the systems are kept in sync instantly because of a platform like Rhapsody. It's able to provide that data rapidly to our systems.

It's there for them and the patient benefits as well. So in a sense the patient probably isn't waiting as long because there is a tool like Rhapsody being able to mediate.

Bill Russell: Fantastic drew, last word.

Drew Ivan: You put a lot of pressure on me with, but it's supposed to be really smart and witty to wrap everything up.

As Marco says, it's really important to get the data to the right place in order to support patient care. In healthcare, we also have another force on the other side, which is around data governance. Because of HIPAA and because of other privacy concerns, you just can't make all the data available all the time everywhere to everyone.

Like, there's so many data concerns packaged up in the umbrella of interoperability, that it can be hard to separate them all out. And that's the world that we live in is the struggle to comply with all these different competing concerns in a way that also supports patient care.

And so, that's what our customers are doing. And I give them credit because I know it's not easy.

Bill Russell: Absolutely. And that's what I learned. Arrogant person coming in from outside of healthcare realized this is really hard work and I appreciate the two of you coming on the show and giving us a little window into what it takes to make all this work.

Marco Drew, thank you. Awesome. Thank you, bill. Thank you.

Thanks