Needed: A Standardized Viewer for Digital Imaging

As mentioned in my last Blog entry, I'm attending the 18th Annual Disorders of the Spine conference in Whistler, B.C.  This morning I was approached by several surgeons who wanted to vent about a common problem brought on by the increasing prevalence of digital imaging and PACS systems in hospitals and radiology centers. As one orthopedic surgeon explained, patients used to be referred to him and arrive in his office carrying physical copies of their x-ray films.  Today, most patients arrive with a CD-ROM of their images burned in the imaging center where their study was performed.  On the surface that would seem to be a great step forward and in many ways it is.  The imaging center doesn't have to make physical copies of films.  The patient doesn't have to carry heavy folders of film around from doctor to doctor.  But here's the problem.  It seems there isn't a single standard for the digital images.  There's not even a standard "viewer" for rendering the images on computer.  So, as one surgeon explained, the patients arrive in the office with a CD-ROM that frequently won't load on the doctor's machine, or if it does, the accompanying proprietary "viewer" on the CD will frequently lock up the clinic's computers.  The surgeon said, "It can take five or ten minutes to get the damn images up on the screen if I can get them up at all.  Multiply that times 20 or 30 patients and imagine how much time I'm wasting and how much that's costing me".  He was particularly upset because the trend toward image distribution on CD-ROMs is saving imaging centers lots of money, but those savings are not being passed on to him.  He mentioned that often the CD-ROMs come completely unlabeled, and the images stored on them have been burned on in no particular order.   "It's like a jigsaw puzzle!", he exclaimed.

So, all you developers out there and manufacturers of digital imaging and PACS systems please take note.  There's an opportunity to develop and widely distribute an open-standards viewer that will cut through the chaos of proprietary imaging formats.  Let's figure out a way so that everyone in the image distribution chain can benefit from the cost savings and efficiencies made possible by digital imaging.

What do you think? Let us know.

Bill Crounse, MD   Healthcare Industry Director   Microsoft Healthcare and Life Sciences.

Comments (6)
  1. Travis Owens says:

    Well it sounds like we have two problems here, first the "lockup for 5 or 10 minutes" is obviously a lack of cpu and/or ram on the viewing machine. Considering that digital image quality is going to increase, they should be "sparring no expense" on the cpu and ram of these viewer machines.

    The second problem, which this post brings up, is much more difficult. It sounds like a committee needs to be form to create a federally approved and license free format for these images. Then this brings up the argument if systems should create really large PNG files or a vector file. Unfortunately, because companies want to control the image format, chances are I’m guessing they use a slightly proprietary image format that can’t be viewed without the viewer software purchasing a license from the original vendor. This control makes sure companies have control over the financials of their market.

    This will probably never change on it’s own which is why a federal committee is the only way to correct the issue. And as far as slow loading, we need to use a format that scales infinitely and can be viewed ‘on the fly’ so we’re talking about a multi-pass system where we have at 3 quality renderings: thumbnail (100 or 200 pixels), standard (1600 pixels) and full res (no limit).

    I will admit a multipass image format won’t be very efficient so perhaps the image file needs to be able to store 4 images, and the software retrieves the specific image as requested. This way, a doctor can thumbnail view a picture instantly, and retrieve a standard view near instantly (for quick re-evaluation) and then only access the full quality rendering, which can take a couple minutes depending on hardware, when he’s doing actual diagnosis on the patient.

    Considering how much health costs are, and the salary of doctors, the patient can’t afford to have the doctor wait.

  2. So I have worked in medical imaging for six years and currently am a part owner in a consulting company that provides services to medical imaging practices as well as work in imaging research at University of Maryland School of Medicine. There are a number of issues holding this back. So medical images are stored in DICOM which is a file format which holds the image data often JPEG or some other non-normal format as well as the associated meta data. Now the JPEG data is not normal RGB data but 10 or 12 bit gray scale. Doctors Window/Level to view different parts of the data since only 8 bits of gray are visible at one time.

    The proprietary issues come into play with how the images are stored on CD but I have never had a problem opening them in E-Film. Sometimes the PACS systems write the series information in funny folder hierarchies.

    As far as what Travis has to say I think he is uninformed about medical imaging. Some of my clients are starting to burn DVDs because of thin slice CT which can generate thousands of images. For isntance University of Maryland Shock Trauma does a head to toe thin slice CT on every trauma patient which yields about 2000 slices(images) for about 1 GB of information. We are now also starting to do lots of 4D cardiac imaging which can generate conservativly 2500 slices per study.

    Bill if you would like to learn more about these issues I can continue to expound upon them or we can talk. I would love for Microsoft to take a more active roll in medical imaging.

    Steve Severance

  3. Travis Owens says:

    Steve Severance,

    You are correct, I was not part of our company’s digital imaging project and don’t know any details of what formats they use.

    I was just commenting in general, I should have known better because commenting on a subject one doesn’t know about can too easily lead to "foot in the mouth" syndrome 🙂

  4. Travis, I would completely agree if you thought that medical imaging has serious standardization problems. 🙂 If you think ERP integration is bad you should see healthcare. I apoligize if in my last post I came off a little rough. I didn’t mean anything by it. Sorry.

  5. hlthblog says:

    Thanks Travis and Steve for your comments and politeness. Nobody has to apologize for not knowing the turf or jumping to conclusions about existing technologies. I don’t think there is any business as complex as healthcare, and solving the issues we are talking about here is not trivial. It will take a team of great developers, business leaders, clinicians, and others to get the job done. Thanks for sharing your insights and confirming the need for improved standards and a universal viewer for medical imaging.

    Bill Crounse, MD

  6. Narayanachar Murali says:

    the PACS is terrible outside the site where it is installed. For mobile viewing it is slow and as Dr. Crounse has pointed out crashes computers or wastes time in doctors office. The best universal standard for archival of both data and images is still pdf. A pdf document is small, nifty, universally viewable on free and constantly updated viewer and can be sent by E.mail, zoomed, scaled, signed and imported/exported into other formats without paying an arm and a leg for PACS systems or burning CD ROMS. the problem with American medicine is that is is 10 years behind in image and data management technology. There are too many vested interests and lot of interference from people who know nothing about IT ( such as our politicians). Large image file size does not translate to better pictures or text. This fact is hard to explain to the hospital IT people. HL7 and DICOM are ages behind in technology of image compression, archival and retreival. Those who have sunk in their fortunes do not want to change anything, as long as hospitals are willing to pay millions for IT.

Comments are closed.

Skip to main content