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

[00:00:00] This episode is brought to you by Rhapsody. You want to accelerate your efforts on interoperability? Have a chat with Rhapsody. If you want a platform with seamless data integration, one supporting all the protocols for improved operational efficiency, Talk to Rhapsody. They simplify data exchange, helping you drive digital transformation, and deliver better patient care outcomes.

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.

University of Rochester Medical Center. I'm looking forward to this conversation. This has been a passion of mine since I got into healthcare. So my first job [00:01:00] into healthcare was as CIO of a health system, and I couldn't figure out what all the fuss was like. Why is it so hard? In every other industry it seems like we can make all these systems work.

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?

Marco Casale: Yeah it would be pretty significant operationally. We've experienced downtimes many years ago unscheduled downtimes with the system. Primarily, things that were out of our control. Let's say they were [00:02:00] something to do with our sand storage or, some sort of infrastructure issue.

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?

Marco Casale: They do. Absolutely. I mean, Epic does have many modules or applications within it. That we've purchased and they are integrated, but even Epic has to talk to many other systems, not only internally, but of course we have third party [00:03:00] systems external to our organization.

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

electronic health record. So, each one of these point solutions that a hospital wants to [00:04:00] deploy creates a need to begin integrating with their EHR and with other ancillary systems. So that, that's one challenge. And then the other challenge is that interoperability is a moving target.

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, some work had to be done to create a new standard to to talk about social determinants of health. But what that meant was now there's additional work to be done for all those interfaces that have already been built. So, not only are we expanding the number [00:05:00] of applications out there, we're expanding the number of things that they wanna talk about.

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?

If so, can it handle it? Does it have a place even to store it? If it does, how is it going to take advantage of that new information? So there's a lot of work to be done within the systems that [00:06:00] are being connected, but also in between the systems that are being connected.

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.

And then we determine effort and typically a project manager's assigned to it. And then we start to delve into understanding what are the points of integration. And that ultimately goes to another committee that we have internally in our department called Ar Tech, or [00:07:00] Technical Architecture Committee, where we as , an information systems division will review the technical aspects of the project and determine what are the.

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 then a lot of times it's a bidirectional pathways that are going on. But then, in our case, our team will then look at what the different points of integration are, and we build out the specifications. And work hand in hand with our [00:08:00] developers to build the routes out in Rhapsody and so forth.

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.

Query the state and ask them, Hey, give me the [00:09:00] history of all the vaccinations that a patient's received. Which became very important when the COVID vaccines started rolling out. And the thing that we had to constantly keep up with was obviously we're adding more and more sites where people could get these immunizations, and so we had to keep up with the locations constantly changing on us.

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.

Then we had to set up multiple ways for the system to automatically query the state to find out what a patient's vaccination history was, even allowing a patient to request it through our patient portal with an Epic called MyChart. It was a constant adventure. I'd say during that point in time, I think I was on evening [00:10:00] calls with our CIO and pharmacy leads and ambulatory team folks, just trying to coordinate changes that were happening to us rapidly.

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.

Same [00:11:00] thing with immunization and lab reporting, integration to public health. A lot of our customers are the state departments of health and they use Rhapsody for collecting reportable lab results and immunization information. And the good thing is that standards were already in place before the pandemic, just like they were for video.

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 I don't know the answer. I hope we don't have to find out the same way. But I think we do have. Better tools now and better experience with [00:12:00] scaling things and understanding that things that work in in regular conditions aren't necessarily going to work when when the conditions change by a factor of a hundred or a thousand.

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.

But Marco, I want to I was looking at some of the documents and bed [00:13:00] census data. To the New York state struck me Rhapsody pulls, if I'm reading this right, Rhapsody pulls hourly files via SFTP, converts them to js o format and transmits them via rest API. That's a great example of an automation that probably would've taken somebody some time to figure out and that kind of stuff.

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.

Into the specifications the state gave us, which was JSON formatted. So yeah this doesn't even involve HL seven, this integration. and it's nice in that we're using encryption over the network. We're not required to have a special VPN for [00:14:00] this, which always can slow down integrations.

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.

