Dicom-Web incomplete Tags


I am currently working on a PACS viewer, that only uses the dicom-web standard. Orthanc, when including the dicomweb plugin, implements this standard at least partially. The problem I have now is, that it seems that Ortanc only sends a limited number of dicom tags out as xml.

For example, when I request


I get the instances with some of their tags as multipart/xml back. Unfortunately, many important tags (mandatory for rendering) are left out, which are definitely known to Orthanc, since I can see them on the Orthanc-Explorer attached to the instance.
Is there a way to tell Orthanc to send all the tags?

As a workaround, I could use the Orthancs own REST Api (which I would not prefer), but then I have to use orthancs resource identifiers, which are not equal to the DICOM identifiers (StudyInstanceUid, SeriesInstanceUid and SOPInstanceUid). Or is there a way to query the Orthanc API using the DICOM identifiers?

Thanks in advance,


Have you tried the “WADO-RS - RetrieveMetadata” URI?

For instance, the following URI would return a single JSON array gathering the DICOM tags of all the instances within one series:


Unfortunately, that gives me a 400 - Bad Request. I think the retrieveMetadata url has not yet been implemented by Orthanc, has it?


It has: “WADO-RS - RetrieveMetadata” is supported for a long time (even back to release 0.2 of the DICOMweb plugin).

For instance, start release 1.0.0 of Orthanc with plugins through Docker:

sudo docker run -p 4242:4242 -p 8042:8042 --rm jodogne/orthanc-plugins:1.0.0

Then, upload DICOM files and use the RetrieveMetadata URI for studies/series (obviously, adapt the DICOM UIDs to your files [1]):

storescu localhost 4242 *

curl -u orthanc:orthanc http://localhost:8042/dicom-web/studies/

curl -u orthanc:orthanc http://localhost:8042/dicom-web/studies/


[1] Note that those are DICOM UIDs, not Orthanc identifiers.

Thanks Sébastien,

I now have managed to get the metadata. It didn’t work out of the box, however. For other users who also get a 400 - Bad Request: I had to manually set the HTTP ‘accept’ header to either ‘application/json’ or ‘/’. The latter will result a base64 encoded xml.

Thanks again