Add support for DICOM protocol

[rbeckman-nextgen]

Add proper support for the DICOM transmission protocol.

Imported Issue. Original Details: Jira Issue Key: MIRTH-591 Reporter: chrisl Created: 2007-10-30T13:35:10.000-0700

[rbeckman-nextgen]

Reopened to take into account the transmission protocol.

Imported Comment. Original Details: Author: geraldb Created: 2008-06-10T15:31:39.000-0700

[rbeckman-nextgen]

Any idea what DICOM commands are you going to support? Let me know if you need anything.

Imported Comment. Original Details: Author: damien Created: 2008-06-25T12:32:14.000-0700

[rbeckman-nextgen]

Initially we are planning on supporting dcmrcv and dcmsnd. There might be a chance that we include dcmmwl in 1.8 also.

Imported Comment. Original Details: Author: dans Created: 2008-06-25T12:40:06.000-0700

[rbeckman-nextgen]

So supported DICOM transactions would be:

||DICOM Command||SCU||SCP||Notes|| |C-STORE|X| | | |C-STORE| |X| | |C-FIND|X| |Modality Worklist Information Model - FIND|

Correct?

Imported Comment. Original Details: Author: damien Created: 2008-06-25T12:49:43.000-0700

[rbeckman-nextgen]

Oh, you guys don't have wiki formatting turned on in your JIRA!

Imported Comment. Original Details: Author: damien Created: 2008-06-25T12:51:50.000-0700

[rbeckman-nextgen]

So supported DICOM transactions would be:

C-STORE as an SCU C-STORE as an SCP C-FIND as an SCU using the Modality Worklist Information Model - FIND SOP Class

Imported Comment. Original Details: Author: damien Created: 2008-06-25T12:52:54.000-0700

[rbeckman-nextgen]

so what will be the advantage of using mirth with the dicom protocoll ? can I split dicom transactions to multiple SCPs (f.e. you implement C-STORE SCP and the received object gets forwarded to multiple C-STORE SCPs) ?

Imported Comment. Original Details: Author: arnold_mad Created: 2008-06-27T00:55:30.000-0700

[rbeckman-nextgen]

Yeah, I kind of struggle trying to figure out the use cases as well....

I especially don't see the need/sense in implementing a MWL C-FIND SCU. If anything, I would see Mirth as being a natural MWL SCP, since there is a good chance that orders (HL7 ORM^O01 messages ) would flow through Mirth.

I think that the use cases for using Mirth as a C-STORE SCU/SCP are centered around routing. I could see using the scripting and filtering capabilities to do some intelligent routing. For example, sending thin slices to a post processing workstation and thick slices to a reading workstation or PACS (in the case of a large CT study). Or, acting as a proxy for misbehaved DICOM devices - massaging DICOM headers before sending them to their destination. Or, normalizing DICOM headers to a common set of rules before sending them to the archive or PACS.

Those are niche use cases, but I do see some value in them. One thing the Mirth developers need to be very careful about is the memory and IO (network and file system) implications of pumping DICOM studies through the system. DICOM objects can be large, and there are many DICOM objects in a DICOM study. For example, the CT scenario that I gave above is mainly of use for large CT studies (many thousands of images) from a multi-detector CT device. I just had several ~18,000 image CT studies go through one of our TeraMedica systems in the past week. That is a big shift in the memory and IO requirements of a system which has previously been dealing with (relatively-speaking) small text messages.

In the Mirth implementation, will the images be streamed from the inbound channel to the outbound channel, or temporarily stored on the file system? If they get stored on the file system, then storage hardware becomes a MAJOR consideration. Also, what will the retention policies be for stored images? It doesn't make sense for a system like Mirth to archive them, therefore they'll need to be deleted at some point, adding more overhead to the system.

Anyway, I am very interested in hearing what the requirements and use cases are from the Mirth (and Mirth community) point of view. Daniel asked me if using the DcmSnd, DcmRcv, etc. classes was a good idea. I think so, but without knowing the use cases and requirements, I cannot say for sure.

Imported Comment. Original Details: Author: damien Created: 2008-06-27T07:30:33.000-0700

