The task of getting a patient’s medical images into the hands of the Specialists, Surgeons and Primary Care physicians becomes considerably more complicated, when those images are produced in an “outside” Organization. The practice of forwarding film-based images ahead of or with the patient is increasingly rare, having been replaced with the conveyance of digital copies of the patient’s images on CD or DVD. While this method of data exchange between organizations is considered more efficient and less expensive than forwarding films, the problems associated with data exchange using the CD/DVD are now legendary.
Aside from such obvious issues as viewing software and media compatibility, the principal problem is frequently basic data incompatibility. The DICOM standard allows a significant degree of “customization” of the DICOM image data header by the PACS vendors. In a white paper recently written by Dr. Wayne DeJarnette, titled Context Management and Tag Morphing in the Real World and posted on their informational web site, there are 10 examples sited where certain key pieces of information stored in the DICOM header need to be created, modified or moved in order for one PACS to be able to properly interpret the data created by another PACS. I highly recommend reading this paper to catch up on the subject generally referred to as Tag Morphing.
Apparently the problems associated with sharing medical image data using CD/DVD media has reached critical mass, because a number of solutions in the form of Data Exchange Servers and Data Exchange Services have recently entered the market. The focus of these new products and fee-per-study services is clearly to provide an end to the pains of data exchange. Unfortunately there is now yet another set of issues.
Clearly the most exciting solution to the data exchange issue is the “Image Share Service in a Cloud”. How can one not get excited about anything in a cloud? I counted a half dozen such “cloud” service solutions being exhibited at the 2009 RSNA or being advertised since. The simple, high-level summary description of this fee-per-study service is as follows. An authorized organization/user accesses the upload application through a secure web site. A couple of simple clicks and data insertions later and a patient’s medical image data is uploaded to a central server in the cloud. There are a number of methods for announcing the availability of these images in the cloud to the intended recipient, ranging from email notification to a phone call. The authorized organization/user then accesses the secure web site hosted by the cloud server and is granted access to only those images intended for their use.
Here is the interesting part. The intended user then downloads to their PC a very small piece of client software, in some cases there is no client software (zero), and this allows the user to view the images on their PC. Most of the display applications I have seen associated with this version of the cloud service are based on what is called “server-side rendering”, meaning all of the image rendering, processing, etc. being directed by the user is actually being executed on the server in the cloud. The result of this rendering, an HTML page, is all that is actually downloaded to the user’s PC. The actual image data itself is not downloaded to the user’s PC. The actual image data itself does not leave the secure server in the cloud, making this a very HIPAA-compliant application.
The current state of server-side rendering display applications allows for support of full-fidelity (loss-less) images and a full range of image processing features (2D, 3D, even Orthopedic templating), so the display application associated with most of these cloud-based image exchange services should be well received by a wide range of physicians seeking access to a patient’s images that were produced in an “outside” organization.
What I find most interesting about this approach to image sharing is that this solution totally avoids the data incompatibility problems encountered when an organization attempts to actually import digital image data from an “outside” PACS into their local PACS. Instead of importing “outside” study data into the local PACS, so the images can be accessed and viewed by the physicians using the local PACS web viewer, the cloud solution depends on its own embedded display application to access and display the image data. Just like all PACS that customize the image header of incoming image data, the cloud server only has to make the incoming study data produced by the contributing PACS completely compatible with its own display application. Moreover these new server-side rendering display applications frequently offer a wider range of features and functions than the incumbent local PACS “web Viewer”. It’s a clever solution that simply avoids the data incompatibility problem. As mentioned, this version of image sharing is available as either a purchased/leased “appliance” or a fee-per-study cloud-based service.
However clever this solution appears, it is important to remember that this version of image sharing does not solve the data incompatibility problem. If an organization wishes to assimilate a patient’s image study data created by an outside organization into that patient’s local longitudinal medical record (acquire the outside study data into the local PACS and add the study to the patient’s local folder); the data must first be modified, more specifically the DICOM headers must first be modified, to satisfy the idiosyncrasies of the receiving PACS. That means executing Tag Morphing of the type and complexity mentioned in the DeJarnette white paper. Unless the contributing and receiving organizations have only a few studies a day to exchange, a manual approach to this Tag Morphing would be too labor intensive to be practical, not to mention fraught with the potential for human error. In short the exchange of study data between two different organizations, and especially between disparate PACS requires an appliance or a fee-per-study service that can automatically execute Dynamic Tag Morphing on the incoming DICOM image data headers, prior to exporting the data to the recipient PACS. Any solution that does not support this key process, is naively relying on “DICOM conformance”, and we already know the problems with that approach.
In summary, I think an appliance or a cloud-based service that can provide the physicians with HIPAA-compliant internet access and display of a patient’s outside images is a significant advance over the CD/DVD method of data exchange. I think the display-only approach is a clever way to avoid the problems inherent in exchanging data between disparate PACS. The participating organizations simply need to understand their needs and make sure that the chosen solution will meet their expectations. Products or Services that suggest that actual data exchange between the PACS is an option should be expected to provide evidence that their product or service supports Dynamic Tag Morphing. Otherwise the organizations will likely end up right back where they are today with their CDs and DVDs.
Note: Currently there’s not a lot of information available on DICOM Tag Morphing out there on the web. In addition to the DeJarnette paper already mentioned, you might want to focus your favorite search engine on “vendor-neutral archive”, as I’m sure any of those vendors can provide additional info on this subject.