Towards a More Cloud-Friendly Medical Imaging Applications Architecture: A Modest Proposal

Abstract

Recent information technology literature, in general, and radiology trade journals, in particular, are rife with allusions to the “cloud” suggesting that moving one’s compute and storage assets into someone else’s data center magically solves cost, performance, and elasticity problems. More likely, one is only trading one set of problems for another, including greater latency (aka slower turnaround times) since the image data must now leave the local area network and travel longer paths via encrypted tunnels. To offset this, an imaging system design is needed that reduces the number of high-latency image transmissions, yet can still leverage cloud strengths. This work explores the requirements for such a design.

Background

At the recent SIIM 2012 Conference in Orlando, we were fortunate to be present at the Learning Track 6 sessions on the future of image archiving. In particular, a great deal of attention was given to the concepts of Vendor Neutral Archive (VNA) vs. Archive Neutral Vendor (ANV). Unfortunately, these acronyms are largely unhelpful in describing what they actually refer to. A VNA is an enterprise image archive that accepts DICOM images from all PACS vendors. An ANV is a PACS that claims to be able to use any third party archive. The panelists held forth on the potential for such systems to enable “cloud” PACS implementations that could reduce PACS capital costs for a medical center. The discussion was not unlike a discussion from a decade prior in which Application Service Providers were thought to hold the potential to significantly reduce costs by leveraging large-scale, shared computing resources. That model has only been moderately successful, largely as deep storage and disaster recovery. One important challenge in such a model is the accumulated network latency that could arise from such a deployment [1]. Consider the following figure for the straightforward case of image acquisition and quality assurance (QA)/interpretation on the PACS (Fig. 1).

Fig. 1.

The classical workflow in a medical center with a VNA feeding an institutional clinical viewer. The gray-shaded figures are Radiology Actors (e.g., RIS, PACS, Modality). The unshaded objects are institutional assets: the VNA, EMR, and clinical viewer. The arrows show the messages transferred among actors and what protocol is used. For example “HL7 results” means a radiology report is being transferred from the RIS to the EMR via HL7. “DICOM MWL, MPPS” between the HL7/DICOM broker and the modality means Modality Worklist and Modality Performed Procedure Step message sent between the two actors via DICOM

In this figure of a classical PACS implementation in a center with a VNA, the workflow shown is fairly representative. The radiology department actors (shaded) create the order (RIS), send the order to the PACS via the HL7/DICOM broker, send exam demographics to the scanner (via DICOM Modality Work List), and finally send images to the PACS (via DICOM). In addition, exam status information (exam start, series start … exam end) is sent by the modality to the RIS and PACS via DICOM Modality Performed Procedure Step (MPPS) messages. Up to this point, the institutional systems (unshaded) have little knowledge of the exam status. At our particular site, it is not until there is a preliminary report on the exam that the PACS send images to the VNA, from which they are made available to the clinical image viewer. Meanwhile, the report is sent from the RIS to the Electronic Medical Record (EMR). Note in this example that there are three DICOM image sends: from modality to PACS, PACS to VNA, and finally VNA to Clinical Viewer.

The time penalty of three DICOM sends is tolerable within the local area network (LAN) of the medical center. It is not clear that network performance meets clinical practice requirements if DICOM sends from modality to PACS, or PACS to the VNA, span a city (or state or country), and if clinical images must jump from the cloud back to the medical center, all the while in an encrypted tunnel [2].

In addition to latency concerns, one can see that the classical radiology components are overbuilt in the era of a VNA. There is little need for the PACS to have a large image storage capacity as long as the department has ready (and restricted) access to the images it creates during the QA and interpretation steps. What radiology (or any imaging department) needs is a set of tools that enable image preparation tasks (including post-processing) and interpretation tools (hanging/viewing/reporting of images with compares). Image storage, routing, and publication (with reports) to areas outside of radiology are tasks more naturally addressed at the institutional level.

Workflow Redux

Numerous authors have described the intricacies of radiology workflows [3, 4]. For our purposes, it will be sufficient to consider the following items:

1. technologist acquires images on the modality

2. resulting images may or may not be post-processed (by the same tech, or another tech in the “3D Lab” and/or on a CAD (Computer Aided Diagnosis) system)

3. Upon completion of acquisition and post-processing tasks, the exam undergoes QA on the PACS to be prepared for the interpretation process

4. The radiologist interprets the exam and creates a report

5. The images and report are “published” to the medical center via the EMR (the report) and the clinical viewer (the exam that underwent QA and interpretation).

It is often the case that each of these steps is accompanied by a DICOM image send: from modality to post-processing workstation, from workstation to PACS, from PACS to VNA, and VNA to clinical viewer server. Consider the impact of these sends in two cases:

• Across the LAN

  Network latency is 1 ms. Images transfers to/from the PACS workstation are on the order of 50 CT slices per second. Clicking on a 1,000-slice CT exam would then require 20 s for all images to be present on the workstation.

• Across the Wide Area Network

  In an experiment in our institution using a VNA located at another site, network latency was on the order of 60 ms. The query to the PACS workstation outlined above thus takes 60 times longer or 1,200 s (assuming there is no change in transfer protocols, compression, etc.).

In addition to network concerns, the sends may not always be automatic—leading to long turnaround times. For example, the CT technologist may have to manually send from the scanner if certain series of the exam should go to the “3D lab” or CAD, but others can go direct to PACS—and such a manual send may be delayed if the tech is also helping the current patient get off the CT couch, etc. Furthermore, delays can occur at the 3D lab if the staff there is working on other cases. The next figure (Fig. 2) shows this scenario (note the incremental inclusion of CAD and post-processing from Fig. 1).

Fig. 2.

An incremental complication of the workflow in Fig. 1. In this instance, the workflow supports intermediate steps from the scanner for post-processing in a 3D lab or CAD processing, before exam images are sent to PACS. The routing steps in this instance are manual sends from scanner to the 3D lab and from the lab to the PACS

To mitigate the human handoffs at our institution, we have implemented a system that automatically classifies exams based on information about the order, modality-specific information (i.e., the MR coil and pulse sequence used), and other information. The system has been described elsewhere, but can be considered a DICOM/HL7 aware workflow engine that enables intelligent routing [5]. We have also coupled it to an array of CAD and post-processing tools that run automatically in most cases and return their output to the workflow router for the next step in the workflow pipeline [6]. The next figure shows how the inclusion of such a device simplifies the human interactions shown in Fig. 2. The key point to grasp is that once the images arrive at the workflow router from the scanner, all movement/processing is automated until the workflow finishes by sending the completed products to PACS (Fig. 3).

Fig. 3.

Similar to the workflow in Fig. 2, but in this case the modality sends to one destination (a workflow enabled DICOM router). This workflow-router classifies the workflow steps for an exam based on information in the order and the DICOM header and then routes the exam through the appropriate pipeline. In a straightforward case perhaps the exam is routed directly to the PACS. In another case, the exam may be sent to a CT de-noising algorithm and then to a pulmonary CAD system, before all original and derived objects are sent to the PACS

While the workflow enabled router mitigates the human “dropped connections” that accompany the scenario shown in Fig. 2, there is still a great deal of DICOM image moves occurring—movement that will show itself ungracefully over high-latency networks. Therefore, a key design goal for a fast cloud-based imaging department is to minimize the number of DICOM sends over high latency networks. Such a goal can be met—if access controls are in place to regulate application access to exams based on the exam status. In other words, what is needed is a “tank” into which images can be poured via DICOM, but:

1. when images first arrive they are accessible only by the technologist’s CAD, post-acquisition image processing and QA tools

2. when quality assurance is done, the images next become accessible to the radiologist’s work list, viewing, and reporting tools

3. when interpreted, the images (with reports) become readable to the clinician’s work list/viewer, or downstream value-added users such as Orthopedics (to create a template plan) or a Radiation Oncology treatment planning system.

4. All the above listed components reside on a high bandwidth, low latency network so only one “slow” networking path is endured, from the modality to the “tank”

To gain insight into a solution to the above four constraints, it is worth looking at the Integrating the Healthcare Enterprise (IHE) Scheduled Workflow (SWF) integration profile [7]. The full-actor diagram showed in that reference is more detailed then required, but it can be a useful base to abstract the required transactions that this “tank” must support. Figure 4 represents a simplification of the IHE SWF actor diagram. Before looking at this figure however, it is helpful to learn the formal labeling of IHE transactions among actors [8]. The IHE documentation formalizes all transactions and documents them in detail. To make the figures visually cleaner, we have truncated the full transaction names to their IHE shorthand. Table 1 provides the meaning of each message.

Fig. 4.

An abstract of the IHE Scheduled Workflow integration profile. This rendition simplifies the official diagram a bit and maps IHE actors to traditional terms like RIS and PACS. However, the key transactions among the classical actors are represented here. An important point, all these actors lies within radiology

Table 1.

Listing of the IHE transactions required to implement the Scheduled Workflow profile, and the protocol they are codified in

Message	Shorthand	Protocol
Procedure scheduled (order)	RAD-4	HL7
Modality work list	RAD-5	DICOM
Modality procedure step in progress	RAD-6	DICOM
Modality procedure step complete	RAD-7	DICOM
Modality image stored	RAD-8	DICOM
Storage commit	RAD-10	DICOM
Image available	RAD-11	DICOM
Procedure updated (order update)	RAD-13	HL7
Query images	RAD-14	DICOM
Retrieve images	RAD-16	DICOM
Creator images store	RAD-18	DICOM
Creator procedure step in progress	RAD-20	DICOM
Creator procedure step complete	RAD-21	DICOM
Query reports	RAD-26	HL7
Retrieve reports	RAD-27	HL7
Performed status update	RAD-42	DICOM
Instance available notify	RAD-49	DICOM

Now we can look at the abstraction of the IHE SWF actor diagram with the awareness of what the transactions are. We start by trimming out the institutional registration and ordering systems, and assume they exist to feed the required inputs to the RIS. We also map several IHE actor names to their classical counterparts. We then have the following as shown in Fig. 4.

Starting at the RIS, the RIS forwards orders (RAD-4) or order updates (RAD-13) to the PACS via HL7 (and possibly including a HL7/DICOM broker). At patient arrival at the modality, the technologist queries for exam information via the DICOM RAD-5 transaction. When the exam begins, the modality shares status information with MPPS messages via RAD-6, 7 transactions and the PPS echoes this news to the RIS. When images start to be moved to the PACS for storage they follow RAD-8, 10. The PACS then informs the RIS of new images via the DICOM RAD-42, 49 transactions. Any post-processing that may be done on the modality or a third party workstation alerts the PACS and RIS to the new objects via RAD-20, 21 messages sent to the PPS. Finally, a technologist or radiologist may review the images on the viewer using DICOM RAD-14, 16. [Although in practice, most PACS’ workstations have direct access to the PACS database and transfer image files via non-DICOM protocols].

It is worth considering the strengths and weaknesses of this architecture. The strengths are:

• All actors in radiology are made aware of the exam status as it progresses

• Data is transferred electronically among systems without human data entry

The weaknesses are:

• Actors outside of radiology are not “in the loop” until exams are finalized in the RIS and PACS and sent to institutional systems

• Many connections among systems are point-to-point, making it difficult to scale to a large number of actors

• There are multiple image transfers, possibly across slow networks, and multiple files writes to disks on the various systems, all of which may limit performance

However, with only a few modifications to Fig. 4 design, one can enable several key features. Figure 5 shows such an adaption.

Fig. 5.

The scenario in Fig. 3 removes many chances for broken/delayed exams (due to human manual sends that are dropped or delayed). However, it does so by physically moving the same image set among multiple systems. In this reformulation of Fig. 3 workflow, the workflow router moves from radiology to the institutional VNA. Further, rather than physically moving images from system to system, all systems access the images in a single place, the VNA. The workflow router becomes a workflow ACL and gates what application(s) can reach the images when based on the exam status

At a high level, one can see that all messages are associated to a one-way arrow; for example the modality gets MWL information from the PPS manager, but sends MPPS status messages and images to it. One will also note that the technologist, radiologist, and clinical viewing tools are visualized as standalone application groups; each group of related applications have independently gated access to messages from the PPS manager and thus may know about an exam at different times based on workflow rules. Also, since all processing/viewing applications are in the same data center with the VNA, it is possible that the radiology viewer server (for example) can fetch all needed images from the VNA directly into random access memory (RAM), avoiding any further disk writes. And for the same reason, only the final display results are sent outside the data center and this can be achieved via thin-client streaming over World Wide Web (WWW) protocols such as Web Access to DICOM Objects [9].

As mentioned earlier, several key architectural changes have been implemented vs. the classic IHE scenario shown in Fig. 4:

1. There is no PACS in the traditional sense of the word in Radiology (or any other imaging department), rather images are sent from the modality directly to an institutional VNA (which may be local or in the cloud)

2. The PPS manager is moved outside of radiology to reside on the VNA, enabling institutional systems to be aware of the exam states within radiology (or other imaging departments). Also, it becomes the central broker for all messages, actors sending IHE messages due so purely via the central PPS (which now must support HL7 as well as DICOM messaging)

3. The workflow router that was used in Fig. 3 to overcome manual routing hand-off issues has been linked to the VNA, but more importantly, its workflow engine creates Access Control Lists (ACLs) that gate application access to the images on the VNA without DICOM movement from system to system. Rather, it is possible for applications to have direct access to the VNA file system over high-speed file system protocols

These points bear further explanation. All message senders send their message as usual, but only to the single PPS manager. The PPS, however, gates the forwarding of those messages to the intended recipients based on the exam status; such gating behavior to be regulated by the workflow ACL. The ACL is also used to gate access to the VNA file system should a rogue system attempt a wild-card DICOM retrieve. For example:

1. When images arrive from the scanner, Procedure Complete and Image Available messages are sent only to the technologist-associated applications and work lists. Further, the files are only accessible to the technologist level applications.

2. After QA, the exam status is incremented in the PPS database by the rules engine on the workflow ACL. The PPS is then directed by the workflow engine to forward the same messages to the radiologist applications and enable file access to them.

3. After exam report finalization, exam status is again incremented and the prior transactions would finally be sent to the institutional systems (i.e., clinical viewer) and file access granted to them

Table 2 shows the explicit steps that are motivated by the above requirements. It is assumed that the VNA file system allows the creation of user groups, and the ACL then enforces read/write privileges on those files for the various groups based on the exam status; in a similar manner the workflow ACL refers to an exam’s status to determine what targets to send messages to.

Table 2.

ACL rules for gating technologist, radiologist, and clinical application access to image files stored on the VNA. An application group will not know of an exam until the appropriate status is reached to enable sending the requisite messages to it

ACL/PPS	Status = “arrived”	Status = “new”	Status = “QAed”	Status = “Final”
File system	Tech = −, −	Tech = read, write	Tech = read, −	Tech = −, −
	Radiol = −, −	Radiol = −, −	Radiol = read, write	Radiol = −, −
	World = −, −	World = −, −	World = −, −	World = read, −
RAD-4, 13	Tech = sent	Tech = sent	Tech = sent	Tech = sent
	Radiol = −	Radiol = −	Radiol = sent	Radiol = sent
	World = −	World = −	World = −	World = sent
RAD-11, 21, 42, 49	Tech =	Tech = sent	Tech = sent	Tech = sent
	Radiol =	Radiol = −	Radiol = sent	Radiol = sent
	World =	World = −	World = −	World = sent
RAD-26, 27	Tech = −	Tech = −	Tech = −	Tech = −
	Radiol = −	Radiol = −	Radiol = −	Radiol = −
	World = −	World = −	World = −	World = sent

