DICOM routing use case

[JoeBatt1989]

As part of Connectathon there have been specific DICOM routing tests which MONAI Deploy can support but that involves setting up workflows and saving te inbound study to Minio...both of these were actions are intended for Clinical Pathway execution. Please see below as to how we are currenty facilitating this functionality and what an example Clinical Workflow in the Workflow Manager would look like.

If this is a use case for MONAI Deploy the the current solution could lead to:

• Lots of Clinical Workflows as you would need at least 2 for one execution i.e PACS -> MONAI -> Execution Engine && Execution Engine -> MONAI -> PACS
• Potential for Clincial Workflows to be triggered accidently if not managed appropriately
• Increased latency in saving inbound DICOMs and sending WorkflowRequest event

If this is a use case is wanted then there could be better ways that this could be acheived, which are scaable and more performant. i.e building that functionality into MIG (to be discussed)

{
	"name": "Connectathon MR",
	"version": "1.0.0",
	"description": "This workflow is to be used for connectathon",
	"informatics_gateway": {
		"ae_title": "FLEISCHNER_MR",
		"export_destinations": [
			"AIRCDEMO"
		]
	},
	"tasks": [
		{
			"id": "export-task-connectathon",
			"description": "Connectathon export task",
			"type": "export",
			"export_destinations":[
				{
					"Name": "AIRCDEMO"
				}
			],
			"artifacts": {
				"input": [
                    {
						"name": "study",
						"value": "{{ context.input.dicom }}",
						"mandatory": true
					}
				]
			}
		}
	]
}

[MMelQin]

I'd definitely agree with you that this use case was NOT the typical intended use of AIDE/MONAI Deploy, i.e. this basically uses AIDR/MONAI Deploy as a DICOM router for it to receive a set of DICOM instances on IG, stores them in via the storage service, triggers workflow, which turns around and tells the IG to send the whole set of original DICOM instance to a another DICOM AET requiring the IG to read from storage again. AIDE/MONAI Deploy can do this, but may not be in the most efficient way. The initial architecture and design is for the ingested DICOM instances be consumed within, and only the processed result (typically a single DICOM instance) sent back out.

The IHE AIW-I prescribed AI Task Manager (no to be confused with MONAI Deploy Task Manager), aka Orchestrator, actually should use UPS-RS (RESTful protocol) to receive requests containing metadata information only, then wait for the registered performers, e.g. AIRCDEMO, to come and claim a request item, and the performer itself is responsible to pull DICOM instances from image manager/PACS. But, given that UPS-RS is not supported by all, we proposed to use this DICOM DIMSE based routing, and made AIDE/MONAI Deploy as the router.

Agree that for a more efficient routing implementation, the rules and destination configurations can be parsed by IG, which will only need to loop backout the instances without needing to trigger an internal workflow, and for AIW-I workflow, the desired solution is to implement what the profiles prescribe, including supporting UPS-RS. Brad actually created the related issues #348 and #349 on the App SDK board, which need to be moved to MONAI Deploy top level or Workflow.