ACR Imaging IT Reference Guide: Image Sharing: Evolving Solutions in the Age of Interoperability

Abstract

Interoperability is a major focus of the quickly evolving world of Health Information Technology. Easy, yet secure and confidential exchange of imaging exams and the associated reports must be a part of the solutions that are implemented. The availability of historical exams is essential in providing a quality interpretation and reducing inappropriate utilization of imaging services.

Today exchange of imaging exams is most often achieved via a CD. We describe the virtues of this solution as well as challenges that have surfaced. Internet and cloud based technologies employed for many consumer services can provide a better solution. Vendors are making these solutions available.

Standards for internet based exchange are emerging. Just as Radiology converged on DICOM as a standard to store and view images we need a common exchange standard. We will review the existing standards, and how they are organized into useful workflows through Integrating the Healthcare Enterprise (IHE) profiles. IHE and standards development processes are discussed. Healthcare and the domain of Radiology must stay current with quickly evolving internet standards.

The successful use of the “cloud” will depend upon both the technologies we discuss and the policies put into place around these technologies. We discuss both aspects. The Radiology community must lead the way and provide a solution that works for radiologists and clinicians in the Electronic Medical Record (EMR). Lastly we describe the features we believe radiologists should consider when considering adding internet based exchange solutions to their practice.

Overview

The appropriate, secure, and confidential exchange of protected health-related information such as imaging exams and reports has long been an essential part of quality medical care in general, and radiology practice in particular. The principal reason to exchange data has been to establish a longitudinal imaging record for the patient and to provide historical examinations usually to compare with a current examination. In addition, patients often receive care from multiple providers or institutions, resulting in the fragmentation of data. This disconnect may lead to duplicative examinations, often associated with unnecessary cost and radiation exposure. Ready availability of appropriate image exchange technology may help avoid duplication and the untoward byproducts [1–3].

What constitutes image sharing? Sharing the information content of images is the primary objective. However, if a report has already been furnished at the originating site, its transmission is a key element of the information exchange, and in some circumstances it may be as important to securely share as the images themselves. Both images and reports contain metadata that are often useful in the management of the patient. Thus, different constituents such as referring physicians or other specialists will require different data elements. The number of actors interested in and related to patient images and imaging reports is expanding [1–3].

In the rapidly changing health-care environment there are several additional reasons why image and report sharing are growing in importance.

Image Sharing—Why?

• Availability of a historical exam during interpretation of a current study may improve the quality of interpretation

• Diminish inappropriate utilization (duplicate exams) by making prior and complementary exams easily accessible, thus reducing health-care costs [4,5]

• Diminish radiation exposure to the individual patient and general population by avoiding exam duplication

• Diagnostic information from one imaging exam is often used by multiple care providers when caring for the same patient

• Make images and reports contemporaneously available at the point of care

Image Sharing—Who Participates?

• Primary interpreting radiologist (site generating the initial data)

• Referring physician

• Consulting physician

• Other radiologist – “2nd opinion”

• Other hospital(s) or health-care enterprise

• Clinical trial

• Patient

• Patient surrogate

Image Sharing—How?

• PACS access

• Film

• CD

• Online (Internet, “Cloud”)

PACS can itself be employed as a means of sharing images. Access rights to a PACS system can be extended to providers outside of the local enterprise. There are security and confidentiality risks associated with extending privileges to individuals not normally credentialed in an enterprise PACS system. One must take care to see that the appropriate legal agreements, policies and practices are put into place and explained to the “outside” user. Keep in mind that one is usually opening the door to the entire archive in such a scenario.

Film-based image interpretation still exists, particularly in the offices of nonradiologist providers. These exams may provide relevant information in the evaluation of the patient. Offices that primarily produce film are rarely capable of creating copies. Thus, patients shoulder the burden of carrying the only existing copy, i.e., original examination, to subsequent providers. This is a cumbersome process, but one that shouldn’t be ignored, particularly when the prior exam can assist in the treatment of a patient. It is not uncommon for a radiology office to digitize and import these exams into a picture archiving and communication system (PACS). A tradeoff results from easier accessibility to the data versus degradation of the exam in the process of importation.

