In my recent blog about the Standards Work Ahead in 2012, I called DICOM a non-standard standard.
This generated numerous email messages, phone calls, and blog comments.
Let me clarify what I meant.
DICOM is a great standard that has unified many processes within organizations, linking radiology modalities and PACS systems.
Why do I believe additional work is needed?
In December, my wife visited a hospital near our home for a diagnostic mammogram. It was clear she needed followup care with a cancer care team. We decided that Beth Israel Deaconess would be ideal because of its electronic health records and personal health records that would help Kathy coordinate her care. We asked for the images to be transmitted to BIDMC and we were told that we needed to visit the radiology department Monday-Friday 9am-5pm for a CD to be created so that Kathy could drive is 20 miles to BIDMC. The CD contained a proprietary viewer that required Windows and hence was not visible on our home computers (all Mac OSX).
What would have happened in an ideal world?
1. An implementation guide for DICOM would specify required vendor neutral content - a basic set of metadata (patient identifiers, name of the radiology study, imaging techniques used etc.) that would work with any viewer - Siemens, Agfa, Philips, GE, Kodak, etc. Any vendor specific/proprietary metadata would be stored separately from the required basic content, so that extensions do not impact generic viewers. CDs with proprietary viewers and media formats should become a thing of the past.
2. DICOM combines content and transport in a single standard. Although that is create for communication within an organization, it is not sufficient for a healthcare information exchange world that uses the Direct implementation guide (SMTP/SMIME, XDR) for content exchange among organizations. The fact that vendors such as LifeImage, Accelarad, and Merge Healthcare have created their own image sharing networks suggests that more standards work is needed to create an open ecosystem of image sharing among organizations.
3. We should not require organizations who want to receive images to have PACS systems. Instead, EHRs with vendor neutral DICOM viewers should be able to incorporate DICOM content sent via Direct into patient records.
Thus our work on imaging standards should build upon the DICOM foundation we have today, but eliminate optionality for a basic set of metadata, ensure that any proprietary extensions to metadata do not interfere with vendor-neutral viewing, embrace simple transport approaches for cross organizational exchange, and enable even the simplest of EHRs to be participants in image exchange.
We'll do this work in the Healthcare IT Standards Committee from April to June, engaging the industry experts who have worked so hard on DICOM to date.
I hope that makes sense!
Subscribe to:
Post Comments (Atom)
14 comments:
Hi!
You can try to view ur DICOM Images with IrfanView. There is a plugin for DICOM.
I can also recommend jDicom Tools by TIANI (it is JAVA)- but more for technicals.
Standardization is a main problem in healthcare domain. Also a "standard" like HL7 has a large room for interpretation.
But - have a look at IHE. It is a orgranisations from vendors and professionals for a better comunication between healthcare systems. http://www.ihe.net
And this is for your cd exchange:
http://wiki.ihe.net/index.php?title=Portable_Data_for_Imaging
Greets,
Chris
Hi,
I think this is the result of having a too wide protocol, when we try to cover so many scenarios that the protocol becomes useless.
My opinion: More than a standard, DICOM is like a guidelines.
Regards,
Pablo.
Hi John,
Everything you ask for is included in the IHE-PDI (Portable Data for Imaging) specification. So, the specification is available, and actually has wide support. There are very few imaging products that don't support PDI today.
Note that there can be an executable program on the CD. This is provided for those that don't have a viewer. There can also be an HTML navigation (similar to XDM) on the CD too.
But the DICOM content is a MUST, and the DICOM content MUST be described in an independent metadata file (DICOMDIR).
It is very possible that the CD you did receive is fully PDI compliant. Meaning that with a PDI compliant viewer you can view and manipulate and import the images.
In fact HealthVault is IHE-PDI capable. So, go ahead and give HealthVault your CD.
I covered this on my blog back in October.. http://healthcaresecprivacy.blogspot.com/2011/10/patient-access-to-radiology.html
Great post and here-here. Vendor neutral, or at least, agnostic viewers would be wonderful.
In fact we should be pushing towards a systems that don't rely on java, but instead use HTML5 - and the viewers are coming...
I had the same issue. Trying to be an evangelist and early adopter, I received my X-ray and MRI on two CDs, but had no way to import them into my PHR. All I can do is carry them around with me anytime I visit a doctor. I will say it did save some expense for when I saw an Orthopedist. He initially wanted to run his own x-rays. After viewing what I provided, which was taken only two previous months earlier, he decided new x-rays were not needed. Please solve this HITSP committee. It makes me think of Robin Raiford's stories about pictures of a puppy, and the actual puppy (when referring to non-discrete vs. discrete data). I hope VNA solutions for archiving can help provide that capability.
Completely agree the discs need to be platform neutral. We were able to load DICOM images with this opensource Osx DICOM viewer, and worked very well for us.
http://www.osirix-viewer.com/
Best,
Tom
John,
I believe you have identified a significant challenge- the easy and secure exchange of radiology images and reports- but looked to the wrong place for the solution.
The DICOM standard is a robust and evolving standard that addresses many aspects of image handling quite well. It is a major enabler for radiology services throughout the world.
You've identified a very real workflow problem; one that requires DICOM as well as other standards to solve. It is increasingly clear that the imaging exam is a highly valued part of the medical record, and must be included in the overall effort to instantiate healthcare data exchange. In fact, the world of radiology anticipated this and has worked through IHE since its founding a little over 10 years ago to develop profiles relevant to this use case.
Today there are 3 IHE Radiolgy profiles that address most of the issues you have identified. THese are Portable Data for Imaging (PDI), Basic Image Review (BIR) and Cross-Enterprise Document Sharing for Imaging (XDS-I.b). These 3 profiles integrate the appropriate standards and describe workflows that enable practical solutions to the issues you describe.
Now, realistically adoption has been slow. The event you describe is in part caused by the fact that the CD you described probably did not fully abide by the PDI profile. As you well know, if standards are not followed then breakdowns occur.
But I think there is good news already developing. More and more vendors and departments are following these profiles. The last one XDS-I.b is likely to be the solution that will facilitate internet based image exchange along with XDS for many other forms of healthcare data. Some of the vendors that you have mentioned as well as others have embraced this profile. It can serve to allow for internet based image exchange in a safe, secure, and expedient fashion.
The RSNA Image Share project, sponsored by NIBIB, is a pilot that employs XDS-I.b to exchange images under patient control through image enabled PHRs. This is live at 5 sites and we hope to greatly expand it. We have 2 vendors providing PHR services and expect to add more shortly. THe solution includes on the fly web viewing and the capability to download the full DICOM data set to an authenticated archive. The University of Alabama has a consortium using XDS-I to exchange images in a more conventional HIE.
I think we are on the way! We need to encourage vendors to follow standards; today many do as evidenced by the robust testing on the part of about 100 companies at the January 2012 IHE connectathon.
Good things are coming!
David S. Mendelson, M.D.
Co-chair IHE International
Principal Investigator RSNA Image Share
Hi John
As a CIO, hopefully you are familiar with what goes on in your own radiology department(s), where standard DICOM (IHE PDI) CD import and export should be routine, right, not to mention your own hospitals' relationships with and/or use of LifeImage which imports and exports DICOM objects (content without transport; shock, horror!)) relatively seamlessly.
Different image sharing networks and companies exist because there is a competitive business model, just as there is for different PACS or different hospitals, for that matter, not a lack of interchange standards or "implementation guides" (profiles ?) for them.
I reiterate from my previous comment that DICOM does NOT mix content and transport, but provides separate components for each, which allows for the content to be separable, so I for one would prefer it if you would stop misrepresenting this.
Otherwise, in IHE we could not do XDS-I, for example, and demonstrably, we can.
On the subject of which, since you mention "Direct" and XDR, I should let you know that in this year's IHE cycle we are doing XDR-I to complement plain XDR (analogous to XDS-I as opposed to XDS). You can find the details in the usual places, including "http://wiki.ihe.net/index.php?title=XDR-I_-_Detailed_Proposal" and "http://wiki.ihe.net/index.php?title=Radiology_Technical_Committee#Cross-Enterprise_Document_Reliable_Interchange_for_Imaging".
You might want to consider the extent to which this is relevant in your committee. At the very least, hopefully your committee and ours will not be working at cross-purposes.
Also, to belabor your own point about separating content and transport, the XDR-I profile will focus on the transport, just like XDR, and NOT sub-specify the content in terms of DICOM attributes or extra meta-data beyond the very basic, since as I pointed out previously, the content simply is not a practical factor in these use-cases. XDS(-I) has already set the necessary standard with respct to (registry) meta-data.
David
PS. Since anecdotal accounts can be informative, albeit not representative, I would point out wrt. your wife's experience, that devices and organizations that do not write DICOM/PDI CDs and depend on proprietary viewers are not only evil, but have been put on notice by a statement from the AMA that effectively renders them as performing below the standard of care (not that the AMA would put it that way).
Further, in my anecdotal experience as a patient, I had no trouble a few months ago whilst bleeding from a fractured hand all over the neighborhood community hospital emergency room floor, in obtaining a standard DICOM CD from the ER radiographer, immediately after the examination was performed. The points being that a) this was one of the (majority) of "good" hospitals in this respect, and b) patients should insist on leaving with their CDs (just like they would have with films), not waiting until "later", when they might be harder to obtain. They too were not part of any image (or any other record) sharing network as far as I could ascertain, not to mention being "out of state" relative to my home.
Obviously we should be using the network for image transfer when it makes financial sense for everyone to do so, which with imaging excluded from meaningful use like incentives, coupled with CDs really being quite adequate if standards are enforced, right now it may not.
I hope you wrote to your peer CIO at the offending institution, and let them know what you thought of their proprietary CD, assuming that you checked it really wasn't a valid PDI (DICOM) disc, of course.
Hi John:
I've found OsiriX (http://www.osirix-viewer.com/) to be a good OS X viewer for those CDs the doctor hands out. I also hate all the time wasted burning CDs in the medical office; may just be inertia from assuming the physicians don't have Internet in their office.
-Lyle
It's not a problem with DICOM, but rather with NOT using it. See this post
I guess my (much) longer comment from yesterday must have got "lost" somehow, but the important part of it that doesn't repeat what others have said in the meantime is ...
If you are going to use something like "Direct" to push images, you need to account for IHE XDR-I (which is being worked on this IHE Radiology cycle).
David
Completely agree, however it is not a problem with the standard but rather vendor implementation and vendor's inability to have an agnostic viewer. As a PACS admin I often get asked to produce a CD but for a Mac for physicians, PACSCube does not do that. MD's don't like to hear that this is not possible and I usually get an ear full. Ideally, it would be great for PACSCube to burn sudies as a DVD. Our hospital also has an online 30 day image viewer for physicians with access.
Although I agree, John, that DIrect is the future for cross-institutional communications, I don't think that 500 MB DICOM attachments are likely to flow through as attached documents.
Instead of offering patients a CD, their images can be made available through the patient (or provider) portal just like the Blue Button files now offered by all VA and DOD hospitals. Blue Button can avoid the delay of moving 500 MB before viewing and HTML5 viewers are coming on the market that work across all modern browsers and mobile devices.
What's missing is the ability for your wife to give her doctor at BI a "valet key" to just that part of the source hospital's patient portal that would include her images. That valet key functionality (technically known as OAuth) is also a part of the Markle Foundation Blue Button best practice. With Blue Button and OAuth, a simple Direct message can carry a secure streaming link to the images ready to view in seconds and available for download as DICOM if desired.
What will it take for hospitals outside the VA / DOD to implement full-featured and standards-based Blue Button patient and physician portals?
Adrian
Osirix is generally able to track down dicom images on almost all image CDs. It will scan the entire disk for dicom files regardless of how the cd is formatted. I often then export this back out as a red-book dicom cd which can be loaded into bidmc's pacs for some images I need loaded from an external hospital.
That being said not sure why these pacs packages can t just produce a clean cd with their viewer on it which can be imported (proprietary or common viewer shouldn't effect this)
Post a Comment