ROI transfer as DICOM SR

[Matthew Lewis]

does anyone know if this is a feature or a bug?

Normally when you use Send to push some images to another DICOM node, you are given the option to include the ROIs.

Behind the scenes, it looks like the proprietary ROI structure is being put into an Encapsulated Document and

sent using a DICOM Structured Report. So using a PACS (such as InVicro iPACS), you can backup your ROIs to a remote location.

(Note: the internal ROI structure has changed a couple of times during the OsiriX->Horos time period, and you cannot QR

and get old ROIs into newer viewer this way - presumably the encapsulated document is the same XML file you get with Export ROI).

My question is the following: if you choose a single Series and push it to another Horos or PACS, the DICOM SRs appear NOT to be sent 

and you don't transfer the ROIs, even if the box is checked.  Trial and error testing indicates that you have to select the study to be sent in the browser  

for the ROIs to be transfered.  For example, if you select a single series and the adjacent study (see attachment), you only get the SRs for the study, not the solitary series.

this behavior is really annoying. especially if you have a study with many series and want to backup just one series with ROIs.

[matthe...@gmail.com]

We have been using InVicro iPACS as a repository for backing up Horos annotations. 

If you push a study (not a series though) back to iPACS DICOM node and you check the box to send ROIs, Horos

will dynamically create DICOM SRs (technically they are 1.2.840.10008.5.1.4.1.1.88.11  SOP Class Basic Text SR, presumably with the XML for the ROI embedded)

and send them to iPACS. Normally in a Horos->Horos transfer, you never see these as they get decoded and deleted immediately at the destination.

But you can Retrieve a study from iPACS, and your Horos ROIs will be restored.

We are now trying to get this same functionality with Flywheel's DIMSE.

One issue we find is that Horos is inconsistent in how it creates the DICOM SRs. 

The majority of the time, it creates a DICOM SR for each slice with an ROI and gives each a unique SeriesInstanceUID.

So each DICOM SR ends up as a distinct series.

Occasionally though, it gives all DICOM SRs the same  SeriesInstanceUID.

For iPACS, this is not a functional problem. Backing up ROIs works the same either way.

With Flywheel, the unique SeriesInstanceUID pathway is a problem (and this is the most frequent).  Has anyone seen this before and tried to understand at the code level why Horos 

is doing this? FYI you can see this in the same study type (say classic CT DICOMs).

mlewis