How to configure dcm4chee local 2.x with OHIF Viewer

[michael.hi...@gmail.com]

Hello, I am trying to configure OHIF Viewer with dcm4chee version 2, this is possible, I have seen that many use dcm4chee version 5, it turns out that I am trying to run OHIF Viewer in a production environment where it already has dcm4chee 2.x and I can not update.

Then my question is, can you configure OHIF Viewer with dcm4chee 2

I'm following the steps from https://github.com/OHIF/Viewers/wiki/Building-for-Production

And i want to know how can i configure it with a local 2cm dcm4chee without using docker

 Here I leave my configuration code

{

  "Servers": {

    "DicomWeb": [

      {

        "Name": "DCM4CHEE",

        "WadoUriRoot": "http: // localhost: 8080 / dcm4chee-web3 / wado",

        "QidoRoot": "http: // localhost: 8080 / dcm4chee-web3 / wado / rs",

        "WadoRoot": "http: // localhost: 8080 / dcm4chee-web3 / wado / rs",

        "QidoSupportsIncludeField": false,

        "ImageRendering": "wadouri",

        "ThumbnailRendering": "wadors",

        "RequestOptions": {

          "Auth": "admin: admin",

          "LogRequests": true,

          "LogResponses": false,

          "LogTiming": true

        }

    }],

    "Dimse": [{

      "Name": "DCM4CHEE_DIMSE",

      "WadoUriRoot": "http: // localhost: 8080 / dcm4chee-web3 / wado",

      "RequestOptions": {

        "Auth": "admin: admin",

        "LogRequests": true,

        "LogResponses": false,

        "LogTiming": true

      },

      Peers

        {

          "Host": "localhost",

          "Port": 4242,

          "AeTitle": "DCM4CHEE",

          "Default": true,

          "SupportsInstanceRetrievalByStudyUid": false

        },

        {

          "Host": "0.0.0.0",

          "Port": 11112,

          "AeTitle": "DCM4CHEE",

          "Default": true,

          "Server": true

        }

      ]

    }]

  },

  "DefaultServiceType": "dicomWeb",

  "Public": {

    "VerifyEmail": false,

    "Ui": {

        "StudyListFunctionsEnabled": true

    }

  }

}

I really do not know if dcm4chee 2x supports that of qdiroot, I'm somewhat lost I hope someone can explain

[Paolo Marcheschi]

Hi
No it is not possible because dcm4chee version 2 does not have the required protocols OHIF needs.
you need dcm4chee-arc-light.
Best regards
Paolo

[Udara M Pathirage]

Are you sure that DCM4CHEE 2.X cannot integrate with OHIF latest version? Because I noticed that this reponse has been published 3 years before.. Please reply to me if anyone knows about this..

Bye

[Subhasish Dash]

Hello, it not directly supported by dcm4chee 2.x but I can do it for you.
So you will be able to see your dcm4chee2.x studies in OHIF viewer.
But it will be chargeable.

Thanks

[Gabriel Kwiecinski Antunes]

I'm also trying to solve this, though I'm new to the medical imaging tech scene. Given that dcm4chee2 only supports WADO-URI and not WADO-RS, the best way to make it work with OHIF Viewer seems to be using a JSON datasource by extracting metadata from the dcm4chee2 database and some that's only present in the dcm files and not in the database, like Columns, Rows and SliceThickness and generating a compliant JSON file for each study. The extraction could be made perhaps on demand and then cached or maybe in bulk for the whole database.

Another problem is the upgrade from dcm4chee2 to dcm4chee5 is apparently possible but I couldn't find any resources online on how to even start doing it. I'm literally considering importing every .dcm file into dcm4chee5 or something, which seems like it would work but it may be too slow for databases with terabytes of data. I know for a fact that exporting .dcm files using dcm4chee2's WADO-URI endpoint like <your_host>/wado?requestType=WADO&objectUID=<target_instance_uid>&contentType=application/dicom and importing those files into dcm4chee5 works just fine like expected, but it's probably not ideal for huge migrations.

Here's what's also funny: if you serve a compliant JSON with a single DICOM instance with the correct URL to the .dcm file but wrong metadata like PatientName and StudyDescription, OHIF Viewer will actually show the correct metadata from the .dcm file instead of what's on the JSON file but the same doesn't happen if there are multiple instances. I don't know why exactly this happens and I still find it weird that OHIF Viewer needs so much metadata from the JSON file like SamplesPerPixel, PixelSpacing, HighBit and ImagePositionPatient when it could just extract it from the .dcm files. Of course, some attributes like StudyDate and PatientName can be queried directly from the SQL database but unfortunately not everything that OHIF Viewer DICOM JSON datasource requires.

If anyone has any ideas or is facing the same problem, feel free to contact me at gabriel.w...@gmail.com

[Gabriel Kwiecinski Antunes]

Ok, so in the OHIF community, there's this possibly helpful answer from fleetwoodfc:

"dcm4chee 2.x does not support DICOMWeb so you would need to add a ‘broker’ e.g. RSNA DICOM-RS Broker 4"

[Gabriel Kwiecinski Antunes]

I successfully managed open images from dcm4chee2.x in OHIF using dicomweb-proxy with minor modifications like redirecting wadouri calls with contentType=application/dicom to the original server to avoid file compression errors from the proxy.

[Alberto Tinoco Ruilova]

Hi Gabriel, thanks for the solution, can you please teach us what did you modify to avoid file compression errors?

[Gabriel Kwiecinski Antunes]

Sorry for the late reply.

dicomweb-proxy copies the DICOM files and tries to serve them locally (from where dicomweb-proxy is). It creates WADO urls that point to those local files. What I did was change the code that was responsible for pointing to the local dicomweb-proxy files so it would point to the original server because DCM4CHEE 2.X works with WADO-URI (what doesn't work is WADO-RS). It was a very minor modification. The drawback is that the files got replicated anyway. I'll look into it again.