Unbridling Radiology Workflow Strategies With Cloud PACS and Dictation Migration

At the Society for Imaging Informatics in Medicine (SIIM) 2026 Annual Meeting (June 10-12, 2026), Ramandeep Singh, MD, MBBS, Associate Chief Health Information Officer and Director of Imaging Informatics, University of Iowa HealthCare presented, "Unbridling Radiology Workflow Strategies With Cloud PACS And Dictation Migration: Strategies For Efficiency Amidst Declining Reimbursements" along with Matthew Guillen, CIIP, Senior Systems Administrator, and Brian Wiese, Senior Systems Administrator.

If you have a SIIM26 registration, you can view the recorded presentation via Virtual Desktop / On Demand until July 12, 2026. For your convenience, here is a transcript of Dr. Singh's presentation, which was originally presented June 10, 2026:

Presentation:

"Hello. Hello, everybody. And thank you for joining this session. I'm Ramandeep [Ramandeep Singh, MD, MBBS], I'm from University of Iowa. I have with me, Matt [Matthew Guillen, CIIP] and Brian [Brian Wiese] , who are our system administrators, in the radiologist and body section. What we're going to be talking about today is something that sometimes worries, sometimes concerns is a rising need, is a rising demand.

We have an equilibrium at this point that is a little skewed in terms of the reimbursements and the need for the radiologist. So we went through this whole process of RFP to go live and we're going to play that as an analogy to how we navigated it and we got some lessons learned from other institutions that we're going to just share, and our hope is that that's going to help our fellow colleagues navigate this process. And if they are in the middle of the process, we can just share some of the experiences on that. I don't want to make this as a project manager presentation, but it might seem a little bit, but we're going to nail it in the sense that, what strategies are we going to deploy.

So if we talk about the radiology workforce, so there is an attrition that is going on annually, and the attrition rate has doubled from 1% to 2.5%. The radiology workflow overall is growing, still, but it's lagging behind how much is the demand going up. The other part of the problem on the workforce side is that a lot of practices which were smaller, they're getting consolidated and there isn't a whole lot of growth in the practices that are new. So this is a time of sort of, shortage and growth that's not matching the growth in volume.

On the other side are declining Medicare reimbursements. So if you adjust for inflation, the physician payment is down by almost 30% since 2001. And then if you adjust for the MR and CT reimbursement, just as examples, they are down by more than 70%, or close to 70%, calculating that, adjusting for the inflation.

So there is this declining reimbursement going on. What it means is that we are working more, for less. And then the other complexity driver is the demographic engine, what it means is that the population in general in the United States is aging and moving towards a majority of population that's going to be 65+ by 2034. Then about 30% roughly from the literature, the number is that the imaging studies are consumed by patients who are above 65 years of age. And then this is growing in the same trajectory and we are going to end up with an aging population that has more complexity of exams, a lot of comorbidity factors.

And as an anecdotal example, it's very easy to read a CT for an abdominal pain in a 20-year old compared to a 70-year old who would have a multitude of other follow-ups and problems that are coming into play. So the acuity is also rising with age and not only that, the complexity is rising.  And then as we look at the historical trend, starting off with xray results, single photon exams, really the modality mix is shifting towards CT/MR, PET/CT and our PET/MRI and each read is taking longer than it used to take in the past.

So now looking at the other dimension, the job market is really hot and hot in terms of both onsite and remote. So onsite and remote is like 60/40, and it's almost 50%, and there are a lot of teleradiology jobs out there. A lot of jobs in the private practice group, more so than the academics.
And one of the literature time points is since 2023, about 50% of the positions are still unfilled. There are three jobs per resident. So the job market is growing and it's growing fast. So what it means for us, radiologists, is that we are in a shortage equilibrium. We have high volume, we have low RVUs and our worklists in some organizations are like forever not clearing. PACS queues get saturated and the dictation system, reports are getting shorter and shorter.

