Managing private tags is tricky

Hello,

I refer to my thread of 2016 ( https://groups.google.com/d/msg/orthanc-users/v60O7x3uYF0/tiuOQTBuAgAJ ) concerning private tags. To create Dicom teaching files from scratch I developed a tool called RadioLogicCreator with Swift3 running on MAC OS X computers. Orthanc is used to archive the files which are viewed with a teaching iOS app on iPads.

The maintenance of the whole system in the ever changing Apple environment is cumbersome and the handling of the tools does not respond to the needs of the users. A first improvement was done by hosting the Orthanc server in a Docker container.

A few weeks ago I started to port the RadioLogicCreator with the associated tools into an Orthanc plugin. This is my first C++ project. I was able to compile a first test plugin with callbacks and javascript inserts into explore.js to create new buttons in the Orthanc Explorer and to integrate new jQuery Mobile webpages. While exploring the SDK and the source code of some Orthanc files in depth I had confirmation of the conceptual and technical ingenuity of the Orthanc project.

Again my thanks to Sébastien Jodogne and the Osimis team to make this great work available to the community.

To create Dicom Files from scratch in the Orthanc environment I examindes three different ways:

  1. create the files in Javascript using DicomWriter from Yves Martel’s DWV framework ( https://github.com/ivmartel/dwv ).
  2. create the files with the Orthanc REST API /tools/create-dicom. I was not able to get this option working with the available description and sample code.
  3. use an existing Dicom file as a template and modify needed public and private tags with the Orthanc REST API.

I have a preference for the third solution. I tried to modify the attached Dicom file anonym.dcm with the following commands:

a) at the patient level:

curl http:///patients/3dced8a9-b04d7b36-f12c39c6-a47259a5-b3ac8cc2/modify -X POST -d ‘{“Replace”: {“PatientName”: “Observations1^^”, “PatientID”: “obs1-4321”, “RadioButton1”: “modified tag1”, “RadioButton2”: “modified tag2”, “RadioButton3”: “modified tag3”}, “Force”: true}’

The response is the expected json code:
{
“ID” : “a20a4626-412a44e2-9ddffd71-06958650-d541e3ca”,
“Path” : “/patients/a20a4626-412a44e2-9ddffd71-06958650-d541e3ca”,
“PatientID” : “a20a4626-412a44e2-9ddffd71-06958650-d541e3ca”,
“Type” : “Patient”
}

b) at the instance level:

curl http://192.168.178.68:8043/instances/37284a7e-9a108547-5eec249b-29ad67a6-faf322e3/modify -X POST -d ‘{“Replace”: {“PatientName”: “Observations2^^”, “PatientID”: “obs2-4321”, “RadioButton1”: “modified tag1”, “RadioButton2”: “modified tag2”, “RadioButton3”: “modified tag3”}, “Force”: true}’ > observation2.dcm

The response is the downloaded file which I uploaded again to the Orthanc server.

The new patients were created as expected, but in both cases the value of the private tags are set to null instead of the new values “modified tagx”.

The tag REST API provides the following informations:

“4321,1010” :
{
“Name” : “RadioButton1”,
“PrivateCreator” : “RadioLogic”,
“Type” : “Null”,
“Value” : null
},
“4321,1011” :
{
“Name” : “RadioButton2”,
“PrivateCreator” : “RadioLogic”,
“Type” : “Null”,
“Value” : null
},
“4321,1012” :
{
“Name” : “RadioButton3”,
“PrivateCreator” : “RadioLogic”,
“Type” : “Null”,
“Value” : null
},
“4321,1013” :
{
“Name” : “RadioButton4”,
“PrivateCreator” : “RadioLogic”,
“Type” : “String”,
“Value” : “SarcomeEwing”
},

The type of the tags has been changed to “Null” and the value set to null.

I checked the source file anonym.dcm and the new files with David Clunies validation tool dciodvfy, which confirms that the value representation has been set to UN in the modified files.

orthancmac:dicom3tools mbarnig$ ./dciodvfy<modified3.dcm
(0x4321,0x1010) ? - Warning - Unrecognized tag - explicit value representation is UN
(0x4321,0x1011) ? - Warning - Unrecognized tag - explicit value representation is UN
(0x4321,0x1012) ? - Warning - Unrecognized tag - explicit value representation is UN
(0x4321,0x1013) ? - Warning - Unrecognized tag - assuming explicit value representation OK
(0x4321,0x1014) ? - Warning - Unrecognized tag - assuming explicit value representation OK
(0x4321,0x1015) ? - Warning - Unrecognized tag - assuming explicit value representation OK
SCImage

Is this intended behavior or is something wrong with my usage of the Orthanc REST API ? I would be glad to get your help with this issue. I would also appreciate to get some hints how to use the function /tools/create-dicom with private tags.

best greetings,

Marco Barnig

anonym.dcm (144 KB)

I forgot to mention that I did the tests with the Orthanc version 1.5.6 on Mac and Windows computers.

Marco Barnig

Hello Sébastien & Osimis Team,

I installed a new Orthanc Development Environment in a Debian Docker container on my Synology Diskstation to further investigate about the issues with my private tags.

To progress with my project I use now a workaround which consist in handling the private tags with a system call to the DCMTK-dcmodify command in my test plugin, instead of using the Orthanc REST API.

This solution works as expected after adding my private tags not only into the Orthanc configuration, but also into the DCMTK-private.dic file.

To my understanding there seems to be an issue with the private tags handling in the REST API commands /modify and /tools/create-dicom. For this reason I created issue 140 (https://bitbucket.org/sjodogne/orthanc/issues/140/modifying-private-tags-with-rest-api ) in the issue tracker to describe the problem.

best greetings,

Marco Barnig

Dear Marco,

Sorry for the delay. Thanks for providing the details of your issue: I have just added an integration test that automates the reproduction of your problem:
https://bitbucket.org/sjodogne/orthanc-tests/commits/9929e4af2b7a85dbd8812ef5f8927463ca777c11

The issue is not trivial to fix. I will have a look asap, but presumably not before a couple of weeks because of my limited bandwidth.

Regards,
Sébastien-

Dear Sébastien,

Thank you for adding the private tag issue into the Orthanc integration test. This is an incentive for me to have a deeper look at the whole unit testing framework.

I will setup a test environment with two Orthanc servers in the Docker environment on my diskstation to better understand the working of the integration tests.

Don’t worry about the time to eventually fix the issue. I am using the described workaround to progress with my project.

best regards,
Marco