Generating new FrameOfReferenceUID

[John Roberts]

FrameOfReferenceUID is important in the context of our MR DICOM images for indicating which DICOM share a common coordinate frame of reference.

Currently, the tag is removed by Orthanc's default anonymization, given that it is listed in Table E.1-1 from PS 3.15 of the DICOM standard 2008.

I believe that, in order to retain the spatial relationships between the MR DICOM, I'll need to generate new FrameOfReferenceUID during anonymization (rather than dropping the tag altogether).

I'm currently researching how to generate a new FrameOfReferenceUID, but does anyone know if any of the other UID generated by Orthanc (study, series or instance) could legally be used for FrameOfReferenceUID?  If so, I would call the restAPI to generate the UID.

John.

[Alain Mazy]

If you're using the Rest API to anonymize the images, you may specify the tags you wish to keep explicitly with 'Keep' (there is also a 'Replace' field to force anonymization):

'Replace' : {
    'PatientName': 'Toto',
    'PatientID': 'Tutu'
   },
'Keep' : ['StudyDescription', 'SeriesDescription', 'FrameOfReferenceUID']

--

Alain Mazy / CTO 
a...@osimis.io / +32 494 31 67 27

	OSIMIS S.A.  Rue bois Saint-Jean 15/1BE-4102 Seraing  www.osimis.io

[John Roberts]

Thanks, Alain, that is how I intend to use the Keep option, though I will be following the anonymization with a modify.

I need to generate new FrameOfReferenceUID since the originals embed machine identifiers that can be used to identify the original exam.  I think this is why they are in the list of tags to replace or remove as given by the DICOM standard.

My question is whether I can use one of the other restAPI calls that generate UID as a replacement.  From my reading online, I think the FrameOfReferenceUID need only be unique like the other UID.  There's nothing particularly different between it and a StudyInstanceUID.  So, I plan on calling the restAPI to generate additional UID as needed for use as replacements for the FrameOfReferenceUID.

This brings up the general issue of generating UID with Orthanc.  I haven't found documentation for a FrameOfReferenceUID generator (like the ones for patient, study, series, instance).  

I also don't see documentation for the SOPClassUID generation.  Yet all SOPClassUID tags are replaced during Orthanc's anonymization.  Either Orthanc is doing this behind the scenes, or perhaps the underlying dcmtk library handles the SOPClassUID generation.  Whatever the case, the FrameOfReferenceUID is not updated (the Keep option only keeps the original).

John.

[John Roberts]

I take that back, the SOPClassUID are left alone and kept by default.  They are not replaced.

[Levin Alexander]

Hi,

I can't speak towards whether it is okay to use Orthanc/DCMTK generated UIDs for other than the intended fields. (although it won't break anything because these UIDs are guaranteed to be globally unique) [1]

May I suggest two alternatives to Orthanc's generator:

- You can register your own UID root and then generate UIDs under that root yourself with your own algorithm.
(you could use https://www.medicalconnections.co.uk/Free_UID medicalconnections.org for that, that was quick, free and without hassle when I last used that. Recommended.)

- (Not 100% sure I've read the standard correctly, but) You can convert UUIDs into Dicom UIDs: http://dicom.nema.org/Dicom/2013/output/chtml/part05/sect_B.2.html
You take a UUID, convert the hex string to a number and prefix it with "2.25."
(as described in this stackoverflow answer: http://stackoverflow.com/a/14165940/55534)

Both of these are guaranteed to be safe.


Levin Alexander


[1]

code:
http://support.dcmtk.org/docs-snapshot/dcuid_8h.html
http://git.dcmtk.org/?p=dcmtk.git;a=blob;f=dcmdata/libsrc/dcuid.cc;h=6da9f04b1c75075a6633fa0df878112d752d2526;hb=HEAD#l1748

Orthanc seems to use the Offis uid root ("1.2.276.0.7230010.3") by default. So they have authority over how that space is used. I have no idea what their rules are.

If you have your own UID root you can compile dcmtk to use that. Then you can use the uids generated by /generate-uid however you like.

[Sébastien Jodogne]

Hello,

You can generate new DICOM UIDs on demand by GET-ing the following URI:

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

As always, this primitive is accessible from Lua through "RestApiGet()":

https://orthanc.chu.ulg.ac.be/book/users/lua.html#calling-the-rest-api-of-orthanc

HTH,

Sébastien-

[John Roberts]

Thanks, Sebastien, that's my plan, though I'm not settled on whether to use an Instance, Series or Study UID to replace the FrameOfReferenceUID.

My understanding is it need only be unique, so probably any of those will work.

Regarding Levin's suggestions, I'm glad of the help.  I suspect that for our scenario, it will probably be sufficient to fake a new FrameOfReferenceUID with one generated by Orthanc's Study/Series/Instance UID generators.

It's only by virtue of Orthanc's usability that I've ventured into the murky world of DICOM coding in the first place.  The DICOM standard reminds me of programming in C - very flexible and powerful, but fraught with pitfalls and dangers.