Support for multipage tif upload

[grintor]

Is your feature request related to a problem? Please describe. We currently have a clinical workflow in which technologists attach multi-page reports to a study and then manually trigger a queued export to send these to a remote location. The remote location does not support encapsulated PDF documents, so the reports have to be uploaded one page at a time to the study as "Secondary Imported Image"/"Capture Image Storage", which the remote site is able to read.

It occured to us that the workflow for the technologist would be much easier if they could upload the multi-page report as a single file which would be converted to multiple image instances. Since tif supports multiple pages, we hoped that the report could be scanned in as a multipage tif, instead of pdf, and that uploading the tif would create a series with multiple image instances.

This is not the case. Currently if you attempt to upload a multipage tif, dcm4chee UI fails with error code 409.

If such an ability existed, we could even then create an export rule to automatically export the study as soon as the document was attached, which would make the workflow even easier for the technologists.

Describe the solution you'd like The ability to upload a multipage tif in the dcm4chee UI which would associate to a study as a single series with multiple "Secondary Capture Image" instances (one per page.)

Describe alternatives you've considered We have attempted to simply upload a multipage PDF, but the remote site cannot open it unfortunately (not a dcm4chee problem). We are working around the problem by uploading multiple jpeg images of the scanned document - one per page.

Additional context In version 5.22.0, the ability to upload tif images was added. See the following: https://github.com/dcm4che/dcm4chee-arc-light/issues/2430 https://github.com/dcm4che/dcm4chee-arc-light/issues/2439 But support for multipage tif was not.

[gunterze]

There is no encapsulated TIFF Document specified by DICOM - so conversion to PDF or JPEG had always be done to wrap the objects into a DICOM composite objects of a SOP Class defined by DICOM. There is also only one SOP Instance UID passed for each multi-part in the HTTP POST request, so SOP Instance UIDs for multiple Secondary Capture Images would have to be generated and assigned by the server. Converting the TIFF to JPEGs wrapped into one Multi-frame True Color Secondary Capture Image seems techncially possible, but it would only help if the remote side can open Multi-frame True Color Secondary Capture Images.

Would rather convert it to PDF and access it from low end clients by WADO-URI, so it just gets the plain PDF.

[grintor]

I understand the desire to convert it to a PDF, but in our case the RIS of the receiving party doesn't support encapsulated PDF unfortunately. I'm not sure if the remote site can open Multi-frame True Color Secondary Capture Images, we could test that.

The current default implementation of arc-lite when handling an upload of a single-page tiff file to a study is the same behavior as that of a jpeg file - a new series, with a single instance for the imported image. It seems for the sake of consistent behavior it would at least make sense that the upload of a multi-page tiff would create the same type of series/instance but with multiple instances; one per page

SOP Instance UIDs are already being generated by the server upon upload are they not? If so, it would just require generating more (one per page). Or is that being done client-side? If it is being done client-side then I can understand the hesitation. Might a reasonable implementation be to increment the client-provided UID by one for each page?

When you say "convert it to PDF and access it from low end clients by WADO-URI" do you mean to provide the remote site a URL to the PDF? That wouldn't be possible in this case because the remote site doesn't have access to our archive. It's a 3rd party company that ultimately distributes the study to one of many possible other 3rd-party companies contracted to perform the diagnosis. I am interested in that solution in general though, is there a dicom-native way to embed external URLs? Does the archive have the capability to automatically embed such a link upon upload?

[gunterze]

SOP Instance UIDs are already being generated by the server upon upload are they not?

That's a workaround for none DICOM PS.3.18 compliant STOW RS clients. Only Attributes of the Image Pixel Description Macro for referenced pixel data encoded in another multi-part may be omitted from the metadata in JSON or XML representation by the STOW-RS client!

When you say "convert it to PDF and access it from low end clients by WADO-URI" do you mean to provide the remote site a URL to the PDF? That wouldn't be possible in this case because the remote site doesn't have access to our archive.

You will need the UIDs also for retrieve using DUL C-MOVE or C-GET services. A dicomWeb client will typically use the Search Transaction (QIDO-RS) to get the (WADO-RS) Retrieve URL or just the UIDs needed to assemble the WADO-URI.

dcm4chee-arc 5.x also supports to push the Retrieve URLs by a HTTP POST request according to the Create Workitem Transaction (UPS-RS). s. https://github.com/dcm4che/dcm4chee-arc-light/issues/3191