-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional field expanders #87
Comments
I think we do have a use case for this, I released it recently - see this example https://github.com/pydicom/deid/tree/master/examples/dicom/header-manipulation I think perhaps the addition you would need is a way to apply the function to ALL tags? Right now, the use case is for a specific tag like:
and then you would pass into the items dictionary like:
Maybe something like this would work to specify all tags?
And you would still add it
Does the * seem appropriate to indicate all tags? or should we have a keyword ALL (assuming that it's never going to be an actual tag :OP)
As a developer * is more intuitive, but for users that aren't programmers ALL might be a better choice. What do you think? |
If you have something very specific / custom you could also just run it over the fields after you extract them, e.g.,
|
Agree that * is less intuitive to non programmers, who seem to be the key target audience for the Recipes mechanics. I was thinking to leverage existing field expander mechanism which can handle
with a few extra lines:
The code also includes a 'contains' in addition to endswith and startswith. The use case is for something like Date and DateTime:
Covers both fields like StudyDate and AcquisitionDateTime. Something else that tends to be in the middle of a field is "SOP" like Referenced SOP Class UID in File:
|
Actually re: all fields I think it does make more sense to do it without the colon for the user, as you suggested:
I feel pretty good that All won't become a standard DICOM tag soon :) |
With the last amendment, I agree on all fronts! It wouldn't be good to have something like
to indicate all fields, because we would want to catch that as an error that the user possibly parsed the command incorrectly. |
I'm having dinner now, but I'll be happy to put this in for you tomorrow (unless you get to it first!) Thanks for the good suggestion. |
hey @howardpchen ! I've done a PR to work on this issue. Would you be able to review when you get a chance? #88 No rush, it's Sunday firstly, and I'm going to go out for a run and will be back later anyway :) Happy weekend! |
first go to add extra field expanders to close #87
My group's use case includes passing a function to all DICOM Tags to check for certain PHI words/phrases. Noticed that while we can do startswith and endswith, there isn't an easy way to apply func:my_function on most or all of the DICOM tags. Would it be of interest if I expanded the deid/dicom/fields.py functionality (e.g. add expander words like "all," "contains," "allexcept" etc) and sent out a pull request? Thanks!
The text was updated successfully, but these errors were encountered: