Category: Work stuff

Just received a much anticipated phantom today: Phantom Lab‘s Liqui-phil organ phantom. I gotta say, it’s pretty schweet too. Purchased with my first grant, I was expecting to get it a month ago. It’s here now, and I’m really looking forward to using it.
At first glance it looks rather daunting. You’re confronted with a phantom with lots of small and large bits. There are 6 fillable organ chambers (liver, 2 kidneys, stomach, spleen, pancreas) each of which can be positioned anywhere you want in the main chamber. There are also a number of fillable spherical and ovoid chambers that can be inserted into the main chamber, or into the organ chambers to simulate hot or cold spots.
This is going to be so much fun to play with.
Next step: Learn how to fill and insert all the chambers without making a radioactive mess out of myself.

A few years ago the department director had me work on a project to replace our paper radiology request forms. The problem with the forms were numerous: sloppy handwriting, eaten by the fax machine, faxed to the wrong number, duplicate requests, etc. I had set up a couple of web-based databases already, and word got around that I knew how to do this kind of thing so I got ‘volunteered’.
So I created a prototype system that was essentially an on-line replacement for the paper forms. PHP/MySQL powered with everything stored in a database (for future datamining/auditing) and requests being emailed out for legibility. Then it languished for a while because we/I didn’t have enough resources to develop it further and lacked the political power to get help developing it or to get people to use it.
Then a resident committee, tasked with finding ways to make residents more efficient in light of the new limitations on resident work hours, said “We spend way too much time filling out and tracking radiology requests. We need a better system”. So a new committee was formed to come up with a solution. Out came my prototype for a few demonstrations and discussion. With the backing of hospital administration and medical staff, we were able to take my prototype to IT and get someone with more skills than me to create a production version.
Now a year later the project has gone from my initial PHP/MySQL based prototype to a JSP/Tomcat based solution developed by the IT guys (because they have the resources, skills and know how to connect to other hospital databases that make it more useful) and is being used throughout the hospital now. Even though I’ve had fairly minimal involvement with developing the current incarnation, I still get a sense of pride at seeing how well the product has been received.
It’s like seeing a kid grow up and become successful 🙂

In less than a week, two floors of the corner of one building for the new hospital sprouted up with pillars to support the third floor going up as I left work today. At this rate this first building should be up within a year or so. From what I’ve heard, this building is supposed to house the diagnostic and treatment building: lab, radiology, offices, clinics etc. Should be fun watching the tower building go up. The campus is going to be a busy place for a long time.

Just learned today that the FDA issued the latest revisions to 21 CFR Part 1020, which outlines FDA standards for how diagnostic x-ray machines should perform.

Haven’t had a chance to go through it yet, but glancing through the summary, I see a few notable changes:

• Switch to using KERMA and air KERMA for exposure measurements
• Changes to minimum HVL requirements
• Last image hold requirement
• Dose information display to the operator

It’s a long 46 page document that will probably take a while to go through, but the summary provides references to the sections that changed so there’s probably no need to wade through all of it. Some of the comments might be interesting though.

For the past few months, I’ve been digging through our PACS database extracting all sorts of gory stats on the storage requirements for CT images. After the first of our 64 slice CT scanners was installed and hearing early reports about 1000 slice studies being stored, I started to get curious about the impact of multi-slice/multi-detector CT (MDCT) scans on our PACS archive.

Our PACS archive goes all the way back to 1996 when it was first installed, so there were a lot of numbers to go through.

Here are some graphs summarizing some of what I’ve found so far.

This is the number of studies per month being stored to the archive. Pretty boring, mostly linear growth happening here.

This is the total number of CT images being stored to the archive each month. You can see fairly steady growth early on with a hint of increase starting around 2000, when the first of our 2 and 4 slice CT scanners were getting installed. The big jump in images/study/month starting around 2003 marks the start of five 16 slice CT scanners being installed. You see another slight increase in the number of images/study/month happening around the end of 2004, which marks the installation of the first of two 64 slice scanners, replacing two of the 16 slice scanners.

Above is the average number of images per study per month being stored to the archive. You see similar trends going on here as with the total images. With MDCT, you have the ability to scan much larger volumes in the same amount of scan time, so naturally you can generate more images. And in order to generate nice looking coronal and sagittal reformats, you need to scan with thin slices which means even more slices.

This shows the maximum number of images being stored each month. As you can see from this graph, we are well past the point where thousand image studies were routine and are getting to where some of the largest studies are approaching 10 000 images. Of course the majority of these images are actually reformats and reconstructed images, not actual ‘x-ray on’ scans. The jump in max images around July 2003 coincides with the installation of 4 16 slice scanners.

Looking at just one CT room, we see what happens here when the switch is made from 16 to 64 slices. The initial data point is an artifact caused by the vast number of images I sent to the archive from acceptance testing the 16 slice scanner. The unit was replaced with a 64 slice scanner Sept 2004, where you see a slight increase in the average number of images stored each month. Then a few months later once the ‘Wow’ factor has kicked in and people start seeing just what the machine is capable of, zoom goes the average images per study.

A similar thing, although much more dramatic happens when we look at the total images stored each month for the same room. Following the switch to 64 slices, the total number of images doubles from what was being stored with the 16 slice scanner, partly because of an increased number of patients being scanned, and partly because of more images per study being acquired.

So what does all this mean? With each CT image taking up at least 512 kB a single CT study starts reaching the GB range for storage requirements. This makes the size of the on-line PACS archive in terms of the number of studies it can store becomes smaller. Studies get moved off-line onto tape or MOD sooner. The more MDCT scanners an institution has, the more pronounced this becomes.

Radiologists need new tools for viewing these massive data sets. 3D and volumetric visualization, which used to be considered just eye-candy for referring physicians, becomes essential for making it through the sheer volume of data.
Interesting stuff. I need to write this up and publish it some place.

Continue reading “Multi-detector CT and PACS storage”