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

date modification functions #70

Open
kirbyju opened this issue Apr 2, 2024 · 0 comments
Open

date modification functions #70

kirbyju opened this issue Apr 2, 2024 · 0 comments

Comments

@kirbyju
Copy link

kirbyju commented Apr 2, 2024

Hi, I'm just starting to investigate the use of this tool as we have been relying on https://mircwiki.rsna.org/index.php?title=MIRC_CTP_Articles for years now, but it has some shortcomings that have led me to explore alternatives. In particular, it is not being very actively developed anymore and it has been extended to support a huge number of use cases over the years. This makes it far more powerful than what we need for most of our data submitters, which also results in a lot more complexity in using it. It would be great if I could setup a meeting with someone from the Kitware team to understand your short and long term plans for maintaining this repository and discuss potential collaboration opportunities.

I love that you've approached this by mirroring the different de-id profiles and options defined in the DICOM standard. However, it doesn't appear that you are currently supporting the "Retain Longitudinal With Modified Dates Option" at the moment if you only support keeping or deleting dates. Let me know if I've missed something, but this is pretty critical to most de-identification use cases. Dates are PHI (so you can't keep them), but it generates useless DICOM if you delete them entirely since you lose all understanding the various timepoints for your patients.

CTP has a variety of approaches to this which you may want to emulate. The DateInterval and the IncrementDate functions are the ones we use most so I would advocate them as the best candidates to implement in dicom-anonymizer.

In any case, hope we can discuss further sometime soon.

Best,
Justin

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

No branches or pull requests

1 participant