Abstract

The present shortage of MRI technologists continues to interfere with the delivery of care of patients. In addition, there have been limited solutions to cover disability, sickness, vacation, and personal days of that limited workforce. Our practice decided that the best way to address these coverage problems was to implement a virtual remote scanning solution. We explain the IT infrastructure, training and policies needed to implement this innovative solution safely and successfully to the MRI technologist shortage.

Introduction: The present shortage of MRI technologists continues to interfere with the delivery of care of patients. In addition, there have been limited solutions to cover disability, sickness, vacation, and personal days of that limited workforce.

Methods: Our practice decided that the best way to address these coverage problems was to implement a virtual remote scanning solution.

Results: We explain the IT infrastructure, training and policies needed to implement this innovative solution safely and successfully to the MRI technologist shortage.

Conclusion: Virtual remote scanning can be a safe and effective solution to address MRI technologist shortage.

Implications for practice: Virtual remote scanning can be a safe and effective solution to address MRI technologist shortage.

Citation: Hinrichs C, Hinrichs S, Scholte R. Implementation of remote MRI scanning. Open J Clin Med Images. 2024; 4(1): 1181.

Introduction

The current shortage of MRI technologists has impacted imaging coverage in most hospital and outpatient practices [1-3]. The field of radiology battles a never-ending leakage of qualified technologist coverage as a result of disability, sickness, vacation, and personal days. The loss of technologists to higher wages and competing health systems is also a significant problem. Per diem technologists who are willing to pick up shifts on short notice are extremely rare. Locums’ coverage requires advance planning and typically is extremely expensive. Overtime is always an option, but this further erodes the limited margins in managing an imaging practice. The pressure of splitting the outpatient dollar continues to be problematic and, in most cases, the above-described options are unlikely to provide a solution to anyone but the largest institutions with significant endowments. Furthermore, the pool of candidates who are properly qualified to perform highly specialized scans such as cardiac MRIs is extremely small. Recruiting and retaining this highly trained subset of individuals is difficult at best, and virtually impossible at every location.

Unfortunately, many of the above-described solutions have been unsuccessful for most practices, including ours. Most outpatient practices in such situations scramble to find last-minute and long-term imaging coverage. When we are unable to do so, which happens frequently, we need to cancel appointments and reschedule patients, which further burdens our front desk and call centers. The difficulty of rescheduling specialized MRIs is even greater because they can only be performed at a limited number of facilities by highly specialized technologists, for whom replacements cannot be easily found. As a direct result of this rescheduling uncertainty, patients’ satisfaction declines and their confidence in their healthcare providers erodes.

The outlook for hospital and health systems is even bleaker because they need to provide 24/7 coverage, which poses a bigger challenge than providing coverage during normal business hours. This leads to many health systems requiring back-up call to cover callouts which come at a cost, both financially and with staff retention. These call burdens further weaken staff recruitment and retention. Some hospital systems are forced to mandate overtime in certain circumstances to provide much needed coverage, which is not ideal for many reasons but especially when it comes to patient safety.

Although our practice is in a suburban area, we have continued to struggle with ensuring adequate technologist coverage at our facilities. An additional challenge faced by our practice is the vast geographical area we cover; we have twenty MRIs which are spread throughout the North, West and Central New Jersey regions, therefore moving technologists laterally across the system is nearly impossible. Most of our technologist’s object to regularly moving amongst multiple facilities, which is understandable because some may not have familiarity with the equipment or workflow in the other imaging centers. Employee satisfaction is always a consideration given the continued competition of nearby facilities when requiring cross-coverage.

Our practice decided that the best way to address these coverage problems was to implement a virtual remote scanning solution throughout our centers through the use of Siemens’ Syngo Virtual Cockpit (SVC) [4]. The primary goal was to strategically roll out SVC in all of our MRI facilities, which required a multipronged approach. First, we needed to test and partially upgrade our IT infrastructure to support this objective. Second, we needed to develop policies and procedures for the safety of our patients and staff. Third, we had to develop a training and safety program for our technologists and technologist assistants. Lastly, we also needed to appreciate that incorporating SVC would require us to reassess our workflow and front desk coverage.

Our secondary goal was to implement Siemens’ We-Scan [5] across our organization to enable virtual coverage for imaging services. Through We-Scan, Siemens offered the services of licensed MRI technologists to virtually cover our facilities for six days a week, and up to three scanners at a time.

IT infrastructure and testing

