I would be more than happy to help. But, I need to get a solution in place and right now I am working with MIRTH to handle the dicom side (3 separate installs, 3 separate servers) and another MIRTH for just HL7 messages. I don't know if it will work properly or not or is fast enough, but I guess I will see.
Here is a simple description:
Datacenter with 23 servers. Of those, 11 are on separate fiber connections for internet. That would be PACS, SQL database, Web sites, routers, etc. Every one is also connected to internal network at 1 GB and everything is on CAT6. All my fiber connections are 900 up/down (at least, we usually get better speeds). The actual fiber hub for the entire pond is also in my datacenter. They decided a few years ago (been open for 10 years now) that since I was bringing in so many lines over the years to move off the pole and put right in the datacenter for easy access and future connections and upgrades.
Our current router software used for incoming studies is on 3 servers, all of them Windows 2008R2, all of them on separate fiber lines at speeds stated above. The data is processed by this router software and then pushed to the PACS. The PACS uses 6 different network cards. 3 of them are for the incoming studies from the router software, 2 of them for outbound studies, the 6th one is for internet access.
The current router software is very old and from a company called Clario. It is based on Clear Canvas and it extracts the dicom header information needed to populate a worklist (through SQL) from each study, does data coercion if needed, and adds accession numbers to any study that does not have one incoming. It then pushes the studies across the internal network to the PACS.
The issues with it are:
1. It is a 32 bit program and only allows 2 dicom connections at a time
2. It does not understand any compression above JPEG Lossless
3. No support or upgrades in 3 years and is now totally unsupported
Also, I am replacing all the Windows 2008R2 servers with either Windows 10 PRO (if I don't need server OS) or Windows 2016.
So, I need a solution that can handle at least 800 studies per day incoming (MRI, CT, MG, US, DR, NM, etc.) AND be able to route out to at least 3 destinations at the same time.
That is why multi-threading is so important. My outbound is great. I have anywhere from 20 to 40 threads running at a time spread over 3 network cards. Those threads are multiple studies level threads sending out at JPEG LS compression.
I would really like inbound to be the same. Since I don't have anyway to extract the dicom header data and send via HL7 to SQL except MIRTH, I am attempting to setup 3 MIRTH on 3 separate servers (mirroring current router software setup) for dicom and then all of them will route to another MIRTH on another internal ONLY server for the HL7 dicom extraction to the SQL server and also route all dicom studies to the PACS. I have to have multi-threading dicom connections and sends to the PACS. One study at a time from each MIRTH is too slow and image by image will clog up the network and slow it down horribly. I actually tested all the outbound to go by the image level and it was a disaster and I quickly had to switch back to study level.
Right now I can get a 500 slices CT or 200 slice MRI to a radiologist in under 1 minute and that is going to 3 destinations at once. So all 3 would have study in under 1 minute. US and DR are in seconds. I need that kind of speed internally to the PACS.
All professional router software out there would run about $15,000 per instance and around $2,500 each per year for service contracts.
My solution was to use Conquest for inbound dicom, do the data coercion as needed, add accession number if needed, forward to MIRTH server for it to do the HL7 extraction and forwarding to the SQL server (and then dump the dicom images) and at the same time route the dicom studies to the PACS over the internal network to