Bill Russell: Yeah I guess Drew what's the business case for health systems to invest in an enterprise integration platform versus. These individual connections. I realize in some cases the individual connections are, you just have to do them. But I would think having a [00:15:00] platform in between just, I don't know, simplifies the whole process.

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.

If you're lucky, those match up and you can just plug them directly together. However, that's almost never the case, and you have to make at least some translation in between. Either you have to translate the protocol like we talked about, translating FTP to I think it was a web service or you have to translate the format maybe from a fixed record format to JSON all of the ways that systems emit data are reasonable choices and all of the ways that systems accept data are reasonable choices. The problem is nobody makes the same choice. So you end up with all these [00:16:00] relatively minor changes you have to make, but in total they add up and you can't rely on either vendor to make the changes on your behalf.

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 can maybe turn on and [00:17:00] off something from being sent, but we can't typically manipulate content. To be in a different format. So that, that would require more work in a sense not from a coordination perspective. And we have less control with us owning the our Rhapsody engine platform we're able to provide that service to our customers.

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.

So trying to understand whether or not it's critical patient care or if it's maybe something more in the realms of HR or patient financial type of interface. That's a Monday through Friday, we'll run the different levels of support [00:18:00] based on that. And in using Rhapsody, we're able to set up alerts within the product and, to be able to notify our on-call person when there is any kind of continuity issue

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.

They live alongside them, which, mm-hmm. is fine, right? Because they were designed for different purposes. The HL seven V two standard is event driven. So the good thing about that is when an event happens in the real world, like a emergency room admission. It creates an event in the message stream, and then you sort of have the what happened [00:19:00] when to whom, and you can keep all of that information together and build interesting workflows off of it, the next.

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.

So that's one advantage is the granularity of fire. The other advantage is it is a more modern standard that's based on REST [00:20:00] APIs. The HTT P Protocol, it's familiar to a lot of software developers. That's where software developers prefer to work is in that type of API world. And so it it makes healthcare integration a little more accessible to technical people.

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

more native to the problem space they work in. But then you have the problem of translating between and among those code sets as you move data from system to system. So, I think that might be the next frontier of interoperability is more on the [00:21:00] semantic side of making sure everyone means the same thing with the data that they're transferring

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.

Drew Ivan: It's a hard question. I'd be interested to hear what Marco is seeing but what we're seeing is that because so many vendors have to comply with U-S-C-D-I it can't be too overreaching because Right. Everybody has to do it. So they do set [00:22:00] the bar a little bit low.

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,

Bill Russell: Marco, I noticed I think it was on for your clinical trial system. Oh, right, yeah. I mean, you're already playing in that world, right? Of bridging FIHR and [00:23:00] HL seven V two. What's the business driver for

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.

That was being maintained by our Epic a DT interface, but rather just tap right into Epic's Fire API and use that as a way of saying, okay, the [00:24:00] encore team, please go ahead, tell me what patients you want. They were initially just sending us a service request to do this work and my team would have to then pick that up as a ticket.

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.

Five tickets a week and now I can look at and see how many times are these folks actually calling? And it's probably up to [00:25:00] 25 times a week where they're asking, Hey, please send me this new patient for this clinical trials that we're doing. And so I think it's worthwhile, at least from that perspective to, optimize our workflow.

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.

One of the key things that we have as well is medical device integration. So the ICU monitors and bedside monitors are being pushed directly through our engine into our Epic system and we need the data to be fast. So timeliness [00:26:00] is important. It helps with patient care. It helps our caregivers have that information at hand when they need that result updated in the charts immediately.

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.

So you have to figure out the right approach to get data where it needs to go and make sure data doesn't go where it shouldn't go, or it only goes there with [00:27:00] appropriate permissions. And so you have these issues of privacy, governance data formatting, semantics retention, routing.

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

for listening to this Interview in Action episode. If you found value in this, share it with a peer. It's a great chance to discuss and in some cases start a mentoring relationship. One way you can support the show is to [00:28:00] subscribe and leave us a rating. If you could do that would be great, thanks for listening. That's all for now.