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

Today on This Week Health.

The more that you can build automatable infrastructure to be able to handle the flexible demands that are coming at you, the better off your systems are gonna be and the happier users will be.

Thanks for joining us. This is Keynote a This Week Health Conference show. My name is Bill Russell. I'm a former CIO for a 16 hospital system and creator of This Week Health, a set of channels dedicated to keeping health IT staff current and engaged. For five years now, we have been making podcasts to amplify great thinking to propel healthcare forward. Special thanks to our keynote show partners for choosing to invest in our mission to develop the next generation of health leaders. Now onto 📍 our show.

All right. Today we have a solution showcase. We're with Canon Medical and we have Larry Sitka, who is the Chief Strategy and Information Officer, VP and Tim Dawson, chief Technology Officer with Canon medical. And we're gonna talk about setting the groundwork for an enterprise PACS replacement and consolidation. Gentlemen, welcome to the. . Thank you. Thanks

for having us.

Yeah, I'm, I'm looking forward to the conversation. We just had a webinar about an hour ago, and there was three CIOs. We were talking about priorities for 2023 and I asked them about, specifically, I asked 'em about PACS, but I asked him about pacs, but I also asked them about application rationalization. And they said, application rationalization isn't a strategy anymore. It's a way of. Especially within healthcare, we have so many systems strewn about, and then I ask them specifically about enterprise PAC strategies, and it's the first time I heard three CIOs essentially say we have it as an objective to get to a single imaging solution enterprise wide pediatric through adult radiology, through cardiology. And so I, I I think this is a pretty timely conversation. Is that what you're hearing in the industry as well, Larry? Yeah, yeah,

that's, that's absolutely spot on. And I think it's economics, right, that are actually driving.

In addition, I think the new demands for patient access and patient interoperability nowadays, right to, if you have a report that's generated, you have to get it to the patient right away. You can't wait for the physician to even read it first and then introduce it to 'em, which is a controversial thing, right?

Some patients want that to happen. Some patients want their doctor to deliver the message, but you're spot on. Correct. What's driving it is the economics, right? You can't afford the service line thought process anymore. You can't buy 10 applications that kind of do the same thing for different ologies. You have to buy one application that does everything and then collapses infrastructure collapses m and s contracts, and brings it all.

it's interesting in our earlier conversation though because we have a couple other things that happened in the past couple of weeks. We had a tech debt issue at Southwest Airlines, which we'll just affectionately call the Southwest Airlines meltdown of 2022. But you were telling me, and I wasn't really familiar with this, the amount of tech debt that's just inherent in the platform that is most PAC systems in healthcare organiz.

that's absolutely correct. I've actually had the pleasure of building the DCOM stack myself three times, once late eighties, once probably mid nineties, and then once around 97. And every organization starts from very similar libraries. All that were created from an underlying, there were two groups that came out when the DCOM standard first. The three standard that is, there were two groups that came out. One from Send and one from Mallinckrodt. And then each of the organizations built upon that, whether it was a, Like a toolkit library or even there's even a Java based implementation one right called DCM Fortune that came out in about 2000.

It was donated basically from a Tianni spirits, right. They donated it and it started. A lot of organizations have built upon that, but you're correct in that if you look at, you can always tell it and it's, it's amazing how I can actually go into another. For example, I was just in Australia and I looked at a trace from a PACS company, right, that we were trying to diagnose some problems.

I could read. and I could read it because I knew it was using the same underlying finance statement sheets. So that tech deck is really hurting us. It's time to take a step back and say, look, maybe, maybe that IBM selector typewriter that I got through college isn't gonna work anymore, right? Maybe it's time for us to actually bring something new.

Leverage the same component on the underlying, but actually on the, on the top end based application. Start to leverage microservices, right? Start to leverage Kubernetes, things that, that actually can bring us forward a with scale. And again, back to the economics thing, right? It's the only way to run this stuff.

wanna join in there? Yeah. In addition to, and I think Kubernetes and, and those are fantastic underpinnings. And then in between, in the interop using newer architectures and newer APIs like DICOM Web are really fundamentally changing how how the the systems are deployed and how they, how they work together and you can provide much better IT management capabilities, much better security by using web-based protocols that IT systems and, and IT administrators understand.

There're not a lot of sites that have deployed a DICOM in a secure manner. Most of them have just kind of just. Gotten the bare minimum working and left it alone. And when you switch to web-based protocols, they all understand how to put htp s certificates and, and all of that to to encrypt the traffic.

And to to make sure that you don't have to copy dotcom to every workstation. All of those sorts of things as well make it makes a huge difference.

So security and that, that's the path I wanted to go down. So somebody's listening to this going look at our health system. We just did 10,000 images today. We had no problems. It still works, it's still function, it's but essentially what I hear you saying is 1980s foundation on that thing. I, I mean, it could look like a Porsche on the top, but underneath it's still a dodge. Well, I mean, not a Dodge Tart, I mean it's, it was advanced in 1988, but it's, it's not advanced in 2010.

So security is one of those things. What are some of the other things that people need to be thinking about if they're thinking, Hey, look, we're fine. It worked today, it'll work tomorrow again.

I think pathway to cloud right in, in terms of. Every solution out there today typically focuses on cifs, NFS based storage and storage mounts. They all focus on their own little caches right? So if you buy a PACS, that PACs will have its own cache Rarely can they directly pull from a VNA They can pull, but then they'll throw away the SLA. So the only way they generate their SLA is to actually create their own cache. What we're saying is to prove this out, the viewing based applications that you have should be able to pull from a centralized, independent DNA in real time using components like Tim was describing, right?

Like DICOM web. Now you can keep up with those transactional speeds. You have one copy of the data so you don't have synchronization. issues It limits the security exposure, right of the information that's available. And you can build on a zero trust architecture inside of foundation of all those applications.

Yeah. You mentioned speed and a lot of times when we hear thing, we hear DICOM web, we hear web and we think latency stateless protocols and all those things. I mean those, that's when we hear web, that's what we and we think that's gonna be slower than what we have today, which is, I mean, in most cases, proprietary database, local cash and all those kinds of things.

But in our conversation, you guys were really helping me to see that DICOM Web. really represents the, the next step for this. And before, before I have you answer one of the conversations I had just this morning with somebody about this concept of AI and where AI is going. And one of the things is we've seen AI and machine learning really take off. In the imaging space. And we also have this incredible worker shortage. And the, the person was essentially saying to me, I think this is the year we see clinicians come to us and say, we need machines to help. But if we try to layer in that technology on the 88 Dodge Dart Foundation, it's, it's not gonna be able to keep up, is it?

Yeah. Larry likes to talk about the next thousand users, right? Or the next million users. It's, it's like one AI bot can seem to an infrastructure like a thousand users because it's just vacuuming up data like crazy and what I tend to look at it is the, the DICOM web doesn't mean it has to run in a web browser, right? You have a phone and use a lot of apps on your phones. The apps on your phone doesn't use local storage and proprietary protocols. It uses web protocols to get the data from the servers. It's just a better PACaged version rather than loading up a web browser and trying to think around on something, using a web browser on your phone, you run an app. Similar. AI applications and PACS viewers can use and they should be, and that's what we do. Use the web-based protocols in order to be able to pull the data down just in time to be able to grab not all of the images, but grab the metadata first, decide what you want, and then grab the data that you need or grab it in the priority that you need it so that the radiologist get a great time to first image, or that the AI application only grabs the images that it needs.

I. All of the images in the study. I mean, that's really kind of the critical capability behind that and we'll really dramatically accelerate that. And in addition, again, having web-based protocols are much better for transporting large volumes of data rather than a very chatty protocol that we've that we've all known over. Over.

Yeah. To add onto that, that's what I was gonna say is di tcp ip based traditional.com read data on a sock. it's really chatty and it breaks down every single PACet into very small chunks. Right? In fact, I was working with a PAC that can only send AK. If you look at a traditional ct, you got a half meg image per slice and you got 10,000 of those to send.