So how are some of the systems across the nation adapting? There's called workless triage that we get to the acute exams quickly, but the outpatient studies sort of linger on the queue for long. And it's not unusual that you pick up a CT Chest routine exam and that's an outpatient scan three days back, the patient has a PE, right? So that's a problem for the organization. And then sometimes this creeps into modality or even the CPT code avoidance for some of the practices, you go for the higher RVU, easier exams rather than the low RVU, complex studies to read preferentially. In the layman terms we call it as “cherry-picking”, but that creeps into the practice and the reports get compressed and shorter and sometimes you put in those macros, which may not be put in that clinical setting. All of this is also contributing to the radiologist burnout and people are retiring early, taking lesser calls, taking shorter shifts, pay per click and so on.

So in this whole storm, and I put in the tornado here because we are from Iowa, which is the tornado belt of the country, this is a perfect storm because the volume is high, the complexity is high, you're on a verge of burnout and there are pertinent staff shortages and the reimbursement is low.

So it's simply not possible to get more people to work to solve this problem, you need a better system. In our institution, as an example, we had a system which was a 20 years old PACS. We revamped our servers in 2015 and they were pending for another revamp in 2020, somewhere close to COVID and COVID screwed things down for us. So it slowed and we were not able to get to the point that we updated our servers and there were over 35 servers in the system. Our worklists were EMR driven. They were EMR driven ever since EMR came to the organization. And then because we had a system where the dictation and the PACS were rolled into one, although it gave us the advantage of hyperlinks that you can click in the report and the series and the image section it takes to the image, it had some redundancies, because the system was more prone to crashes.

As an example, we had this top three people who submit the most crashes will get coffee and we will present that at every faculty meeting and there would be mostly residents and that was not a good precedent, because there's a lot of crashes happening and people are frustrated and there would be sometimes exams like CT Angio which is like 4,000 images. I'll click the study and I'll go for a cup of coffee and come back and the study is now loaded. So there were really bad examples in the system.

And then there was this pressure because we kept on growing and this is very common with most organizations that we keep growing, we keep adding more sites and with those more sites comes more heterogeneity. You want to have one system for all, but we each have their own system. And then we had almost 1 PB (petabyte) of storage and data that we had and we were projecting our volumes and this was also for the part of the RFP process, which we're going to talk next, as to how the volumes are going to be continually increasing. And we grew about 12% in like three years.

So why Cloud PACS? Why did we go in that direction? Why not just upgrade the servers? Why not just go for a vendor which is like a hybrid solution, like you have some onsite and some cloud solutions. The first thing we wanted as an organization, because we have a lot of rural healthcare initiative going on. We took over 70+ clinics up lately and there's an unmet need in the state of Iowa. We wanted a scalable solution, a solution that we can just deploy enterprise wide as we continually grow. And then we wanted remote RADs, to have the same capability as the onsite RADs, that we are on the forefront of AI innovation and then we can deploy some of the solutions that are scalable in the cloud. We wanted to lower our IT team burden and they were really burned out, a burnout of IT that nobody talks about and we wanted enterprise level connectivity.

What we envision and what we all encounter in our mind is what sort of a system do we want? We want a unified image access, right? We want faster workflow. We want AI to help us with that dictation and also if they can help with some of the triaging of the exams, very basic needs, 85% of the pyramid at the bottom is what the radiologists need is a better workflow and the rest 15% comes, you get detection and other systems in place.. We wanted interoperability across the enterprise and we are also moving in that direction with other sites to be able to do more across the state. We wanted cloud resilience and something that we can analyze, we can continuously optimize. We have more hands on to work on.

The way I think of when went through this process is the game of chess. You have the King's Pawn opening, you have the Queen's Pawn opening, you have the Trompowsky Attack, and those are sort of our RFPs. You open with that. Then there is a middle game where all the action happens. You take some pieces, you have the candidate move, developer moves, and so on and you are going through the server build, the interface linking, the routers talking and then we go through the training and the test. And then there's an end game, which is the time point of go live.

