Anthony Guerra 0:09
Good afternoon and welcome to data archival, minimizing risk, maximizing ROI Health System CIO media in production sponsored by 314e. Just a little housekeeping before we get started. My name is Anthony Guerra. I'm the editor-in-chief of Health systems CIO. And I will be your moderator today. We're looking forward to audience participation, you can send in your questions or comments in the… in the q&a box, and we'll take them later in the programme. Nice way to look at the screen click on the top centre, get it in side-by-side mode, then you can adjust the divider to get the video boxes in the slides the size you want them. And it should say speaker view in the top right hand corner. So you see how we're going to spend our time today we're gonna go about 35-40 minutes with our main panel discussion featuring Chuck Podesta, CIO at Renown Health, Saad Chaudhury, CIO at Luminous Health, and Abhishek Begerhotta, CEO of 314e Corporation. So let's jump right into our discussion. Important discussion today. Chuck, let's start with you. Can you give me an overview of your organization and your role?
Chuck Podesta 1:24
Sure, thank you, Anthony. Thanks, everyone, for taking time out of your busy days, especially during the holiday season. So I'm checked for that says Anthony said, CIO, Renown Health. I've actually been here about four months… in Renown Health, you don't know is integrated… the only integrated delivery system in Nevada. And it's not Nevaada, by the way. It's Nevada. I learned that a couple of months of being here and seeing the bottle all the time. Definitely, they knew as an east coaster, you know, right off the bat but only integrated delivery system in… in Nevada, and we're out in Northern Nevada, as they said in Reno. We have five hospitals, including a children's hospital, along with a large medical group. And.. and, we also have a… an affiliation. We just… just joined us a University of Reno Med… University of Reno, excuse me, medical schools joined us. And so it's you and our medical school. So we are rapidly moving towards being an academic medical centre. And they just joined us in July. So we… we have a bunch of faculty that we put on to epic in the fall, and we're starting to merge them in and doing expanding on research and hiring chairs and all the things that you do in an academic setting. So pretty exciting stuff.
Anthony Guerra 2:54
Very good, Chuck. Thank you. Saad?
Saad Chaudhury 2:58
Thank you for the intro there. And thank you, everybody, for being here today for the talk. My name is Saad Chaudhary, I'm the Chief Information Officer for Luminous Health. Luminous Health is an integrated delivery system here in the East Coast, Central Maryland to be exact. We are a three-hospital system. And about 80 ambulatory facilities spread out amongst about four counties in Central Maryland, about 1.5 billion annual revenue about 9000 staff members and employees overall. We have… We… it's a relatively new health system. So we've had our sort of obstacles that come along with organizational integration. The system itself was formed when two smaller health systems came together in 2019. I am the first enterprise-level CIO here.
Anthony Guerra 3:52
Very good, Saad. Thank you. Abhishek?
Abhishek Begerhotta 3:56
Yeah, thank you. Thank you for hosting this Anthony. My name is Abhishek. I'm the CEO of 314e Corporation, where 16 odd-year-old healthcare IT services and now products company, you know, around 300 people, you know, worldwide…150 odd staff members in the United States, and 150 in Bangalore, India. We do Interoperability and Analytics is our core capability, a lot of epic implementations as well. And over the last few years, we're rapidly embracing product development. And, as it so happens, we have an archival product as well. And look forward to participating in the discussion.
Anthony Guerra 4:42
Abhishek, we got to speak a little bit at the recent Chime conference. And you told me a little bit about the founding of the company. And it's an interesting story. It's sort of evolved out of a project that you were involved in. Can you… want to just give us a little overview on that? I think people would be interested in that.
Abhishek Begerhotta 4:58
Yeah, no, sure. And thank you for remembering that Anthony. So, I used to be a programmer for IBM, and IBM was developing a clinical information system for Kaiser Permanente, largely ambulatory. And this was in the early 2000s. And Kaiser had a change in leadership, they hired a gentleman called George Halverson as their CEO. And he used to be the CEO of HealthPartners, in Minnesota, which had deployed Epic. And once George Halverson came on, you know, he was… you know, there was a lot of custom software development projects failing in the late 1990s and you know, early 2000s. So, he was, you know, not necessarily happy with Kaiser spending hundreds of millions of dollars on custom software development. And they, you know, they essentially hired a big five consulting company, to do an Epic Cerner Bakeoff. They fired IBM, they chose Epic, and when, you know, so 314e was essentially formed as a byproduct of that when I got the pink slip from IBM, they needed data converted from the IBM clinical information system into Epic. And that's how we started and you know, Epic, essentially, it'd be fair to say, Kaiser probably was and still might be the biggest customer. And they essentially took off right after that, and this was around, I would say, 2004 or so.
Anthony Guerra 6:28
Very good. Well, thanks for recounting some of that for me. I appreciate it. All right. So let's start with you. Let's get into the topic. Can you talk about some of the main data archiving and application sunsetting projects you've been involved with? What did you learn from these experiences? And what are the main CIO skills needed to be successful in this kind of work?
Saad Chaudhury 6:48
That's a very loaded question. And it's a very complex one, happy to take a stab at it, of course. You know, a lot of our footprint, as I mentioned in the intro, is in the ambulatory side, so that's about 80+ ambulatory facilities, and then very concentrated, because they're spread out only in about three to four counties in middle of Maryland, most of them we acquired over time, so great… so as you're acquiring these clinical facilities, sometimes they're coming with EHRs, that are housed on-prem, sometimes more often, actually, they're coming with EHRs, that they're getting from somewhere else, or sort of like a cloud provider, just because, you know, they're small clinics, and they don't have the overhead of an IT team. So as you acquire them, as the CIO of the organisation, from the acquiring side, you have to figure out what to do with their data coming in. So not only building them and bringing them into your EHR, but also what happens with their legacy data. And then along with that, if you have a specific brand of EHR, as all of us probably know, you have a specific instance of that EHR, and it doesn't necessarily mean that another practice in other hospitals somewhere else that's in your health system that you bring on board with the same exact EHR, would be able to just combine their legacy data for a specific instance. So an example of that would be, even though we brought on, you know, 20 odd practices over time, the logos of the EHR vendors were probably about four… four or five, however, we had to maintain over a dozen different instances of EHR data… legacy data, simply because… just because the logo was the same, the vendor was the same, it was a separate instance, and hence had separate data structures, different versions, and so on, and so forth. So what I began to learn from this was that, just because there is, and we talked about interoperability a lot in healthcare, but just because you have the same EHR vendor also doesn't always mean that you're going to be able to very quickly combine the legacy data archives, and sunset, those applications from running on a server somewhere just for archival access purposes. The other thing is, we often joke about this in healthcare that a lot of the startups and innovation and innovative teams and companies out there, they're really just custom development shops that have a very niche sort of value proposition, whether it's an application or something that they do as a function. And then they have to build something custom around that to take it to production to actually allow it to operate in an actual healthcare setting. Well, unfortunately, or fortunately, regardless… it depends on how you look at it, whether you're Abhishek or whether you're Chuck and I. A lot of this archiving stuff is that it's actually a lot of custom sort of sorting and data manipulation to ensure that you can get to a state where some standard output comes out of it, whether it's a data structure, a… a central data warehouse from multiple different instances of legacy EHRs, and so on and so forth. That initial thing is always some level of custom data manipulation. And then what that essentially means is that a CIO just needs to be comfortable with the idea that there will need to be some level of partnership upfront. It's not just going to be a turnkey project that you say, You know what, I'm going to buy this, I'm going to plug it in an appliance somewhere in the data centre. And that's going to be it. There's not going to be any other manipulation, data transfer… transformation of any sort required. So this does take some care and feeding. And just because you have sunset, an older application, and you do need to keep that data around doesn't mean that it's going to be an easy road, it still requires a little bit of attention.
Anthony Guerra 10:47
So a quick… quick question, you use the word instances when talking about a particular vendor application… instances… how does word instances relate or is it the same or different than versions or upgrading? So when you know, an upgrade comes out? You go to a new version? That… How does that relate to the word instance, in terms of interoperability, and being able to merge data from two different versions or instances together? Sometimes when you have a new version come out? I would imagine it doesn't change a lot. But sometimes it may. So how do you… How do you work through that?
Saad Chaudhury 11:24
That's a good question. So you know, at its very, very base level, the instance in the EHR world essentially means where your pool of data for the EHR rests. So if you want to look up, if you're a physician, and you're treating Saad Chaudhury, and Saad Chaudhury has been a patient at your health system, he… my data will appear in that instance. However, if our organization is about to acquire another practice or another hospital, they may also have the same EHR as us. But I may not exist in their instance, in their database. There's multiple databases, of course, in the background, but in their data warehouse, or whatever you want to call it, the issue is, so if you take the example of the Microsoft Office Suite, if you have a Word document that you save on your computer, even if you have a different version of Microsoft Office Word, and you send it over to me, I will be able to open it, Word will be able to make sense of it. However, if you have an EHR by the same exact name brand as me, and if you have had different version upgrades, you've changed some things over the years, and somebody else has the same exact EHR company, but they have done theirs over the years a little differently. If you were able to just give me a database from the structure, just a single database saying, Hey, can you just import this on your side, it's not going to be plug and play, it's not going to be somebody just saying, of course, it's the same vendor, it'll just work right away, it doesn't work that way. So that's what I mean, by instances, you know, your instance of an EHR will inevitably be different than somebody else's, if they have grown up in a different environment and not integrated with you.
Anthony Guerra 13:01
Got it. Thank you for that.
Abhishek Begerhotta 13:06
And Anthony…so you know… Saad’s exactly right, the variability in these instances comes from a… version differences. You know, even if it's the same vendor too, the workflow of the provider might result in using this, you know, different features. And so data, you know, the same kind of data might be in different places, even if it's the same version. And then sometimes really small vendors, they may not have had the discipline, they could have done custom work on a given providers instance. So we've seen that as well. So all those three things result in variability where and then obviously, lack of standards, you know, fires addressing that a little bit, but there is no standard data representation of this data, you know, the continuity of care documents tried to address that a little bit. But, you know, for some type of data, but you know, so as a result, you literally, it's not easy to export patient data from one EHR and import into another. And hence, you know, you know, challenges that result from that.
Anthony Guerra 14:13
So, Saad's example of how a Microsoft document can work on whatever computer whatever version of Microsoft you have, that is something that these vendors in the EHR side have not done. They have not kept it in such a condition where what works with a Microsoft document… it won't work with EHR instances, correct?
Abhishek Begerhotta 14:35
That is correct.
Chuck Podesta 14:35
Yeah, yeah. Just to add to that, if you think about the data itself, and let's just… since we're diving into the weeds a little bit here… let's think about lab data, right? So you've got loud data from five, six years ago, or lab data coming from another organization that is merging with you and you need to ingest that data, you know, based on normal values and abnormal value So five years ago versus what they are today for various tests are very different, could be very different from state to state on what's normal, and what's an abnormal is really there are some national standards around that. But, you know, not everybody adheres to that. And that's a wide variety of, of lab tests. And so if you've got different ranges versus what's coming into your system, and a physician pulls that up from say, it's old data, you know, do you do translate into the new values that you have for normals and abnormal, so do you leave it static, because that's the way it was four years ago. And then conversely, if you bring in data from an m&a process, and it's different values, which ones do you pick, so it can get very complex when it comes down to data governance. You know, back in the day, when I've been at CIO for 25 years, he was just pulling the data and it was read only, not actionable, that you just wanted to it was for retention purposes only, and, and you'd like maybe link it to the EHR, so you can pull it up, when you pull the patient up, if somebody wanted to see some of the older data, but it wasn't really actionable. A lot of times, there's a bunch of PDFs, that's all changed now. You know, with the 21st Century Cures Act, you know, with interoperability, you haven't used FHIR®. And, and also, you know, from the standpoint of retention, and then when a patient asked for the information, you know, being able to get them the entire record, or whatever they're looking for in a very fast and easy process, which is very difficult to do out of an EHR. So, you know, it's, it's the world has completely changed, but the data piece of it has not, and can get in the lab is only one example, I'm sure, you know, Abishek inside can say many, many more.
Anthony Guerra 16:59
Saad you described… and we've talked so far about the complexities why it's difficult, you know, we've gone over the reasons it's challenging. Do you feel like you've got some best practices, as a CIO, that have to grappling with this, that you feel like you've got a methodology or a way forward to deal with these difficulties? Or is it still feel like a work in progress?
Saad Chaudhury 17:28
You know, I think the best practices around this really do develop from one organization to the next. And part of that is because some of those will lie in your partnership with organizations like 314e. So, if you have an organization that you're working with to have an archival solution in place, over time, the people at that vendor and at your organization will come to a standard operating procedure, hey, we're buying a new facility, hey, their previous EHR was XYZ, oh, yeah, we archived one of those before. So let's get on with the data transformation and analysis initially, and then we'll get them into the same exact kind of archiving solution that we've had in the past. The… the trick around this, from my perspective, the learning for me, was to just be comfortable that… that initial analysis will output a level of custom work. Sometimes it'll be repetition, if you've done a lot of archiving in the past, but there will be something unique. And I have come across every single one of these, there's going to be something unique about each one that you do. And you just have to be open to saying that, okay, we'll just have to figure a way around it, we're just gonna have a figure away, approach it and then add it to our, you know, if you have a single repository for archiving, or multiple ones, so it's just being comfortable with the idea that there's not going to be a one-hit wonder sort of status. As soon as you know, upfront that you're about to buy a hospital or facility or sunsetting an application, you'll know exactly what you need to do with that data and how it needs to be transformed for the archive.
Anthony Guerra 19:04
Doc, it sounds… is this an area that you really want a strong vendor as a partner to help you with these conversions? I mean, do you want to be sitting there slogging through this yourself as an IT department or you want to just say, have someone trusted and say, Okay, we just acquired them? Deal with it. Figure it out?
Chuck Podesta 19:23
Yeah, no, I mean, you definitely want to have a partner that's dealt with like various EHRs, all different types of, you know, ERP systems, whatever it might be, because then they've seen it, right? And you don't have to reinvent the wheel. You can rely on them as, hey, they, they just did this at hospital X, you know, two months ago. So you just rely on them to do the mapping and making sure that connections work back to the systems for viewing and things like that, but it's interesting kind of where the market is going because of what's happening with the 21st Century Cures Act and just where healthcare is going. A lot of these vendors, maybe wish I could talk more about this are actually going into the data analytics side of the world, right? And because they're capturing all this data from multiple systems, and like I said, it originally was for retention, and retrieval, for patient care. But now, it can be used for research, it can be used for a variety of different reasons, right? And that requires more than just what an archival solution will do. That requires, you know, tools and databases that are beyond what's in the normal archiving. So, I'm hearing a lot of… of discussions, some vendors are already moving in that direction, some are thinking about it. So that kind of an interesting aspect of what's happening.
Anthony Guerra 20:56
Abhishek, you want to talk a little bit about that?
Abhishek Begerhotta 20:58
Sure. Yeah. So that's, that's very, very accurate, Chuck, that, you know, what we're seeing is that, you know, you know, five years back, seven years back, even a couple of years back the archival was essentially non-actionable data, which, you know, you're, you know, some vendor is extracting data from your systems and locking it up somewhere. And the only value to the health system is, know, if I can, you know, is essentially retention, you know, so you're complying with, you know, legal medical requirements, and in some cases, a little bit of, if I can use the expression, CYA that, you know, I don't know what's in there, and when this might become valuable in the, you know, down the road, and, you know, let's just keep it somewhere. Now, what we're seeing is that the same effort, one can leverage in at least three different ways. So, you know, you talked about the data warehouse, you know, obviously, we're in a world where information is valued, and, you know, data is liquid gold, or so, you know, a lot of organizations want to use this archive data and put it to use in all kinds of analytics. The second thing is, you know, conversion. So, you know, you obviously, if at least if it's clinical data, you want to extract some of it and put it in your new epic system, for instance. And, you know, typically, we see that those are run as separate efforts. And, you know, this joint projects, and what were at least for one of our customers, and we're seeing more and more of this, that all three of those could be, you know, run off of a single project, and the organization derives a lot more value at a lot lower cost. So, you know, certainly that's the direction the industry is going. And as you mentioned, Chuck, with the Cures Act, now, all of a sudden, there's going to be requirements to make this data available as FHIR® resources to patients, or the applications that they sort of delegate, and the archival vendors are going to have to step up and support FHIR® API's, or the onus is going to be on the health system to figure out some way of again, extracting legacy data, assuming that you've not put all of that data in your, you know, Epic, or Cerner or what have you, then you're going to have to go back and find some way of, you know, again, unlocking that data and delivering it as FHIR® resources.
Anthony Guerra 23:32
Very good. Saad, what do you think is the proper level that a CIO should be involved in these projects? In terms of what do you delegate over internally to someone? And also, then you're bringing in a vendor possibly to deal with it? To what degree do you need to manage this and stay involved? I would imagine it would be very bad for one of these projects to go south. That's not good, right? Because you can really have a big problem, compliance and all sorts of things. But tell me your thoughts on that.
Saad Chaudhury 24:04
So the answer to that will differ depending on which CIO, you're speaking with, how long how big their team is, you know, how big their org structure is, in general. I would say probably that this kind of stuff, more often than not, will fall under whichever leader reports up to the CIO that handles the EHR landscape, and/or deals with the data structures and data warehouses and analytics oftentimes. Those kind of leaders are usually the ones that these projects fall under. As for what do you want to outsource versus do yourself? I am of the same mind as Chuck. So a lot of this is, as I've mentioned before, ends up being at least a little bit unique, if not very unique when you go from one archiving project to the next and usually it's better to be able to get the experts that have to do this for a living day in and day out. They tend to have at least some level of experience with all the major EHRs, they've dealt with different versions, they've dealt with different kinds of projects where you're dumping a lot of data from very, very disparate kind of instances, cleaning that and cleaning the data in the sense that you're standardizing it to some extent, and then you're creating one single archive from it. That's the holy grail when it comes to data archiving, right? So you want to get that external partner and you want to make sure as the CIO, that the folks that actually deal with the inherent little issues that go around how data is accessed from the user perspective, are the ones that are overseeing that project. As a CIO, I tend to say that if I get down into the weeds, everybody's in trouble. Because we don't we don't know as much as the subject matter experts as the leaders that are very tactical that understand the reality on the ground. So we need to let them lead these kinds of things.
Chuck Podesta 25:55
Great... and there's a couple of years of strategy focus, where as CIO, they really need to look at when you… when you think about archiving, one we talked about was a 21st Century Cures Act. So you know, you're responsible for the technology to meet, you know, that particular requirement. So how does archiving fit in so define the strategy of how it fits in from a FHIR® perspective and how to fix it fits in from interoperability potentially, and also retention and delivery of information in a timely fashion to the patients when they request it. So how does that piece work, but then you also have this thing called application rationalisation, which we're all you know, going through, and I doing that here now been here for months, we have way more applique even though we have, you know, Epic is our EHR, we got another, you know, 799 that aren't Epic, and that have just been acquired over the over the years, and many of those have been sunsetted we're still paying, you know, read-only maintenance on on them, I… we've calculated 15 that we're currently moving right now just to be able to get rid of the software maintenance. So there's an ROI associated with that right? So my job is uh, you know, from an app rationalisation is out of those 800 applications, how many can we just archive away, get rid of the… get rid of the maintenance aspects of it, get that ROI and plug it into whatever system it needs to have, you need to pull this information backing contextually with the patient and start to reduce that, that spend over time. So archiving has a play in that. So that's the CIOs job is to try to figure out, the vendor can help as well, because they've seen a lot is where does it fit? It's not just moving the data for retention? Where does it… Is there a data analytics play? You know, because we're moving to research now. So I mentioned University of Nevada, Reno, Medical school. And so is there a play there? So that's my job is to kind of figure out where it fits. But then let the others you know, do the… do the work, as Saad mentioned?
Anthony Guerra 28:01
Obviously, what are you seeing in terms of CIO involvement? When you deal with a lot of different customers, what are you typically seeing as the CIOs role in these projects? And my other question is, what do you need from your customers, to be able to help them be successful with the project, so you can do what you need to do? I'm sure you see all different types of engagement, some customers, give you everything you need to help them be successful, and some may not give it to you at the right time when you need it in the proper form, and you're waiting, and you're not able to provide the service that you want to, because they're not giving you the certain things you need to do it. So what are your thoughts on both of those?
Abhishek Begerhotta 28:45
Yeah, so, you know, I think, you know, as Saad and Chuck said, you know, it's, you know, typically not the CIO, that is sort of in the weeds of this, right? So it's one of their, you know, VPs, or directors, depending on the size of the organization. And, you know, typically even a project manager that we're dealing with, and, you know, when it comes to executing, you know, the, the challenge, the biggest challenge we see is what once we set the right level of expectation, and that's very important, right? There's no magic bullets, right? So it's not like, you know, it's not plug and play, you know, as Saad was alluding to so, you know, obviously, you know, the vendor also has, you know, we need to set reasonable expectation of the timeline, you know, cost etc. And typically, we're able to get fixed prices, but the biggest challenge is that the outgoing vendor may not be the most, you know, they may not, you know, be the easiest to work with, and especially if it's a cloud-hosted sort of environment where it's not, the outgoing software is not on-prem. So typically, you don't have access to the database. You could be reliant on the other vendors to give access or to provide data extracts. And those can take a long time. And you know, and I think we've run into several situations where typically, that has to go up the food chain to the CIO to then get involved and somehow find a way to push that vendor that, you know, you need to cooperate. But I think that to us has been, you know, in a lot of instances, that becomes the challenge. So, you know, one of the things that, you know, sort of, we would advise learning from those experiences is, you know, if you're signing a SAS contract, then you know, you need to have, you know, your lawyers review it really well, as far as you know, the, you know, the price points, and, you know, the availability of your data made available to you, and hopefully, in industry standard formats now that, you know, fires rapidly becoming a standard, at least for clinical data. So in, you know, getting that from the outgoing vendor is… is a challenge.
Anthony Guerra 31:00
So that's very interesting. So, Saad, if we know that one of the biggest difficulties in executing these can be cooperation from the outgoing vendor, we want to in the future get ahead of that, as Abhishek was saying, from a contractual point of view, and make sure as we're getting in, that we know we have an out that we know they're going to have to cooperate on these projects. Number one, have you had challenges without naming names? Have you had challenges with vendors being sunset in terms of them cooperating to help you transition off of their software? And have you put more thought into contracting to help you exit if and when you want to?
Saad Chaudhury 31:43
So I think that's a great question. And I'll answer that question in the inverse way. So I'll answer the second part first. Yes, we are taking a very, very thoughtful approach now when it comes to signing any contracts where and most of the time, I think right now, the new systems and sillery specially systems are in the cloud. So we are taking a very thoughtful approach to how does that data… first, how is it collected, where is it kept, there's of course, the whole cybersecurity piece of it, where you're actually evaluating the infrastructure behind the vendor, what they utilise. And then you're also looking at that out-clause? How does that data who owns it after the fact and in perpetuity? And then how do we actually get it back out if we need to, in terms of the experiences, it's been a very bunch, so I can say this, that I have dealt with, I would say over a dozen different instances, in terms of dealing with sometimes the same vendor, but with a different account person, with a different contract, and so on and so forth. None of them have ever said - No, you can't have the data. But what usually happens is because you are cancelling a contract, they're not going to say, Hey, I'm gonna put my star engineer on your account to help you get the data in the exact way that you need so you can smoothly archive this. So what's going to happen is they're going to kind of, they're going to start off with saying, Hey, we're just going to export this out with our most standard way that we export our data for you and we're going to deliver it. These are your options, pick one. The issue is, is what we all discussed a little bit ago, which is that usually there is some level of thoughtfulness that goes into this project. It's not a very standard turnkey thing. And so as you're going through that initial analysis and review, to figure out what you will actually need to do you and your partner, what will usually happen is that you may go back to that application vendor and say, Hey, we would like to have our data in this manner. Instead, we know you are capable of doing it, you can you just do this, and they will sometimes, you know, put up roadblocks because it may require extra hours, billable hours from their side, but they may come back to you and say, we may need to charge you to do X, Y and Z. So there is a little bit of negotiation from the, from the folks that are actually dealing with that account. Sometimes it gets escalated up to the CIO. Sometimes the CIO may not need to step in, but it is a little give and take. So that's where I have seen issues. It's never a no you absolutely cannot have your data. It's more of a how that gets to you.
Chuck Podesta 34:31
And that has to be done at the beginning of the contract, unfortunately, you know, as myself, we move around we inherit these contracts, right? So, you know, it comes down to the 60-90 day termination and you got to go off of what the existing contract is, but assuming you're going into a new one, you know, think about it. All good contracts are done when you… when you manage to divorce first, right? You go into the divorce first and you map that out. So when you give that 60-90 day notice, what happens, then? What, what is my responsibility as a customer? What is the vendor's responsibility, and you know, all the things that you unwind, how you get your data, you map that all out in very detail, right? Because a lot of times, just like in a regular marriage, you know, you go into these new vendors, and it's all euphoria, oh, my God, this thing is going to solve all the problems of the world here. Oh, I can't wait. And, you know, three or four years later, it's like, well, this thing's a dog now, and it's not working. And we got to move on. And, and, you know, let's shake hands and be friends. But, you know, if you don't do that divorce aspect before the marriage aspect, you're, you're really going to go down a wrong path. And we… we all know because we were constantly trying to unwind these things and Abhishek's in the middle of it as well, trying to get the data and being nice to the vendors, but they have no, you know, they've got other clients that are you know, they have no real, no real benefit to them to help you except that, you know, the good ones want to go out on a high note.
Anthony Guerra 36:11
Abhishek, do you ever feel like a marriage counselor or a divorce lawyer?
Abhishek Begerhotta 36:16
Well, I think what Chuck's talking about is having a strong prenup in place. So,
Chuck Podesta 36:20
yeah, there you go.
Abhishek Begerhotta 36:23
I think that's always, you know, that's a good, that's a really good idea, you know, so for sure, I think, especially with the SAAS applications, I think that's just a must. But we're seeing that a lot of customers do not put enough thought into it. So we're certainly seeing that, and, and it comes back. And, you know, as… as Saad said, it's not that anyone's going to sit your face, we're not going to give you your data, but things can get really dragged out there, they, you may have to spend a lot more money on multiple iterations, essentially, because, you know, they didn't give you the documents in the first instance. And oh, we didn't know you needed, you know, scanned documents, which were in the EMR itself. And you know, they've given you an export, which doesn't have that. And now, you know, all of a sudden, two months have gone by in the back and forth. And the other aspect is, you don't know what you don't know, in that what has been delivered, is it complete or not? Till such time the archive vendor or your data conversion into your EMR, they have had, you know, a few weeks or months of looking at it. So, you know, if they mess up the legacy vendor and giving you the data, you're going to inform them much later, not right away. So it adds to the timelines consistently.
Anthony Guerra 37:48
Abhishek, what's the difference between a excellent vendor in this area, someone like yourself that provides these services? What's the difference between an excellent vendor and a average Vendor? What does somebody do? who's really good at this? For their customers?
Abhishek Begerhotta 38:09
That's a good question, Anthony. You know, obviously, there's the technology aspect of it. So but if I leave that aside, right, so if you're, you know, as long as you have all the right features, and you know, you're looking towards the future, and helping with, you know, Cures Act compliance and what-nots, but other than that, it's really, you know, putting the customer first and doing the right thing. So, you know, you know, we realised that healthcare, you know, we're not a one-trick pony, we've been around 15 plus years, and we want to be around the next 15-20-30 years. So, you know, we have to build long term relationships with the customer, and not be caught up in the moment about, you know, sort of petty negotiations or, you know, so we tried to take the high road with the customer. And I think that separates… in general, I think, vendors that leave a good taste in the mouths of the customer, versus the ones that don't.. You know, I think we, you know, I don't know how did that adage goes, you know, do unto others as you would have them to you. So I think that's what we take to heart. We want to treat our customers really well. And more, I would say almost 100% of cases that's reciprocated.
Anthony Guerra 39:29
Yeah, don't nickel and dime. I think Saad was talking about potential charges from the set vendor being sunsetted. And I was wondering Saad, if they offer you a reasonable number of choices for free, A, you know, ABC can have for free, then you come back and you say, well, we'd really like D, which wasn't an option you offered me that's what we want. If they were to come back and say okay, that's actually going to take some man-hours and they gave you a reasonable quote. Is that appropriate?
Saad Chaudhury 40:01
It depends, right? So I'll give you a quick example. Whenever you're setting up an application, a lot of times you stray away from what comes out of the box, you configure some things, you're using some fields, you're not using other fields. And by default, if you do an export out of a specific database, it'll include every field that's in there. And it'll muddy up the waters in terms of what that looks like when it's exported out to be imported into some kind of archive. So you may ask, for example, as the CIO or the customer, that, hey, we would love to only get the fields that we're using, from our… in our instance. And the response may be well, that's going to take some… some manipulation and man-hours to do so we're going to charge you for that. The… in that specific case, I would say, you know what, we paid to get a specific kind of software, and we were using only a part of it. And… and you said at that time, if we wanted to use the other features, you would charge us more for them, and we for.. went for there. And we said, well, we don't want to use them, we just want to use this. And now you're saying we're just going to dump the entire data piece, because that's the easiest thing for you to do. And you're going to charge us extra to take those things out. In those specific cases, I would… I would hazard a guess that you would want to put your foot down and say, No, I don't want to pay extra for this. But on the other hand, you know, that can turn around very quickly, because you may actually be the person that has customized something to an extent that suits your organization. And it would actually take a monumental effort for that vendor to adjust things on their side. In that case, I would say, you know what, these guys have mortgages to pay, and they have salaries as well. So we should probably pony up that extra cash.
Anthony Guerra 41:37
Chunk, any thoughts around that? What's… what's reasonable and fair, and there's lots of nuances and things, you're a reasonable guy, right? You're not trying to break any… break the bank or break anybody? So what's reasonable?
Chuck Podesta 41:50
Yeah, we saw I mean, you know, you know, the vendors in the business to make money and provide a good service. So you don't want to, you don't want to bankrupt them, because they are a partner. At least, you know, until you give them that 60 to 90 day notice. Again, you know, you got to have the contracts there. But, but like with an archival, you know, with Apple checks company, you know, if I had 15 applications that I knew about, and I hired his company, they came in and took care of that. And then I found the 16, to the 17. And for him to say, you know, hey, we'll just do that, we'll just take care of that. Right? No problem. That's what you want an apartment to come back with oh, 16 through 17, that's going to be another, you know, 20-30,000 dollars, that's gets to your nickel and dime. So when it gets to the knot, we're talking about now say, ERP vendors, whatever it might be that you are, you are sunsetting, you've just given the 60-90 day notice, I think what you can do now with some of the newer contracts, is start to embed FHIR® into that as part of their capabilities that at some point, they need to have FHIR®… now they do anyway, right? Because of the government, you're going to have to be, from an interoperability standpoint, they're all going to have to have that. So I think we're going to be in a better place a few years from now. Because we'll be able to get that data through a FHIR® type of mechanism, as opposed to them having some sort of proprietary database that only they can manipulate to send us the data. So I think in your contracts, you're going to want to you know, focus on that piece. You know, when it comes to that divorce that we talked about.
Anthony Guerra 43:30
All right, very good. It's time for my favourite segment or ask a co-panelist… where I get to relax and watch other people do the work, so to speak. Just kidding. Abhishek, do you have a question for one or both of your co-panelists?
Abhishek Begerhotta 43:44
Well, I'd love to know if you've run into any serious landmines or any application that you just have not been able to archive for whatever reason, either their data structure was, say cache and data was not easily extractable. or for any other reason. You know, either of you, Chuck or Saad?
Anthony Guerra 44:06
Chuck.. We'll start with you.
Chuck Podesta 44:07
Yeah, I've got… I've got a couple actually, I'm looking at right now. They're over… we actually… should have mentioned in my intro, we have a company called Hometown Health, we actually have an insurance product. And from a payer perspectives, a lot of kind of old applications there. We're actually putting in some new stuff now with Salesforce and tapestry with Epic, but there's some really and we haven't dug in enough yet. But these are systems that were running in 2003-2004. And just in looking at some of the data structures, I think it's going to be a big challenge for us. So there's some of that stuff around.
Anthony Guerra 44:46
Saad?
Saad Chaudhury 44:47
So usually, when you will… we've… we've had that, so we've had a few instances where it was a… it was a very unique or add in one this is actually a custom-developed app. So they just… that specific clinic just went out to a custom developer and said just make us a registration type app and they kept adding to it. In those cases, it basically required another custom developer to get that data to be ready to be archived. But you know, the… the… the end result whenever any CIO hits this roadblock, is to just keep an instance of that EHR or app running on a small fenced off-server somewhere. And that's an issue when the organization gets large enough, or if the organization in itself is already very large, because then you have to care and feed so many different archive instances of that application running somewhere, keep them updated, keep their OS updated, all that stuff. So we run into issued landmines, and then you basically end up creating something that may become a landmine later on… from another perspective.
Anthony Guerra 45:51
Very good. Very good. Saad, do you have a question for one or both of your co-panelists?
Saad Chaudhury 45:56
Sure, so I'll actually ask Abhishek this… so Abhishek, you, you are in this business, right? So this is one of the things that you do. And you've probably had some success stories, and you've probably had some difficult horror stories, I'd love to hear bookends, I'd love to hear your favorite success and your, your perhaps even more favorite place of opportunity.
Abhishek Begerhotta 46:20
Sure, so, you know, I think most of them have been, you know, reasonable successes, you know, I, you know, we're working with a customer right now, where we're archiving data from 15, different, you know, actually, it's probably more like 20, if, and if we count instances, it's going to be around 40, or 50. So, but 15 different unique pieces of, you know, software, all the major EHRs that you can think of, they're consolidating into epic, and we are using that opportunity to actually create a enterprise data lake for them. And we're extracting data from that data lake, which is going into Epic, you know, five years of data. So that's data that's converted, and then we're archiving all of that, including the documents in our system. So, you know, they're super excited, we're super excited, we don't know, of too many other instances where the same technology stack has been used to sort of achieve all three of these things. So that's certainly a success. You know, in terms of… I'm trying to think of where we've had issues, and I think we've, you know, one… a customer on the West Coast, I know, we had, you know, it took a year to get the job done. And, you know, I think they weren't very pleased with us. But essentially, it was, you know, back and forth, and back and forth with the vendor, the legacy vendor, it was just a little too much. And, you know, after a while, you know, the, you know, and I can't blame the CIO for thinking, hey, you know, you could have done something more or extra or different. And, you know, I think we were a little bit of, you know, yeah, we couldn't meet the expectation of timeline.
Anthony Guerra 48:07
But you couldn't meet it, because you weren't getting what you needed from the vendor who was being sunset, the customer, your ultimate customer may have just said, I hired you to do this, right? I hired you to solve this problem with them. And you're saying… well, I've done as much as I can, there's no… because I don't have… I didn't even have any contract with them. You know that it… it gets complicated, right?
Abhishek Begerhotta 48:30
Complicated. And it was one of those situations I mentioned earlier, where it took us a while to figure out, you know, what was wrong? Right? With the data that was delivered, because, you know, some data was missing. And it takes a little bit of time. And by the time we went back to the vendor, you know, they were again, they… and it took two or three iterations. And then we extended the timeline, and you know, the customer…
Anthony Guerra 48:56
Yeah, if you have to go back to the vendor who's being sunsetted, multiple times, they're probably like, we didn't want to deal with you the first time. And now you're coming back again. Right? So you… their tolerance gets lower and lower for cooperation. So I can imagine it's challenging but appreciate your answer there. Chuck, you have a question for one or both of your co-panelists?
Chuck Podesta 49:16
Sure… I'm just gonna pile on…
Anthony Guerra 49:19
Oh boy! Poor guy...
Chuck Podesta 49:20
We.. we… I'm sure we talked about a little bit earlier, we touched on it, but for your product and also archiving, what do you… what does 2.0, 3.0 look like?
Abhishek Begerhotta 49:32
I mean, 2.0 really, is this Cures Act compliance. So you know, the… our… our product is.. yeah, and we're almost there. What we're focused on doing is, you know, A, the smart on FHIR® launch, which is, now you're able to seamlessly launch from the EMR with essentially the same privileges as in the EMR as well. So you know, who's launching, you know, You know who the user is, and you know, you may, they may not have the privileges to see that patient, for instance. So, you know, that setup is coming from smartphone FHIR®, then, you know, we're actually persisting our data as FHIR® resources. And in our contracts, we're writing that, you know, at no cost to the customer, we're gonna, you know, you know, if you divorce, for whatever reason, we're going to give you the data as essentially FHIR® resources. So it's sort of highly interoperable way of giving the data back to the customer. And then we run a full read-only FHIR® server. So which essentially means that, you know, an organization that is going live with say, Cerner or Epic, you know, they're essentially a duopoly now, and they, but they just have five years of data in there, they can seamlessly you know, and this is work-in-progress, we can deliver the FHIR® resources but we want in our to-dotto that they are able to come through my chart essentially. And, you know, the… the patient's going to be able to ask for an application on their behalf can… you know, they can allow them to get access to the legacy data and will deliver it to the application in a FHIR® native format. So, you know, the last bit, you know, I would say that is version to-dotto. We're not quite there as yet, but we're almost there. So even today, we run a full capability, you know, FHIR® server, but making that last mile of you know, how that data actually gets to the patient, without their having to get another ID password, integrating that with my chart for Epic. I think that is the next version for us.
Chuck Podesta 51:50
I actually, I really liked that… that's great self-service, just, you know, they're bypassing HIM you have anybody who has my chart account can now request not only, you know, see the data from the current EHR, but also see any legacy data that was four or five years old without, you know, calling medical records or, you know, Patient Relations or whatever it might be so, good, good move.
Abhishek Begerhotta 52:17
Exactly. And that's very exciting for a vendor like us, I think. And we're thankful, frankly, to the United States of you know, adopting the FHIR® standard and pushing the big vendors, you know, the Epic and the Cerner. And so they're developing their app orchards and Code.cerner.com. And that really is good for the, you know, end customer, there's no way the patient essentially. So I think this is going a long way towards, you know, interoperability in healthcare, which has been lacking over the years. But we feel like, you know, the next, you know, five years, we're just seeing going to see an explosion of, you know, of, you know, innovative products that really help the patient.
Anthony Guerra 53:01
All right, we have time for a quick last word. So, Chuck, let me start with you. Final piece of advice for your CIO colleagues grappling with this challenge.
Chuck Podesta 53:13
Yeah, so I think we touched on, you know, almost all the various challenges, the one thing we didn't do as on the implementation side. So you know, and I've been involved in a few big implementations with, like an epic EHR and things like that. And what typically occurs in these big implementations is that archiving becomes an afterthought, because you're so busy on, on implementing, you know, a huge EHR, or in the case of like an ERP. And there's a lot of company, a lot of organisations now starting to do a lot of that I think, most everybody has an EHR now, but think about it from an ERP perspective, you're about to do a big implementation, make sure your archiving strategy is embedded in that ERP implementation. So they want to be ERP implementation, for example, is a day one of your archiving implementation. So when you get to the end, and you go alive, you've already figured out where the data you know how much you're converting, but where the rest of it is going to be using your archiving partner. So that allows you to get your ROI a lot faster can now you can give that 60-90 day notice, you know, right after Go-live as opposed to a year or a year or two years down the road. Right? So that would be my one. One recommendation.
Anthony Guerra 54:31
Perfect. Saad?
Saad Chaudhury 54:33
So you know, one thing that was a high moment for me was at the… one of the last conferences that was in-person, somebody mentioned, hey, what do you guys do from a data governance perspective? When asked after keeping a patient's data, you know, X amount of time after they have passed away? So do you have rules around what happens and how you archive data for long-standing records that are no longer going to be updated ever? And that got me thinking In the past decade, majority of the United States, healthcare organizations have gotten an EHR, right? So we met through the meaningful use, and they have been on these EHRs majority of them for about a decade. Age of consent plus three years being 21 years, probably in another decade, we are going to see a lot of organizations scrambling to figure out their data governance and archiving policies. Because at that point in time, they're going to start asking themselves that very question. Organizations at large have not been on EHRs long enough to grapple with terabytes, petabytes of data of patients that have passed away. And then you don't know what to do with that data later on, and how to actually get rid of it or archive it in such a way it's not taking up active space. So my advice right now is that maybe we should start thinking about those detailed things today, instead of waiting for another decade, and then making that another buzzword with another sprouting of companies and vendors around it.
Anthony Guerra 55:55
Very good. All right. Very good, Saad. So Abhishek? Final thought.
Abhishek Begerhotta 56:01
I'm going to echo Chuck's sentiment, you know, I think that, you know, great advice. We often run into customers who don't think about archival, you know, enough in advance. It costs them, you know, you know, in some instances, you know, big amounts of money, you know, we worked with a customer who paid their legacy, you know, only one legacy EMR vendor $3 million, and they had a one-paragraph extension, you know, for three years, and you know, which was rock-solid, they couldn't get out of it, and 3 million dollars, essentially down the drain. So, you know, sort of planning this in advance at the same time as you're planning a big project really helps and will save you money and a lot of, you know, headaches down the road, so
Anthony Guerra 56:48
Excellent. All right, very good. Well, that is about all we had time for today. Regarding continuing education, you could use the final slide in this deck, you'll get an email when the on-demand recording of this webinar is ready for viewing. If you want to sponsor an event with us, you can reach out to Nancy Wilcox from our team. And if you want to register for upcoming webinars and go to our site. With that, I want to thank our tremendous panel of our good friends Chuck Podesta, Saad Ch,audhury and Abhishek Begerhotta. And I want to thank 314e for sponsoring today and our attendees for continuing to come to our events. And with that, everybody have a wonderful day. Thank you.