So you can see how long it takes. There's no real way to parallelize the thick, what Tim was describing, right? The web-based protocol. You cane that information and bring it back in parallel or bring back very specif. What you want inside of it, which is where these, these AI applications, but I think it goes a bit further.

There isn't enough land or land bandwidth, nor is there the capacity to be able to, and like Tim was saying, I'll just, I'll throw a real world example. We have a VNA service that installed at one of our sites. That site does about 15 to 17,000. I was looking this morning, studies per day.

And that's net new across 400 radiologists. Okay? They have one AI algorithm that runs at 2:00 AM to 3:00 AM every night. It pulls on average 20,000 studies in one hour. Can you imagine when we get 50 of these? And Bill, this is the problem is. Traditional PAC solutions were not built to share data.

They were built to consume it and display it, period. Done. When you start trying to, and proof of this, try and migrate away from a PACS, when you do, not only does it cost you a bunch of money to migrate away, but it could, it's gonna take you months or years to move data out of that solution.

and that's where you can actually see that they weren't built, they weren't created to scale to the the flavor of what AI's data demands. I mean, humans today, they store things, they move things, they find things. They go home at night, they take lunch breaks, and they may do one or two queries a minute max.

You have ai. That's just data. As soon as an AI application is done, it may pass information to other AI applications of which they're gonna come back and consume the data. So our philosophy at Cannon is to take the algorithm and move the algorithm to sit directly on top the data. So now that 80% transport time that you typically see with, with applications by having to send can pretty much either shrink them dramatically or even what we're hoping for is it goes away with direct file access, right? Through keto requests and weight over trees.

a lot of this is the architecture. Now, you could throw up a really complex architecture slide right now but if you were to simplify it and not throw up the really complex architecture slide, what makes this possible from an architecture perspective?

Starting over. Starting over. That's the biggest thing that I can. Interesting. Yeah. It, it gives us an opportunity to say, That was technology before. Here we are now. What can we create within the realm now that allows us to scale forward and knowing that this solution at some point in time will move to cloud, right?

Everything will vote to cloud eventually, as soon as we figure out some of the latency issues. By being able to do that and using and leveraging this new technology and starting over, but layering it on top, a service that can feed data that quickly. that's the secret sauce that I, that I see for us in particular. Tim, anything to add?

Yeah, I mean, I, I, I think you nailed it right around the head, which is when you design something from scratch to utilize new capabilities that are provided in the internet age as opposed to provided in the land age. You make sure that you, you actually have the ability to scale. And, we can have built in and learned a lot from the people that have come before us in building out Google and Facebook and all of these big sites.

As Larry mentioned, Kubernetes before, and capabilities like that enable the sort of flexible autoscale demand. The secure storage, all of the underlying capabilities that these systems and really the automation, IT automation is really kind of a killer app for this because our customers can't afford to hire all of the IT people that they need.

Nobody can it's impossible to find everybody that you need. And so the more that you can build automatable infrastructure to be able to handle the flexible demands that are coming at you, the better off your systems are gonna be and the happier users will be.

I think that's also our different approach. We're approaching AI from the enterprise. We're not approaching it from a single vendor with, with 10 AI algorithms. Right. Our expectation is to create a, to have a. That allows us to run our algorithms plus other algorithms. And therefore take the burden off the site.

So the sites today, they'll go out and they'll sign individual contracts. With individual AI companies, that's not sustainable, right? If you have 50 AI companies, you can't go do 50 contracts. Why not just create an enterprise based platform that allows you to run the Cator container based algorithm?

On a Docker platform, talking natively to the dna, and then being able to do this in and out of, have different AI-based algorithms. Now you don't have to go sign a new msa. Supportability is all inside a one. Security is inside a one. And then most importantly, if I don't like an algorithm and I'm not using it, I can unload it. I don't need it. I can go get.