Conceptually, the compact disc (CD) appeared to provide the ideal solution for image exchange. Despite significant advantages as a transport medium when compared to film, several challenges have arisen. CDs remain the most common means of exchanging imaging data, and several steps can make this process useful and less burdensome.

Lastly, online image exchange using the “cloud” is now available. In other areas of life, businesses have become accustomed to moving many types of information across the Internet. Music, photos, videos, and financial information are some of the data transferred using cloud technology. It is clear that society finds this means of information exchange efficient and desirable. Acceptance of this relatively secure exchange of confidential information across the Internet indicates a reasonable level of trust by users in this technology. However, the challenge of ensuring the highest level of security and confidentiality for Internet-shared health-care data is not trivial. Experience with the current, commonly used data types may inform the pursuit of health-care information exchange.

Current and future Internet technologies are exciting, dynamic, and offer opportunities to promote the seamless exchange of health-care data. As newly developed solutions are implemented, it is important to note that the medical imaging profession has experienced tremendous growth, in part through the observance of standards such as DICOM and HL7. Ideally new exchange technologies will respect these standards that support hardware interoperability while leveraging the advantages of Internet-based information exchange.

Both DICOM and HL7 are constantly evolving. A current focus is to keep both current with modern internet technology. Many of the applications we all use daily on the Internet are based on RESTful services. REST is an acronym for Representational State Transfer. This is an architecture that is commonly used by large organizations, including Google, Yahoo, Microsoft, Amazon, etc., to communicate with end-users through a browser. It is an efficient means of communicating information that allows more complex processing behind the scenes.

There are new DICOM RESTful services intended to allow imaging to leverage these modern Internet technologies. This includes QIDO-RS to query for images, WADO-RS to retrieve images, and STOW-RS to store imaging data. HL7 is in the midst of its Fast Healthcare Interoperable Resource project. In a similar manner this is intended to bring RESTful services to HL7 standards.

Integrating the Healthcare Enterprise

Integrating the Healthcare Enterprise (IHE) is an endeavor founded in 1998 and formally incorporated in 2007; the IHE mission is directed at enabling transparent interoperability between the many systems used throughout health-care enterprises. This interoperability is accomplished by identifying common workflows, description of the systems used, the transactions between these systems, and the existing standards (DICOM, HL7, etc.) that might be employed for these transactions. End-users, engineers, and other technical experts work together to organize these factors into so-called “IHE profiles” that can be used to solve a specific workflow challenge. When IHE profiles are followed by vendors, their products will have a consistent expected behavior, and can then be used together in a “plug-and-play” fashion. The end-user can have a well-defined expectation with regard to what a product can do and specifically what its output will be. Connecting systems becomes easier and less expensive. There should be little need for customization in such an environment.

The entire IHE process is intended to streamline the purchase of IT solutions and make it less expensive. The radiologist with only a minimal-to-moderate level of technological knowledge should be able to make an intelligent purchase without the assistance of an engineering consultant. Although a purchase may be plug and play, it does not mean that the solution is not technically sophisticated. However, it should be easily deployable into an existing legacy environment, have minimal interface needs, and be ready to use. The radiologist should be able to focus on learning the functional details of the solution and not be distracted by the need to interface the solution to the surrounding environment.

IHE International—The Organization

IHE activity is divided into “Development” and “Deployment.” Deployment activity is broken up by international regions. For example there is an IHE USA, IHE Japan, etc. The deployment groups are responsible for publicizing and instantiating the IHE profiles in their region or country. They may also help to modify IHE profiles that require some customization for a specific geographic area.

IHE Development Domains support work to develop IHE Integration Profiles. These groups represent health-care specialties as follows:

• IHE Anatomic Pathology (ANAPATH)

• IHE Cardiology (CARD)

• IHE Dental (DENT)

• IHE Endoscopy

• IHE Eye Care (EYECARE)

• IHE IT Infrastructure (ITI)

• IHE Laboratory (LAB)

• IHE Patient Care Coordination (PCC)

• IHE Patient Care Device (PCD)

• IHE Pharmacy (PHARM)

• IHE Quality, Research, and Public Health (QRPH)

• IHE Radiation Oncology (RO)

• IHE Radiology (RAD)

These domains have international membership. Yearly they identify workflow processes that would benefit from a formal profile. They then gather the appropriate end-users and technical developers to work through the details of the profile. This may take place over one to several years.

IHE profiles are published as part of the IHE Technical Framework [6] for each of the domains. The Technical Framework is actually published in two volumes. Volume 1 is titled “Integration Profiles,” and Volume 2 is the actual “Technical Framework.” Volume 1 describes the clinical need, use cases, and the subsequent individual actors and transactions for each profile. Volume 2 describes the technical details and specifications for each transaction.

These are publicly available documents providing the technical specifications and guiding the implementation of system(s) that vendors should follow. Customers should familiarize themselves with relevant profiles and then specify compliance with these during the request for proposal (RFP) and contracting process.

IHE Radiology

IHE Radiology is the oldest domain and has a robust portfolio of profiles:

• Radiology Scheduled Workflow (SWF)

• Patient Information Reconciliation (PIR)

• Consistent Presentation of Images (CPI)

• Presentation of Grouped Procedures (PGP)

• Access to Radiology Information (ARI)

• Key Image Note (KIN)

• Simple Image and Numeric Report (SINR)

• Charge Posting (CHG)

• Post-processing Workflow (PWF)

• Reporting Workflow (RWF)

• Evidence Documents (ED)

• Portable Data for Imaging (PDI)

• Nuclear Medicine Image (NMI)

• Cross-enterprise Document Sharing for Imaging (XDS-I)

• Mammography Image (MAMMO)

• Import Reconciliation Workflow (IRWF)

• Teaching File and Clinical Trial Export (TCE)

These profiles fall into one of three classes:

1. Content profiles that address the management of a particular type of content object

2. Workflow profiles that address the management of the workflow process by which content is created

3. Infrastructure profiles that address departmental issues

Each year there is work to refine existing profiles and develop new profiles as new technologies present and workflows evolve. When a new profile is believed to be finished it is published for trial implementation. Early experience may result in some further refinement, after which the profile is published as final text. Over the years, as changes are brought forward, revised versions are published.

As the numbers of domains have expanded, some of the profile work has started to overlap. IHE international has provided a mechanism to reconcile overlapping profiles, retire or deprecate some, and reference the “transactions” and actors of one domain in the work of another. This works toward the goal of transparent interoperability and prevents redundant efforts. The profiles of the IT Infrastructure domain have often found re-use in radiology.

IHE Profiles

The Development Process

The IHE profile development process involves the following:

1. Define a workflow problem.

2. Identify experts who will work to develop the profile.

3. Identify the systems or “actors” and the transactions that will take place between them.

4. Identify the existing standards that are applicable for the transactions.

5. Develop a consensus as to how the actors should work together, which transactions are applicable, and the standards that are to be followed.

6. Formally propose this solution as an IHE profile.

7. Release the proposed profile for public comment and revise accordingly.

8. Release the revised profile for “Trial Implementation.”

9. Allow for testing to take place on the part of vendors interested in providing solutions based upon the profile. Such testing takes place several times a year, internationally, at “IHE Connectathons.”

10. To finalize the profile, continue to allow vendors to test and establish that their product has tested successfully for the given profile. They may publish an “Integration Statement” indicating that they have successfully tested a profile, thereby reassuring customers that the product will behave in an expected fashion.

Actors and Transactions