So strategic planning just like in chess is important. And some games may go longer, some may go shorter. The only difference we have in our go live was that we were really tight on the timeline and we wanted to deliver within that timeframe. So the chess clock wasn't for us. The chess clock, I compare that to the project managers because those are the ones who are keeping the scores and keeping the clock moving.

So we built the case for change. Part of the case for change was contributed because we had a transition in the (Radiologist) Chair. That's another thing that I always compare either to VR site where transitions happen pretty quickly. And we got a new Chair and got the package with how the dictation and the PACS is a part of the package and how the vision is going to look like that we have a better system for the department. And then we built in governance structure around it. We thought about what the architecture is going to look like, how the integrations are going to plan, how we are going to plan for the growth that is not seen yet that comes in future. And then we configure, test it, train during the process and how we will do the go live and how the post go live would actually look for us.

This is a real world example of an RFP process that we ran. So any of you who have not been through this process, don't go through this process unless you have done your homework. And the homework I mean is that we have connected to different sites both before. And once you enter the RFP process, then it's your purchasing agent that's going to build all the network and you have to go through the legals to get connected to any site that you want to hear about.

So we went in early 2024, pre-RFP and then RFP in March in the first quarter, we issued 144 questions, 11 vendors responded and then we had the first scoring, and then we had the second scoring. In between that we did two demos, and then we also did a couple of site visits to know how the system hands on is working. And then we had some mobile viewing demos and then the site calls in addition to that.

The key thing here is that the pricing, we kept it separate because if you run through the RFP process and pricing is a part of the process, pricing will beat a lot of the opportunities that you're actually seeking in the long term framework. And we had the couple of RFPs done for the dictation system before, which were not going in the direction that we wanted and we couldn't get those.

Now, we constituted a committee. For those of us who want some insight on the questions, we grade on like a grade of one to 10. And when you grade, it's important that you grade it in a way that you aim for the product that you actually want. And that's independent. Of course, everybody in the committee is going to independently create it, but make sure the difference is in a way that you are able to select or go for the product that you wanted. Like for example, don't do seven and eight because then the price is going to beat them. So do like six and 10 or seven and 10, something like that.

Then in the group, we had a majority of representation from the radiologists. Our technical team was super committed and all the way there. But in the core committee, we kept it very short and that was intentional because if you keep it a larger committee, it's hard to arrive at a decision with more moving parts involved into it.

So we kept it short. There was an inclination towards one vendor, technically the other vendor in terms of robustness in the cloud. And we had a clinical department present attending the demos. So they were inclined towards another one. So you need all the voices in the organization to be heard and to be dealt with. And then we dealt with each of the departments and what their expectations are in terms of the PACS that we are going to be landing in.

So I've simplified the 144 questions into metrics and we wanted the first top priority for us was cloud maturity and software as a service readiness. We wanted the system to perform remotely to the best capability. We wanted scalability. We wanted the disaster recovery. That was a different thing that we built unlike some other places that we had our own on prem server backup and we wanted to share that.
I mean, the enterprise interoperability was something that we wanted and so on, and workflow, display protocol depth and enterprise imaging breadth. How are we going to implement it? How is the timeframe of implementation look like? How are the lesson learned from other institutions that have gone live with different systems? And how are the operations going to be managed during and after the go live? So those were key things. And then strategically, how ready are we for the future? And then we finalized two vendors. We went to four, then four to two, we had two rounds and then we scored the vendor that we wanted.

And now the question comes as, who's going to run the show? Is it going to be the ACHIO? Is it going to be the director of rad engineering? Is it going to be image management? Or is it going to be informatics? Who's going to run the clock and who's going to make sure that all the schedules are falling in place for the go live? So that's where we learned from another organization as well who deployed project manager. And we had an in house project manager team that organized a weekly project call and also some breakout sessions as we went towards the change in the system.

