dicom-server
dicom-server copied to clipboard
microsoft
Add SOP Class UID to ChangeFeedEntry
User story As a consumer of the change feed, I would like to process or discard a received instance according to its SOP Class.
Currently, this can be done by retrieving all the meta-data and extracting the SOP Class from it. However, adding SOP Class to the ChargeFeedEntry itself would mean that the feed could then be used without the meta-data fetch, leading to improved performance.
Although extension of ChangeFeedEntry should not be done lightly, I think processing decisions based upon SOP Class UID would be a common usage scenario.
In our scenario, for example, we want to ignore all CT Image instances (or any other image), and process only RT Structure Set, RT Plan, and RT Dose instances (so just 2 or 3 instances per 200-or-so instance study in this case).
Acceptance criteria
- SopClassUid is available as a string attribute in each returned ChangeFeedEntry.
Have you tried /changefeed?offset={int}&limit={int}&includemetadata=true
Does that help?
Yep, that works great, as I described in the Issue. It's just that we are interested in a few instances, and we would have to pull the metadata from potentially thousands of irrelevant instances per day to determine that they are indeed irrelevant. Retrieving this data seems slower, and also I don't really care for all the PHI flowing across for patients our modality has no interest in etc. Our application needs to act on all instances of a certain SOP Class only.
I guess I see SOP Class UID as a pretty fundamental descriptor of the instance, in the same way that SOP Instance UID or Study Instance UID is.
Great. Another option, which would mirror the approach taken by the DicomFile method in fo-dicom, would be to be able to restrain the number of tags read in to the meta-data (or specify those tags explicitly). This would be poweful option for applications, but would complicate the API query parameters quite a bit I guess.
With help from the Team, I am now using DICOM Cast, then the FHIR change feed, getting the n-1 version of the modified ImagingStudy, performing diff on the two versions, and accessing the SOP Class of that difference. This seems to work. So by all means consider this issue on its merits, but I now have a workable alternate solution. Thanks!
Dave, this is a really good request. When I look at potential ChangeFeed uses, filtering for modality tops the list. No action on either side with this comment, Dave, but I wanted to provide feedback. It's an important ask, and a good one. Thanks!