[rbeckman-nextgen]

Arnold: Yes, you could have a DICOM Listener (C-STORE SCU) and multiple DICOM Senders (C-STORE SCPs) so that the transaction goes to all SCPs or filters to different SCPs depending on the DICOM header data for example.

Damien: Thanks for the information. We have a few users on the Mirth message board that are using DcmMwl inside of Mirth (just calling it directly from javascript). One user has taken it upon himself to implement it as a full Mirth connector. I am not exactly sure of the use case either but I know a few clients have also asked for it. This would probably be a good topic to bring up on the mirth message board.

Yes, we have noticed problems with message size. We currently strip out the image data from the dicom message and store it in the internal Mirth db. The image data is later put back in the message before it is sent out.

Mirth has message pruning options to delete older messages or the option not to store message data at all.

Thanks for your input!

Imported Comment. Original Details: Author: dans Created: 2008-06-27T10:24:49.000-0700

[rbeckman-nextgen]

Ok, thanks for the response.

For reference, here is a link to the dcm4che issue Daniel created: http://www.dcm4che.org/jira/browse/DCM-209

Imported Comment. Original Details: Author: damien Created: 2008-06-27T11:37:24.000-0700

[rbeckman-nextgen]

DCM-209 has been resolved in SVN trunk. I don't think there will be a new release of the toolkit for a little while, so you're going to have to build it from source in order to use the modified classes. See http://www.dcm4che.org/confluence/display/d2/Building+dcm4che2

Imported Comment. Original Details: Author: damien Created: 2008-06-27T12:23:03.000-0700

[rbeckman-nextgen]

Created http://www.dcm4che.org/jira/browse/DCM-210 for second dcm4che enhancement request.

Imported Comment. Original Details: Author: damien Created: 2008-06-27T14:21:29.000-0700

[rbeckman-nextgen]

These are kind of abbreviated, but here are some use cases I can think of:

1. Using mirth as an edge device for small hospitals, just routing dicom and hl7 in a small package or appliance for that matter...

2. Dicom cohersion (update headers before sending)

3. query and retrieve not necessary (as Damien said)

4. Integration with Radiological Teaching File systems.

5. The ability to generate an ORM message based on a DICOM inbound.

6. Image replication, 1 in 2 out, to multiple destinations.

7. Anonymization.

Imported Comment. Original Details: Author: sween Created: 2008-07-16T10:16:17.000-0700

[rbeckman-nextgen]

I have concerns about the implementation of this feature. Discussion is here: http://forums.dcm4che.org/jiveforums/thread.jspa?threadID=653

Imported Comment. Original Details: Author: damien Created: 2008-07-23T15:17:02.000-0700

[rbeckman-nextgen]

Hi all,

just as a use case. I'm trying to integrate the information of a large external PACS (only pointers to that PACS studies) in my database. At this point I could configure a channel reading my patient requests, querying with QUERY/RETRIEVE at destination point, and redirecting the answer to another channel in order to feed my database. This channel could be optimized, of course, but please, do not discard QUERY/RETRIEVE mechanism easily!. I read all your comments about DICOM, and you are right discarding any features demanded but Q/R is an unvalued way to obtain information without overloading Mirth (using only query service without retrieving the images).

Hope this make you think about.

Thanks in advance.

Imported Comment. Original Details: Author: ricber Created: 2008-09-16T14:43:11.000-0700

[rbeckman-nextgen]

Add support for queries.

Imported Comment. Original Details: Author: jacobb Created: 2008-10-02T17:02:08.000-0700

[rbeckman-nextgen]

Add ability to query DICOM MWL. We have several instances where we need to initiate several requests to 3rd party systems based on a MWL status.

Imported Comment. Original Details: Author: wakesk8 Created: 2008-11-26T11:13:36.000-0800

[rbeckman-nextgen]

DICOM is already implemented and supported. New ticket for DICOM Query: http://www.mirthcorp.com/community/issues/browse/MIRTH-780

Imported Comment. Original Details: Author: dans Created: 2009-05-15T12:37:12.000-0700