So the first call we had was in May of 2025. So between August to May, legal took a little bit longer than we anticipated. So make sure as an organization, if you're moving to change the system, sometimes the legal hurdles, the security and everything could take a little longer than you would expect. So in the first call, we changed our deadline. So we went for October 14th to November 10th as the day of go live. Why? Because first we didn't want to go into the holidays. And second ... Or I would say first was that our current PACS was end of life on December 31st. That was a contract that was expiring and we were not ready to renew it for another time point because people were not happy with that. And then we had a double go live. So we bought a little bit more time. We didn't want to go close to Thanksgiving, neither RSNA nor the holidays so that we have some time.

So then we had another transition here. So the Chair transition I talked about and then the ACHIO transition happened in 2024, December. And then we had a project manager transitioning during the project. So the one we hired had actually done an image exchange project and then she had to leave for another job and then we got another project manager in August, but we were not happy because the experience was missing. Then we had an operations improvement specialist from the department pulling that money in to run the whole process, and then we kept those. And we had another project manager coming in September and we were able to navigate the challenges that we got, but we didn't push our timeline because of that.

Now, how we organize the team is an executive oversight committee, then the radiology core team, which has all the technical team members, the oversight committee has the leadership. The enterprise IT and the interface team, which has the Epic team, the Radiant team, which is our EMR, the interface team, the security cloud team, and how are we going to do the training and education. And then the vendor and the implementation partners, which were the PACS vendors, the dictation vendors. So we bucketed them sort of in a way that we have everybody organized and that was the job that our project manager did.

So I'm going to first run through how we had the challenges on the dictation and how we navigated that and what are all the challenges. So we wanted a dictation that was having the component of AI to help us out. I mean, now Claude and ChatGPT and other OpenAI solutions we are using day in and day out. So we wanted something that's not very generic, but it's a futuristic dictation platform. We wanted a modern platform and we wanted a component of automation for the impressions and for the findings. And we had those constraints in the legacy systems.

So when we started the dictation, this RFP was done before most of our current leaders took place because they took over the project because it was twice rejected and then we sort of were recycling that RFP. When the dictation vendor came in, they had a vision that they can go live in August or September. Of course, if they can go live earlier, it's going to be still on the pre-prod environment and we can switch that environment at the data go live. So we were happy about that. But we encountered the first challenge and the first challenge was that the servers were not ready in July. As soon as we started the call in May, we came to know that there is a server requirement. We were thinking this is going to be all cloud, but not there. And those were ready in September and that took a bit of our time. And now we enter October and we are in a template crunch because we need all the templates at go live. That was our ambitious goal that we kept for ourselves.

With conversation with the vendors, it was that we could do like 20 templates per specialty. Now, that's going to be a lot of generic templates. It's going to make a lot of users unhappy on day one. So we pulled in some radiologists, some fellows, some trainees, some residents to make sort of a consortium of a team that's not going to be ideal because those people are not technically experienced. So our folks sitting on the podium with me, they did a fantastic job in lining things up and clearing some of the errors that happened. But nevertheless, there was support and there was help, and we could navigate 1000 templates in about less than three weeks, which were all manually built from scratch.

So if you're going in the direction of a new dictation system, make sure you ask them, "Are you going to be able to import our current template in some form or fashion to the new system?" Because it's a lot of work and it's a lot of boring manual work that somebody has to do. I mean, the technical team will do it, but if you do a double go live, then you're going to be ending up with constraining your resources.

Then the goal I support, I would sure an anecdotal experience was a little dwindling. We were not clear until September that the go live is not going to be available, support is not going to be available in person on Monday the whole day that we go live. And this is not a fault of anybody. It's just that dictation vendor starts on Tuesday, all the projects go live, but we had a Monday go live. And our PACS vendor goes Monday go live. And we wanted not to salvage another day to get one day less of support, but we'd rather go on Monday and have the full week of onsite support for us.
So we had to escalate it internally all the way to CIO. And then the CIO had another transition because our CIO, the previous CIO retired and the new CIO took over in late September. And then in October we had to escalate that to get the risk aligned model for us.

