As an update to the issue of display order on the Hologic workstation, it seems that Hologic generates groups of series during its use, taking the input data and creating 3 separate, but related, series of views of the data.
Those series are then linked together for display purposes with embedded ReleatedSeriesSequence DICOM tags which contain DICOM UID of the related series. When you view results on Hologic, you really view 3 series simultaneously.
These RelatedSeriesSequence tags are naturally removed by the default anonymization process. I think most anonymization routines, whether Orthanc, Osirix, Matlab or others, are going to miss the embedded connections stored in the RelatedSeriesSequence tags.
The anonymization of the Hologic studies will require some special handling. That’s because the connections are made using the very same UID that anonymization replaces.
First, the connections between series will have to be determined. A table must be constructed of the pre-anonymization UID and what series and instances point to other series and instances using these pre-anon UID.
Then, the anonymization will have to proceed in a very particular order and at the instance level. Because the UID are the only guaranteed unique identifier of each DICOM file, we have to work at the instance level because it’s the only way to be certain that the anonymized instance we get back is the instance we sent to the anonymizer. If we were to anonymize at the series level, there would be an ambiguity in the order of the instances returned. Are they in the same order as what went in? I don’t think Orthanc guarantees this. Maybe I could figure out the order if the DICOM included the InstanceNumber tag, but that tag was not meant to be a unique identifier like the UID.
Working at the instance level, we first anonymize the instances that are pointed TO by other instances and which themselves point to no other instances. Then, you work outward in the connection tree. The next level of instances are anonymized and we update their RelatedSeriesSequence pointers to point to the new UID we previously anonymized.
It’s my understanding that anonymizing at the instance level with Orthanc will require tracking the PatientID, StudyInstanceUID, SeriesInstanceUID, etc. (essentially anything above the instance level). That’s because Orthanc will generate new UID for the same input instance each time you anonymize it. This has to do with hashed current time stamps that are used to generate the UID.
So, if you want to anonymize two instances from the same series, but have them remain in the same anonymized patient, study, and series, you need to catch the new patient/study/series UID of the first anonymized instance and then anonymize all later instances with these values fixed as input to the anonymization. Only the first instance should be fully anonymized with no fixed input UID.
I may be mistaken about the PatientID, but I think the study/series UID are generated as I described and will require special handling to keep anonymized instances in the same study/series when anonymizing at the instance level.
I’ll be implementing a solution in LUA. If it works, I’ll post here.
The situation does have general implications for studies which embed links between series using UID. I’ve seen this often with MR exams, where later series will point to the initial localizer they are associated with. If you want to maintain the connections in the anonymized study, I would imagine you’d have to implement something like what I’ve described here. Again, this is not limited to Orthanc. I’m not aware of DICOM anonymizers that retain these connections in the anonymized output.
John.
