How to handle Frame of Reference UID in anonymization

Hi there,

We worked on a anomyzation ImageJ plugin based on Orthanc (

We met a problem, commercial AWServer workstation rejected anonymized DICOM with “Incomplete Header” error message.

I isolate the problem, now I can confirm that this is due to one single tag missing : 0020,0052 Frame of Reference UID

So if I put the 0020,0052 in the Keep argument of the anonymization command my anonymized DICOM are accepted by AWServer with no problem.

The limitation is that keeping 0020,0052 keep a trace of the original data and we could recover original patient using this tag (not completely easy to do but therorically possible)

My question is : How I can replace this Frame of Reference UID safely in my Java program ?

  • Is that UID have to match a real Instance UID in the study ? Or should I generate an arbitrary UID and use the “Replace” Argument to inject it in all Anonymized images ? (is there an Orthanc API to generate an UID ?)
  • How to do in case of study anonymization, this tag should be unique (as far as I know) in series geometrically related, If the anonymization is done of a Patient or Study level, how to manage if the anonymized study should share or not a common Frame of Reference UID ?

This problem has been discussed there :
It was proposed to be managed in a plugin or an external app.

I’m ready to manage it in my external Java program but I don’t see how I can manage it using Orthanc API? Adding the 0020,0052 in the Keep list is a quick fix but not optimal since I still get an identification key to original data.

Best regards,


Hi Salim,

Indeed, the FrameOfReferenceUID shall be consistent in your complete study (don’t know if it should be consistent across multiple studies).

So you should clearly use somethings like:

UID anonymize(UID& sourceUID) {
  // if this is the first time we encouter this sourceUID, generated a new UID and save it in a 'cache'

 // else, returned the cached UID

Orthanc does not offer a route to generate Dicom UID. However, these are usually quite easy to generate. This is how we do in python: we use a prefix that we got from and we add a timestamp + a random number and we make sure it’s not longer than 64 bits.

def getDicomUid():

    now =

    return '1.2.826.0.1.XXXXXX.X.XXXX.{timeStamp}.{random}'.format(
        timeStamp = int(now.timestamp()),
        random = random.randint(0, (1 << 128) - 1)

Once you have your UID, you can add { “Replace” : {“FrameOfReferenceUID” : uid} } in the anonymize query.

Best regards,


Dear Alain,

Thanks to your explanations. I see now how I can generate an UID.

My problem is : how I can know if a study really need a new frame of reference UID ?

When I start a anonymization of a study I don't see how I can monitor the frame of reference UID.
In fact the only way I see is to make a /shared-tags for each series and group series that have the same frame of reference UID.
Then send the anonymization query at the serie level specifying each reference frame UID that should be included but even this solution will not fit because the anonymization query will land on different study UID so the different study will not probably not be merged.

In short I see you idea about getting reference frame UID and generating a new UID for each new in a batch process but I don't see any dynamic API that could allow to monitor and inject new UID during the anonymization process.

I could generate a new UID and put it in the replace of the study anonymization call but I'm not sure all series should have this tag. For example does structured report or secondary capture should have the same reference frame UID ? In the nema I found that a common referenced frame UID is for series specially related (this is not case for secondary capture or SR or dose report).

Do you think it will be safe to generate a new referenced frame UID and apply it to a study anonymization request without mapping original referenced frame UID ?

Best regards


Hi Salim,

I understand your point and I don’t know what would happen if you include a ReferenceFrameUID tags in series where it does not make any sense.

Since you’re Java software is controlling the anonymization, you might try to perform the anonymization at the series level instead of the study level (or eventually even at the instance level).
When working at lower levels like these, it’s up to your software to make sure that anonymized fields are consistent between series (i.e: that the PatientName/PatientID are the same in every series → you must generate them yourself and force them in the ‘replace’ tags) So, it moves part of the anonymization complexity to your software …

Best regards,


The problem with the series level is that the Study will not be unique anymore, The first request will generate a new studyUID for series1 and the second request for serie 2 will generate a new study with another different StudyUID, it would need to force StudyUID as well when making request (and hoping that there is not another tag involve accross series of a same study).

Well, for now I will keep the Reference Frame UID with “Keep”. It gives a remaining identification key but it sounds very unlikely to me that an user could recover it, it would need to get his hand on the orignal storing system and have access of the whole database of UID to find this specific key.

Your idea of mapping UID in a batch is a good solution but it seems to me that it is possible only inside Orthanc during DICOM re-writing since it is pretty hard to manage all UID and Instance level tags in an external program.

Best regards,



Orthanc does not offer a route to generate Dicom UID.

Actually, such a REST API route to generate DICOM UIDs does exist:

curl http://localhost:8042/tools/generate-uid?level=instance

curl http://localhost:8042/tools/generate-uid?level=study

curl http://localhost:8042/tools/generate-uid?level=series