Closed psavery closed 5 months ago
Hi @psavery
Thanks for your pull request. When parsing dicom files we have tried to handle as many implementations error as possible, so of coarse we should strive to do the same when reading from DICOM web.
Your approach inspired me to make some changes that would enables us to (hopefully) re-use the _search_for_instances()
method also for other implementation errors. Is it ok if I push to your branch?
@erikogabrielsson Sure, feel free to push to it! :slightly_smiling_face:
We would love to have these changes in soon, so that we can start utilizing wsidicom
with that large database!
Another possibility would be to merge these changes, and add new features as a separate PR.
Thanks so much, @erikogabrielsson! Can we get a new release so we can start using these features?
Thanks so much, @erikogabrielsson! Can we get a new release so we can start using these features?
Released in 0.19.0
This change adds support for Google Healthcare API DICOMweb servers, such as the NCI's Imaging Data Commons.
The problem: Google Healthcare API raises an error if
AvailableTransferSyntaxUID
is a field, or ifSOPClassUID
is used as a search filter.The
SOPClassUID
should definitely be allowed as an instance-level search filter, as documented in Table 10.6.1-5. Required Matching Attributes. However, this has apparently been a long-standing problem of nearly four years (see here), so it may not be fixed anytime soon. And even if it is fixed, the Imaging Data Commons may not update their software anytime soon. It would be highly advantageous to support such a large DICOMweb repository by working around the issue.The fix in this PR is as follows:
search_for_instances()
calls are still performed identically as before, as long as there are no HTTP errors.search_for_instances()
arguments are patched to work for Google Healthcare API, as follows: a)AvailableTransferSyntaxUID
is simply removed, if present. b)SOPClassUID
is manually filtered, if present (meaning it is not supplied in thesearch_filters
, but only instances with a matchingSOPClassUID
are returned).These changes shouldn't have any impact on any situations except where an error occurs from a Google Healthcare API server. And in that case, the function calls are patched and then work properly.
The following example works after this fix:
Fixes: #141