With the rules arranged as shown in Table 2, we have replicated the same issue that institutional systems had in Fig. 4; that is that the institutional systems will not know of an exam until the exam status is final on the radiologist’s “PACS”. However, there is nothing preventing relaxing the rules so that a clinical viewing work list may be aware of an exam while QA is being done. The value of the workflow engine is that these choices can be changed by the site at will via changed workflow rules.

In summary, Fig. 5 represents a design for an imaging center that collects all DICOM moves (other than the first from the modality) within the same data center and ideally on the same network segment. It also moves the PPS manager from being a radiology-centric device to a multidepartmental, multiprotocol device. If one ignores the dashed lines for a moment, there is very little more that is novel in this scenario; applications could be built as they are today, with large local file systems, and perform their requisites DICOM queries/moves from the VNA when they are notified of a new study of interest. But as alluded to earlier, to realize the maximum value of the VNA, we propose to remove the large local file systems and “extra” DICOM moves completely from the technologist, radiologist and other downstream processing/viewing systems. How?

Consider the normal behavior of a DICOM move transaction: a client issues a C-MOVE request for a given study(s) to a VNA. The VNA responds with a C-STORE operation to the destination’s DICOM receiver. The receiver software stores the files onto the client’s local file-system. Then another process becomes aware of the new files, indexes them into the application’s database, and begins whatever processing is desired. The key point to be aware of is, at the end of the process, DICOM files end up on the client’s file system. Is there a way to achieve this without actually moving the files over DICOM?

Indeed there is. Let us now take note of the dashed lines in Fig. 5. For illustration purposes, let us assume that the technologist application can mount the VNA file system in a manner similar to how a Microsoft Windows user mounts a remote network disk (Microsoft Corporation, Redmond, WA, USA). Further, assume that VNA also mounts the file system of the technologist applications. When the technologist application is alerted to new studies via a RAD-11 (for example) transaction, it issues the C-MOVE request as mentioned above. Only now, the VNA does something different. Rather than sending images over via a C-STORE operation, it creates symbolic links to the images on the technologist’s server file system. The technologist application, in turn, sees these links as files, and when the application needs to open them, the real file is opened on the VNA. Using this approach, several points are immediately seen: the processing/viewing application cannot see files on the VNA until the ACL allows it. Further, the technologist application needs very little local disk storage (only for its own logic and user profiles), since it simply is reading/writing image files back to the VNA. In fact, the “file-system” on the technologist server would be best served by being a so-called RAM disk, that is, a device that acts like a disk (only at least 100 times faster), but is really only a special location in the computer’s main memory.

The advantages of the approach just outlined are several: a viewer server needs no large disks, transfers of images from the VNA to the viewer occur over the highest performance network protocols available, writes to the server occur at RAM speeds, and very little needs to be changed on the various viewing applications servers to support all this. The main work lies on modifying the VNA’s DICOM sender to allow this workflow for participating servers. Then all that remains is permitting the VNA and downstream server(s) to mount each other’s file systems. There is one caveat of course; the VNA and the server must both have the same “endianess” for the files to be directly shareable between them [10]. However, with the vast amount of imaging software being delivered on Intel compatible processors, this is not a great impediment (Intel Corp., Santa Clara, CA, USA).

Conclusions

In this paper, we have endeavored to craft a conceptual outline of a medical imaging system that minimizes image file movement across slow networks, concentrates the bulk of any required moves within a single data center (and ideally network switch), and thus promotes the strengths of cloud based computing. To achieve the maximum potential of VNA-based server architecture, a slight modification has been suggested to a standard DICOM sender that would enable direct file reads/writes among systems, while still largely relying on the vast efforts in IHE integration that have already been invested. This approach addresses the need for high speed movement of full fidelity image files among the information systems.

User interaction with the system can be implemented over thin clients that leverage existing remote display and/or streaming protocols. Such methods not only avoid moving large image sets back out of the data center, but enhance security if a viewing client platform is lost or stolen [1 op cit , 11].