Yeah. So I, I want to go down the path. I, I mean, I've got a lot of things here. I've got security, I got performance, essentially we're talking about going from Dodge Dart to Tesla with the big screen and all those other things. We're talking about, we're talking about a platform.

We're talking about something different. We're moving the AI and, and those things directly to the data instead of moving the data to the AI platform. I mean, there's a lot of things you guys have. All right. You convinced me I'm ready to move. What does that look like? I mean, I have all these disparate PACS systems.

and I already have a V N A or something to that effect, and, and you're telling me, Hey, you should start over cuz it's a new architecture. I assume I'm putting something in there and moving our existing images over. You've done this for a bunch of clients. Give us an idea of what this looks like and, and then we'll talk about what some of the outcomes are that they've experie.

First message I have in recommendation is don't try and boil the ocean. Right? Start out, you're, you're building your house, and when you build your house, you have to build it on a very strong rebar, cement concrete foundation. So the first place to start data governance, focus on quality, focus on normalization of information that comes into the solution.

And then focus on centralization of it. Once you have that started and established, find what I'll say is the biggest roi. Typically, those big ROIs are radiology and cardiology. Bring those organizations on board with, the expectation is you buy a terabyte now. You never repurchase that same terabyte again in the future.

So this is an infrastructure plate. Stop writing those checks that you're writing to those storage companies, right? You're gonna write one, write it, and be done with it. Never again. Never more. In addition, on the migration side, right. If you look at historically, it's kind of getting humorous, to be honest.

If you look at it historically in the eighties you bought a PACS, you paid to put data. In the nineties, you bought a PACS, you bought a migration to put data in it. 2000, 2010, you bought a PACS, you put data in it. Here we are 2023 and we're looking at this PACS replacement market again to replace with another vendor that's got the same code basis.

This is crazy. Right? Let's change the paradigm here. Let's say if I'm gonna do this, it's the last time I'm gonna pay for the storage and it's the last time that I'm gonna pay for the migration cost going forward. That's a real savings, right? C f o from these organizations can actually go in and see the checks that they've been.

And see the m and s contracts that they've been writing. Then you start app consolidation, right? So you start bringing radiology, you bring cardiology and you bring endoscopy and you bring in ophthalmology. You start to bring in digital path. These things that every single time I go out and buy, I have an application.

I have infrastructure and I have storage. I have an application, I have infrastructure, and I have storage for every service line. Let's collapse that infrastructure into a centralization model. And then let's start either reduce the cost of those applications on their m and s contracts, or just get rid of them. If I now have an enterprise viewer, that allows me to see it all.

Talk a little bit about not specific client success stories, but clients that have migrated. What does the process look like? How long does it take? What are some things that maybe surprised people in the, in the process? And what were some of the outcomes?

I'm sure Larry will add on to this, but you know, one of the things that that you do is you start by, as Larry said, you don't boil the ocean, right? You, you have to migrate one system at a time. The surprising thing is how many systems that you find, you start, you expect, and the customer signs the contract with thinking that they have two or three or four PACS if they need to migrate. And then as they dig in, find, oh, here's a place where there are a bunch of images. Here's another PAC, here's another.

And then you deal with acquisitions and mergers and and strategic relationships and things like that. And in some of our customers, the go-live never stop. We're always having a a new one of a new system that's being brought onto the central archive. And this happens multiple times a year that we're, we're bringing on a, a new site with all of the new data is being brought in and managed that way.

And that is that is achieving a huge economy of. For customers to be able to reduce all of the number of systems that they manage, and as Larry said, to reduce the number of m ands contracts that they're paying

I'll add on to what Tim was talking about. I'm thinking very specifically about one of our sites with, I've maybe in my career, done a hundred plus.

Migrations I know 60 of those specifically I did on my own inside of that, I know how long some of these migrations take. One of the things that our solution just, I had, had to, had to wipe my eyes was the speed and performance. And as Tim was saying, there were four primary PAC systems that, that they were decommissioning and that's how they built an ROI to pay for it.

