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.
5 comments:
The imaging community is in dire need of help getting their data moving. Very happy to see this post! As part of the HIMSS/ONC Interoperability Showcase in New Orleans we (National Association for Trusted Exchange) demonstrated Care Coordination between Oregon and California in a trusted environment. The clinical use case incorporated the movement of clinical summaries, Chest xray images (Jpegs) and a 4D echo using Direct Secure Messaging. Direct can handle the imaging attachments for sure, but it will be exciting to see how this develops in a way that allows for greater access and ease of viewing.
The imaging community is in dire need of help getting their data moving. Very happy to see this post! As part of the HIMSS/ONC Interoperability Showcase in New Orleans we (National Association for Trusted Exchange) demonstrated Care Coordination between Oregon and California in a trusted environment. The clinical use case incorporated the movement of clinical summaries, Chest xray images (Jpegs) and a 4D echo
Health Magazine
Maybe you heard what you wanted to hear :)
I am sure he knows that it is important to:
1. distinguish between DICOM the payload and DICOM the protocol (and in the later case the traditional DICOM protocol from WADO, WADO-WS and WADO-RS, which are all part of DICOM too, but http-based), as we have discussed before
2. distinguish the use-cases, and using MU-speak, to distinguish View from Download and Transmit.
One can use standards to Transmit or Download DICOM payload images using WADO, WADO-WS (XDS-I.b)or WADO-RS for "long distance", since the original DICOM protocol does not always scale well over long distances optimized for http transport.
For viewing, as you say, alternatives to a DICOM viewer are possible and desirable, as the current craze for "zero footprint" and/or "universal viewers" would suggest, and all VNAs and image sharing solutions come with these, whether they be based on a transmitted payload of JPEG or similar, DICOM decoded in the browser one way or another, or something else designed (and optimized) for the task, but they mostly use "proprietary" code in the browser of one type or another (whether it be JavaScript or Java or ActiveX or Flash or Silverlight), because most (though not all) use cases benefit from some degree of client side interactivity. Currently these are characterized by tight client-server coupling, since at the very least, the navigational and control (HTML) pages are proprietary, even if the pixel data payload is retrieved and transmitted with a standard like WADO (which has been possible in a standard manner since 2002).
One cannot ignore the need to download and transmit a full set of diagnostic images to another system when required (e.g., to import into the PACS of a referral physician's facility for surgical or RT planning, 3D visualization, comparison as priors etc.), for which a DICOM payload transmitted in whatever manner is appropriate (DICOM traditional protocol, WADO-*, XDS-I.b, XDR-I, or event DIRECT email if the email can handle gigabytes of pixel data).
Anyway, needless to say, the imaging industry and the imaging standards bodies (DICOM and IHE Radiology Domain) are not ignoring the opportunities to standardize the areas of application that you describe.
On the security side, in imaging we rely on IHE ITI to guide us on the http front, and they have indeed been very active in this over the years (I assume you are familiar with their access control white paper), and recently they have been investigating OAuth and its relatives. Our goal, like everyone else's, is to leverage whatever single sign on distributed access control mechanism for providers and patients that the entire EHR industry (not just one popular vendor) standardizes on, rather than invent an image-specific incompatible solution, so if you know what that is, let us know.
Where there are gaps (e.g., for rich queries), DICOM working groups are busy filling them (e.g., QIDO), as is IHE (for example, the Invoke Image Display (IID) profile that we just finished, specifically to link EHRs to whatever viewer is available with a standard request).
Since this sort of thing is Hamid's bread and butter, I expect that he is all too familiar with the multitude of standard alternatives, and which the market has yet to decide is going to prevail, and the cost and risk he incurs by picking and choosing at this relatively early stage in evolution.
If anything, there are too many alternative approaches, yet just like the push versus pull, central versus distributed debates, SOAP versus REST, XML versus JSON, OAuth versus SAML debates, which will dominate where remains unclear.
In the long run, I think that we all share the goal of actually making the distinction between local and long-distance completely transparent, but for now it is a lot easier said than done.
DICOM, IHE and MITA folks would not doubt be willing to brief your committee, if you want.
For those unfamiliar with the acronyms:
WADO = Web Access to DICOM Objects (2004)
WADO-WS = WADO via SOAP Web Services (2011)
WADO-RS = WADO via RESTful Web Services (2013)
All three are officially final text. From a convenience point of view, the latter two will move inside Part 18 of the DICOM Standard later this year, rather than being separate documents.
WADO lets the client specify whether the payload returned by the server should be a full DICOM image, or a rendered JPEG with the relevant clinical, administrative and technical metadata stripped for display.
The imaging community along with almost all of healthcare is facing the challenges of exchange. What shouldn't be lost in this discussion, first and foremost, is the importance of maintaining the rich diagnostic information that is present in current imaging studies. Emerging, exciting new imaging technologies will only increase what we can offer patients. DICOM has been a major enabler of our ability to advance imaging. Accurate diagnosis should be priority #1.
With this in mind, how can we share this information, without compromising it? How do we ensure it is in a format useful to a variety of end-users? The radiology community recognizes that different users may have different viewing requirements- as long as the full set of diagnostic data remains available as needed. DICOM working groups and organizations such as IHE are working hard to ensure easy and appropriate availability. We know that there are quickly evolving means of viewing and moving this information.
In viewing some of the discourse one might think we are polarized- I would submit that we are not. In fact, along with many other parties, the radiology community is making a strong and aggressive effort to achieve effective distribution of our information while advancing the diagnostic and therapeutic applications in our domain.
One solution may not solve all issues. Hopefully we can converge on a limited number of overlapping solutions that together can be deployed in a cost-effective manner providing our patients with the optimal care available. And make no mistake, none of these will be final solutions, they will need to evolve. The Radiology community is doing just this with the standards we have in place today!
Post a Comment