Once the community has identified a workflow that it wishes to develop into an IHE profile, the first step is to identify the systems involved. These systems and their component modules are the actors. This needs to be done to a very granular level. Once all the actors are identified, the transactions that take place between them can be identified. In most cases the transactions will come from a variety of existing standards, some that may compete with one another. Then the task of the development team is to select the most desirable transaction.

Cross-Enterprise Document Sharing (XDS)

XDS is a set of recently developed profiles that are directed specifically at the exchange of health-care information between legally disparate enterprises, including individual providers and large health-care systems. The IHE ITI domain designed XDS to describe the transactions needed in a health information exchange (HIE). These are depicted below in Figure 1. The data types are numerous and include discrete lab data as well as text data, such as a medical summary. The information starts out at the local site where it was generated, the “document source.” It is then registered in the HIE “document registry” so that it can be discovered by others participating in the exchange (or in IHE terms the “affinity domain”). A duplicate copy is stored in the document repository. When the patient travels to a different participating entity, that provider, known as the “document consumer”, can query the HIE if proper consent, which may be governed by local policy, is obtained. The document consumer may then discover and retrieve the available information. These actors and transactions are depicted in the schematic below.

Figure 1.

Cross-Enterprise Document Sharing – b (XDS.b) Actors and Transactions Diagram (reprinted with permission from Integrating the Healthcare Enterprise co-chair David S. Mendelson, MD, FACR).

XDS-I—Imaging Exchange

There is a variant of XDS for imaging known as XDS-I. Why? Imaging exams are much larger data sets than the text and discrete data that make up much of the medical record. The cost of storage and the bandwidth required to move the image data to a repository and then to a document consumer have been considered impediments to using the architecture of XDS. Instead of moving the images to the repository, a manifest of the exam listing the available images, known as a Key Object Selection (KOS), is placed in the repository when the exam is registered. When a document consumer wishes to retrieve the images they would first retrieve the KOS. The KOS directs them to retrieve the images from the originating source, and it also lets the consumer know how many images to expect. For now, this is the way imaging data flows in IHE-enabled imaging exchanges. It remains to be seen whether this methodology will converge with basic XDS as the cost of storage and bandwidth diminishes.

XDS-related Profiles

IHE has evolved several parallel exchange mechanisms with XDS as the basis to address variant use cases. Cross-Enterprise Document Reliable Interchange (XDR) is a point-to-point mechanism without a formal health information exchange.

XDR provides document interchange using a reliable messaging system. This permits direct document interchange between electronic health records, patient health records, and other health-care IT systems in the absence of a document-sharing infrastructure such as an XDS registry and repositories.

The Cross-Community Access profile is designed to allow independent XDS networks to communicate and exchange information with one another. One can begin to facilitate local, national, and international information exchange using these profiles as building blocks.

A related profile, Cross-Enterprise Document Media Interchange (XDM), provides document interchange using a common file and directory structure over several standard media. This permits the patient to use physical media to carry medical documents. This also permits the use of person-to-person email to convey medical documents.

Practical Implications and Implementation Issues

The IHE XDS profile is particularly relevant to the exchange of health-care information. As noted previously, it is part of a family of evolving HIT interoperability and exchange methods intended to facilitate the secure and confidential but transparent exchange of the patient’s health-care information. Providers need this information to deliver high-quality care to their patients. In the United States, this notion of interoperability is emphasized by the federal government through the Health Information Technology for Economic and Clinical Health (HITECH) program. This program awards providers and health-care enterprises financial incentives for implementing health information technology and using it in a “meaningful” way.

What to Ask Your IT Staff and Vendors

Ask if the system you are about to purchase is compliant with the relevant IHE profiles.

The entire IHE process is intended to streamline the purchase of IT solutions and make the process less expensive. As noted, compliance with IHE profiles should provide for an easily deployable solution without the need for expensive interfacing services. Plug-and-play solutions should be our expectation.

Use of CDs

The opportunity for digital image information exchange was present from the advent of digital image acquisition. However, for many years, digital images were typically printed on film and reviewed and exchanged in an analog fashion (i.e., nondigital images). Only as traditional film images (radiography) became digital did practices reach the point at which it became economically feasible to use digital media for image exchange. At the time (1990s), CDs were the most widely used portable digital media and were the obvious choice for exchanging digital images. With few viable alternatives, CDs rapidly replaced film as the exchange medium of choice. At one practice, the prevalence of CDs brought in by patients for medical care went from less than 5% to more than 95% in just five years [7]. Such an adoption curve is remarkably fast when compared to the rather slow adoption rate typical of major IT advances in health care.

Over the past 15 years, the adoption of CDs has been nearly complete, but changes in technology and complications with CD use have created pressure to develop alternatives. Over that time period, the file size of a typical cross-sectional imaging study has increased dramatically, largely due to the advent of CT multidetector technology and the growth in MR complexity and utilization. Exams using other modalities such as ultrasound have also seen increases in file size. As digital image archives become more established, the number of prior imaging examinations available on a patient also rises. Additionally, the number of examinations per CD has also increased, a recently noted trend. With the number of examinations and associated large file sizes, such data often rapidly approaches the maximum capacity of a CD (around 750MB). This has led some providers to use DVDs, which offer approximately seven times more capacity than a CD.

The DICOM standard was an important enabler for the use of CDs as a universal portable digital image medium. DICOM specifies the way that each image should be stored as well as provides a directory system that allows a suitable imaging application to efficiently discover what is on the disc. The adoption of the DICOM standard for storing images on CD was always high—greater than 90% around 2000—and has slowly crept up to over 95% in one study [7]. The use of the DICOM directory structure, however, is somewhat less prevalent—now at around 90% (unpublished data). The IHE organization has further elaborated how the DICOM standard is best implemented, resulting in the Portable Documents for Imaging (PDI) specification.

Switching to DVDs addresses the capacity problem but does not address the more fundamental issue of using physical media to transfer images. Having to share a physical disc among health-care providers has many important challenges. First, although it may be feasible in smaller facilities to simply pass the disc from one health-care provider to the next, or to have the patient carry it, this does not work well in more complex clinical scenarios.

Patients with intricate problems typically see multiple providers, creating contention for access to the single imaging disc that might be important in decision-making. Additionally, in the film era, it was not uncommon for a film to be lost. This scenario is possible for a disc, and losing all of a patient’s examinations would have an even greater impact. Handling the disc also risks physical damage that might make the disc unreadable. For these reasons, sharing the disc among health-care providers is not an optimal solution.

An alternative to sharing the physical CD is to import the CD contents into the local image viewing system, most commonly the PACS. Until recently, most PACS did not have efficient tools to import CDs. Now this option is more widely available and is often implemented in a way described by the IHE. The IHE provides for two main variants of image “import reconciliation workflow (IRWF)”—one where it is “scheduled” and one that is “unscheduled.” The main difference is that in a scheduled workflow, the system creates an order before the import is performed, which potentially allows information (such as the type of examination) to be included in the text description presented by the image viewing system. In the unscheduled scenario, the images are imported, but no additional information about the study is provided.

Importing the images into the viewing system allows enterprise-wide access to images, addressing the problem of a single disc being available to all health-care providers. It also addresses another important problem: many discs include simple viewing software, but those that don’t are not useable because DICOM viewing support is not included in any major institutional imaging operating system. Including a viewer on the disc addresses that problem but creates a new one—users need to be able to use the viewing software to view images. No such software package is regarded as universally easy to use. Each particular viewer has its fans and its detractors, and each seems to provide a slightly different array of viewing tools presented in nonstandard graphical user interfaces. IHE has created a Basic Image Review (BIR) profile to help increase the similarity of user interfaces on viewing packages to reduce the problems of familiarity. However, if one set of images is in one viewing application, and the follow-up examination has to be viewed in another application (possibly even on a different computer platform), comparing imaging time points is more challenging. Furthermore, notes or annotations created during image review may not be saved to the CD. Finally, compliance with HIPAA for CDs is more easily maintained when viewed from within a PACS than with a CD.

Another important challenge that is not widely recognized is the low data integrity of CDs. There are physical and logistical components to data integrity. When the physical integrity of the disc is degraded (such as by scratching or bending the disc), it can become unreadable. A more insidious integrity issue is whether the data on the disc truly belong to the intended patient. In one recent report, it was found that 1% of discs contained information that was derived from multiple patients, and another 1% contained only studies from a single patient source that was different from the intended patient. In many such cases, the “other” individual had a nearly identical name or medical record number, and the mistake was likely due to operator error during CD creation.

Images contained in CDs are considered patient medical information just like medical images on PACS or nonimaging medical data. It is often not clear if HIPAA applies because, for example, the data may be generated at a different facility, and the patient may have served as the conduit for the transfer. Much as verbal comments given by the patient to health-care providers are protected by HIPAA, it is rational to handle CDs in a way that protects the patient’s privacy. Since it is very difficult for a viewing application on the CD to truly authenticate and record actions of a user, it is virtually impossible for a CD-based viewing application to create proper HIPAA logs. From that perspective, data viewed as important enough to guide medical decision-making should be imported and viewed using the local viewing software to assure confidentiality and HIPAA compliance. Once import of images has been accomplished the disc should be returned to the patient as quickly as possible.

Finally, there is also a substantial cost to transferring images by physical media. The media itself is cheap—typically a fraction of a dollar per disc. However, the cost to produce a CD is rather high, though it is hard to determine the true costs. A survey of several institutions suggests the labor and system cost is in the range of $15 to $25 per disc. The cost is higher when images must be produced in an ad hoc fashion, requiring a query for a specific examination from the image archive, having a person wait while the images are written to the disk, and then creating a mailer and mailing the disc. The charge to the patient for creating a CD varies from $0 for the first copy to more than $40 per disc.

Image Sharing on the Cloud

Benefits of Cloud-based Imaging Platforms

The benefits of cloud-based imaging sharing platforms are becoming clear to stakeholders across the entire health-care enterprise. There is new value creation from cloud-based imaging by making images easily accessible for radiologists, referring physicians, and most importantly, patients. Cloud-based image sharing ensures increased availability of imaging studies in space and time, geographically and among multiple health-care providers at the point of care.

Key benefits include [5]:

• Increased quality of care

• Reduced costs

• Reduced hassle of duplicative imaging examinations

• Potentially decreased duplicative radiation exposure

Instead of sharing images through physical media, such as hard copy and CD, cloud-based image sharing enables files to be digitally transmitted in minutes or less. Furthermore, elimination of physical media saves cost and reduces potential errors for lost or corrupt data. Speed of image sharing will reduce the chance that patient care is affected by delayed diagnosis or treatment. Opportunities to reduce radiation dose occurs when cloud-based image sharing tools can avoid unnecessary repeat nuclear medicine, X-ray, or CT imaging, particularly for patients who may be transferred between institutions or who receive care at multiple facilities. Cloud-based image sharing represents a major evolutionary step in health-care informatics, enabling sending, sharing, and access to imaging from multiple disparate facilities.

When properly implemented, cloud-based solutions aim to safely and securely provide images and reports.

Suggested Strategy for Cloud-based Image Sharing Vendor Selection RFP

Each health-care facility or physician group will have a unique set of use cases and needs. Given the numerous cloud-based image sharing solutions currently on the market, it may be a daunting task to select a solution, but key specification categories can be used to review and select the appropriate solution. Such specifications include capabilities related to:

• Integration with existing systems

• Image storage

• Image distribution/sharing

• Image viewing

• Pricing models

DICOM and HL7 Integration

Significant efforts in the health-care information technology community are underway to improve the way computer systems share medical information. Specifically, one keystone effort is the IHE initiative. This effort aims to coordinate the use of established standards. Systems that use established standards such as DICOM and HL7 will be easier to integrate and implement in a health-care facility. DICOM routing, push, and query/retrieve (pull) features are essential components that should be supported in a cloud-based image sharing solution. Integration features need to support the following potential issues and requirements:

• Medical record number/patient identifier reconciliation

• XML/HL7 communication standards

• Autorouting of studies to PACS or other image archive via cloud-based solution

• Full DICOM routing support (push/pull)

Data Security and HIPAA Compliance

When evaluating systems designed to transfer digital data, particularly health-care data, a critical question to ask of any vendor is “Where are the images physically hosted?” A high- security, HIPAA-compliant data hosting center is essential. Data centers used by vendors need to meet strict standards for data protection in order to be HIPAA certified. These standards include specific on-site training for personnel. Data centers must also be subject to government audits by HIPAA inspectors. When selecting a vendor, one should enquire about prior audits and HIPAA certification of data centers used to store medical imaging data.

A solution that is both secure and HIPAA compliant must have the following features:

• Identification and authentication

• Authorized privileges

• Access control

• Confidentiality

• Integrity of data

• Accountability and audit trails

Image Viewer

Several methods of viewing medical imaging have been developed. Over the years, technologies have used methods including, but not limited to, Java applets, thin-client downloadable scripts, Adobe Flash, and ActiveX-based technologies. Each of these is limited in that it may only work on specific platforms, not all. One preferable option for the review of images for a cloud-based solution is the “zero-footprint viewer.” This latest development requires no software to download and, furthermore, is not limited by device or hardware specifications. From an IT security perspective this is highly desirable; many sites do not permit the installation of applications, including viewers, on front-end computers.

In today’s health-care IT enterprise, zero-footprint medical image viewers enable access to data on any device in a completely seamless manner. For example, tablets, smartphones, mobile devices, and any platform PC (Mac, Windows) are compatible with true zero-footprint viewers. Zero-footprint viewers are faster and utilize the built-in web browser plugins and technologies to enable viewing with minimal installation or software “footprints.” One should be aware that zero-footprint viewers often come with limitations in functionality. These limitations are often acceptable to the nonradiologist audience or for the specific purpose that the zero-footprint viewer is intended.

Pricing Models

There are general pricing models that exist for cloud-based image sharing solutions. Although in general any relationship with a vendor can be customized, there are fixed/subscription models and elastic (resource-based, pay-as-you-use) models. Typically, fixed and subscription pricing tend to be more traditional and may be renewable on a fixed time period—annually, for example. A resource-based usage model is a more novel and recent pricing model. In this elastic model, users pay per unit hour of use, CPU cycles, or bandwidth consumption.

Security

Although there are significant benefits to delegating imaging data to a cloud vendor, a major limitation is the risk burden that a health-care facility carries when relinquishing direct control of the imaging data. Placing protected health information (PHI) on the cloud requires significant due diligence regarding a cloud vendor’s security and privacy capabilities.

Vulnerabilities or security-compromise events may result in risk management challenges and liability issues that must be handled promptly. Data breaches can be costly due to downstream litigation, harm to health-care facility’s reputation, and government-based fines. The cloud vendor should have the ability to encrypt and back up all data. Furthermore, the cloud vendor should allow any client to conduct regular audits.

HIPAA Compliance

There are regulatory issues related to cloud computing for health-care enterprises. Specifically, establishing a relationship/contract with a cloud vendor for the transfer, storage, or management of any kind of health-care data, including medical imaging, requires compliance with HIPAA and the HITECH Act.

Bandwidth Requirements

Cloud-based services require significant investment in network resources and Internet bandwidth. In the noncloud health-care enterprise, users are accustomed to the advantages of a high-speed local area network (LAN). In a non-LAN environment, namely a cloud-based environment, users may experience performance or latency issues resulting in potential customer satisfaction issues. If the data center(s) are located geographically across multiple sites or if there are Internet-related outages, the network speed and, ultimately, access to mission-critical medical imaging data may be affected. As a result, in order to limit exposure to the risk of bandwidth compromises, testing of cloud-based vendors and cloud-based solutions are requisite. The cloud infrastructure must be stress-tested to ensure that the health-care data stored in the cloud is accessible, minimizing bandwidth bottlenecks. If there are any bandwidth issues during the testing phase, it is recommended that the health- care facility work with the vendor to resolve any potential issues prior to deployment of a cloud-based image sharing solution.

Image Sharing in Research

Image sharing in context with (multicenter) imaging-based research presents many similar and some unique challenges to the clinical use case. Imaging has long been used as a means to provide objective data on patients; for example, for study inclusion of therapy response assessment. It is also well recognized that research conducted at a single site is important but may not be generalizable. As such, sharing images is essential for high-quality and multicenter collaborative science.

Compared with clinical image sharing, there are some important and unique requirements for research. For many research protocols, adherence to a predetermined acquisition protocol is essential. In cases where there is a specific window of time for acquiring images (e.g., one requests imaging a certain number of days after an intervention), rapid transfer of images is required. This rapid transfer is necessary in some clinical situations, but in these specific scenarios, validation of protocol adherence must also be rapidly determined. In most cases, it is possible to automatically determine if the technical aspects of the acquisition have been adhered to by examining the associated DICOM metadata (e.g., slice thickness, mAs, TR/TE). Assessment of artifacts such as motion often requires human quality evaluation. Technologic solutions ideally enable rapid and secure transfer of properly anonymized data to a central site where technical and practical image acceptability can be determined rapidly, so that proper responses can be made (such as rescanning the patient).

Another unique demand of research is that reports are usually not required and might even be a liability because anonymizing report contents may be much more difficult and because blinded reader assessment may be required as part of the research protocol.

Removing portions of images that might have data in the image (not just the header but also information burned into the pixels of the image in case of secondary screen captures) are necessary functions. This can be a great challenge but fortunately is becoming less common. There are libraries being built that document which devices may “burn” information into images and the location of such burned in information, allowing automated deletion of that information.

As with clinical image sharing, the options for research image sharing include exchange of images using physical media such as CDs, as well as electronic transfer. The research community has a longer history of creating image transfer methods, and there are several open source and proprietary tools for research image exchange. Some utilize encryption, allowing use of public networks, and others require virtual private networks or even physically private networks. Nearly all such transfer methods require unique software to transmit the images, and since there is no standard for research image exchange, each method utilizes its own software. The result is that large imaging centers often have to support many different image transfer software platforms for various clinical trials. An example for a solution built to facilitate multicenter imaging research is the ACR “Transfer of Images and Data” (TRIAD) system. It has been used extensively in multicenter trials of the American College of Radiology Imaging Network^®.

Security is also an important consideration in research image sharing, but the issues are slightly different than in clinical image sharing. It is commonplace and expected by most institutional review boards that patient-identifying information will be removed before images are transferred to a researcher, whether for internal or external use. As such, random discovery of such information on research-related images is of lesser concern. Instead, investigators may worry that someone else might obtain unauthorized access to the data and gain knowledge of intellectual property unique to the research project. Although this risk is likely small, it is real, and it is an important consideration in design the security model.

Figure 2.

Cross-Enterprise Document Sharing for Imaging Diagram (reprinted with permission from Integrating the Healthcare Enterprise co-chair David S. Mendelson, MD, FACR).

Table 1.

Key features necessary for a cloud-based image sharing solution

Image storage

Security – Does vendor have security certification (i.e., SSAE-16)? Are data encrypted?

HIPAA compliance – Does vendor provide encryption and meet privacy laws in your state?

Backup – What is the disaster recovery plan?

Image data integration, distribution, and sharing

PACS compatibility

Ease of integration into health-care enterprise

DICOM routing (push/pull)

Image viewing

Viewer – Does solution have a zero-footprint viewer available?

Cost and pricing models

Fixed or subscription pricing

Elastic or pay-as-you-go plans (based on data or bandwidth usage)