We're over 30. PAC systems, those GoLive, they're not ending. There's a new GoLive about every three months right at the site, which is great because they're now created, they're offering up a digital transformation offering, right? For outside organizations it comes with apac, comes with a v a, it comes with epic, comes with image share, exchange, et cetera.

But what I will tell you is that the infrastructure requirements to do this migration initially, We're very small. There was, there was roughly 16 VMs total inside of those VMs. We migrated 17 million studies in 54 days, peaking at 35 terabytes in a single night.

yeah, that's,

that's, that's kinda

staggering. It, it,

I still get like, holy, I've never seen anything in my entire career like that. I've been around a long time.

so that kind of it's interesting. I mean, when you. Put that kind of throughput in I guess you start to see where the rest of the architecture breaks down around it.

You're spot on. Correct. And that's why I say APAC system as we stay set today, cannot stand up to the data demands of ai, period. It just can't, they weren't built to send data. They're built to ingest and display and that's it An enterprise imaging solution is, is built to function at the enterprise level, right?

It's designed to scale at all components. In and outcome and to service this new user called ai, that's what we're gonna, we're gonna have to run at those rates. I believe so for this site, I think being able to serve up half a million studies in a single night is going to be an expectation that we're going to see for AI applications.

I think one of the things, areas where you were going, bill, as. Is when the software and the architecture can handle those volumes, other areas of the IT infrastructure end up being your bottlenecks. And you have to find ways to route around them. So if you over overflow a load balancer, Okay. What's a new strategy of getting at the data, of pulling the data out and pulling it around the load balancer so that the load balancer isn't a bottleneck for you? Making sure that you are built on top of a storage infrastructure that can deliver the throughput that you need in order to satisfy what the application can scale to. Those are all critical parts that we have helped customers work through. and make sure that we find the right mix to be able to satisfy the performance capabilities that our system can provide.

it's, it's really interesting. We started this talking about the potential to do consolidation. We've talked about performance, we've talked about security, and those are obviously critical, top of mind kind of. Talk about the number of contracts we're able to consolidate as a result of this. It sounds like in some of these, you're, you're able to find contracts. , it sounds like they just keep popping up as, as you, as you do these projects.

That's what's happening effectively, specifically here in the us And you'll see a lot of these larger providers, they're out acquiring smaller organizations, so it fits right into their acquisition. Because one of the biggest costs with an acquisition is the IT transformation, right?

How do you bring all that data that sits over there in that format into a viewable and shareable environment for the entire organization? And that's what we're able to do. That's what we're able to bring.

Fantastic. Well, gentlemen, I want to thank you for your time. It's really exciting. I think this will be definitely be a year where a lot of people are looking at these kinds of projects, especially around enterprise imaging. You have the AI demands, you have the security demands coming in, and you also have the financial pressure. Seems like almost the perfect storm is happening in this area to create this demand. Canon Medical, they can reach out to you guys. Where can they get more information? So

I would suggest reaching out either just through the website or we have several sales executives that can assist with the initial relationship communications. And then of course any of the, we attend hymns, we attend sim, we attend Arsen A we attend five, we attend chime Reach out to us specifically from the website or even if you, you wanna contact me directly through LinkedIn and then we can switch over and then I can get you a connection off to one of the sales executives.

Fantastic. Appreciate that. So Larry Sitka and Tim Dawson, Canon Medical. Want to thank for your time and thanks for sharing your experience with the community. Really appreciate it. 📍 Let's go.

I love the chance to have these conversations. If I were a CIO today, I would have every team member listen to a show like this one. It's conference level value every week. If you wanna support This Week Health, tell someone about our channels. We have three This Week Health conference, This Week Health Newsroom and This Week Health Community. Check them out today. You can find them wherever you listen to podcasts. Apple, Google, Overcast, Spotify, Stitcher, you get the picture. We are everywhere. We wanna thank our keynote partners 📍 who are investing in our mission to develop the next generation of health leaders. Thanks for listening. That's all for now. 📍