Issue114multiplerdsrversions

#150 Merged at e6f4205
Repository
Branch
issue114multiplerdsrversions
Repository
Branch
develop
Author
  1. Ed McDonagh
Reviewers
Description

Refs #114

Newer Siemens CT scanner software creates and sends an RDSR after each event. Each RDSR contains the information for the whole study. This situation can also occur when an operator performs part of an exam, then ends the exam before starting it up again and generating new events.

The rdsr.py function will now look for a SeriesTime and ContentTime which the Siemens RDSRs have, and allow the code to determine which is the latest of the new import and the previously imported RDSR. If the new RDSR is newer, the database version is deleted and the new one is imported.

I don't know if anyone else has sample data to try this with - particularly if they have non-Siemens CT examples?

Otherwise I will test this with the two scanners we have with this behaviour and merge the PR if I don't have any issues, and no-one else pipes up!

Comments (5)

  1. Ed McDonagh author

    I should have added, this branch needs a database migration to introduce the series and content time fields.

    Also, I have been thinking about what happens if you try an throw a backlog of RDSRs at this routine; I have a limited allowance for one RDSR being imported before the previous one has finished, but I haven't allowed for RDSR no. 2 and RDSR no. 3 both being imported simultaneously - they will both see the existing entry from RDSR no. 1, both try and delete it (will one fail?), then if no failure both will import not knowing about the other. If a fourth one is then imported it will log the fact that there are two studies with the same Study Instance UID, but that is the only indication.

    I guess this could also happen in routine use, if there has been some sort of hold up in delivering the RDSR to OpenREM and several get delivered at once. Not sure of a practical way of dealing with this.

    For dealing with the backlog, it would probably be safest to either reduce the number of workers to 1, or to call the routine directly so that it has to complete before the next RDSR is started.

  2. Ed McDonagh author

    Codacy Here is an overview of what got changed by this pull request:

    Issues
    ======
    + Solved 1
    
    
    Coverage decreased per file
    ===========================
    - openrem/remapp/extractors/rdsr.py  -1
    
    
    Clones removed
    ==============
    + openrem/remapp/extractors/rdsr.py  -1
    

    See the complete overview on Codacy

  3. Ed McDonagh

    Codacy Here is an overview of what got changed by this pull request:

    Clones removed
    ==============
    + openrem/remapp/extractors/rdsr.py  -1
    

    See the complete overview on Codacy

  4. Luuk

    I can't test this , because we don't have equipment that has this behaviour. About the possible simultaneously importing, I don't know what the possibilities are in Python, but I would think it would be good to have some object-locking to prevent the same study (studyInstanceUID) to be imported simultaneously. How are these objects stored in PACS? Does the PACS have also different objects? Because if that is the case and OpenREM performs a query / retrieve on the PACS, I can imagine that scenario's with simultaneous imports are realistic.

  5. Ed McDonagh author

    Thanks for the comments Luke. From the testing I have done importing a backlog of RDSRs for two CT scanners it all seems to work well. I hadn't thought of PACS QR, but if you were using that, the key would be to allow duplicates for queries that might have this issue.