Now on the PACS side, things were more or less lined up. There were little delays that happened in August and September because of our routers. We had a lot of delay in setting up our routers. But they were reverse engineered from the date of go live, to the date that we started the project call, which was impressive for us. So the contract was awarded in May of 2025. We had a kickoff then. And then we also did a demo for PET and nuclear medicine folks, because we wanted them to be a part of it. We didn't want two, three systems. We wanted one robust system for ourselves.
Then we had the other bottlenecks. So that's another lesson learned and what we share is that make sure your interface resources are available at your disposal if it's going to be a crunch timeline. So our interface team was very busy because they acquired 70 plus other sites. There was a site that went live in May of 2025. There was still work done there. So we had to really escalate internally to get the pull that we needed to get the interface resources allocated. There were only three people in the interface team that did the whole magic for us in terms of integrating the three in the Cloverleaf. 

So the next challenge that we encountered, and this was a need that came once we explored the vendor space that the worklists in PACS were more likable to the radiologists in a way that they have more control. They can navigate the exams, change the priorities, they can combine with a single click. And then there was this need of having a worklist load balancer or load distributor for auto assigning some of the exams to the radiologists that we are still in the process of completing to the level that we needed because our scheduling software has changed.
But because of these flexibilities, and sometimes less is more, some people can argue more is less, that you can get a lot more from EHR, but sometimes less is more, especially for radiologists. And that was the need that came up after the demos were done and people were excited about the worklist. And that was a challenge for us because we were planning to be a phase two in the discussions, but then phase two is never a phase two. It becomes three and four. So we wanted to give it a shot and the go-live itself. Now the hidden workflow risk was that, unlike other organizations where the vendor kind of moved from workflow from PACS to PACS, or EHR is left in EHR, we had a unique situation. We wanted to go from EHR to PACS where we still retain the EHR driven workflow, but we build a PACS driven workflow, which works more efficiently for certain other features, even like auto advance, combining and things like that.

But this was a challenge because this is something you have to build from scratch. It's not already built that can be just extrapolated, unlike many other sites. So October was a struggling month, I would say, for us in that sense. And we had to do the workplace validation and build during that time. And then the reverse planning, I would say, is a lesson for the same that the weekly agendas, they became the operational control plane for our go-lives. So if you are strategizing how you want to do the process for us and for multiple other places that have gone live, the weekly agenda call works the best and you don't lose sight of it. But it also means that a lot of people may not be off during the time period that you're going through the transition. So June and July, I would say was our technical foundation time where we built a lot of the equipment [workflows].
The ADT, the ORM, the ORU subsequently, like ADT and followed by OMR, ORU was moved from the test was the PROD. The primary system build we completed in July, and then we moved from VPN to the direct connect. So that's another thing because there the IT security will come on your way. If you want to build up the direct connect, because a lot of organization have not gone through legacy to the cloud, and if you're in the process of it, make sure that's talked about early, ahead in the game. We identified protocol champions, and that's critical. Radiologist participation is critical if you're going to gain efficiency in the PACS and the dictation system. And we had one per section and this was also an idea that actually our vendors brought up to us, that you identify the protocol champions and that's required. So the protocol discovery sessions we got done in June and July, then the governance sort of was entered into early.

August and September, since we went live from May to November, our timeline was super short. August to September was more like security and production readiness. We had the direct connect established. Now, the problem we had, like the servers for our dictation, we had the DICOM routers that were not delivered, and then they were not installed until August. So that delayed things quite a bit, stressed us on that timeline. And then the protocol discovery and the protocol build session extended till September, and then the TLS over the DICOM, that was built in August and September. By late September, all the HL7 over TLS, the thin layer encryption was complete, and then the trainings were sort of planned in that timeframe. A lot of technical items were improving, but we were still in the crisis phase still in October because there was a lot of work that was happening.

