We’re excited to announce that with the upcoming release of Ozone 1.0.0-alpha.12 the Ozone ecosystem will welcome a new app: Orthanc. Orthanc is a lightweight DICOM server designed to store, receive, and transfer medical images.
OpenMRS ←→ Orthanc Data Flows:
Orthanc, acting as a DICOM server, receives DICOM images from a modality (e.g., an X-ray machine). For this integration, we’ve used the ‘Other Patient IDs’ DICOM tag to store the OpenMRS identifier, thereby mapping the study to a specific patient.
A thumbnail is generated by Orthanc out of each DICOM study and is made available as a very minimal representation of the study, and we have leveraged this feature. Once Orthanc receives a DICOM image with a patient identifier set in that tag, a dedicated OpenMRS-Orthanc EIP route saves the thumbnail in OpenMRS as a patient attachment.
Moreover we have enriched this attachment with a hyperlink to Orthanc’s viewer for the associated DICOM study. This way OpenMRS users have a convenient way to access the study, provided they have the credentials to do so in Orthanc.This integration is currently a proof of concept and has the potential for further enhancements, such as:
Sending radiology orders (ServiceRequests) from OpenMRS to Orthanc and syncing back the studies to OpenMRS when available in Orthanc.
SSO across OpenMRS and Orthanc.
Implement role-based access control Orthanc.
Expand the use of FHIR across the OpenMRS ←→ Orthanc data flows
Does Orthanc also support a DICOM modality worklist functionality?
Because then indeed the functionality for send radiology orders would be super useful.
I also like the simple approach how you have solved the display of the results as an overview image with a link to the actual study!
Thanks on behalf of @sidvaish97, all credits to him
I wasn’t aware of this Palladium ESM. Perhaps this could be used indeed but it would have to be assessed, specifically what’s being done on the backend side of it, and brought back to /openmrs.
I confirm that Orthanc supports DICOM worklists, but it does not force the way worklists are stored. Orthanc comes with a sample worklist plugin that stores the worklits as DICOM instances on the filesystem.
However, the Orthanc SDK provides full flexibility about how worklists are retrieved given an incoming DICOM C-FIND SCU query (cf. the low-level function OrthancPluginRegisterWorklistCallback() in the Orthanc documentation). This offers the opportunity of tight integration, for instance against OpenMRS.
Note that even if the Orthanc SDK is written in C, a Python mapping does exist to help with the prototyping. The same feature could be wrapped in Java if need be.
Hope this helps, Sébastien-
NB: As a new user on this forum, I cannot share more than 2 hyperlinks in this message, so I am unable to provide direct links to the SDK documentation and to the Python/Java plugins.
