Check when all dicom files of a study have sent

[Thanasis Iliopoulos]

I have implemented my DICOM listener with a modified version of Storage Service (using as base dcmrcv tool) which implements the AssociationListener interface so i can monitor DICOM file send requests.

However i would like to know also WHEN all DICOM send requests for a whole study has sent! In other words to know which is the last DICOM file send request in a study!

Is that possible?

How am i going to route some processing on the DICOM sent files (just stored in file system) if i do not know when the whole study have sent?

any ideas?

[Patrick Popek]

DICOM is a stateless transfer you not be able to tell when all images of a study have transferred. The association request won't contain a count of total instances within the study to create a stateful transaction. You could potentially guess on this using the association close, but this wouldn't account for an A-ABORT, or exception that prematurely closes an association.

[Thanasis Iliopoulos]

Thanks for responding Patrick!

So here is my business scenario in order for you (and everybody) to understand the case better:

I am implementing a DICOM Router actually which runs in a separate workstation. It accepts DICOM association & send requests from several DICOM clients (MRI) in a local network. 

These requests are being made on the level of a study.

After the completion of each such request (on the level of study) i should process (e.g. anonymize) all its files, then i should zip them ... and then store i an remote location.

So i guess i should find a way on how to monitor whether i have a whole study send in order to process it!

I am quite new to DICOM protocol so a newbie question could be the following:

- If i was going to make a DICOM Query back at the client for a specific study and then try to match remote (at client) and local (at my listener file system) dicom files then i should manage to know whether the whole study have sent. But i doubt if such information is kept on the client (e.g. an MRI) after the initial DICOM send request!

- Another approach would be to just anonymize & process (add to zip file with studyID as identifier) each DICOM file. Then check if the client is idle for a fixed and sufficient amount of time and if yes, then i could send my DICOM zipped files (whole study) ... But this is something like a workaround and not a proper solution

Finally maybee i have misconcepted or i am missing something here!

any ideas?

[fleetwoodfc]

After a quick read of your requirements I believe dcm4chee already has all the features that you need.

[Thanasis Iliopoulos]

Thanks fleetwoodfc for replying...

if you mean dcm4che pacs server (bundled with jboss & mysql) ... i CAN NOT use it since i am trying to build an indepedent, native application that will run as service in a workstation ...

so i am using dcm4chee2 toolkit (java libraries) to build a lightweighted server (dicom listener) for managing incoming association requests ...

so i need some advice on how to monitor & then control (start processing sent files) DICOM files after all files of a study have sent ...

i hope it is clear ...

[fleetwoodfc]

Not sure what you mean by .."trying to build an independent, native application that will run as service in a workstation ..."  - dcm4chee can be run as a service. 

There is also the dcm4chee-proxy project that might be helpful.

[Thanasis Iliopoulos]

OK! i will try to be as specific as possible ...

So, a question first ...  By "dcm4chee" you mean the dcm4chee pacs server? All the bunldes i have checked, run on an application server. So it is a web application ... right?

I do not want to install any jboss or any other application server on the workstation that will host the DICOM Router ...This is a requirement i do not set :( It is set by the project for which i am implementing this tool!

The dcm-proxy project is also a web application ... right?

So instead of using these tools/web apps i would like to build my own, lightweighted DICOM "server" using dcm4chee toolkit (v2) ... and i am seeking specific information (or i think so :) ) ....

As a base i am using dcm4che2 toolkit's "dcmrcv" tool! which is supposed to be a Dicom listener. So i have modified DcmRcv class and added some functionality and the next step is to how to check if a study has completed its send (all dicom file send requests of a study have sent)!

So, any guideliness on this?

Thanks!

[Jon Ander Zuccaro]

I faced a similar problem, I had to burn a Study to a CD once the study was fully received. Since it is perfectly legal to request additional series to an existing study after it was performed there is not really a sense of “closure”, if you will, for a study, at least from the DICOM point of view.

I solved this problem by adding a timer, since you can at least assume that the whole study will be sent to you at once you can add a timer that checks the arrival time from the last image received, you could work under the assumption that if no additional image for a given study is received after a certain amount of time and no transfer is currently in process it is safe to conclude that no additional images are coming.

We settled with a 5 minutes waiting time and it works just fine. Be aware that your waiting time, specially if it is too short could pass because you are still receiving a large image since you received the previous one, so even if your time expires you should check if no additional image for that study is now in transit.

Hope it helps.  

On Tuesday, November 4, 2014 6:03:02 PM UTC-4:30, Thanasis Iliopoulos wrote:

OK! i will try to be as specific as possible ...

So, a question first ...  By "dcm4chee" you mean the dcm4chee pacs server? All the bunldes i have checked, run on an application server. So it is a web application ... right?

I do not want to install any jboss or any other application server on the workstation that will host the DICOM Router ...This is a requirement i do not set :( It is set by the project for which i am implementing this tool!

The dcm-proxy project is also a web application ... right?

So instead of using these tools/web apps i would like to build my own, lightweighted DICOM "server" using dcm4chee toolkit (v2) ... and i am seeking specific information (or i think so :) ) ....

As a base i am using dcm4che2 toolkit's "dcmrcv" tool! which is supposed to be a Dicom listener. So i have modified DcmRcv class and added some functionality and the next step is to how to check if a study has completed its send (all dicom file send requests of a study have sent)!

So, any guideliness on this?

Thanks!

On Wednesday, 5 November 2014 00:24:16 UTC+2, fleetwoodfc wrote:

[Thanasis Iliopoulos]

Thanks Jon for your clear answer!

Indeed the scenario i am trying to implement actually overcomes and somehow breaks the DICOM protocol! However i need to come with a working solution ...

On which level did you created your timer and then checked for this time interval?

My Dicom Receiver is registers as follows:

