Category: Work stuff

Work related posts

Posted on

Reworking an old project

Now that I have my equipment database project living comfortably over at code.google.com, it’s time to think about how I want to rewrite it and what I want to do it with. The new version of whatever I end up creating will live over at github, since that’s what all the cool kids seem to be using these days.

Since PHP is what I know, it’s the most likely candidate for this new version (although I’m open to using something else). Leaning heavily towards using some kind of framework for it, although I haven’t picked one out yet.

I had a thought that I could maybe use Drupal to take care of the front end stuff with the back end being handled by modules that I would create. Each piece of equipment would be a Drupal ‘node’ and modules could be used to create the reports as ‘views’. I need to dig into Drupal dev more to see if something like this would be viable.

Lots of possibilities to choose from. All of them will force me to expand my rudimentary programming skills earn more skill levels in programming.

Posted on

A place to stash some code

Long, long ago, I cobbled together a database and a bunch of PHP scripts to help me keep track of x-ray equipment and the dates I tested them. There are a few other things that I track with it, and a bunch more things that I’d like to keep track of.

For most of its existence, I was the only one who used it so features were added on an “as I wanted/needed them” basis. Worked well enough for my purposes. Made attempts to keep track of bugs and features I wanted using Bugzilla, but I never really used it very consistently.

Now my little database has been “discovered” by management at work and others are starting to poke around in it. They’re also starting to make requests for additions, so I decided it was time to start up again with some bug/issue/feature tracking. I didn’t want to go with something heavy like Bugzilla again. Wanted something relatively lightweight, that I could use to track multiple projects and wouldn’t be too difficult to install/configure/maintain. I also wanted to be able to access it online so I’d still be able to reach it if I wasn’t at work or home. I started looking at a few, then came across Google’s project hosting, code.google.com.

After looking at the docs for a bit, I decided it would probably work. Nothing for me to install, configure or maintain. Works with version control software. Has a wiki for documentation. Fairly flexible looking bug tracker. Pretty much everything I was looking for.

My little equipment database project has a home out in the wild now. With more people using it now, I think there will be a little more motivation to keep up with the bug tracking and continuing development (in what little time I have for it). Maybe it will help making the long wanted re-write a little easier.

Posted on

SQL subqueries and joins

A while back, a script I had written to dig stats out of our PACS database stopped working for some reason. Since I was mostly done with that project, I didn’t mess around with it too much.

Now I’ve been asked to resurrect it to gather more usage data in advance of a planned migration.

The PACS database uses Oracle, but all my DB experience is with MySQL. This is the main query I’m dealing with (it runs from a shell script, which is why the variables are there)

select
count(study_uid),
avg(num_images),
sum(num_images),
max(num_images),
min(num_images)
from dosr_study
where study_ref in (
select
study_ref
from dosr_series
where modality='${modality}'
)
and study_date between
'${c_year}${c_month}01' and '${c_year}${c_month}31'

For some reason this query stopped running. Well, it runs, but it just doesn’t spit out any numbers like it used to.

If I reformulate the query into what I think is the equivalent query without the subquery,

select distinct
count(study_uid),
avg(num_images),
sum(num_images),
max(num_images),
min(num_images)
from dosr_study, dosr_series
where dosr_study.study_ref = dosr_series.study_ref
and dosr_series.modality='${modality}'
and study_date between
'${c_year}${c_month}01' and '${c_year}${c_month}31'

the query works, but returns different results from what I got before when the original query worked.

I suppose I’ll need to find out more about Oracle SQL so I can figure out why the original query stopped working in the first place.

Update: One of my friends thinks I probably haven’t rewritten the query correctly (what I was thinking as well) and suggested changing

from dosr_study, dosr_series
where dosr_study.study_ref = dosr_series.study_ref

to

from dosr_study
join dosr_series on dosr_study.study_ref=dosr_series.study_ref

Posted on

Radiation dose tracking

Many of the x-ray machines I work with, particularly the newer ones, have some capability of recording the amount of radiation used during a procedure, which can be used to estimate the radiation dose to patients.

A dose report is usually generated and stored with the patient images, and on some systems it can be sent to the PACS. This is good.

In almost all cases, the information is sent as just a screen capture wrapped up in DICOM headers. This is not so good. Good for archiving, lousy for searching.

It occurred to me that I should be able to set up a DICOM receiver that the machines could send the dose reports to, do some OCR on the images to extract the numbers that I need and then stash it all in a database. This is essentially the way ACR’s Dose Index Registry (DIR) works but it relies on getting the dose reports as a DICOM Structured Report. A lot easier to get at dose data that way and no need to OCR and parse images. Data in the DIR is anonymized, but for my purposes the dose data would only be partially anonymized.
The OCR part would require some kind of machine specific mapping to identify what parts of the image contain what information. Sadly, some machines are completely incapable of sending the dose reports anywhere (I’m looking at you Siemens). Some way of dealing with those machines will be needed. Studies with lots of series will have multi-page dose reports which is another case that will need to be dealt with.

Nation wide some of this info is being collected in the National Radiology Dose Registry, but all of that data has to come from somewhere, and has to be extracted somehow. This would help us see what goes on locally, and would be a useful source of information. If a dose estimate needed to be done, we could look up the numbers, do a little bit of crunching and come up with something reasonably accurate. It would also be a good data source for studying radiation exposures.

I need to work on this.

Posted on

Mining stacks of data

All of the interventional radiology (IR) labs at work are capable of spitting out a report that tells about the amount of radiation used in a procedure. Unfortunately, none of them are capable of sending that report to the PACS system with the exception of the newest units.
That means a valuable source of patient radiation dose information usually ends up archived away on optical disk somewhere. Good archiving, lousy search capabilities.

About a year ago we decided to start collecting the dose info so we could find out about the radiation doses patients were getting from IR procedures. The techs were educated on what information the dose reports provided, and we asked them to start printing out the dose summary sheets, which they’ve been doing for the past year.

Then things started getting in the way and while we were still collecting the dose sheets, no analysis of the data was getting done. Now I’ve got close to a year’s worth of data that I’m finally getting around to entering into a database. It’s a lot of typing and data entry.
It will be worth it in the end though I think. All of this dose information is a veritable gold mine and I think it will tell us a lot about what radiation doses in IR procedures are like and how the machines are utilized.

It’s going to take a while to get all the numbers in, but I’m chipping away at it a month at a time. 4 months down so far for one room.