Image Exchange

Last week, the Clinical Operations Workgroup of the HIT Standards Committee held its third hearing on image exchange, seeking testimony from Hamid Tabatabaie, CEO of LifeImage and Michael Baglio, CTO of LifeImage.

He made several important points
1.  We should think of image exchange as having two major categories - local and long distance.    DICOM works well for modality to PACS connectivity within an enterprise (local).   DICOM was never designed for internet-based cross organizational image sharing.   DICOM images tend to be large, including a vast amount of metadata with every image object in a study.    DICOM was also never designed to work well with the kind of firewalls, load balancers, and network security appliances we have today.

2.  Two image exchange architectures have been used in the marketplace to date, which Hamid called "iTunes" and "Napster",  classifications first suggested by Dr. Keith Dreyer.

iTunes refers to the centralization of images into a single repository or what a appears to be single repository - it may actually be a clearinghouse to other image stores, but the user never knows that.   Query/response transactions against this central repository can be straightforward, using standards such as Blue Button Plus/Direct for share, access, download.

Napster refers to a decentralized, federated model in which images are not placed in a single repository -    an index of images and their location is all that is centralized.   Typically, query/response is done with standards such as XDS-i.   XDS itself was never designed for image exchange and is incomplete.  It can be challenging to search for a single exam on a known date of a known modality type.

3. Current standards do not include any privacy metadata and security is not built in.  Future standards should enable applications to restrict image flows based on consent/patient preferences.

4.  We need a web friendly method for visualization that does not require the download of a proprietary viewer, one that is often operating system specific.   Consumers should be able to view thumbnails of images on a smartphone, tablet, or the device of their choosing without special software.   If the full DICOM object is needed (patient mediated provider to provider image exchange), download and transmission should be enabled using standards such as REST, OAUTH2/OpenID, and secure email.

5.  Hamid made a forward looking statement that should be carefully considered as we plan the lifecycle of existing Radiology Information Systems (RIS) and Picture Archiving and Communication Systems (PACS) systems.   He is seeing EHR features expand to cover many aspects of RIS workflow.   If scheduling, image viewing, report construction with templates/front end voice recognition, and easy exchange of reports with clinicians are supported by the EHR, maybe radiologists (some of which want to qualify for meaningful use payments) will start using increasingly capable EHRs instead of RIS.   Vendor neutral archives (VNA) which store images of all "-ologies"  and enable easy search and retrieval may replace PACS.   Imagine 5 to 10 years from now when RIS/PACS no longer exists and is replaced by EHR, HIE,  and VNA.   Interesting possibility.


Great testimony.    In the past when I've suggested DICOM is not ideal for internet-based multi-organizational exchange, I've been criticized.   In the past when I've suggested that DICOM has issues of vendor-specific proprietary metadata extensions, cumbersome viewers, and heavy payloads, I've been challenged.   It's refreshing to hear from someone doing the hard work of high volume image sharing that current standards not ideal.  We need new approaches to move payloads efficiently on the internet, view images via web-browsers, facilitate easy searching, support security, and enable multiple provider/patient/group sharing use cases.