Storage Commitment in storescp

[roydobbins]

In order to test storage commitment, I was thinking of adding this SOP class to storescp?

Right at the moment I don't see a better alternative. Unfortunately, from what I have seen none of the popular PACS support this...

I have tried Conquest, and a couple of others, and they all seem to balk at a storage commitment command.

Another possible test tool I may still try would be the MESA test tools, but it seemed like it would be easier to just add the necessary protocols into storescp

Anyone think this would be a good/bad idea?

Thanks

[Marco Eichelberg]

First of all, there should be at least two free implementations of Storage Commitment available: the IHE MESA tools and the Java-based dcm4che archive, which is hosted on Sourceforge.
Adding storage commitment to storescp is probably not a good choice for a two reasons:

• It would require storescp to browse the working directory for files that have been stored previously. Given the absence of an index database and the various options that affect the creation of filenames, this would be very inefficient
• The whole idea of storage commitment is that an SCP takes over a guarantee for the reliable long-term storage of images/objects that have been received before. This is exactly what storescp can not guarantee, so any positive storage commitment would be a plain lie. This does not mean that it would be impossible to implement this technically.

Within DCMTK, I would rather see Storage Commitment as a possible extension for the dcmqrscp (former imagectn) tool that resembles a real PACS in the sense that it provides storage and Q/R services and maintains an index database (at least an index file) that would significally simplify implementation of storage commitment.