Comment Brief Outline of Medical Imaging Information Flow (Score 4, Informative) 467
This is part of the subtext both of the original article, and of this most recent post, so I thought I'd share what I know about it. FWIW, I'm a radiologist--that is, an MD who interprets the results of imaging studies--and an informatics geek.
Images are created on whatever imaging device--CT scanner, MR scanner, ultrasound machine, digital X-ray machine--and manipulated by the device's controlling system to do simple annotations, reformatting, etc. This is typically a Unix-based system running custom software designed and maintained by the device's vendor. The images are not usually interpreted on these systems.
From there, the images are sent to the PACS (Picutre Archiving and Communication System), which is just a gigantic central image database. These also tend to be Unix-based systems.
There tend to be two front-ends for looking at images in the PACS database. The first is the radiologist's interface, which is a high-end video workstation dedicated to showing medical images with the greatest possible fidelity. Most systems I've seen are Windows-based (Windows 2000, in our case) and run software which was built by the the imaging system vendors in the late 1990's. Much is made of the "lossless" nature of the images which are displayed; for example, when you log into such a machine, you're warned about how "This is a medical device" and that you shouldn't mess with it. Much is also made of "diagnostic-quality monitors" and high-end video cards to drive the monitors. This is an artifact from the early days of digital imaging interpretation in radiology, when there was a great deal of concern about whether the quality of the digital images would be adequate for us to figure out what was going on in Grandma's chest X-ray if we weren't looking at a piece of acetate. Most of these concerns have died away, as the differences in resolution and dynamic range turned out to be relatively minor and the added conveniences of being able to manipulate the images digitally turned out to be huge. For example, the new LCDs I seen being put on PACS workstations are off-the-shelf Dell 22-inchers, as far as I can tell.
Finally, there are "non-diagnostic" interfaces to the PACS images, which do tend to be web-based. These are so non-radiologist doctors can look at the images, too. Some are IE-based, and use an ActiveX control to display the images, and some use a Java applet. These are displayed with lossy compression (since someone might want to look at them from off-site via a VPN), and officially are not allowed to be used for interpretation. And in fact, I wouldn't want to; it's a lot harder to see subtle things on them than on a full-blown PACS workstation. Part of that is just the interface (it's hard to use those stupid ActiveX/applet things) and part of it is crummy/mis-configured monitors, but I suppose compression artifacts could also play a role.
So, to review: you go see your doctor, Dr. Smith, in her office, and she orders a chest X-ray for you because you're coughing and have a fever. You come to the hospital, and the nice technologist takes frontal and lateral view of your chest on the digital X-ray machine. He then goes back to the X-ray control room, and sees that the images are pretty good, and so he sticks your name on them, and a marker of the date/time and his name, and so on, and then sends them to the hospital's PACS system. I (the radiologist) am working at my PACS workstation, going through the long list of all of the CT scans, MR scans, and X-rays taken in the hospital. I get to your chest X-ray and look at it; I don't seen any sign of pneumonia, so I write a report (the subject of a whole different set of informatics) that basically says "Clear lungs" and that gets entered into your electronic medical record. Then, Dr. Smith back in her office can see your X-ray via her Web-based interface. If she wonders about something she sees, she can call me up and say, "What's that stuff at the left apex?" and I pull up your X-ray again and say, "Oh, it's just the end of the first rib." So Dr. Smith doesn't give you antibiotics, tells you to rest and drink plenty of fluids, and you feel better in a few days.
My basic reaction to the DRM-protections in Vista with regards to medical imaging is that I can't imagine they'll have a significant effect. The current generation of hardware and software is adequate to the task of displaying the images for radiologists, and no one's in a hurry to mess with that. I'm sure these systems will still be running Windows 2000 for at least another five years and require only incremental upgrades in hardware.
The problem is this: the next generation of systems for displaying these datasets should be coming soon. There are a ton of ideas we could implement to make interpreting images more accurate, more efficient, and more useful to patients. Many barriers are in place to creating and installing such systems, however. Most of them have to do with the fact that the first generation systems (which are now in place pretty much everywhere) were designed without any idea of expansion, upgrade, or evolution. But the Vista DRM stuff will make engineering and delivering new solutions even more difficult and expensive, just because Windows platforms will be that much more difficult to work with, and hardware (especially high-end video hardware) will be more expensive. And I suspect that there are many little niches like this one where the cost of an all-out commitment to DRM will hinder innovation.
Images are created on whatever imaging device--CT scanner, MR scanner, ultrasound machine, digital X-ray machine--and manipulated by the device's controlling system to do simple annotations, reformatting, etc. This is typically a Unix-based system running custom software designed and maintained by the device's vendor. The images are not usually interpreted on these systems.
From there, the images are sent to the PACS (Picutre Archiving and Communication System), which is just a gigantic central image database. These also tend to be Unix-based systems.
There tend to be two front-ends for looking at images in the PACS database. The first is the radiologist's interface, which is a high-end video workstation dedicated to showing medical images with the greatest possible fidelity. Most systems I've seen are Windows-based (Windows 2000, in our case) and run software which was built by the the imaging system vendors in the late 1990's. Much is made of the "lossless" nature of the images which are displayed; for example, when you log into such a machine, you're warned about how "This is a medical device" and that you shouldn't mess with it. Much is also made of "diagnostic-quality monitors" and high-end video cards to drive the monitors. This is an artifact from the early days of digital imaging interpretation in radiology, when there was a great deal of concern about whether the quality of the digital images would be adequate for us to figure out what was going on in Grandma's chest X-ray if we weren't looking at a piece of acetate. Most of these concerns have died away, as the differences in resolution and dynamic range turned out to be relatively minor and the added conveniences of being able to manipulate the images digitally turned out to be huge. For example, the new LCDs I seen being put on PACS workstations are off-the-shelf Dell 22-inchers, as far as I can tell.
Finally, there are "non-diagnostic" interfaces to the PACS images, which do tend to be web-based. These are so non-radiologist doctors can look at the images, too. Some are IE-based, and use an ActiveX control to display the images, and some use a Java applet. These are displayed with lossy compression (since someone might want to look at them from off-site via a VPN), and officially are not allowed to be used for interpretation. And in fact, I wouldn't want to; it's a lot harder to see subtle things on them than on a full-blown PACS workstation. Part of that is just the interface (it's hard to use those stupid ActiveX/applet things) and part of it is crummy/mis-configured monitors, but I suppose compression artifacts could also play a role.
So, to review: you go see your doctor, Dr. Smith, in her office, and she orders a chest X-ray for you because you're coughing and have a fever. You come to the hospital, and the nice technologist takes frontal and lateral view of your chest on the digital X-ray machine. He then goes back to the X-ray control room, and sees that the images are pretty good, and so he sticks your name on them, and a marker of the date/time and his name, and so on, and then sends them to the hospital's PACS system. I (the radiologist) am working at my PACS workstation, going through the long list of all of the CT scans, MR scans, and X-rays taken in the hospital. I get to your chest X-ray and look at it; I don't seen any sign of pneumonia, so I write a report (the subject of a whole different set of informatics) that basically says "Clear lungs" and that gets entered into your electronic medical record. Then, Dr. Smith back in her office can see your X-ray via her Web-based interface. If she wonders about something she sees, she can call me up and say, "What's that stuff at the left apex?" and I pull up your X-ray again and say, "Oh, it's just the end of the first rib." So Dr. Smith doesn't give you antibiotics, tells you to rest and drink plenty of fluids, and you feel better in a few days.
My basic reaction to the DRM-protections in Vista with regards to medical imaging is that I can't imagine they'll have a significant effect. The current generation of hardware and software is adequate to the task of displaying the images for radiologists, and no one's in a hurry to mess with that. I'm sure these systems will still be running Windows 2000 for at least another five years and require only incremental upgrades in hardware.
The problem is this: the next generation of systems for displaying these datasets should be coming soon. There are a ton of ideas we could implement to make interpreting images more accurate, more efficient, and more useful to patients. Many barriers are in place to creating and installing such systems, however. Most of them have to do with the fact that the first generation systems (which are now in place pretty much everywhere) were designed without any idea of expansion, upgrade, or evolution. But the Vista DRM stuff will make engineering and delivering new solutions even more difficult and expensive, just because Windows platforms will be that much more difficult to work with, and hardware (especially high-end video hardware) will be more expensive. And I suspect that there are many little niches like this one where the cost of an all-out commitment to DRM will hinder innovation.
