Hello everybody, thank you for joining us. I'm Florent Sainclair, I'm Chief Operating Officer for DICOM Systems and I'll be your host today for this conversation that is co-produced by RS&A. We're honored to have Mr. Sam Essa from University of Southern California Keck School of Medicine and also Dimitri Tichelnik, the founder and CTO of DICOM Systems. So this conversation today is really all about change management, right? The title of our presentation today is about how to maintain clinical integrity at times of transition and transition is just another word for change, but what kind of change is the question, right? The sheer number of possible scenarios that we face every day as professionals, especially as hospital managers and facilities managers, is mind-boggling, right? The most evident possible scenarios involve mergers and acquisitions, maybe changing a major IT vendor. In every case, careful management and careful planning is what we're going to be talking about here. We've prepared a set of 10 recommendations that we'll share with you in just a minute that should help you better understand what are some of the key elements that you need to be paying attention to before you start to effect change within your own organization. Those transitions are precarious. They present many opportunities for errors and for missteps that can be very costly in the future. Some of those costly mistakes, as some of you may hopefully or may not know, involve ransomware attacks, cybersecurity attacks, vulnerabilities that you never even knew about because those transitions represent, you know, in some cases, some dangerous unknowns. And so, this conversation is going to revolve around some of those preparatory steps that you can be taking to get yourself ready. So, I typically like to talk about change in terms of an archaeological dig. When you prepare for change, for any kind of a transition, it's really tantamount to becoming an archaeologist and digging and understanding your organization at depth that you were not even involved with 10, 15, 20, 30 years ago. The IT organizations that we as vendors encounter are not unidirectional, right? There are interfaces that go in all directions and the discovery process is very similar to what I'm showing on screen now, which is the concentric circles, the cross-section of a tree with the most recent IT acquisitions at the center and the oldest acquisitions that are still part of the picture on the outer parts of this picture, right? A system that may have been purchased 30 years ago was not well-documented but is still chugging along and adding value. Well, if you're going to yank something out without knowing what it does, what's the possibility that you're going to harm patient care? It's very high. And so, let's examine some of the real-world scenarios and I'm going to invite Sam to talk about this a little bit. What I'm showing you on screen now is a real-world East Coast-based academic medical center that's quite large. They process about a million plus exams a year to give you an idea of scale and the discovery process, what this picture shows is that just the imaging enterprise alone has a sheer number of unique vendors that are used by differentologies but all doing imaging stuff in excess of 40-45 vendors and growing, right? Because we're adding new AI vendors on a nearly monthly basis now. And so, one of the key challenges I would like for you, Sam, to address here is not strictly how do you manage this stable of vendors but how much collaboration can you possibly have because if you look at the bottom of the screen, this particular academic medical center, which is not USC by the way, has nine unique departments that are all in charge of different aspects of imaging and they don't always talk to each other, right? So, if you're going to effect change like a fundamental large-scale transition at USC, for example, what do you have to do to ensure that you don't leave any stones unturned and break something really vital to patient care? Go ahead, Sam. Absolutely. Thank you, Florent. Thank you for the RCNA and DICOMSIS team for this wonderful event. So, I'll provide you an example with recent transition we had at USC with acquiring another hospital, for example. As you mentioned in the first picture is really dig and learn this environment. Learning your current environment is key for success. Understanding all your different systems, how does it function, system structure, how is your current data modeling, all the different integrations, your current network infrastructure is a key for success. Documentation becomes a really big part of all your healthcare imaging ecosystems and imaging systems to know how is your current workflow is designed and operating so you can know what to expect during the transition and be able to plan for a smoother transition for continuity of patient care and integration. Thank you, Sam. There's another aspect of this that I think is really key and, Dmitry, perhaps you can walk us through this and that is backward and forward compatibility of technologies. I think there is a blind spot in many cases when it comes to any kind of a transition and especially M&A. If you're going to acquire a health system that has an aging infrastructure that may still have some old Windows 7 machines that are no longer supported and represent a cybersecurity vulnerability for our customers. But it doesn't stop there. There's also fundamental incompatibilities. Can you address some of those? Absolutely. Thank you. Obviously, the system up-to-date status in terms of supporting newest protocol inversion goes without saying. When you implement a new state-of-the-art system and using new protocols, you have to make sure there is a legacy compatibility there as well. New vendor and software developer, there is no point for them to support all type of legacy systems, so they use the latest technology that exists today. For example, I'd like to bring up compatibility between legacy and still today's protocol like HL7, DICOM, IPv4, and make sure that they correlate with new industry protocol like FHIR, DICOM, and IPv6. When you install the state-of-the-art system, you need to make sure they can communicate with all the legacy systems and other systems that are still in place. They're not necessarily legacy. They might be a new production for a while and see how many different systems we have on the current diagram you display. In that event, you need to make sure that there are tools in place for that compatibility to exist so you can transfer that protocol back and forth from, let's say, from DICOM to DICOM, from HL7 to FHIR, and back and forth. With the increased security lately, you want to make sure that you have the compatibility between DICOM web, let's say, transmission, a secure transmission to whatever the protocol your current system uses. That's very important. Certainly. Another interesting aspect of this is, and you'll notice in this area on the left side, you've got your EHR ecosystem. On this side, you have actually a lot of chaos. The historic buying pattern, purchasing pattern, procurement pattern for imaging is siloed. Cardiology will go and do their own thing. Radiology is the largest user of imaging, but everybody is expected to do what they can with what they've got. The result is a pretty chaotic picture on the imaging side. Transitions are an opportunity to bring a little bit of order to the chaos. I like to distinguish between this side, which is the EHR, and this side, which we really, as an industry, should start called the IHR, the imaging health record. Anything imaging should really be very cohesive. It's an opportunity for you to establish an interoperability layer that will bring that order to the chaos. Let's briefly go back a step up and talk about some of the transitions that a health system may undergo at any given time. Believe it or not, some of them may go through all of these. I have no less than 10 different ways to look at transitions on the screen here, but a health system may be going through an M&A transaction. Few people think about the reverse. You think about two health systems coming together, but what about a divestiture? What about an unmerger? What do you do? You have spent so much time and effort bringing the two health systems together over a period of potentially three, four, five years, and something goes wrong, and you have a governance issue at the top, and you decide to part ways. We saw that a few years ago on the procurement side when Stanford and UCSF built a joint venture in the Bay Area to become sort of a GPO, a group purchase organization of their own. Well, guess what? It took a lot of work to bring them together, and it took a huge amount of work to take them apart as well, right? So, Sam, could you address that a little bit from your perspective? I'm sure you've seen both of these things happen in your tenure at USC, but we'd love to hear your perspective. Yeah, absolutely. Thank you, Florian. So, being in the industry for almost 20 years, I have been through many transitions from M&A affiliation, adding new systems, taking systems away, and with any sort of transition, it is very important and vital to have some sort of a transition committee. Transition committee plays a key role to decide how are we going to manage the transition, what is needed. Transition committee should encompass people from the entire enterprise, imaging, IT, InfoSec, finance, integration, network, to provide guidance through the process, do the proper assessment, planning, discovery. Also, decide which tools you are going to need during the transition. For example, with an M&A transition, you are going to be dealing with converting DICOM, HL7, multiple EMR systems, multiple PAC systems. You need to decide how are you going to do the data modeling, DICOM integration, HL7 integration, and what are the tools you need to perform all of this, not only from the imaging side, from the clinical side, integration side, network, and the whole entire ecosystem to be able to ensure you have continuity of patient care. For example, you need to account for what happens if you have a stroke patient. It goes back to discovery, assessment, and understanding your own workflow, and for example, what involves a transition, for example, an M&A or adding a new site or a new affiliated site or a hospital. As I mentioned, continuity of patient care, and one of my previous doctors says all it takes is one image to save a patient life. For example, if you have a stroke patient, when you are adding a new hospital or retiring a system, what do you do with your STAT patients, with your stroke patients? We all know stroke patients. You have to scan them right away, and we all rely on outside reading partners and outside vendors, so you have to know how are you going to maintain this? How are you going to manage your downtime, your entire health system, and specifically imaging workflow? That's where the transition committee plays a very important role in deciding all these factors, work on governance, deciding the flow of the transition, different phases, and whatnot. Thank you, Sam. You're welcome. So let's take a quick look at this top 10, and by no means is this an exhaustive list of what should be looked at in a transition, right? Every health system is different. There's different culture. There's different people, and everybody brings a different level of experience with these types of things, but know your organization is really the beginning of this, right? Let me briefly go back to this visual here. This was the result of us working and doing due diligence with our customer on the East Coast to discover, painstakingly, what do you currently have in your inventory of software solutions out there, right? One experience I can recall about 20 years ago, Stanford Healthcare went through a process of outsourcing their IT function to Perot Systems in Plano, Texas. I don't know if any of you will remember that that far back, but they implemented Epic, and the organization that implemented that for them was Perot Systems. They're the ones that won that contract with Stanford Healthcare. That discovery process was probably one of the most painful archaeological expeditions I've ever been a part of, because in some cases, we encountered servers in the data center that nobody could tell us what they were there to do. And literally, the only way for us to figure out what that server did was to unplug it and wait for the complaints to start coming in. And so, you can establish pretty rapidly that that is not the right way to do things, right? The discovery process before you start transitioning has to come up with the full inventory, as exhaustive as possible, of all the elements of your IT ecosystem. And then, as Dimitri pointed out earlier, you want to watch out for things like IT obsolescence and cyber vulnerabilities. Systems that were designed 20 years ago were not designed for today's cybersecurity challenges. And so, just because they're still in production doesn't mean you can't discover them and make sure that you mitigate the vulnerabilities associated with them. Sam mentioned the importance of forming a transition committee. That transition committee is typically there, right? Health systems are very professional organizations, and they know that they need change management, right? They typically have change management procedures. The problem is not everybody is represented in those committees. And that's why we say, at a minimum, you really want a committee that is formed with clinical IT, security, infrastructure, and workflow specialists involved. Because if you don't know the workflows, if you don't document the workflows, and in a minute, I'm going to share with you a slide. Actually, here it is. This is a workflow that Sam documented for us at USC. And I don't want to steal your thunder there, Sam, so I'll let you present this. But the lesson to draw from this workflow analysis is that there's no less than 17 steps in one workflow that need to be documented, especially if you're going to migrate them to a different system. So, Sam, can you please walk us through this? Absolutely. So, as you see in the diagram, I know it's a loaded diagram, but basically, that's an illustration of what happened during a transition. In this example, adding another medical center or a hospital. Again, as I mentioned, you will probably end up with multiple EMRs, multiple imaging systems. And as a daily operation of hospital, you need to maintain the workflow. So, at the end of the day, you have to make sure patient workflow is not interrupted, and everything is accounted for starting from scheduling orders, image acquisition, all the way until it reaches the radiologist so they can issue a report and do the clinical interpretation and distribute the report back to EMR and other entities. So, during this process, for example, you have live patient data, you have migration happening, you have the middleware engines that is running all of this, as I mentioned, part of going through a transition, you have to decide what tools you need. And in our scenario, we actually decided we needed a middleware DICOMSIS engine to manage all the patient traffic integration and transformation. So, in this picture, you see live data, data being migrated, DICOM HL7 being transformed before it reaches to the enterprise system. So, you could easily count 15 or 17 steps for each patient workflow. So, for each patient, you have about 17 different transactions taking place from orders, HL7 transformation, DICOM transformation, marrying DICOM and HL7 to the proper system, so doctors and radiologists can get clean data with no collision to make sure they can read images as fast as possible. And also, the technologist and staff in between, they would have a better time tracking and managing patient to make sure there is no disruption. So, with 17 different transactions, as you can imagine, there is a lot can go wrong, right? And planning. Yeah. So, Sam, essentially, if you multiply those 17 steps per patient by the number of patients you're going to see today, every single 24 hours, you have 17,000 possible missteps that you may need to go back and manually correct if you don't get that transition right in the first place, right? If you have 1,000 patients a day, that's how many steps you're going to need to recount and potentially go through logs and manually correct those situations. So, you mentioned something interesting that I want to go back to, which is right here, which is step number six in our recommendation, establish a vendor-neutral interoperability and middleware layer. Why is that important? Well, in a transition, it's almost inevitable that a vendor will be either becoming less important or eliminated in the process. And it's human nature, right? If you go from one PACS vendor to another, chances are the PACS vendor that's being replaced is going to begrudgingly collaborate and be a part of the process, knowing that they've lost your attention, they've lost your business, but they still need to play ball because patient care is involved. Vendor neutrality is super important. And so, the layer that you mentioned, Sam, is this interoperability and integration layer that you want to be independent from any new vendor or any old vendors, right? So, that gives you the freedom to manage your intramural and your extramural workflows cleanly because you have control over those tools without having to ask permission to this vendor or that vendor or wait for their project manager to be ready, right? You don't want to have all those stars aligning. You want to have control over that. So, tell me about that middleware layer and how you establish that, Sam. Absolutely. So, the middleware layer really plays a crucial role during the transition. As you mentioned, Florian, during the transition, you are going to have to do a lot of stuff. And mainly, one of the major components is data modeling and the structuring your data, meaning, for example, during a transition where you have two different EMRs or two different PAC systems, you need data to be transformed, right? In specific ways, you can store your data on your enterprise imaging systems in a specific way so you can segregate it and identify it properly. You could perhaps do this in all other vendors, but you are really going to run into a lot of complexities and you will be dependent on almost hold hostage to these vendors to transform your data. Whereas the route we decided to go is to have a middleware engine to ingest and transform and distribute the data to other imaging systems. As you see on the right side where it says imaging applications, all these imaging applications, it's important to keep the data clean and clear, make sure you don't have any MRN collisions. Your data is arriving with proper patient identifiers and storing properly. So the middle engine was really our key for success to ingest the data, transform them, transform the data without disturbing our current patient workflow or the newly added entity workflow. Understood. Thank you, Sam. You're welcome. So let's briefly talk about fault tolerance because as you know during a transition, the opportunity for interrupted workflows is there at every step. And so as you establish your middleware layer, it's not just about making sure it's established, it's about making sure it's continuously available during the transition, before the transition, during and after the transition. So this is your design at USC. This is how you're ensuring that you have several layers of availability fault tolerance. Can you tell us a little bit about the architecture you devised there? Absolutely. For USC, the middle layer for us is a backbone of the medical imaging. It's doing a lot of work to make sure our current day-to-day operation goes smoothly and with no any disruption or any interruption in patient care. So for us, it became a very hot topic. How can we make sure this middle layer is always up? And we wanted to ensure maximum uptime. So one of the designs we came up with is we have the middle layer currently in our data center. And as many other hospitals, we have a secondary data center or a fill-over data center where we will deploy another instance of the middle layer or DICOMSYS. And to ensure maximum uptime and optimal high availability, we will be deploying another instance on the cloud. As you are probably aware, cloud deployment is becoming a hot topic right now. We are actually, one of the things we are talking about at USC is starting to utilize the cloud for medical imaging. So this would be one of the designs we will be implementing. Understood. And hopefully we have a few minutes to talk about AI deployment and orchestration in this conversation. I wanted to turn our attention to another aspect of transition, which is the importance of compartmentalization among functions. So let's say you're going through a transition, you're absorbing another health system, they have their own infrastructure, you have your own infrastructure. Here, you've actually architected this not just for fault tolerance, but also for functionality fault tolerance. You've actually segregated migration work from enterprise DICOM modality work list, and you've also segregated the DICOM routing and the ability to bring in outside images as well. So what does that achieve? Is that if, for example, we have an issue with DICOM routing, you've ensured that DICOM modality work list is still available, even though the infrastructure running routing is down for whatever reason. If the fault tolerance didn't work out, you don't have routing going on, but you can still run patients through because your DICOM modality work list engine is still available. And same thing for data migrations. As you know, a migration, especially if you're going to be doing mammography type images in a migration doing SCO to BTO conversions, those are computing resources intensive. They take up a lot of storage, they take up a lot of bandwidth. And so you don't want your current production routing to be impaired by a data migration of, I don't know, 20 terabytes of data coming in from an outside set of images. So I'm going to ask Dmitry to talk a little bit about the compartmentalization and how that serves our customers. Absolutely. Basically, compartmental approach and its equivalent, I would like the analogy with the board design. And it's why we use method to ensure that vessel doesn't sink, right? So even if it suffered damage in one of the area, there are automated damage control, like bilge bomb, or more automated than the big bots, but you have to, you have to, and also you have to test that approach to avoid the design flow. So usually the recipe for disaster, we all know the Titanic stories. First of all, with design flow and human error. So you want to separate those. In IT, it's a similar approach, you want to segmentation and isolation. So make sure you divide the privilege access, role-based network segmentation, like shown here. So we have different type of cluster, you're responsible for different type of workflow. So also, if you talk about the integrity, safety, and redundancy, obviously essential. So it's important to have procedure for certain situations, specifically in case of outage or disaster, to avoid, rely on figuring out as you go, it's not the right approach. So making sure the proper procedure are followed to prevent human error is important as the correct design. In case of comfortalization, it's what we always suggest for our customer. Even if you can run everything on one cluster, it's really important to divide those workflow, make sure that one workflow, like you mentioned, the data migration doesn't affect your production at all. And we have a good blog about it on our website, actually white paper with performance metrics. So if anybody interested, we'll put it there, resources at the end of the, I think in the last slides, right? Yeah, it's in one of our last slides in the presentation. And actually, that's an interesting transition to talk about. We've increasingly started to support our customers through their move to digital pathology, which as you know, can be a conundrum for our customers. The adoption of whole slide imaging type equipment, right? It's costly. So you're going to want to have a return on investment as quickly as possible. The problem is it has a very direct and deep impact on the infrastructure to support it, right? And it impacts that supporting radiology or cardiology operations cannot be supporting whole slide imaging as well. And so we've seen a clear trend among our customers where the adoption of digital pathology, just like the adoption of AI, is causing the IT groups to have to rethink their architecture and think about the kinds of investments they need to be making. I'll give you an example. We have a customer on the East Coast who was PAX customer A, and they were transitioning to PAX customer B, right? B vendor. PAX A required block storage. And this customer of ours made a substantial investment in block storage to the tune of about $4 million. And then realized that by moving to PAX B, this infrastructure that they bought two years ago to expand their utilization of the previous PAX would be obsolete the moment they turned on their new PAX, right? So that's one of the possibilities that you need to think about is you're going to move from vendor A to vendor B, you'd better understand what each one will require infrastructurally. And pathology is one of those situations where we're able to actually do enough due diligence up front to support our customers through a clean transition to digital pathology. Let's briefly talk about AI and some of the challenges that the adoption of AI is having on diagnostic workflows. I'll give you a very simple example that you may or may not have encountered in your clinical practices. But let's say you have a physician reading a CT and the patient is being treated for a possible ICB, intracranial bleed, and the physician reads the images, they read the regular CT slices as they all do, and their conclusion is this is a normal study. The patient is fine. There's no, there's no ICB. They sign the report, move on to the next patient and the next patient. Now there are three patients down and there's an AI notification that comes in that says, wait a minute, patient ABC has an ICB that we detected. Well, how did that happen? The physician decided there was nothing wrong with the patient. The AI decided there was something wrong with the patient, but the AI engine got a different set of images than the radiologist did, right? The ultra thin slices is what was uploaded to the cloud for analysis. And so that poses a problem of workflow orchestration, right? The adoption of AI is inevitable. We have this tsunami of AI coming at us. We all know that. And so you need to think about the transition to a place where you strictly have human physicians looking at images and the augmentation of those physicians with AI, it's going to have some impacts, potentially legal and clinical impact on your ability to practice medicine. And so it's really important. It doesn't mean that the AI is not useful. It is right. It detected an intracranial bleed as small as it was. It should have been addressed, except it wasn't. And so now the physician is going to have to go back, stop the read that they're currently doing, go back two or three patients before, try to get a hold of those ultra thin slices to see what the AI is talking about and validate or invalidate the diagnosis. And so the reason I'm bringing this up is that this is one of those transitions, right? If you're going to adopt AI and everybody is right, it's inevitable. How do you integrate that in your existing clinical workflows? So Sam, can you run us a little bit through what USC goes through for the adoption of AI and simultaneously cloud, right? Because most of the AI that's available out there these days is being made available as a cloud solution. So tell us a little bit about your stance at USC on cloud and AI integration. Absolutely. As you mentioned Florian, AI and cloud computing, it's almost becoming more increasing in every day. And if I recall how many cloud discussions I've been at in the last six months alone, at least maybe over 30 or 40 different discussions about some sort of an AI algorithm solutions that need to be implemented. And the key topic with all of these AI and cloud solutions, one, as you mentioned, many of the AI solutions or algorithms are mostly cloud vendors. And the topic always comes in, how are we going to manage and orchestrate the data? Making sure we're sending the correct data. Most of the AI vendors or algorithms require a lot of data. So getting data from multiple data sources can be very challenging where we are actually designing as an AI orchestration, which the middle layer can be used for it as well to start looking for the data, bring the data from all different systems or perhaps a prefetching and distribute the data to the AI engine and also get things that results back and send things that result back to the downstream imaging system. So that's one of the approaches we are taking with AI integration. Understood. And you mentioned an important aspect of this, which is the middleware layer. One of the reasons it's important is that you want an engine that can translate between protocols. As you know, some of the newest technology, as Dimitri mentioned earlier, the newest vendors, they tend to use the newest protocols like DICOM Web, like FHIR, and they may actually produce results in different types of formats. There's no cookie cutter when it comes to the nature of results coming back from AI. And so if you have an AI vendor that's going to send you or expect to receive data via KEDO-RS and WADO-RS, which is DICOM Web, and then send us back a result via STO-RS, which is also part of the DICOM Web protocol, but all the input is strictly DICOM, well, you need an engine that can translate between those or you're not going to have a smooth workflow orchestration possible. So we're getting close to 45 minutes into our presentation. We have another five minutes. And I'd like to use that time, if Dimitri would indulge us, can you please run us a little bit through the real-time situational awareness step? The real-time situational awareness, by that we mean, what do you do to monitor when you're doing these changes? You still want to keep an eye on all the metrics. You need to be able to monitor before, during, and after the transition to make sure that the steps that you are taking, the rightful step that you are taking is not having a performance impact on your current patient care. So Dimitri, how do we do that? Absolutely. I want to go back to number six when we talk about the middle layer again, vendor-neutral interoperability and middleware layer. It's not just important during the transition. It's really, really important to have that before the transition takes place. So as a matter of fact, most of the organizations, it's in a constant state of transitions and some system, it's always being updated, replaced, upgraded. So when you're planning transition in any kind, it's very important to plan to install middle layer before starting any kind of upgrade as a step. So after basically that layer is established, it's critical to monitor and collect statistics before they upgrade, during, and after. So benchmarking, it's really, again, this data, very important to monitor. First of all, how the transition, when transition takes place, what, if it's out, it changed the workload. So middleware can dramatically improve receiving and transfer speed, for example, but can introduce queuing delay to legacy packs and VNA system if they cannot keep up. So if middleware didn't exist before, you simply wouldn't know that, you wouldn't have that statistic, you don't know what's going on. So it's really important to compare so you can really measure the result with the statistical data and benchmarking before and after. And as an example, some of the current system, some of the old system, they didn't have the today's technology, like 10 gigabyte network, like SSD disk speed to test with. So you want to make sure that the vendor you introduced, they take advantage, first of all, they take advantage of this because those systems were not testing against such infrastructure before. So the vendor must comply with the requirement to, basically, that requirement to test with the periodical test with the latest technology. So if they don't do that, that burden falling on the customer. And as a result, we have the good blog about this as well and that on our website. And it's going to be in the last slide as the resources. Great, thank you. Thank you, Clarence. I think there's a clear example of what you just mentioned. We have a very large customer that runs dozens and dozens of hospitals across the US and they have a chosen VNA vendor. And they didn't previously have a middleware layer in place and all of their remote hospitals would be expected to send all their images and those images count in the millions and millions, would go into the VNA, except the VNA was not capable of multithreading or, you know, in any meaningful way, absorbing the sheer number of images coming at it on a daily basis. And so that's on the receiving end, right? So the middleware layer can ensure that all of these remote hospitals can effectively receive the send the images in to the VNA centrally. But then you may have a bottleneck effect if you're not examining the rate at which your end system, the VNA or the PAX, is able to absorb that traffic. And so our role for that large customer is to literally receive all those images, hold on to them until we've spoon fed them to the VNA so that it can be absorbed correctly. So my alarm just rudely woke me up to the fact that it's 12.45 Central Time, so we'd like to open up this conversation first, Sam, thank you for preparing these visuals. They are very telling of the amount of work that it takes to go through a transition. Dimitri, thank you for your insights. I'd like to open up the conversation to Q&A, and let's see what kind of questions we have. The first question, let me read it for the audience. Have you encountered a transition mission where outside DICOM change was not considered? How have you been successful at correcting this and properly normalizing outside data that was not documented or done correctly? Thank you, David, for the question. So who would like to take that question? Sam, do you have some thoughts on this? Sure, absolutely. Part of the transition and that comes back to doing the proper discovery, analysis, and assessment of the workflows, keeping in mind outside imaging is part of it. And just think outside images, even without a transition, can be difficult because with outside images, you have different patient identifiers, you have different data types that may or may not store on your current imaging or PACS system. So one of the ways we are handling this, we use one of the image exit change solutions. For example, AMBRA, to ingest outside images, attach them to an order, normalize the data, and route it to the imaging system. So that's one of the main key components you would have to consider during a transition. We actually manage this a little bit differently through the middle layer because we have a different EMR system, we have a different PACS system where images need to land, too. So we essentially throw the middle layer to make sure we normalize the data, throw the EMPI and patient matching to give it the proper identifiers before sending them to the enterprise PACS system. I would like to add that data normalization work will become more and more prominent for our customer. So it's planned and we have the, as the data coming in, we perform data normalization to make sure all the procedures are in place. Also, we have an engine for the ad-hoc normalization, as the ad-hoc normalization, we have an engine for the ad-hoc normalization, as the ad-hoc normalization. So we have an engine for the ad-hoc normalization, we have an engine for the ad-hoc normalization, we have an engine for the ad-hoc normalization, we have an engine for the ad-hoc normalization, we have an engine for the ad-hoc normalization, as the new modality comes in. So we have to do that. That's part of the game, I would say. That's what the middle layer is for. So we encourage that. We come through this a lot, I would say, as a vendor. Thank you, Dmitry. One other question that's come up is really, it goes back to item number four in the top 10 due diligence recommendations, and that is knowledge transfer. So, for example, Sam, when USC acquired Arcadia Hospital in Southern California, for example, I'm sure there was a whole world of custom interfaces, things that were built up over time. And as you know, people come and go, right? Leadership comes and goes. A PACS administrator that worked there for 15 years has transitioned out and went away somewhere else and didn't do a particularly good job of documenting all the custom interfaces they built over the years. And so you at USC now have inherited this brand new infrastructure, right? Even though it's an old one, it's new to you. How do you go through that discovery process? Because not everybody has a proper knowledge transfer protocol in place when there's change management at the people level, right? Absolutely. That's one thing I have seen in so many transitions, M&As and whatnot. I'll give you actually some of the examples I have personally run into. You run into unstandard workflows, custom workflows, like, for example, where systems need to integrate with each other via HL7 protocols. You will see, like, custom scripts for transferring data back and forth, paper workflow, a lot of non-standard, non-electronic workflows. So the way to make sure you are accounting for all of this is really doing very thorough assessment and discovery, walk into the department, talk to the technologist, and how they do their workflow from A to Z. Just ask them, like, walk me through your day from A to Z. And documenting and tracking everything so you can make sure during the transition you are aware of all the different dependencies and all the different data points and components of the workflow and the enterprise. Yeah. We've seen that a lot as vendors as well, right? I'll give you the example of having to unplug a server because nobody knew what it did. You know, it's one of those situations. I mean, you can plan as much as you can, and you will encounter some wildcard elements that you never anticipated. And so you do need to roll with the punches. Another thing that comes up that I think we should probably talk about is when you're transitioning between vendors, how do you ensure that, you know, because you're essentially doing almost like a heart transplant, right? You have a situation A, and you're transitioning to situation B. You introduce an interesting concept that I hadn't really thought about because I'm on the vendor side, right? And that is the concept of throwaway work that will inevitably occur in those transitions. How do you minimize the amount of throwaway work that you do? And it's not just about the planning, right? So I would love to hear how USC manages this process and understanding that you need to invest in some throwaway work. How do you decide what's going to be permanent or not? Absolutely. With every transition, I've almost been through, I've been in about almost 10 different transitions in my life with so many different organizations. And with each transition, you are going to have some sort of an interim state. With each interim state, there will be some throwaway work. Because as I mentioned, you are going to be dealing with different EMRs or multiple or two, three or more EMR and PAC systems. And you are going to have to build some interfaces on the middleware to manage data normalization, patient matching, multiple patient identifiers, dual MRN, et cetera. So in order to have less throwaway work, that again comes back to understanding your current hospital workflow and other new hospital or new system you're adding or retiring workflow. So the better analysis, discovery and digging is going to result in less throwaway work and less financial impact. Very well. Thank you for your insights, Sam. This is invaluable. I would like to ask if you have any closing comments that you'd like to add, things that we may not have had the time to go into in this conversation. Dimitri, same from your end. Any closing remarks? The one thing I mentioned is the importance of the transition committee. One of the main components or one of the main items for the transition committee that I have seen over the years is taking care of governance and planning. And as we have probably discussed sort of this session, planning, planning, planning for so many scenarios, unknown. Unknown could be a demerger, a sudden vendor that will sunset their solution or retires their solution during the transition. If you are hiring outside company to help you with transition and all of a sudden they are not performing or lack of resources. So planning, discovery and analysis and establishing proper representation in the transition committee is very important from all over the enterprise. Certainly. Very different points of view, right? Right. The IT person may not think about an arcane clinical aspect that needs to be thought of. And so that collaboration on the transition committee is really key. I see another question came through and that will probably constitute the last questions that we have time to address here. The question is, how do you handle the integration and management of non-DICOM images, proprietary data formats or ologies, for example, pathology, ophthalmology that might not fully support the DICOM standard? And what solutions do you suggest investigating to ensure compatibility and seamless access across our clinical workflows? So this may be a question that should be addressed by Dimitri initially, because that's a highly technical question, right? We encounter both schedule-based and unscheduled, you know, encounter-based workflows that utilize visible light imaging, such as, you know, endoscopy for videos, you know, pictures for dermatology or wound care. We clearly encounter non-DICOM all the time, right? And in our world, which is the DICOM world, really, you know, ideally, all of these objects are normalized to become part of the DICOM standard. And so we pretty routinely take non-DICOM input, turn it into DICOM, and marry it with the right metadata, right? That is the real challenge here. It's not the transformation of a non-DICOM object into DICOM. It's the ability to have the right access to the source of truth when it comes to this particular patient's MRN, date of birth, last name, first name. And so part of the way for us to solve this is to utilize the FHIR standard. And again, not all EHRs are FHIR compatible, but the ability to use a very simple user interface on a mobile device, like an iPhone or an iPad, and do a query on the EHR would allow you to very quickly and efficiently marry the right MRN with that picture that you just took, right, of a burn patient or a wound care or, you know, a dermatology or even ophthalmology image. Now, we're finding that ophthalmology and pathology are increasingly DICOM conformant. But, you know, Dimitri, do you have any thoughts on how else... Yeah, but supporting the simple third-party images is something that's available with RESTful API as needed. But again, as you mentioned, patient matching and matching to the correct record and correlate with the proper study and pull that information from the EMR and integrate with your imaging health record, it is something that middle layer has to be capable to do as well. Even if some of the images are able to, like you mentioned, translate to DICOM or not, you still store the source of truth available with the latest protocols available, RESTful API, and even DICOM Web have some of the support of the non-DICOM stuff. So, this is in case of, as mentioned, pathology and ophthalmology, that's what we have increasing number of customers using that for both ologies. Thank you, Dimitri. Thank you. That was a good... That was a really good question and it's always come up as a part of any transition. So, we have another few seconds left in our hour with our audience. So, first, I'd like to thank everyone for participating, for your thoughtful questions, and for your contributions, Sam and Dimitri. Thank you so much. Everyone. Thank you. Have a great rest of your day.

change management

healthcare transitions

clinical integrity

IT vendor changes

data interoperability

patient care

system integration

digital pathology

AI in healthcare

operational disruptions