DICOM Template - mbarnig/RadioLogic GitHub Wiki

To embed the Observation and Answer pictures into DICOM instances, the straigthforward process would be to use the Orthanc REST API /tools/create-dicom. Unfortunately the creation of the needed private tags fails with this function. The related Issue 140 was raised in May 2019 in the Orthanc Core issues tracker on Bitbucket.

As a workaround, a system call to the dcmodify command of the Offis DCM Toolkit was tested. Sadly inserting new private tags in a DICOM file with this tool also fails. Therefore a DICOM template with all required private tags was created and uploaded as protected study into the RadioLogicArchive.

The template consist of one study containing two series. Each series has one instance. The template name is RADIOLOGIC^OBSERVATION^ANSWER, the patient ID is "radiologic-4321".

The following two figures shows the metadata and the image preview of the Observation instance:

If we inspect the metadata of the Observation DICOM file we see the private tags starting with the PrivateCreator tag (4321,0010) named RadioLogic. Ten tags for possible diagnoses are listed after the private creator, followed by the ScrambleKey and the ClinicalCaseAuthor tags. All tags are empty. Inserting values into the existing empty private tags with the dcmodify command works as expected. The place-holder picture in the Observation DICOM file is replaced with the real Observation picture during the creation process. The content serves as model for the teacher editing this picture.

To display the private tags correctly in Orthanc, we must add the tags to the DICOM dictionary. This is done with the configuration file radiologic-dictionary.json. Here is the content:

{      
"Dictionary" : {    
      "4321,1010" : [ "LO", "PossibleDiagnosis0", 1, 1, "RadioLogic" ],    
      "4321,1011" : [ "LO", "PossibleDiagnosis1", 1, 1, "RadioLogic" ],    
      "4321,1012" : [ "LO", "PossibleDiagnosis2", 1, 1, "RadioLogic" ],     
      "4321,1013" : [ "LO", "PossibleDiagnosis3", 1, 1, "RadioLogic" ],   
      "4321,1014" : [ "LO", "PossibleDiagnosis4", 1, 1, "RadioLogic" ],    
      "4321,1015" : [ "LO", "PossibleDiagnosis5", 1, 1, "RadioLogic" ],    
      "4321,1016" : [ "LO", "PossibleDiagnosis6", 1, 1, "RadioLogic" ],    
      "4321,1017" : [ "LO", "PossibleDiagnosis7", 1, 1, "RadioLogic" ],    
      "4321,1018" : [ "LO", "PossibleDiagnosis8", 1, 1, "RadioLogic" ],    
      "4321,1019" : [ "LO", "PossibleDiagnosis9", 1, 1, "RadioLogic" ],    
      "4321,1020" : [ "LO", "CorrectDiagnosis",   1, 1, "RadioLogic" ],    
      "4321,1021" : [ "LO", "ScrambleKey",        1, 1, "RadioLogic" ],    
      "4321,1022" : [ "LO", "ClinicalCaseAuthor", 1, 1, "RadioLogic" ]          
  }    
}  

The next two figures shows the tags and the image preview of the Answer instance:

In the Answer DICOM file we see also the private tags, starting with the PrivateCreator tag RadioLogic and followed by the CorrectDiagnosis and the ClinicalCaseAuthor tags. Again all tags are empty and will be filled later during the creation process.

In both DICOM files the SOP-, Series- and Study-InstanceUID's have the RadioLogic prefix 1.2.826.0.1.3680043.9.6278 which has been provided in June 2016 by David Harvey, former Managing Director and founder of Medical Connections Ltd. The company continues to provide free UID prefixes for small and medium scale developers.

The next chapter RadioLogic Clinical Cases deals with sessions, user-defined metadata, nomenclatures and checksums.