Indicator for region altered by PHI removal in pixels

[WVasselloMMI]

In testing the new PHI removal for burned in text, it seems to do a great job overall. However, as the underlying pixels are altered, it would be great if there were (at least an option for) an indicator of the regions where text was removed. In our current application we use an old school black box to cover all text within a bounding box. But given what a great job the anonymizer does with the text removal already, maybe a more elegant solution would work. Perhaps an unfilled red outlined box?

Has anyone proposed or looked into an option like this yet?

[mdevans]

Thank-you for your feedback which is very encouraging.

Please can you clarify where you think the modified pixel regions should be recorded: on the image itself? List of rectangles in associated text file with same name as image? In the DICOM header? The standard does provide some facility for doing the latter, however after discussions with the TCIA team it was concluded that both backing up the original image or recording the text removal was unnecessary.

Your suggestion of adding an unfilled red outlined box implies on the image, perhaps you could elaborate your particular use case?

Since the general intent is for the images to become part of a model training dataset burning in rectangles on the image is not the preference. The current implementation uses a pixel text contour detection and in-painting algorithm to remove text overlying any anatomy and attempts to not create artefacts which could potentially interfere with training, especially for smaller datasets.

When you create a project and check the Remove Pixel PHI checkbox it instructs the Anonymizer to start a background server which scans every incoming image and removes any text detected, there is currently no whitelist or entity recognition employed to focus only on potential PHI strings, this provides some peace of mind since entity recognition is rarely 100% accurate but it also makes sense in the context of model curation and training not to have any text in the images.

A forthcoming version of the Anonymizer includes a Series Viewer where the user will have full control over the pixel phi removal process by using a combination of OCR and user-defined blackout areas, it also provides a whitelist dictionary. This version should be available for testing in the next week via pip upgrade rsna-anonymizer.

[WVasselloMMI]

You are correct. My initial thought was to capture the bounding box on the image itself. I had not really considered storing that location data in a tag or separate file. Which is an interesting possibility.

A little background on my perspective: Our use case for an anonymizer on our platform is really two fold. Our platform is used both by providers and patients. And so predominately a provider offers our platform as a way for patients to upload their outside imaging prior to an appointment to avoid forgetting their disc or to have the ability to share the image with other providers during the course of care. However, some of our providers wish to share the imaging for other uses, like poster exhibits or lectures. And some patients wish to share their images for second opinions or more recently submitting to public AI platforms. In both these cases, there is a responsible need to offer an anonymization option. We adhere to the RSNA guidence and standard for tag anonymization and currently use an AWS product to place the filled bounding boxes over any text found. While this is a more brute force approach, it makes no mistake about where the image is altered and eliminates those areas that could be misinterpreted.

In watching the recent video MIDRC video on the updates to the RSNA anonymizer, I learned about the pixel PHI removal function and like the viewers in the Q/A, I was curious about how the underlying pixels were handled.

As I said, my first impressions of the tool are great. Well thought out, fast. Overall huge improvement.

In regard to the altered pixels: If the downstream use of the image is for an AI training set or even a human training program, I would think that there would a risk of more false positives in the altered region. So my initial thought was to provide the bounding boxes as "exclusion zones" as a safety precaution. While maybe not strictly necessary for the text on the margins, any text that is part of a markup or anything overlapping anatomy is a reasonable risk. Especially in a bulk training set use case.
I would guess this could be a project setting and since the code is already building the boxes in it processing, it would seem like an easy option to add. (In fact, I may look at the code today and manually turn it on to check out the results.)

Awesome to hear about the user defined options coming in the next version. Looking forward to checking it out.

[mdevans]

Thank-you very much for your comprehensive reply & feedback. I will reply in full by tomorrow, if you'd like to try out the Viewer please upgrade to the latest released version (17.4.4), here are some simple guidelines (docs not yet updated):

From View you will see the index of studies anonymized, showing the PHI and Anonymized fields. Select a study or group of or all studies and click View Projections, a graphic display of all the series projections of all the selected studies which will be auto paginated and you can specify the size using bottom right buttons, Small, Medium, Large. Clicking on a specific series projection set will open up the Series Viewer where you can detect text and specify blackout areas, the edit context can be set to Frame or Series which will control whether Detect Text or Blackout Area button actions applies to the full series or just current frame. There is a shortcut to open a series view directly by selecting the series in index list and right clicking.

This version does not allow saving changes, forthcoming one will.

ps. for server side install you can start from command line with path to project settings file and it will start headless
pps. please can you send a link to the midrc video you referred to.

[mdevans]

FYI, here's a screenshot of Series Viewer:

[WVasselloMMI]

The black out works fine. The drag box gets created and all is good.

If the ocr detect is restricted to horizontal, than that would probably do it. The auto finds it fine, so that must have some flex in it.

I'd say you could just have a radial option on the project settings page. If the problem being solved is that some unknown number of potential false positives could creep in over a larger dataset, then I suppose that implies the user is processing enough to need it on the project level. Can't see switching back and forth much. Especially if the model is expecting exclusion areas in one form or the other.

[mdevans]

Thank-you for your feedback, I'll let you know when next beta is ready, which will incorporate your recommendations. I am also considering configuration for the auto mode to signal PHI detection without automatic removal.