Under our original setup, our twenty MRIs utilized a mixture of business level cable modems and fiber. We also had a small MPLS (multiprotocol label switching) network covering two magnets and were in the process of upgrading our entire network to ELAN (Ethernet Local-Area Network) and eliminating the MPLS. During our initial testing and validation, we quickly realized that using cable modems caused large latency and jitter between both the SVC server and their respective steering stations. We also discovered that cable modems, even ones designed for commercial use, utilize a shared medium which equates to over subscription of the service provider during peak hours. Siemens requires a strict 25 millisecond latency threshold which will manifest as poor performance if that threshold is not met. In order to mitigate this issue, we opted to deploy dedicated fiber transports or utilize low latency queuing on egress interfaces within the network.

Such infrastructure enabled the system to bypass internet service policies and carrier congestion, which is traditionally considered best effort outside of the WAN (Wide-Area Network) edge. Utilizing private WAN links enabled us to have full control of bandwidth across all locations while giving us the flexibility to consider failover and load balancing techniques. ELAN terminating devices were used to route local traffic to all branch offices while seamlessly allowing networks to span the remote edge utilizing carrier Ethernet techniques.

We have deployed SVC across all our Siemens and non-Siemens MRIs. The Siemens platforms which had access to Syngo Expert-I (Expert-I) to connect with SVC used that connection method. Expert-I allows interactive remote assistance during the MRI exam and provides real-time access to imaging data and exam information from any networked PC within the network. The non-Siemens units and the Siemens MRI without access to Expert-I required a KVM (Keyboard, Video, and Mouse) switch (Figure 1). A KVM switch is a device which connects a keyboard, monitor, and mouse to multiple computers and allows control and switching between them. It has the ability, depending on the model, to access other connections such as audio and USB ports. Local network infrastructure may also require a KVM switch on a Siemens platform with access to Expert-I. This issue will be discussed in greater detail below.

As mentioned above, because latency drives everything in SVC, a robust network and dedicated individuals willing to deploy QOS (Quality of Service) are a necessity for success. QOS is the concept of prioritizing traffic by treating varying classes of traffic differently. Our resident network engineer took a holistic approach by spending time understanding individual traffic flows and business requirements. Traffic that needs priority, such as SVC, must be considered front and center if a successful rollout is desired. Radiology networks are notorious for the sheer volume of data that travels through a given network during a sampled time period; therefore, congestion in network links is always a concern and must be addressed. Devices which support multiple QOS queues and thresholds are recommended, if not required, as it allows for a more granular traffic association as many processes may have various different levels of priority.

In our organization, we run VoIP (Voice over the Internet Protocol), which is a priority, on our QOS as we do not want to drop voice packets or have call degradation as a result of SVC implementation. In addition, bandwidth competition is always a concern when sending massive tomosynthesis studies as they interfere with our latency and therefore our ability to connect to the MRI with SVC. Having the voice phone traffic classified, marked and queued in a low latency queue is of utmost importance, followed by a priority queue matching SVC traffic patterns. Real time traffic sensitive to latency such as SVC should be prioritized directly after voice. This classification ensures that if congestion hits the egress interface facing the WAN edge, it has dedicated bandwidth and scheduling time by the network device to function properly. Be mindful that allocating too much buffer space in QOS could result in higher latency as data is buffered for a period of time that may exceed the Expert-I and KVM latency threshold. We found this phenomenon, commonly known as buffer bloat, to most often occur with Expert-I. If you are unable to deploy this successfully, then KVM switches across the system are the way to go as they require far less bandwidth. However, be aware that there is a higher cost associated with procuring the supported KVM switches as many, if not most, are purchased by the military for non-commercial purposes and you will pay a premium for them.

As for metrics, our network engineer measured sample SVC traffic across the following three controls: (a) Expert-I native connection; (b) Expert-I over https (newer software); and (c) KVM switch. During peak stress, the output was as follows: 65 mbps, 98 mbps and 22 mbps, respectively. The greater the output, the more stress there was on downstream equipment which, in turn, resulted in bottlenecks impacting SVC latency. As the numbers reflect, KVM is the top performer from a bandwidth output perspective.

If you use Expert-I communication channels to connect to modalities using SVC, keep the following considerations in mind. One of our biggest delays rolling out the product was the limited information that we were able to obtain regarding the ports, protocols, and services utilized by Siemens to connect from SVC to the MRI itself. Within the SVC infrastructure configuration manager, there are several options to choose from for your transport method. There are three Expert-I settings and one KVM option (which we will not cover here). Our delay during initial testing was caused by not understanding which Expert-I connection method to use on a per-MRI basis as well as which port to connect to. After several attempts, our network engineer had to run packet-captures within the network to finally understand the connection settings. Consider having someone who is proficient at network troubleshooting involved in this process as it can be a major hurdle in implementation.

If utilizing KVMs, there are some unique considerations which must be considered prior to implementation. This device is simple to connect. The AWS (MRI acquisition workstation) video is connected to the KVM via a video cable. The input on the KVM is an HDMI (High-Definition Multimedia Interface). The output from the AWS varies but is most often a DVI connector. A USB-to-USB cable is also used to connect between the AWS and KVM and the mouse and keyboard is disconnected from the AWS and plugged directly into the KVM. The native ethernet cable connected into the AWS remains, and an additional ethernet is connected into the KVM. A full understanding of the KVM workflow and data exchange process was something that our IT staff needed to grasp as it is an integral part of understanding how the system works from an IT supportability perspective. Someone familiar with SSL (Secure Sockets Layer) certificates and certificate authorities should be involved on any deployment as connections to and from the KVM must be validated via SSL certificates not only on the SVC server infrastructure, but also every steering and modality client workstation. Sites with domain controllers would benefit from their internal DNS (Domain Name System) servers be registering KVMs to their local DNS databases for easy look ups. In our case, some more thought had to go into this topic as we utilize three different domains. For instance, we leveraged host files within the Windows operating system to resolve hostnames to correct IP (Internet Protocol) addresses that also needed to match certificate names and SANS (SysAdmin, Audit, Network, and Security). This is used to validate that the application is correctly receiving secure data from the correct KVM.

After overcoming the initial hurdle of getting secure IP connectivity to the KVM switches, it is important to follow the SVC installation manual closely as the application is extremely strict for data verification. Within the SVC server manager, there is a technical configuration page where you must enter the appropriate data per KVM and per license, which is known as the “modality configuration.” One field within the modality configuration page consists of entering in the FQDN (Fully Qualified Domain Name) of the modality client. During initial set up, IT struggled with trying to allow modality clients to generate “on the fly” KVM credentials for? the SVC steering technologist using Siemens configured backend APIs (Application Programming Interface) to the KVM switches. The FQDN within this page required the full name of the host workstation, identified as the modality client workstation, to be entered in and the data must be case sensitive.

Steering clients (technologist controlling workstations) connecting to KVMs must also be configured correctly to allow proper communication to and from both devices. The steering client workstation required additional software to allow the SVC software to make the KVM data feed appear correctly on the SVC application. The first challenge we encountered was understanding that not only did the SVC infrastructure need the KVM certificate stored in the Windows trust store, but also on the steering workstation. The logic from the application design is to have the steering client submit a connection to the KVM in which the server sends a direct request to generate credentials. The SVC infrastructure server then communicates with the KVM using the modality configuration settings and SSL certificates loaded into the trust store to negotiate a secure encrypted channel. From there, the specified KVM generates an “on the fly” modality login for the steering technologist to authenticate the KVM itself. When the steering client ultimately uses the credentials to log-in, the steering client then connects directly to the KVM using the same method as the SVC infrastructure server.

Once a secure channel from both the SVC server and the steering client is established and authenticated, the last step is for the application to understand how to handle that data stream. This is where a third-party tool kit, which in our case was AKC (active kvm client), is utilized. The AKC client is software from the KVM manufacturer that allows third parties to interface with applications. SVC needs a mechanism to transfer data from the KVM, which is not compatible with Siemens, to SVC; AKC client is the mechanism that allows SVC and KVM to interface. Without AKC client, when you launch SVC through a KVM, the system freezes. AKC client allows the proper display of the KVM vendor’s software into the SVC software. It is important to understand that the AKC client tool kit must be deployed in the correct SVC file path to enable the KVM data feed to be displayed correctly within the SVC application itself.

Once a secure channel is established and the data is displayed within the SVC client application, IT initially had problems obtaining the correct resolution to display from the Modality Acquisition Workstation (AWS) onto the steering client monitors. This is due to the KVM acting as the negotiator trying to link native resolutions across two substantially different, and possibly unsupported, devices (i.e., AWS and a native steering station 4k monitor). Our IT staff had to spend some time customizing resolutions until a successful and reliable process was devised.

SVC utilizes and depends on reliable camera feed positioned down the bore of the MRI, as well directly at the contrast injector. During the initial camera set up, IT staff spent time obtaining the most optimal settings to yield a real-time camera experience. In all instances, the resolution, frame rate, bitrate and image saturation across all locations remained identical and resulted in a favorable outcome. It is important to understand that with Real Time Streaming Protocol (RTSP) cameras, there will be inherent delays with receiving the data on screen despite the protocol’s name. This delay is mostly caused by the receiving end having to decode the information which can be processor intensive. Although SVC technicians were initially under the impression that zero delay was achievable, after many attempts of technical measures, the average delay time stood at about one second.

SVC utilizing RTSP cameras with high compression codecs should also be a consideration during the design phase. A high compression codec susceptible to network congestion can cause extreme loss of real time video if packets are dropped. This is because if one compressed packet is lost, the remote viewer will lose the equivalent of uncompressed data in terms of frames, which will result in a substandard experience.

Given our original infrastructure, SVC was set up in a way where each MRI location had the ability to run any magnet in our system, which required a dedicated VPN from each site to every other site. As you can imagine, for an organization with over twenty facilities, we have a tremendous number of VPN connections across the system. When we eventually deploy ELAN, these will no longer be needed as data will be routed to a remote location over the private circuits. However, these firewall VPNs will ultimately be available in the event a local site loses its connection to the private WAN and a backup VPN needs to be utilized. This design consideration was the reason we opted not to wait for ELAN deployment to go live.

We rolled out SVC at one location per week over a period of time, testing and re-testing the system in all directions. IT staff and our lead technologist were heavily involved during this period validating all successful communications and performance complaints. To expedite troubleshooting of both clinical and performance issues, it is important to pair IT staff with a technically savvy MRI technologist who can “translate” and be a liaison between the clinical and IT staff.

One of the first challenges we encountered was that the SVC workstations (Figure 2) which were utilizing SVC were underpowered. Although our initial workstation devices were from the recommended Siemens specifications, we quickly noted that while using SVC, the CPU of the steering station was being highly utilized in the 90 percentile while trying to stream and process SVC traffic across the network. IT discovered that most, if not all, of the SVC MRI graphical data was being processed by the CPU, and little to none by the actual graphical processing unit. This caused the workstations to require additional CPU resources, a shortcoming we did not anticipate. Our first trial workstation was an 8 core Intel I5 processor, but given the problems we encountered, we moved to a 12 core Intel I7 to address CPU overutilization. When considering the SVC workstation selection, we recommend overprovisioning the workstation as opposed to under provision, especially if the anticipated workstation will be steering multiple MRIs. Our final standard deployable workstation was determined to be an Intel Core I7, 12^TH generation or newer, paired with 16 GB of DDR5 memory, as well as a M.2 NVME SSD for disk, paired with two 4k monitors, which are scalable to 2560 x 1440.

When selecting monitors, you should purchase monitors with 4k resolution as per Siemens specifications. When the IT staff was finally ready to test the application with MRI technologists, we quickly realized that the native 4k resolution paired with SVC did not work well together. We concluded that what yielded the best experience from the MRI technologist’s perspective was to use 2560 x 1440 resolution, while also having no scaling enabled on the workstation. In addition, with this setting, the application did not throw any ambiguous errors at the actual user trying to steer a remote modality.

Utilizing voice and audio through the application is straightforward and leverages the built-in tool provided by Siemens. Once an auxiliary device is plugged into the physical workstation, Siemens lets you select the input and output device to utilize with SVC. This worked well almost instantly. Over time, we started to notice that through the Windows operating system, the microphone would turn off automatically for unknown reasons. We recommend turning off the audio enhancement setting under the voice properties as this inexplicably conflicted with the SVC application. After this setting was toggled off, no errors related to microphones were reported to IT. One thing to mention is that less technical MRI technologists will mute via the auxiliary microphone/audio device and will frequently call IT complaining that their microphone is not working correctly. Explaining to the technologists the process of how the external microphone and audio device works was the easiest way to remedy this minor problem.

After IT procured the correct workstations, monitors as well as external audio devices, technical trouble tickets between MRI technologists and the IT staff became a rare occurrence. Most technical issues from this point forward were strictly related to topics such as performance, technologist’s SVC credentials, and standard KVM related issues. All the issues identified above are issues your IT team needs to be comfortable managing and handling internally if SVC is to be used.