mercure should run on a wide range of different hardware configurations. Since the routing process is largely I/O bound, it is recommended to use SSD drives and optical network cards when choosing server specifications. However, this is just a recommendation and not required. mercure also runs on virtual servers with small foot print. However, it is required to provide sufficient disk space (ideally 500+ GB), so that mercure can buffer incoming images and keep discarded images for the desired retention period.
If mercure receives images and no routing rule does apply, the images will not be deleted but instead kept in the “discard” folder for a retention period. This enables resending the images to the router again if a routing rule had not been properly configured (otherwise, the images would be lost). The retention period for which the files will be kept in the discard folder can be configured in the configuration files mercure.json.
mercure dispatches series of a study in the order they were received. If multiple simultaneous connections are used to transmit a study (this depends on the sender), it could happen that the dispatching order is changed. At the moment, there is no mechanism for sorting the dispatching order again. However, if there is sufficient interest among mercure users, we will implement a feature to enforce sequential dispatching of all series belonging to one study.
If you should run into a situation where the default mercure setup is not able to handle the load of incoming DICOM series, then you can scale up the instances of the router and dispatcher module. By default, only one instance of each module is used (i.e., in the case of the dispatcher, only one series per time is sent outwards).
All modules have been designed such that multiple module instance can be used in parallel. To enable this, you need to modify the file “services.json” in the “/configuration” folder and duplicate the entry of the module that you want to scale. You need to give the additional module instance a different name (e.g., “dispatcher2”). Moreover, you need to duplicate the corresponding .service file for systemd and rename it accordingly. Note that it is not necessary to scale the receiver module, as the receiver automatically launches a separate process for every DICOM connection.
No, at this time, mercure is neither FDA-approved nor does it have a CE label. However, it uses the Offis DICOM toolkit (DCMTK) for the underlying DICOM communication, which is well-established and used in numerous research and commercial products.
mercure DICOM Router has been developed by Kai Tobias Block and Joshy Cyriac due to the requirement to integrate various prototypic analysis tools into the clinical workflow without creating additional load for the PACS. The name stems from mercure, the messenger of the gods in ancient Greek mythology.