Toshiba CT RSDR errors

[Utting, Stuart]

Dear OpenREM users,

 

Having just completed a fresh install on a new Windows PC and changing from 0.7.4 to 0.8.1 I have encountered some errors when importing previous data. I’m not migrating the data as I want the anonymised patient names that were not previously input/recorded.

 

The error occurs, and stops further importing, on all my Toshiba Aqillion One scanners (various versions) when they scan with variable helical pitch (vHP).

I get Invalid tag errors (0040,a730) etc., which when tracked down appears to be due to the [standard deviation of population] tag, in [Dose reduction parameters], having [10.50/ 15.00] which is multi-value item in a NUM field, using a forward slash instead of a backwards slash, which might have worked.

The two standard deviation numbers are due to the different SDs used on different pitches in the single scan run and I believe there may be more for certain longer runs (e.g. Neck protocol going into Chest protocol going into Abdo/pelvis protocol all on the same run).

 

I’m presuming there is a reason it is reported this way and have reached out to Toshiba/Canon.

 

Has anyone else seen this or is it a local issue?

 

Kind regards

 

Stuart Utting

Poole Medical Physics

Poole Hospital NHS Foundation Trust

 

[David Platten]

Dear Stuart,

Do you have an example RDSR that you can make available that includes use of the variable helical pitch? It would need to be a non-patient scan. I could then look at making the OpenREM import code work with it.

Thanks,

David

[Ed McDonagh]

I have one David - we'll need to catch the error on decode at the start, just as with Kodak filter thicknesses. I'll send it on to you.

It would be interesting to know if this is specific to the Poole configuration, or common to all Toshiba systems?

Ed

--
You received this message because you are subscribed to the Google Groups "OpenREM" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrem+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at https://groups.google.com/group/openrem.
For more options, visit https://groups.google.com/d/optout.

[Ed McDonagh]

Dear Stuart

Please see issue 670 on BitBucket.

I have a proposed fix that I'd appreciate if you would try out? You will need to replace your copy of openrem/remapp/extractors/rdsr.py with the version you can find on bitbucket here.

If you can feed back, I can finish the issue off and merge it into the 0.8.2 release.

Kind regards,

Ed

[Ed McDonagh]

I thought it might be useful to explain why these RDSRs are a problem in 0.8 but imported fine in 0.7.4 and earlier.

In 0.7.4, the import routine went through the RDSR looking for particular 'code meanings', and then copying the corresponding value into the database.

Every time there was a string that could be non-ASCII, we had to try and deal with it so it would import accurately without crashing.

In 0.8 this changed, and now we start the import process by 'decoding' the RDSR right at the beginning. This goes through every value string in the RDSR and converts it to Unicode, making use of the encoding statement at the start of the file so it knows which character set has been used. We then don't need to worry about the individual strings, as they are all already in Unicode.

However, it also means that parts of the RDSR that were never looked at before (the troublesome value is in effect in a private sequence) are now being parsed, and any illegal values will cause the function to crash as we saw here.

The Toshiba value here might not be the only example - it would be useful to find out if others have this same issue with Toshiba, and if there are other examples from other scanners?

The fix I have proposed is specific to numeric values using the Toshiba schema, so won't fix other examples.

Kind regards

Ed

[stuart...@gmail.com]

Dear Ed, David,

That is a good fix. OpenREM is happily importing it all.

I’m guessing this is just an issue with Toshiba Aquilion Genesis and Vision.

Many thanks for the fix.

Stuart