public DcmRcv(String name) {

        device = new Device(name);

        executor = new NewThreadExecutor(name);

        

        device.setNetworkApplicationEntity(ae);

        device.setNetworkConnection(nc);

        ae.setNetworkConnection(nc);

        ae.setAssociationAcceptor(true);

        ae.register(new VerificationService());

        ae.register(storageSCP);

        ae.register(stgcmtSCP);        

        ae.addAssociationListener(storageSCP);

}

where storageSCP is a custom version of StorageCommitmentService implementing the AssociationListener interface ...

Is this the place where i should create and manage this timer?

And if so i should subsequently batch process all the dicom files in the dicom listener storage directory?

Until now i was trying to grab and process individually each dicom file after its Association closure ... without sucess ...

Thanks again for your answer ...

[Jon Ander Zuccaro]

We had a small embedded database (http://hsqldb.org/) where we stored a representation of the study as the images were arriving, just some basic data like Study Instance UID and physical disk location where we stored the DICOM files with an additional date column that was updated each time a new image from the study arrived to “reset” the timer.

Then we had a scheduled task (http://quartz-scheduler.org/) that would scan the database periodically for new studies to burn checking if the date column was now old enough.

We had 2 more additional columns, one was a Boolean in_transit or something like that that we updated to “true” once a new image from that study began arriving and to “false” once the transit was completed and the other column was a Boolean that we updated once the study was processed / burned to “true”

So, basically, the scheduled task simply had to perform a SQL query to get all studies that were not in transit right now, that were not processed already and that had an old enough “last image received” date and call the burning process for those studies.

We used the source code for the dcmrcv tool as guide to implement a StoreSCP server that would not simply receive the images and store them to disk but actually read the received DICOM tags to create the database record for the study and perform all other database updates.

Hope it helps

[Thanasis Iliopoulos]

Thanks Jon!

thats clear ... i was thinking a similar approach for dealing with this (FileSystemWatcher of java nio library for monitoring folder/files changes but i think your approach is simpler!) ...

I have modified a bit the onCStoreRQ method but i am unable to fetch the StudyID:

@Override

protected void onCStoreRQ(Association association, int pcid, DicomObject dcmReqObj,

                                    PDVInputStream dataStream, String transferSyntaxUID,

                                    DicomObject dcmRspObj)

                throws DicomServiceException, IOException {

        

        final String classUID = dcmReqObj.getString(Tag.AffectedSOPClassUID);

        final String instanceUID = dcmReqObj.getString(Tag.AffectedSOPInstanceUID);

        config = new GlobalConfig();

        final File associationDir = config.getAssocDirFile();

        

        final String prefixedFileName = instanceUID;

        final String dicomFileBaseName = prefixedFileName + DICOM_FILE_EXTENSION;

        

        File dicomFile = new File(associationDir, dicomFileBaseName + PARTIAL_FILE_EXTENSION);

        assert !dicomFile.exists();

        

        final BasicDicomObject fileMetaDcmObj = new BasicDicomObject();

        fileMetaDcmObj.initFileMetaInformation(classUID, instanceUID, transferSyntaxUID);

        

        final DicomOutputStream outStream = new DicomOutputStream(

            new BufferedOutputStream(new FileOutputStream(dicomFile), 600000));

        try {

            outStream.writeFileMetaInformation(fileMetaDcmObj);

            dataStream.copyTo(outStream);

            

        } finally {

            outStream.close();

        }

            dicomFile.renameTo(new File(associationDir, dicomFileBaseName));

            System.out.println("DICOM file name: " + dicomFile.getName());

}

dcmReqObj is actually empty (only AffectedSOPClassUID & AffectedSOPInstanceUID tags are populate ,,,

Even if i try to fetch it after: outStream.writeFileMetaInformation(fileMetaDcmObj)  

Also in this method if i try to fetch "dicomFile" inside onCStoreRQ  i can only take it in a transitional phase where it is not yet a populated DICOM object ... 

On Thursday, 6 November 2014 19:50:44 UTC+2, Jon Ander Zuccaro wrote:

We had a small embedded database (http://hsqldb.org/) where we stored a representation of the study as the images were arriving, just some basic data like Study Instance UID and physical disk location where we stored the DICOM files with an additional date column that was updated each time a new image from the study arrived to “reset” the timer.

Then we had a scheduled task (http://quartz-scheduler.org/) that would scan the database periodically for new studies to burn checking if the date column was now old enough.

We had 2 more additional columns, one was a Boolean in_transit or something like that that we updated to “true” once a new image from that study began arriving and to “false” once the transit was completed and the other column was a Boolean that we updated once the study was processed / burned to “true”

So, basically, the scheduled task simply had to perform a SQL query to get all studies that were not in transit right now, that were not processed already and that had an old enough “last image received” date and call the burning process for those studies.

We used the source code for the dcmrcv tool as guide to implement a StoreSCP server that would not simply receive the images and store them to disk but actually read the received DICOM tags to create the database record for the study and perform all other database updates.

Hope it helps

[Jon Ander Zuccaro]

Now we are reaching the limits of my memory, but I believe that the information that you are looking for was located in the dataStream. dataStream.readDataset() gives you a DICOMObject and you can obtain the information from there.

May I suggest you search the forum or ask another question with that specific query? I am sure somebody else could help you with that because it has been done probably a lot by now.

Cheers!

[Thanasis Iliopoulos]

Thanks alot Jon for all the useful info...

DICOM protocol and dcm4che has alot of details and is quite vast (at least for a beginner such myself) ... So you have helped me alot! 

Seems that your memory has quite broad limits!

cheers!

[matthe...@netscape.net]

I know that it may be blasphemous but:

For the requirements you list below, it may be better to just use Conquest pacs.

Anyway, something to think about.

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