We noticed in the Conquest logs multiple repeating entries similar to:

UPACS THREAD 0: ENDED AT: Thu Oct 19 09:23:58 2006
UPACS THREAD 0: TOTAL RUNNING TIME: 0 SECONDS

We also discovered that by turning off one specific ultrasound machine, the log messages would go away, and things would speed up. Now we are trying to figure out why/how this one GE Voluson is causing issues with Conquest.

This problem seemed to occur out of the blue. Things were working fine for the longest time. Also, we have Volusons at other clinics, and do not have this problem. My colleague suggested using a packet sniffer called Wireshark, and that has unlocked some more clues about this problem.

Those THREAD 0 log entries in Conquest are a result of the Voluson sending TCP Window Request packets to Conquest. Research has told me that the TCPWR packet is essentially used by the receiving system to acknowledge a specific amount of data has been received, and to send the next chunk.

Monitoring a normally functioning system illustrates this very well. When a modality sends data to PACS, PACS will reply with a bunch of TCPWR packets. Also, when PACS sends images to a review station, that review station will likewise reply with TCPWR packets. So this tells me something is wrong with the Voluson, since it is sending PACS the TCPWR packet, repeatedly, without receiving any data to prompt such a packet.

GE has been made aware of the problem and of the issue with TCPWR packets. Hopefully they can solve the problem in short order, although I expect it will not a straightforward process to figure out this particular issue.

Bookmark to:
         

This had started a while back at our busiest clinic. It was infrequent, so I did not look into it further. It then started happening at another clinic. In this second case, the problem seems linked in some way to a GE Voluson ultrasound unit. This GE device will constantly send “empty” requests to Conquest. When the GE united is powered off, these requests stop, and things speed up again. Because of this other aspect, I ruled out that these two problems were related.

Just recently, two other clinics have had the slowdown happen. That began getting me worried, it seemed like we had a growing problem. Worst of all, at the first two clinics, it was occurring much more frequently, going so far as happening each day for a short period.

As luck would have it, I was downloading a large file one afternoon, and noticed that the reply times to one of our clinics got terrible during this download. Sure enough, I got a call from said clinic that images were slow to arrive from the modalities. This at least narrowed down the problem some. It did not seem like a problem on the clinic side, but more to do with the fact that each clinic auto-forwards all images to a backup server at our central site. It would seem that something was happening because of these backup transfers that was causing adverse effects on Conquest.

Then yesterday, I decided to start turning off these auto forwards, to see if the problem goes away as a result. While doing this work, I noticed that our backup server had numerous stuck tasks revolving around data transfers. That gives me more to look into, and if turning off the forwarding fixes the problem, I will try to narrow it down to a performance issue on the backup server. I still wonder about the network causing some issues as well. We use a wireless provider, and it could be that as the day gets busy, traffic gets affected, and perhaps Conquest is not able to handle the delayed or lost packets.

Nothing is fixed yet, but at least I have some information that will let me work on isolating the issue. Nothing worse then people saying “its broken” but having no idea how to fix it!

Bookmark to:
         

I enabled debug logging in Conquest (a VERY handy troubleshooting feature). However, nothing was showing up when the Philips would try to send the 3D image. Nothing. Which struck me as very odd, usually some sort of message comes up indicating Conquest started communication. That led me nowhere.

Back on the Philips, I started going through configuration screens. Inside the PACS server setup screens, I found some 3D related check boxes, that were not enabled. Enabling these did not fix the problem. I then looked for the DICOM file type/compression settings.

The setting was for RGB, Uncompressed ILE. ILE stands for Implicit Little Endian. I also noticed a blurb saying all 3D are sent as RGB, Uncompressed ELE (Explicit Little Endian).

I got thinking, perhaps Conquest was having issues with ELE. To test, I changed the regular setting to ELE, and took a picture. Sure enough, it just sat in the queue and did not get to Conquest PACS. So now I knew the problem, but how to fix it? A quick search on Google provided no help. Sadly, Conquest help is extremely hard to find online (that is why you are here!).

Next I searched the Conquest documentation. I quickly found that Explicit Little Endian is an option in the DGATESOP.LST file, and it is disabled by default. I opened the file, removed the # prefixing the ELE line, saved, and restarted Conquest. Sure enough, images started arriving. Thus far, there have been no negative consequences from enabling that function.

I am by no means a PACS guru, I know what I know based on what I need to know to do the job. I am sure some of you understand the definitions and differences between ELE and ILE. Feel free to share in the comments! However, like all my posts, I hope this helps one other person in some way.

Bookmark to:
         

As we all get more and more busy, it is all too easy to forget about pending domain renewals. In many instances, the domain registrar for your domain will kindly email you a reminder to renew. However, what if the email address that the registrar has is out of date? Perhaps the original contact is no longer with your company, or, simply that the email address has changed. I find it essential to put domain expiry dates in my calendar, and to ensure a few other individuals at my company do the same.

How can you easily find out when your domain will expire? Try:
http://www.dnsstuff.com/tools/whois.ch?ip=google.com
Where you change google.com to your address.
This WHOIS search will show you what company you registered with, when your domain is up for renewal, as well as the contact information on file. Try to avoid having one person being the Admin and Tech contacts. Separating these to different staff helps guard against that one individual leaving and leaving your company without a contact.

Given the relatively small cost for domain renewals, especially compared to the impact of the domain going offline, it is recommended to renew the domain for the longest time period possible (currently 10 years). Furthermore, at the end of each year, try to remember to renew it yet again so that it remains valid for 10 years.

If you are unfortunate enough to have let the domain expire, what can you do? ICANN, the governing body of domains, has recommended a 30 day grace period, whereby participating registrars will allow you to easily renew your domain within the month it expires.
http://www.icann.org/bucharest/redemption-topic.htm
After this 30 day window (or right after expiry if your registrar is so inclined), the domain can be grabbed by anyone. You may be lucky enough to find it available, however, the trend these days if for someone to grab recently expired domains in the hope of making money. This can include hosting ads at your (former) website, as well as charging a fee to give the domain back to you.

Given the importance of keeping your domain properly renewed, it should be handled as any other business critical element. Multiple people should be made aware of the issue. The needed login and contact information for your registrar should be documented in a safe place. Periodic WHOIS checks of your domain are a wise idea, to ensure all information is correct and up to date. It only takes a few moments of your time to ensure you and your company have a trouble free domain experience.

Bookmark to:
         

Bookmark to: