Skip to content
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

Closed
howardpchen opened this issue Dec 29, 2018 · 7 comments · Fixed by #88
Closed

Additional field expanders #87

howardpchen opened this issue Dec 29, 2018 · 7 comments · Fixed by #88

Comments

@howardpchen
Copy link

howardpchen commented Dec 29, 2018

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!

@vsoch
Copy link
Member

vsoch commented Dec 29, 2018

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:

REPLACE StudyInstanceUID func:generate_uid

and then you would pass into the items dictionary like:

for item in items:
    items[item]['generate_uid'] = generate_uid

Maybe something like this would work to specify all tags?

REPLACE * func:clean_data

And you would still add it

for item in items:
    items[item]['generate_uid'] = clean_data

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)

REPLACE ALL func:clean_data

As a developer * is more intuitive, but for users that aren't programmers ALL might be a better choice. What do you think?

@vsoch
Copy link
Member

vsoch commented Dec 29, 2018

If you have something very specific / custom you could also just run it over the fields after you extract them, e.g.,

new_items = dict()
for field, value in items['items']:
    new_items[field] = func(value)   
items['items'] = new_items

@howardpchen
Copy link
Author

howardpchen commented Dec 30, 2018

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

REPLACE allFields: func:clean_data

with a few extra lines:

    if expander.lower() == "endswith":
        fields = [x for x in contenders if x.endswith(expression)]
    elif expander.lower() == "startswith":
       fields = [x for x in contenders if x.startswith(expression)]
    elif expander.lower() == "contains":
        fields = [x for x in contenders if expression in x]
    elif expander.lower() == "allfields":
        fields = contenders

The code also includes a 'contains' in addition to endswith and startswith. The use case is for something like Date and DateTime:

JITTER contains:Date 123

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:

REMOVE contains:SOP

@howardpchen
Copy link
Author

Actually re: all fields I think it does make more sense to do it without the colon for the user, as you suggested:

REPLACE ALL func:clean_data

I feel pretty good that All won't become a standard DICOM tag soon :)

@vsoch
Copy link
Member

vsoch commented Dec 30, 2018

With the last amendment, I agree on all fronts! It wouldn't be good to have something like

JITTER allFields: 123

to indicate all fields, because we would want to catch that as an error that the user possibly parsed the command incorrectly.

@vsoch
Copy link
Member

vsoch commented Dec 30, 2018

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.

@vsoch
Copy link
Member

vsoch commented Dec 30, 2018

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!

@vsoch vsoch closed this as completed in #88 Dec 30, 2018
vsoch added a commit that referenced this issue Dec 30, 2018
first go to add extra field expanders to close #87
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants