Posts by pmstacey

Marcel, I really appreciate all your work. I actually am on a work vacation now in Tampa Florida and will not be working on this again until late next week. It is a lot to absorb for someone with no programming experience, but I am more than willing to try it all.

First for me is to get the data coercion to work and, just as importantly, to make sure I can insert accession numbers if that field is blank and when that happens, to NOT do any data coercion to it. If I can get that to work, then I don't need to do a "send as" command and it will save me a tremendous amount of work and time to insert so many rules in the PACS.

I will work on this diligently late next week.

Again, I can't thank you enough

wow. I agree. I may wait on trying that.

oops never mind just saw rest of message

looks like fun. Will give it my best shot. What about adding accession numbers to a study where the dicom tag is empty?

you are the best. I will try to work with the non-split one and put a real load on it and then do the same with the split and monitor closely. If the results are close, I will use the non split.

If I can get the data coercion AND the insertion of accession numbers (where dicom tag 0008,0050 is empty), then I don't need the "org" option.

I have been preparing a spreadsheet with all the data coercion rules I will need as if I can't do it in Conquest (and at this time I have no idea since I don't know anything about scripting) I will need to do in the PACS. If that would helpful, once I complete and check it to make I am not missing anything, I can upload if this system takes Excel files. BUT, if I have to it in PACS, then I will have to be able to a "send as".

If I have ONE example of how to add a prefix to an MRN and a suffix to an accession number (only if the accession is included with the study. If it is blank, then I need Conquest to insert a random accession number at least 8 digits long and NO data coercion) and also how to have it insert accession number if needed, I can do the rest. I work best when I see how it works (example) as then I can understand it or have fewer questions at least.

understood about "send as". That, right now until I can figure out how to data coercion and also how to add accession numbers if none are there, is going to be needed.

I did them both. But, the second one I was very pleased with. 20 DR studies from originating PACS to RSA PACS in under 2 minutes.

My next step is to use both and put under a much larger load (include CT, MR, MG, etc., more sites sending, and higher study number) and see how it performs, but I am very encouraged right now.

I did the config as you said and it did work, after I made a few mistakes that is!. I will continue testing but 20 DR went to Conquest mulit-threading and sent out the same at the study level.

Question, I tried adding the "org %u" command at the end of the lines and it locked up Conquest and killed the server. Is it still possible to use the "send as received AET" option or do I have it wrong or in wrong place?

I have downloaded it. I will start testing and let you know. Many thanks again

sounds good. Let me know and I will install and test

I forgot, I am using 1.4.9 version

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

it is like it never sees the ForwardAssociationLevel = STUDY at all. It does as described whether the forward level command is there or not.

understood. what it does is the second one:

open association, send 1 image, close association

open association, send 1 image, close association

It is NOT open association, send images 1 by 1 until study is done, close association.

It creates an association for each image, sends it, then closes association and starts all over again until study complete

What I see is:

1. In Conquest, I see each image coming in from sender (this case, CT). As the image comes in, an association is created to RSA PACS, a channel is opened (I see the "channel=x") and the image is sent

2. In RSA PACS, I see the study incoming image by image. I see it in the live monitor and I see it on the study itself, image by image the count increases. And that is the issue, just as you stated, it does each image as it comes in. I can't have 800 studies incoming being broken down image by image on the send. We are talking large CT studies, MRI, Mammo, US, etc. It breaks down each of those studies at the image level and sends at once and that ends up having thousands of images coming into PACS at once. Bogs it down terribly and remember, the PACS is sending all these studies out to at least 3 different destinations at once and it waits for entire study to be received and then sends to the destinations at the study level WITH multi-threading so I can have several studies going to several destinations all at the same time using JPEG LS compression.

If I use ExportConverters and tell it to use study level and delay, it sends the entire study at once, not image by image. On ImportConverters, it creates an association image by image. If I send a lot of studies, I see multi-threading and I see image by image. It does not hold the study until the entire study is received and then send the study complete with Import, it sends each image as it is received. I need it to wait until the entire study is received and then send on the study level. Using Export and telling it to both delay and send at study level, it waits until the entire study has completed, waits the 30 second delay, and then sends the entire study at once. The issue there is it will only do one study at a time. I need it to send multiple studies at the same time (multi-threading). That it can't do. And, with 800 studies a day coming in, doing 1 at a time is way to slow.

If ImportConverters can't do study level, then I can't use Conquest. ExportConverters will only do 1 at a time (too slow going out when you have over 800 studies a day) and ImportConverters multi-threading is what I need, but I can't let it go by image level as that much data, again at 800 studies a day (CT, MR, MG, US, DR, DX, NM) slows process and clogs up my system.

Until ImportConverters can do "study" level or ExportConverters can do multi-threading, I won't be able to use Conquest.

Again, do appreciate everything and I love Conquest, but those limitations prevent me from using it.

I went back and changed it to "forward STUDY to RSAPACS" and it went at study level. That is with Export. With Import, if use the word STUDY in the ImportConverter

(ImportConverter0 = forward STUDY to RSAPACS channel *) then Conquest locks and I have to restart

Ok, I have to be doing something wrong. Now, even with delay, it is doing it image by image. I am going to keep trying until I can see why this is happening.

Does it matter where in the dicom.ini the ForwardAssociationLevel = STUDY command is maybe? Right now, it is before the Import and Export commands

I watch the RSA PACS and Conquest. I see image by image storing and also in Conquest, doing both ways, I see it store and send image immediately. If I use the delay command, then it does it at study level

Marcel, here is what I have now:

ForwardAssociationLevel = STUDY

ImportConverter0 = forward to RSAPACS channel *

still forwarding at the image level.

I did as you said:

ForwardAssociationLevel = STUDY

ExportConverters = 1

ExportConverter0 = forward to RSAPACS

No delay, but forwarding at image level still

Ok, will that also work with ImportConverters? I will try it.