To me, the basic components of a medical record are Problems, Medications, Allergies, Notes/Reports, Lab/Micro Results, and Radiology results including images. Of all of these, image exchange between different vendor systems and among organizations is the most problematic. Standards exist to transmit the outputs of CT, MRI, Ultrasound and digital xray machines to PACS systems, but most vendors customize or extend the standards to meet their own proprietary needs. Sharing images among providers is essential for coordination of care and efficiency. The path forward to enable image sharing across vendors, modalities, and imaging technologies is not entirely clear.
Creating an archive of all image types used within an organization seems like a logical first step. I've written about the technologies to do this (Cool Technology of the Week ), which involve placing images from all departments into centralized storage devices (NAS, Data Domain appliances, tape or optical disk juke boxes) then storing metadata about the images in data repository which can be accessed by an image viewer which works with all image types.
However, there are multiple possible approaches. General Electric offers an Enterprise Archive product that is capable of managing images from multiple modalities as long as they are DICOM-based. (GE's product can manage multiple image types: jpeg, jpeg2000, DICOM, etc. in the long-term archive. However, if using their PACS Workstations, and/or Web viewer, it must be converted into a DICOM image, if it was not originally acquired in DICOM.) Teramedica's product uses a Service Oriented Architecture to retrieve DICOM and non-DICOM files from storage devices.
Joe Marion, a consultant at BIDMC working on developing a roadmap for cardiology applications and image management recently wrote a blog about these competing approaches.
It's an interesting issue. On the one hand GE is correct - DICOM is the universal standard for image management in healthcare. Utilities are available that can turn other image formats, such as JPEG, GIF and TIF, into DICOM objects. A standard DICOM viewer from GE, Merge-Efilm, or other third party should work reasonable well with DICOM formats.
On the other hand, are Flickr, Facebook and Myspace using DICOM for image management? In the world of web 2.0, you'll find technologies like SOAP/XML for managing metadata and industry standard image formats such as JPEG for storing images.
Who will win - DICOM for all healthcare images OR a flexible service oriented approach to using DICOM for some images and JPEG for others?
We're continuing to investigate the pros and cons. My prediction is that as more and more hospitals discover the importance of unified image management, multiple companies with various technology approaches will enter the marketplace. Teramedica is an early entrant with technologies that enable migration of images among different storage devices, compression based on business rules, and image deletion by replacing large DICOM objects with a small object that when viewed presents a simple graphic stating "Image deleted by policy". GE claims its approach is high performance and ensures data integrity. IBM has its GMAS product which offers a grid of storage for image management. I'm sure that Siemens, McKesson and other PACS vendors will follow soon with their products.
My advice is to assess the features needed in your institution to accomplish image viewing and archiving within the built and bought systems you have. Define the workflow needed by your users. Determine what dependency the archive creates on a single vendor i.e. if the vendor goes out of business or discontinues its product, what will your options be? Joe Marion's blog entry will help you understand the issues.
In the meantime, I'm working at the national level via the 2008 HITSP "Consultations and Transfers of Care" use case which requires we constrain the optionality of DICOM to enable exchange of images as part of a patient's lifetime medical summary. Reducing variability of DICOM will better support plug and play interoperability of images among different vendors.
In 2008, BIDMC's plan is to learn about all the approaches, convene the vendors together, and determine what is possible. You can be sure I'll share those vendor discussions with you via my blog as they happen.
Hey John,
ReplyDeleteThis is a huge issue for the small office. A unified platform for image management (scanned documents and radiology) would seem logical but it's not easy. We've looked at AGFA but it's cost prohibitive for even a large group practice. Do you have any advice for smaller groups on this front?
BTW - do you considering scheduling data (clinics/appts, etc...) a significant part of the patients chart?
Doctor's office automation consists of a practice management system for registration and scheduling, plus an electronic health record. Thus, I view all scheduling info as part of the administrative practice management system. Of course, the EHR would contain the documentation of each visit including diagnosis.
ReplyDeletesorry John, just got back to the comment. so the scheduling is seperate from the EMR? For us, having the two linked is a major efficiency item (most of our action buttons are schedule based). the way you describe it is three systems??? practice mngt, EMR, image mngt???
ReplyDeleteTypically practice management systems, EMRs and image management are seamlessly interfaced or integrated. In the case of our work at BIDMC, the practice management system and EMR are built on the same platform and share data completely. The Image management system is a separate platform but is available in the EMR with a single click on a URL.
ReplyDeleteJohn,
ReplyDeleteI would like to support this strategic discussion, as a solid promoter of standards and their effective adoption, not as a GE employee.
The fundamental issue about imaging interoperability is not about the image pixels but about standardized metadata related to these images. This is where DICOM may have the upper hand having harmonized the common metadata as well as addressed the modality specific elements for imaging in cardiology, dentistry, endoscopy, mammography, nuclear medicine, ophthalmology, orthopedics, pathology, pediatrics, radiation therapy, radiology, ultrasound, surgery, veterinary, etc. Whether the encoding format is XML, DICOM, moves in Web Services or not, is really a secondary point (although it will be a an interoperability barrier if left unspecified).
The metadata semantic standardization is the heart of the issue, to reach interoperability beyond a few IT systems in a single hospital project.
So choosing a strategy with an active, expert and forward looking standardization community that address both medical metadata and workflow standardization issues is most critical to making this type of decision.
Charles Parisot
John, you mentioned large DICOM objects. Having received my own scan images on CD from BIDMC (thank you!), I'm wondering, how down-sampled are they? How much data does one of my CT scans generate?
ReplyDeleteEach of my scans seems to occupy <200MB on my PC. Now that I think of it, I'm sure that's very downsampled, but how much?
And here's the zillion dollar question: how big does it have to be, to qualify as diagnostic quality?
In my case, with inch-plus lesions, it's not hard to play Find the Goober in the Guts. But now that my goobers is gettin' tiny (and disappearing), my POV on this subject has shifted a bit.
BIDMC uses 1:25 Wavelet compression for its compressed images. DICOM object size is a function of the modality, grey scale, number of slices etc. A typical CT is 200 megabytes. A typical MRI is a few gigabytes.
ReplyDelete> typical CT is 200 MB
ReplyDeleteHuh - that suggests that I actually got all the data on my CD! Would that be correct? And if so, would that make it diagnostic quality, as they say?
Obviously, in light of the recent Doc Searls story, what I'm exploring is the portability of my image data. If I actually have the whole magilla on my laptop, well, I'm pleased as punch!
I confirmed that the images on your CD are uncompressed DICOM
ReplyDeleteJohn great post. I have seen this issue with many healthcare organizations. Image unification across specialties and departments have proved very challenging. We have partnered with many of the aforementioned image management solution vendors to help unify enterprise storage and image archive from top to bottom. I think this is an important point to unify and virtualize up and down the entire stack and not just the client facing layers/protocols. When looking at the backend supporting your image management solution consider storage virtualization, disaster recovery, and cloud storage as part of your strategy. Unified image management with storage stovepipes only solves half the problem.
ReplyDeleteContact me at dko,at,bycast,dot.com or 416-728-6346 if you want to talk further about this.