And we had a lot of breakout sessions at that time with the leadership. Should we push the timeline? Should we not push the timeline? And decision was not to push the timeline, particularly so with the worklist because we had the EMR worklist already at our disposal and we tested it in October, so we would still be at a functioning level with a good PACS and a good dictation. And then we had a pre-fetch and the gap migration rules set by the PACS team that would tied us over even if we have not the entire data in the cloud because the movement was a little slow, the rate was improving, but it improved in October. So we can't be all the nine million exams on the Cloud PACS by November. That was not something doable. The radiologist and heavy clinician groups, they were staged. We had demos that we conducted, and the onsite plan was sort of robustly set in that there would be onsite support, at the site of the radiologist, at the elbow.

There's going to be an onsite command center that we ran through the whole week and we just did one big Microsoft Teams group rather than different groups, where we had the voice from the clinicians coming, and the informatics coming, and the radiologist coming, and we would have these sessions like breakout sessions in the noon and in the evening if we have issues that are persistent and we want to escalate. And it was at that time that our worklist was sort of 90% there, but the 10% was during the week of go-live, and the vendors were available that could help us navigate it efficiently. And then we also had a Zoom support on the workstation for their rads in case there is not somebody present by the desk, that they can just hop over and quickly get their issue resolved if they have any.

And of course, all the rads got a one-on-one training of 90 minutes on the PACS side and 60 minutes on the dictation side. And if we look at the November 6th snapshot and the way I think is in the sixth, then you have seventh, eighth, ninth, and then 10th, you're going live. We had a Thursday call every week with our PACS system. So that's how we went to the November 6th snapshot. We had almost 60% of the studies in the cloud, and that's another thing to keep in mind. If you're going with the vendor to change the PACS, make sure you know what is the fail-safe mechanism if not the entire data are going to be in the cloud. And then we had the third party dictation buttons that were visible on the workstations. We also did one very interesting thing. From July, we had a workstation with a demo set up for the Cloud PACS in the reading room, and we retained it all the way till go-live. So anybody can just go in there, watch the videos and the training material which were shared in July, and practice how they're going to load the studies and just be familiar with the interface.

Then it's important to realize that if you're going dual go-live, in our case, it was actually triple go-live because of the worklists as well, which were built from scratch that you line everything up in terms of the readiness, in terms of the support, in terms of the trainings and from both the admin side, radiologist side, technologist side, that it's available. And one interesting fact which is extremely important in building such strategy is how we want to communicate. And with this, I mean, over communication is always better than under-communication. So we presented at the faculty meeting that there's a new system coming. We presented at the clinical staff's high level committee with the chairs and the organizational leaders. We had every meeting that we could go to, we would just talk about a little bit that there's going to be a PACS and dictation system coming.
We had a “Noon News”, which we call it as a bulletin that comes every day, at least spread that out as the word, or educational material was put up on the intranet somewhere in August. We segmented that so people are able to get to that easily. We had the tip sheets, we had the videos and there was educational material from the dictation system, which was provided early on that people can actually self-learn while they're going through the process. And in addition to that, the other unique thing we did, we had two organization-wide demos from the Cloud PACS vendor where anybody from the organization could jump in and we timed it in October and early November, late October, early November, just before go-live so that people know that if there are any questions that they have or they at least get that feeling that there's a new system coming and they're ready for it.

What we also did, which was very unique, and if you have the bandwidth, you could do it if you're in that process. We kept both our interfaces open. With what it means is that if you want to click on the earlier Legacy PACS, you can click that and have the images visible, and you could also have that on the Cloud PACS. It would require that the images still keep going to the old PACS, through the routers, and we set the compass in a way that it would read the rules, that if the study is already there in the Legacy PACS, then once the study comes there, it'll go to the Cloud PACS, and if it's there in the Cloud PACS, it's not there in the Legacy PACS, it'll go there. So the rules were set on the routers. And then one of the other reasons we had to keep these open because, unlike other organizations, when they move their PACS systems, some of them did not have the capability to visualize images on the mobile devices, which we had.

And that was something that was not discussed or not brought up that keenly, and there was sort of a vague understanding that we are going to go live with the mobile devices after our full system go-live. So we had to really ask our vendor to escalate that and they responded and we were able to get a excellent workable solution before we exited December 31st. As an anecdote, I was sitting in The Bahamas on December 30th and my CHIO was sitting in France, and we were trying to navigate, because one of the clinicians needed some PCs that... because we were in the process of getting that out and getting that in. So we needed a backup so they're able to use the full system and not having to use the web client that was not something that they expected, but they were all good with once we get the new system.

The other thing to always keep in mind is how you transition to support. It's not a situation where you're kicked out on the day of go-live, and we still have our project calls going on biweekly with our vendors to make sure that things are getting worked out, if that comes up, getting escalated, the tickets are actively resolved, and we have the radiologist still submitting the request in case they get any. We just went live with a PET MRI new scanner. So this is a relationship. It's not like go live, you're done. Go live is actually a start. And then we had a follow-up training sessions after a go live for the radiologists and a lot of radiologists, a lot of clinicians from the specialties that we did not expect would need a training session in addition to the radiologists that we had before go live.

They enrolled for those sessions. So talk to the clinicians if you're in the process, as soon as you could, present to them. People are not going to show up for some of the demos sometimes. You're going to make them show up, you're going to be active and proactive, and once it rolls downhill, it will roll to radiology anyway. So you need to be proactive on that. And what we learned is a date is a date. A deadline is a deadline. Don't try to move it unless it's impossible to achieve it. There is going to be nervousness, there's going to be stress, but that's the mind game that you're going to navigate. And our leadership was very supportive, and our team is extremely good at handling and working under pressure and make sure the technical foundations are appropriate, that there isn't a step that we are missing in this strategy and escalate. 

Anytime things are going downhill, escalate at the first instance. We used to have this close-knit meeting like three or four people and we will escalate in the leadership that this is not going to go in the right direction. We anticipate, we escalate. And make sure on the go-live time you have a command center that's going to hear, that's going to listen to all the problems because the amount of support that one gets as an organization level at the time of go-live is unprecedented. I mean, the issues are resolved quickly. There's a hotline established. So make sure you take advantage of all the resources at your disposal.

And a Cloud PACS, like I said, it's a beginning of a new operating model. It's not the end of the project. So there are thoughts that come after the project and it's going to be a continuous improvement. So if you're inclined to go that direction, make sure that the vendors, the project managers you work with, are the nicest people around that you would like to be in a relationship with. And make sure that the clinicians have access, the patients have access. So think about it, talk about it, keep repeatedly bringing up in the meetings, get the questions answered, and be proactive on that.

So sometimes these are some of the questions that we thought and I would like to share. Why Cloud PACS? Why now? What is the problem that as an organization we want to deal with? What is the bottleneck that we want to resolve? Sometimes it may not be changing the PACS. Sometimes it could be changing the PACS. And who owns the workflow is extremely important. In our case, we had the EMR team mostly owning it and now the RAD team is owning it, which is one less step to resolve any workflow issues. What is the critical path? What do you think are going to be the dependencies which would help not validate your project? And then how do you think the end users are going to actually look at it, anticipate that they're worried there are going to be some people who are going to be, no matter what you do, going to be unhappy, but they're going to be some logical people and you don't want to end up in a situation that you have a whole lot of people that are unhappy in the organization. That's not the success definition.

And what happens after go-live is extremely important to know. And that's where a lot of the relationships which we built during this whole process worked out. We had two site visits in different places and then we had another site visit, which was actually in 2025, May itself. So like six months before because of the workplace that we were thinking to change or adapt to. And then we had pre go-live talks with multiple organization and one of the chairs from one of the organizations came to present just a couple of weeks or a week and a half before go-live on how their PACS is functioning. So you're going to build that momentum. If somebody has read that book from John Kottler, Leading Change, I would strongly recommend that. It's a great book. It tells you about how you empower people towards the goal and not push them towards the goal because that doesn't work.