[mdevans]

17.4.6 just released, please give it a go and let me know your thoughts, eg. histogram and whitelists
Config changes we discussed still to be implemented

[WVasselloMMI]

Great! Will check it out this morning. I was out of the office last week and wasn't able to give it a try yet. Looking forward to it.

[WVasselloMMI]

In reading through our discussion thread, I see that you asked about the video that I was referring to. I missed your request for the link. Here it is. Video came out about 3 weeks ago and is part of a series.

https://youtu.be/qjwZH03dD3Q?si=mszO-SdFuJeuJJCT

[WVasselloMMI]

Looks like 17.4.6 solves the angled text detection for the manual select and all the functions in the viewer are working on the sample images I have been checking. Great work.

Definitely fast and clean.

[mdevans]

Awesome, thank-you :) Yup, I found the MIDRC video and watched it when you pointed it out, I have been working with both Adam Flanders and Errol Colak. Regarding your proposition for your use-case for a red border on a blackout square, I was wondering if adding the rectangle(s) to a DICOM overlay would work for you?

…

On Mon, 12 May 2025 at 15:40, WVasselloMMI ***@***.***> wrote: Looks like 17.4.6 solves the angled text detection for the manual select and all the functions in the viewer are working on the sample images I have been checking. Great work. Definitely fast and clean. — Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIXFIHLXZKUK7HGMAGXVFT26CQD7AVCNFSM6AAAAAB4DXPOS2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMJRHA2TKNI> . You are receiving this because you commented.Message ID: ***@***.***>

-- Michael Evans *DX.LIFE (Pty) Ltd.* +27 72 584 6989

[WVasselloMMI]

An overlay is potentially a good option. Since we have a few different use case paths for different users, we might be able to manage the inclusion of the overlay or not when appropriate.
For example, if a patient wanted to upload an image to a public Ai tool, we would include the outlines in the JPEG export with the suggestion to include instructions to ignore regions within the boxes. (although I think our preference would still be a black box since anyone motivated to have an Ai reconstruct the PHI would have good odds of success and the safest overall route is no available pixels)
Or. if a Provider wants to include an anonymized X Ray as part of a poster exhibit, then the reviewing physicians could hide the boxes if they are distracting.

One caveat though, we have some Ai partnerships lined up that have FDA cleared tools that make use of DICOM files directly. And I somewhat doubt their model is expecting overlay info to be incorporated in their read. In fact, quite the opposite. So if the exclusion regions are in the overlay, they will most likely be ignored. Now, given these are previously and properly trained algorithms, miss identifying findings from removed text may be a low probability risk.

Again, I am trying to think of the most general use case for the bulk of your intended users and not so much our particular specific needs. Hope the discussion of options is at least helpful and valuable.

[mdevans]

Ok, thanks for the clarification, yes, overlays can be problematic. I think we will stick with providing the Anonymizer user in the Project settings with the option to "generate missing pixels" or black them out or flag the series that text (out of whitelist for that modality) was detected in auto mode. I do like the idea of capturing all the text rectangles which were processed somewhere in the DICOM header of the file, what do you think and which tag do you think would be most appropriate for that sequence? I recall that the DICOM Basic Anonymization profile does provide for encrypting removed phi and store in some field, I'll look into that again... I don't know if you looked at the current code which does the pixel generation required to replaced the burned in text, it uses OpenCV to *threshold* the rectangle contents then *find the contours* of the text and draw them on a mask, *dilates* the mask and then uses then *inpaints *the dilated mask on the source image. I have noticed this works extremely well for ultrasound images but not so well in regions with high contrast. I see the possibility of using generative AI models to improve on this but in practice it is rare to find anatomy being obscured by text in modern imaging. Your thoughts?

…

On Mon, 12 May 2025 at 16:32, WVasselloMMI ***@***.***> wrote: An overlay is potentially a good option. Since we have a few different use case paths for different users, we might be able to manage the inclusion of the overlay or not when appropriate. For example, if a patient wanted to upload an image to a public Ai tool, we would include the outlines in the JPEG export with the suggestion to include instructions to ignore regions within the boxes. (although I think our preference would still be a black box since anyone motivated to have an Ai reconstruct the PHI would have good odds of success and the safest overall route is no available pixels) Or. if a Provider wants to include an anonymized X Ray as part of a poster exhibit, then the reviewing physicians could hide the boxes if they are distracting. One caveat though, we have some Ai partnerships lined up that have FDA cleared tools that make use of DICOM files directly. And I somewhat doubt their model is expecting overlay info to be incorporated in their read. In fact, quite the opposite. So if the exclusion regions are in the overlay, they will most likely be ignored. Now, given these are previously and properly trained algorithms, miss identifying findings from removed text may be a low probability risk. Again, I am trying to think of the most general use case for the bulk of your intended users and not so much our particular specific needs. Hope the discussion of options is at least helpful and valuable. — Reply to this email directly, view it on GitHub <#28 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIXFIA5EYYIKDRO67WTR6326CWGRAVCNFSM6AAAAAB4DXPOS2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMJRHEZTMMQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Michael Evans *DX.LIFE (Pty) Ltd.* +27 72 584 6989