When a CT examination is complete, our CT scanner (just like any other CT scanner) generates a patient protocol which contains examination-related information. This protocol can be displayed at the scan console or the VoxSpeed image console.

This page describes a method how the radiation protection related documentation problem described in the sidebar can be solved by evaluating the patient protocol in a fully automatic way.

The Toshiba scan software can be configured so that each time a patient is closed (by clicking the "Next patient" button on the scan console), the patient protocol is exported to some network location in the form of a DICOM secondary capture file (the filename of such a file starts with "SC."), which is something like a "screenshot". Depending on the number of scan series performed during a CT examination, the patient protocol may not fit on a single screen. In such cases, the protocol is broken down into a series of files, with each file holding one screen. Fortunately, the total mAs of the CT examination (this is the number we are interested in) is always on the first page, in a section called << Dose Information >>, which comes right after the block with patient demographics:

This is the second page of the protocol. It contains the Scanoscopes (in other systems these images are called "topograms" or "scout images"), single slices, and a helical scan (which gives the main dose contribution). The mAs of all contributions add up to the total mAs of the examination (300 + 22 + 6480 = 6802), so the total mAs number also contains the mAs of the scanoscopes.

All one has to do is this: evaluate the total mAs field for all patients automatically, and write these numbers to a database.

Our solution

First we checked that the patient protocols are ALWAYS generated and exported, no matter what the user does on the scan console (the whole process shall be fully automatic, without any user intervention, especially without any danger that the user "forgets to do something"). This was an easy configuration task for the Toshiba service engineer.

Then we defined a network share on our ARIA image server (where backups run every night). The path is: \\w3454images\Dicom-CTTotalmAs. Here, for each patient a folder is automatically created (if it does not exist already), which receives the SC-files (ONLY the SC files, no image files!) from the scanner:

Typical contents of such a folder look like this:

There are four SC files. The patient was scanned twice, which can be seen from the file modification dates. The first two files are the ones displayed in the screenshots above.

Reading out the total mAs numbers from the SC files was not straightforward, because a secondary capture is a screenshot. Screenshots are not machine-readable.

So we needed some OCR software. We chose GOCR, which is open source. The EXE we use (gocr049.exe) accepts PNG files, so we first have to convert the DICOM files to PNG, which is acomplished with the help of the scriptable IrfanView.

The rest was some smart .NET programming by Michael Papauschek and Jochen Reiterer.

By cross-checking the results over a few days (comparison with manual bookkeeping), we made sure that the OCR works as expected.

Some information from the header of the SC files was also needed, so that the total mAs number can be linked to a patient. And we need the timestamp of the scan, so that we have a means of checking that we already have imported a certain file (to prevent double imports). Michael wrote a converter called dicom2txt, which reads this information from the DICOM header of the SC files.

Jochen Reiterer integrated the mAmin database into his multi-purpose "iCheckNet" software (which has become something like a QA Leatherman, a Physics multi-tool for radiation therapy).

iCheckNet (once again) grew by one button:

iCheckNet start screen


When we click the "Total mAmin" button in iCheckNet, the database is updated and we get the desired list:

iCheckNet total mAmin list

One line per week is listed. The week number is in the second column. The date in the third column always is the Monday which starts the respective week. Total mAs (4th column) are converted to mAmin (5th column). The number of slices is displayed in the last column. This number also contains secondary reconstructions, so it is higher than the number of slices which contribute to the total mAs. The number of slices has no relevance in the context of radiation protection.

Note that once the statistics is updated, the Dicom-CTTotalmAs directory could in principle be deleted without losing any data: if the SC files get lost, the necessary information is already in the database. Only the data not yet imported into iCheckNet is lost. On the other hand, since the timestamps are checked during statistics update, one can be sure that no record gets imported twice.

Here is a screenshot from the database. Only phantom patients are shown, therefore the names and IDs are a bit strange ...

One can copy data to Excel and make nice plots:

mAmin per week 13-12-2010 to 23-03-2011

The data goes from 13 Dec 2010 (week 50/2010) to 23 Mar 2012 (week 12/2012). The peak in week 10/2011 is due to the scans which were acquired By Niko Metz for our reconstruction speed analysis.

The plot shows that we are currently WELL below our workload limit, which is 50000 mAmin per week. Even in weeks of excessive testing we are currently on the safe side.


Altough OCR is not the perfect approach, we found a working solution which runs in the background, as desired. So in case you want to stop writing stupid lists for radiation protection, you can already do so.

Ask Michael or Jochen if you are interested in implementation details. (You may send them an email together with your credit card details ;-)

If the necessary mAs information (Total mAs) could additionally be written to the DICOM header of the SC files by the scanner software (private tags could be used for this), no OCR would be needed. However, this would require the cooperation of the CT vendor, since the scanner software must perform this task. At least Toshiba Medical Systems Corporation seems not to be interested ...

back to Medical Physics home