Discussions with Agfa have yielded only the suggestion that we change our workflow, because it is the activation of the "dictation" button while images are incoming that leads to the crash. That is actually not an unreasonable suggestion, but it is only a small part of the solution. Having my client crash when I do a "no-no" is an even bigger "NO-NO" in the software world. An anonymous Canadian commenter on my last post said this:
And indeed this one turns out to be a known issue. It's time to give it priority, before it gets too cold up there in Waterloo.I hope Agfa is not implying that it is acceptable in any way to get this type of error message; you are offering a work around, not a solution. As an Impax user (and someone with a degree in Computer Science) I find it totally unacceptable that a live clinical product has this type of bug. Furthermore, Agfa makes little or no active effort to correct or prevent these types of bugs.
Frankly, I have given up on reporting bugs. The usual response from Agfa support is...after 1 week level 1 support says you are doing something wrong...after 1 month level 2 support says they will look into it, and have never seen this problem before...after several months level 3 support says 'Oh yes, that is a known issue, but it has not been given priority'.
Here are two quick and dirty coding fixes that would keep me from whining louder and losing sales for Agfa:
- Throw up a dialogue box when the error conditions occur saying something like, "There are new images being received for this study...please stand by."
- Grey-out the dictation button.
I prefer the first, personally.
Crashing the client is NOT an acceptable method of warning me about something. Fix this, please. Your customers are watching, and based on the comments I'm receiving, they aren't surprised by this. Is that a reputation you want to cultivate? I didn't think so.
3 comments :
Oh my.. while I appreciate, and actually anticipate, your posts, is anyone else getting sick and tired about hearing of the pitfalls of every vendor EXCEPT Amicas? Come on!! First of all, I agree with you as I am not a fan at all of GE, Agfa, Siemens, and many others. In addition, I am also an Amicas user!! However, my system crashes and my system has issues, just as does every system out there. I think, and this is just my honest opinion, that readers would better appreciate unbiased views as continuing to knock the others and failing to mention your own products shortcomings is a little silly. However, this is your Blog!!! (And I still love it.....)
Has anyone ever questioned the modality vendor(s)? Why don't they make it so they're machines can actually communicate properly with PACS. Why is it that most modalities(possibly all) will not even let a PACS know how many images it's sending across? That's probably why your system is crashing and most likely why you will never get the "grey out" on the dictation button. Because PACS is at the mercy of the modality and cannot control the information it does not have.
Oh my, there are SOOO many parameters that could be the root cause for this issue! Is this an enterprise site with remote image cache gateways? If so, can every gateway speak to each other? What is the study timeout value for these modalities in Administration Tools/Network Manager? If the WAN is a decent speed then 30sec be sufficent Slower links require longer timeouts.
It sounds like the PAC's group have provided Rad's with the "View Open Studies" permission. While I have not seen this to cause this problem it can cause many other problems.
My suggestions is to have PAC's turn this permission off--while it may delay viewing "a bit" it will prevent the need to re-log in from a crash. If this permission is changed make sure the modalities "study closed" values are set to reasonable value for the speed of the network; the default is 900sec which is WAY to long. Make sure the value is not set to short either... this can cause another set of problems (duplicating jobs in the job queue)
Post a Comment