Using Orthanc to add REST API to an existing PACS

Google Groups archive
1

I really like the API Orthanc exposes and the plugin system you’ve developed. I wish most of the PACS I’m working with would have this kind of API :
I’m developing a DICOM Viewer so I ended up creating a custom connector for each PACS to acts like a API and send the information to my viewer in JSON.
I was thinking if maybe could be possible to use Orthanc with an existing PACS and expose the PACS data using Orthanc’s API? I’m newbie on orthanc so I don’t know so much about how it works but I know that you can define custom routing actions and store just metadata intead of just images.
Could you tell me if this workflow could be viable?
1.- Setup autorouting in the Customer PACS to send every instance to Orthanc
2.- Setup Orthanc to just store metadata, not dicom instances but previews (is it possible?)
3.- Once you want to access the dicom data (maybe a custom plugin like the WADO example), the system will query the Customer PACS and send it back.

2

Dear Fernando,

Thanks for your positive feedback. The steps you describe are definitely achievable with Orthanc.

First of all, as Orthanc is vendor-neutral, you can configure any third-party PACS to automatically send its images to Orthanc (of course, provided autorouting is implemented by the third-party PACS).

Secondly, the feature that consists in only indexing the metadata while discarding the full DICOM file, is built in Orthanc. You just have to set the “StoreDicom” option to “false” in the configuration file:
https://code.google.com/p/orthanc/wiki/OrthancConfiguration

Thirdly, you could implement a C/C++ plugin with 2 main features:

  • Whenever a DICOM instance is received, the plugin generates a thumbnail of the image and attach it to the DICOM metadata. Have a look at “attachments” stuff in the REST API of Orthanc to this end.

  • The plugin adds some REST callbacks so that your viewer can ask Orthanc to Q/R images from the third-party PACS when the full images are needed. This may require a second instance of Orthanc with “DicomStore” set to “true” and with “MaximumPatientCount” set to, say, 100 (in order to implement a kind of sliding window by recycling the disk space used by old viewing sessions).

HTH,

Sébastien-

3

Dear Sebastien,

Thank you for your quick reply.
I don’t get why it’s necessary to use two instances, is not possible to do a Q/R within the same instance? I guess because “DicomStore” is false and it means for Q/R too.

I was thinking, maybe it’s possible to set DicomStore=true so the Q/R will be allowed to store the instances on the instance, and then set a filter to prevent the other instances to be stored (the ones from normal production from which we just need their metadata).
I guess this workflow will become more complex as you may need a table to store the instances that you’ve query from the viewer, so you could let pass the dicom store filter to just those.

Anyway I think I really prefer to go for an approach that could be maybe harder initially to develop but easier to maintain, trying to prevent having two instances running.

What do you think?

4

The two approaches are possible, but I fear that your approach will be much more complex to implement in practice.