So you build that anticipation, build that momentum, build that excitement as you go towards it. And we supplemented that with site calls. We were in continuous process with talking to multiple sites as we were going live with it, as we executed the project, so that we don't lose sight of something that is going to be of huge importance to not only the radiologist, but also to the clinicians. And this is a slide while every family member I would say in our project or in our strategy was sort of involved in some way or fashion, because you take some time away from your family when you are in a timeline that is crunching. And my daughter, she was sitting with me a couple of days back and she's good at making Canvas slides. She wanted to make a slide and said, "Please don't delete it." And this is the minimum I could do for my family who enthusiastically participated. So thank you everyone for listening. We are happy to take any questions. I appreciate everybody's attention and attendance. Thank you."

Q&A:

Audience Member:

Did you have to go through a vendor selection process or did you kind of deconstruct what you had in place already for making this happen?

Dr. Ramandeep Singh:

No, we did have to go through the whole process. So when we raised the RFP, we had about 140, 144 questions, and then we invited the vendors to submit responses to those questions and we went through all those responses and to see the key things that we wanted in the system, there were 11 vendors that responded and we sort of individually in the committee went through that to decide on which of the vendors are going to be the ones that are preferentially going to be included. We didn't want to rate all the 11 vendors because then it becomes hard. You have a 10-point scale, how can you rate 11 vendors and justify that because it's going to be sometimes bottlenecks to break seven and seven, and that's not going to land us into a position that we decide. So we want to be decisive. So we went, navigated that to four, and then four to two, and then two are the ones that we scored in the final scoring criteria.

Audience Member:

Second question, what was the level of representation before and then where did you [inaudible] line that afterwards? So did you have a lot of organization to do from workflow and analysis perspective before you jumped into the project? How do you do the discovery phase?

Dr. Ramandeep Singh:

Oh, yeah, that's a great question. I think the major part of the discovery phase, like I joined the organization in 2023 and every faculty meeting, there would be a presentation from the informatics side like a slide on the number of crashes, and people are going to get like, "Top three people who would submit the most crashes are going to get coffee at the coffee shop." And I hated it because I came from another organization that I saw a robust system functioning.

And I would say I asked my Rad Eng team to say that, "What percentage do you think?" And they said, "It's hard to coin it because it's going to be like one extreme where you have..." And we would have like sometimes 10 crashes a day, 20 crashes a day. You reboot the system, it again crashes, you reboot the system. So we were like really unhappy.

And then the choice was whether to go with the server upgrade, but then the whole opportunities that cloud would give you would never be available on the on-prem server. So I would say our baseline was very unhappy and it was a system which was there from 20 years and we wanted to get out from that system. And we had unsuccessful attempts previously because of the pull from the organization in terms of what you said, fragmentation, because the leadership is very fragmented on the side of the clinical because they are controlling the money. Radiology is giving them the money, but they want their money back, but it's a process. And then sometimes radiologists are taken like, "Oh, you guys are only reading pictures and we are dealing with the real patients." So the voices sometimes are not heard.

So to navigate that, since our Chair was already a Vice Chair before in the organization and he became the Chair, he just got it as a Chair package and that's one thing that he advocates to the future Chairs as well and that you just get it as a deal because that's important for the organization to navigate and be... Sometimes I think it's just like, how can you give a surgeon a bad surgical equipment? You cannot do it. You have da Vinci robots now doing their job. For radiologists, their only thing is their PACS, their dictation, and their chair they sit in, and then the desk that they see. So that's where we bring the money into the system. It's not a huge ask, but that's something that we learned as well in the process.

Yeah. Thank you. Yeah, go ahead, please.

Audience Member: Inaudible

Dr. Ramandeep Singh:

In terms of the dictation and the PACS? Oh yeah, I think that's a great question. Thank you for asking that. Yeah, we can answer it out, I think. Yeah. Okay.

Audience Member:

Sorry, they're cutting us off. Can we take your question out front? Sorry.

Dr. Ramandeep Singh:

I can give like 10-second answer and we'll be out. So I think the project manager is extremely important to have in your organization because the project manager is sort of the nodal point where everybody will sort of revolve. So yeah, thank you everybody. We have flashing screen to wrap up. Thank you.