The visual DICOM browser provides a new user interface for quick viewing and retrieval of patient images stored on remote DICOM servers. The new tool is optimized for clinical workflows where the focus is on all the images of a single patient - as opposed to the existing DICOM browsing experience, which was more suitable for bringing together images from many patients.
Both server and local content are located at the same place and are visualized by thumbnails. All data is retrieved in the background using classic DIMSE networking (most commonly used protocols in hospitals), in multiple concurrently running threads. The currently supported operations are:
Browsing and filtering with thumbnails of content of local DICOM database and multiple remote DICOM servers.
Query/Retrieve data from servers (DIMSE C-FIND, C-GET, C-MOVE SCU). All the operations are done in background and in parallel. Downloaded data is automatically cached in the local DICOM database. A unique feature is the possibility to retrieve images using C-GET protocol (suitable for cases when many Slicer instances are running in docker containers) with a clinical PACS that only supports C-MOVE protocol (most clinical PACS), via a proxy server (such as the free Orthanc).
Import data from local files.
Receive data sent from remote PACS (DIMSE C-STORE SCP).
Send data to remote PACS (DIMSE C-STORE SCU).
Quick browsing of all DICOM metadata and pixel data.
Remove data from local database (not from server).
The new interface is available in the DICOM module. To enable the new browsing experience toggle the Show experimental visual DICOM browser option in the dropdown menu of the Show DICOM database button:
We have tested the widget mostly on Linux and Windows on multiple servers (Orthanc, www.dicomserver.co.uk, and some clinical PACS). It would be great to get feedback how the browser performs in different environments.
Developement is still ongoing, and a comprehensive roadmap is available here. We are looking forward to receiving error reports or any comments and suggestions for further improvements.
For developers
Example scripts for accessing the widget logic from Python can be found here
Hey Andrey. It’s one of our long term enh in the roadmap. I agree that it would be critical to have also dicomweb. The issue is that the new widget is fully written in C++ at ctk level and there is no clear supported C++ dicomweb library. We will also explore other ways (e.g. python libraries )
During the project week (see Project Description | NA-MIC Project Weeks) we plan to get feedback and discuss future plans and probably dicomweb will one of the main discussion item.
Ultimately it will depend on people interest and funds
We could move MITK’s C++ DICOMweb implementation to CTK and use it in this browser. Classic DIMSE support was prioritized over DICOMweb implementation because DICOMweb is still very rarely supported by hospital PACS. If there is a confirmed need then it would not be huge work to add DICOMweb, because the framework is designed to support multiple protocols (DIMSE, DICOMweb, and custom PACS/cloud provider protocols).
I appreciate your prompt report, and I am sorry for the inconvenience. @Sam_Horvath and @jcfr are currently addressing a minor issue with the Windows binaries. For further details, please refer to the ongoing discussion at: Slicer build error on Windows on the dashboard
Meanwhile, the MacOS and Linux binaries are fully functional – I’ve personally tested the Linux version, and it works seamlessly. If you’re using either of those systems, feel free to download and use them. We anticipate resolving the Windows binary concern by early next week. Thank you for your understanding.
Furthermore, in today Slicer preview (Linux and MacOS) we have released a refreshed UI that comes with a dedicated Jobs list:
Please, let us know if you have any comments or suggestions.
Just to be clear, I don’t want to say there is a confirmed need from my side. It’s just that I do not work with any DIMSE servers, and I am not going to set one up for the sake of testing this. With DICOMweb support, testing of this functionality would become trivial using, for example, Google Healthcare API.
The browser can be tested with local DICOM files - thumbnail display, searching and filtering, etc.
To try the PACS connection features, you can use the Medical Connections DICOM test server. This server is preconfigured in Slicer by default, you just need to enable Query/Retrieve for this server in the Settings section.
In my view, one of the interesting testing scenarios would be to try it out against a database that has a non-trivial amount of heterogeneous data across the range of manufacturers/modalities etc. That’s not something that can be done using local files or that test server. But could be done with the DICOMweb server we have in IDC that has >50TB of data. Or with a smaller subset of that.
In any case, if you guys want to test it using such a subset using other means, I am happy to answer any questions related to selecting and downloading data from IDC!
This new DICOM browser is optimized for clinical workflows (you focus on a single patient and access complete history of that patient) and not for exploring research databases (where you don’t know what patient you want to see and often want to aggregate data over multiple patients). For example, in the visual DICOM browser there is very limited set of patient search&filter features, because the clinician knows the one single patient he is dealing with; while in a research database browser a big part is to find relevant set of cases.
But thank you @fedorov for the offer. As @Davide_Punzo wrote, large databases can be useful for performance testing and optimization. After DICOMweb support is added we could also see if the browser can be adapted to work conveniently for non-clinical/non-patient-oriented workflows on research databases.
