Monday, December 25, 2006
My wife has become quite addicted to "The OC", and I have to admit I enjoy it as well. So, for her big gift this year, I was able to get hold of some screen-used props from the show itself. I'm hearing rumours that the fourth season of "The OC" will be the last; hopefully this isn't the case. (Although the show just hasn't been the same without Marissa!)
While it's a little late for Hanukkah greetings, it is Christmas Day, and I do want to wish everyone the happiest of holiday seasons. May your PACS systems run well, and your ER's be quiet. Ho Ho Ho!
Sunday, December 17, 2006
3mensio---is not a women's problem
Amicas---is not a Chinese manual calculator
Barco---has nothing to do with dogs
Bracco---is not the sound of retching
BRIT Systems---is not British
Cardinal Health---has nothing to do with the Vatican
Cedara---does not refer to pleasant-smelling trees
CHILI GmbH---has nothing to do with spicy food
Dell---is not where the farmer lives
Eclipsys---does not blot out the sun
Emageon---is not imaginary
Empiric---does not relate to Ceasar
Fluke Biomedical---does not deal with parasites
GE---is not an exclamation of delight
Intelerad---is not the opposite of stupid rad
Hologic---is not how streetwalkers reason
Kaiser Permanente---is not the king for life
Mayo Clinic---does not diagnose Hellman's
Novarad---does not deal with lox
PACSGEAR--is not a wheel with teeth inside your PACS
Picker---is not a little boy with a dirty finger
Proscan---is not a place for golf experts
RamSoft---is not a male problem
Siemens---has nothing to do with boats
Shimadzu---does not deserve "Gesundheit" in response
SoftMed Systems---see RamSoft
Stentor---is not one of those heart artery things
Stryker---does not require scabs
Sun Microsystems---does not make miniture stars
Swearingen Software---is not found in courtrooms
Thinking Systems---still requires humans
VIDAR Systems---does not make anything for Geordi LaForge
Saturday, December 09, 2006
A few weeks ago, Agfa had determined that over a period of time, server resources accumulated to the point that one of the servers would freeze up. Since then, they had put a process in place to release system resources, which has greatly decreased the frequency in which the client failed.Unfortunately, in order for us to determine the root cause of the problem, Microsoft has requested that we gather a "Crash Dump" log file off the server. In order for us to get this file, we need to disable the process written by Agfa and wait for the system to degredate. This may cause the clients to begin crashing with more frequency, however, I want to inform you that this is in efforts to determine the real nature of the issue.
Friday, December 01, 2006
Four days at RSNA can go very quickly, although it's enough time to thoroughly wear you out. I had the honor (and I'm not being sarcastic) of rooming with Mike Cannavo, the One and Only PACSMan, since he couldn't find another room in Chicago. If you can imagine walking the Technical Exhibits with someone who spots every little advertising discrepancy and innuendo, well, that's what it's like strolling the GE Boulevard with Mike. Check out his (in)famous 2006 PACSMan Awards and keep in mind that I was along for the discovery of a few of the winners.
I actually tried to attend as many educational sessions as possible this RSNA, which didn't allow a lot of time on the show floor. I still managed to see and learn a few things... In no particular order:
- Cardiac CT is probably going to be as big for radiology as for cardiology; we just need to market it correctly and do it perfectly.
- To actually achieve that perfect cardiac CT takes a 64 slice CT (or beyond). Toshiba announced for the 7th time a 256 slice scanner, which may actually sell in a few years. GE is using some clever "step and shoot" techniques to lower the dose on its 64 slice unit, and GE promises to emphasize spatial resolution. Siemens offers the Somatom Definition which has two separate X-Ray sources. The Definition has the best temporal resolution in the business, but its price is about double that of the others (although no one knows how much Toshiba's opus will cost). I now have to convince the hospitals that the cost is justified. Wish me luck.
- I finally got to look briefly at McKesson's Horizon PACS. We never were allowed to consider McKesson because we had just dumped HBO as our HIS. I really didn't have enough time to do it justice, nor to do a proper write-up. Some of the big names from McKesson (many of them were from the original ALI team) gathered 'round the Dalai (who is already pretty round himself) for the demo. Again, I am humbled and honored by such attention! I have always heard good things about Horizon, and I found the stories to be well-founded. This is a very solid, usable program, which I would trade Impax 6 for in a minute. Horizon is a Smart-Client, but it is a Windows application, and does not utilize .NET. In my brief demo, I could see a lot of potential. Particular highlights include a nice streaming protocol that loads the images of a series based on which one your mouse is hovering over, and good hanging protocols. My one complaint is my usual whine: the system has a zillion configurations, and feature-fatigue could be imminent. How about keeping it simple?
- Rumour: A big Amicas client may bail and go with Fuji. Bad choice in my humble opinion.
- After sitting through umpteen educational sessions, I'm now worried about the last 100 cases I read before coming to RSNA.
- A meeting of radiology bloggers didn't go off quite as planned, but I did get to meet Steve Severance, formerly of the Baltimore VA, but now a consultant at http://www.ivirtuoso.com. We had a great talk about PACS, and having worked with the luminaries such as Eliot Siegel, his perspective is amazing.
- The first session I attended was about PACS workstation design, and I'll probably write a full post about that alone. Suffice it to say some of my ideas aren't that far off the wall.
- In the not-so-sexy but still interesing department, a Korean company that makes backlights for high-res monitors showed a prototype monitor that uses LED's for backlighting. This allows uniform lighting with easier calibration and much longer life. I hope to see a production version soon.
- GE's booth was larger than ever, easily covering several city blocks. Sadly, I didn't have time to see their "Future Theater" which supposedly showed what CT will be like in 10 years. No doubt GE will play a critical part.
- As if McCormick Place isn't large enough already, there is a new West Building under construction that will probably double the available floor space. Attendees will need to steal Agfa's Segways to get around.
- Amicas continues to progress nicely. A year ago, I had hoped to debut Version 6.0 (rather unfortunate title given the other Version 6.0 I deal with) at this RSNA. Well, it isn't ready yet, but the prototype gets better and better. I'm proud to say that it even incorporates a few of my suggestions, among a host of much better ideas. I truly think this system, written from scratch, will trump the other systems out there. It keeps the look and feel of the older product, while adding fantastic functionality, including some I can't talk about under NDA. I have two requests of Amicas on this topic: First, devote all possible resources to getting Version 6.0 out the door as soon as possible. Second, don't do an Impax and deploy it before it's ready. Trust your developers, and don't even think of running out of Red Bull! As for the near future, I got a chance to demo RadStream as integrated with LightBeam in prototype form. I was not a RadStream fan at first, since it seemed to mainly add an Amicas-like worklist to Centricity, which badly needs one. But, in its Amicas integration, it provides an incredible communcation system from tech to radiologist, and from radiologist to an "operator" who is in charge of getting reports out to referring docs. I just needed to see how it would work, and now that I have, I am a big fan. This is the most straight-forward approach out there, and it will work beautifully. Anyone want to be my operator? The communication package is rounded out by the VisionReach system that will allow automatic e-mailing, among other alerting, of properly equipped clinicians or their designates. I'd say Amicas is in for good times.
No doubt I've left something out, and I'd love to hear about your favorite booth or session. Next year in Chicago! (They might have the snow shoveled out by then!)
Oh, and by the way, I had to take call the day after I returned from RSNA. My Impax 6.0 station crashed about every 30 minutes throughout the evening. I wish I could report more progress from Agfa. Maybe next year.....
In case you wanted the lyrics to the Prosty song, I have provided them for you below. Enjoy!
Prosty the Spokesgland
Is a prostate gland, we're told
Buried deep inside largely out of sight
He's ignored by young and old
Prosty the Spokesgland
How we hope that lump's benign
But it's hard to say
Cause the only way
To diagnose and treat is blind
There might just be some cancer
In that lump they found today
But we really can't be sure right now
Cause you can't trust the PSA
Prosty the Spokesgland
Spreads the word on what we need
No more pokes and prods
No more biopsies
How about some imaging?
Prosty the Spokesgland
It's time that we all gave a damn
Cause we know he needs New technologies
Like a hi-tech Man-ogram
Lumpety lump lumpLumpety lump lump
Look at Prosty grow
Lumpety lump lumpLumpety lump lump
No more bending over so
Wednesday, November 22, 2006
While I am no fan of Fuji Synapse, it does have a very significant presence in the marketplace, but as yet, it has no RIS of its own. Well, that's about to change, at least for sites with lesser demand, such as imaging centers and the like (those that remain standing after DRA-2005 takes effect, that is). Fuji will work with Empiric Systems to provide a combined RIS/PACS package targeted at the outpatient market. Just how tight the integration will be remains to be seen.
I use Empiric's leading Encompass.NET web-based RIS, and I am a big fan of this product. I hope no one takes offense, but I consider it the Amicas of RIS systems. Its interface is very clear and easy to use, even though it does have the power to do everything I need it to do. It may not be up to running a full hospital enterprise, but in reality, it really isn't far from having such capability. It has integrated quite well with our Amicas PACS.
When adding a significant chunk of programming to a big product, it is always hard to decide whether to write the functionality from scratch, or to simply acquire it from someone else. I do believe Fuji made a very wise choice by bringing in a best-of-breed RIS to do the job, rather than trying to reinvent the wheel. Maybe they will continue the trend of good decisions when it comes time to revamp their interface.....
Monday, November 20, 2006
One thing that we began working on even before we left the hospital was a solution for the "dictation race" that we saw occurring in your reading groups, where dictation was accidentally being completed by rads who did not notice that another user had already started dictating on a study. It was immediately evident that this situation was causing a lot of friction for the rads, and so we have identified this as an area where we want to help in the short term. With doctors B. and Dalai, I quickly sketched up an interrim solution for the problem. Both doctors described the need for a notification (Dr. Dalai demonstrated the notification on another vendor's system) that would clearly and unmistakeably identify when a displayed study was already being dictated by another user. I jotted down all of their suggestions, and have a proposal for their review:
As soon as the study is loaded into the Image Area display, a message box will pop up in front of the images: Title: WARNING! Message Text: Dictation is currently in progress for this study.
User options (buttons) available in this message box:
- "Remove from my worklist" - this is the default selection
- "View study anyway"
Friday, November 17, 2006
You cannot access the following Web address:
This site is blocked under the following categories: Pornography
Submit a site review request to your network administrator.
Temporarily bypass filtering on this computer if you have an authorized override name and password. (Note that your administrator may be notified that you've bypassed filtering.)
Use your browser's Back Button or enter a different Web address to continue.
Thursday, November 16, 2006
I think the poor guys were expecting something like Osama bin Dalai to greet them, not the adorable little fuzzball that they found here. I'm pretty benign in person, at least most of the time. Apparently, the team was given a send-off suitable for a departure to Baghdad. "Wear your Agfa condom, and thanks for taking one for the gang!" Nice to know that I'm so feared everywhere but my own backyard, where I'm either ignored, despised, or laughed at. When I asked why they thought I was such an SOB, my very own hospital's PACS administrator piped up, "It's because of your blog!!!" Thanks. I never would have guessed that. But, the visit was really productive nonetheless.
Impax 6.0 must have realized that it had more to lose if it made ME look bad than if it made its parents look bad, and like any petulant child, it misbehaved quite badly the moment the Agfa folks walked in the room. My workstation displayed the dreaded error and crashed three times within the first 5 minutes of their visit. I swear I didn't monkey with anything to cause that. Really. To ice the cake, the whole system went down for about 30 minutes later that afternoon, which I have heard was due to someone putting on a Microsoft patch without checking with Agfa first. Easily fixed. But this all set the tone for the visit. As of yet, we don't know why the workstations are crashing.
I have openly wondered just how Agfa tested this product, and if there were any real, live radiologists involved. I asked this question again, and again, the answer is yes, and in fact there were about 20 of them. I could not really drill down to whether or not these were Agfa users exclusively, but I rather think they were. That might explain to some degree why the viewer portion is a direct port of that from 5.2, which was a tweaked version from 4.5, which was a tweaked version from 4.1. The differentiation was made, however, between testing like they did, and in-the-field real-life observation, like they were doing with us. The former got them to where we are today, and the latter will get them to fix where we are today, and go forward to a bigger and better system. Well, a better system, anyway. This is probably the take-home lesson for Agfa, and really for ALL PACS companies. There needs to be a great deal more effort toward involving practicing, PACS-savvy radiologists at every step of development. Granted, they won't agree on everything, but they will ultimately hash out a workable path, and viewing in a production environment will yield multiple clues about functionality. And crashes.
I stated for our guests, the childish, yet profound Dalai philosophy of PACS: The image has to get into my brain via my eyes, and the interpreation has to get out of my brain and into the microphone via my mouth. That's it! Anything that distracts me from concentrating on the IMAGE is bad, although some interference is necessary, or we're back to film. (Gee, no buttons, no controls, just hold it up to the light...those were the good old days...) So why does Impax 6.0 have, in their words, "enough controls that you could never use all of them if you changed one every day for a year?" (Can you say, "feature fatigue"?) Ah, but this is a deliberate choice! It is easier, I was told, to simply add a multiple-choice option than to tell user A that this item functions this way because user B wanted it that way and not your way. This example was used: if user A wants it to come in black, and user B wants it to come in anything but black, you need to offer it in black and white at the very least. Multiply that by 200+ variables, each with 2-5 settings, and you have a very large number of permutations. Now, the Agfa folks say they found (and were surprised by the discovery) that radiologists have somewhat of the tinkering spirit, and that they all want these variables. My group must be a bunch of primitives, because we all really prefer the simplicity and limited control set of a certain competitor. I think there is a fundamental philosophical difference here. Agfa (and quite frankly Amicas too) is listening to the voices of the buyers on the showroom floor, who are totally enamoured with the 39,000 bells and whistles available on a product which they haven't actually tried in a production setting. Once you take the toy out of the box, you might find that the bells and whistles are so frustrating, it's more fun to play with the box. Feature fatigue, folks, it's a real phenomenon.
Let's deal with some of the issues on my doo-doo list, and see where we are. I am happy to report that a number of those issues were instantly solved by changes in user profile settings. In particular, the problem with the measurement tools disappearing if you click too rapidly turned out to be due to the activation of the 1:1 tool. It assumed that a rapid double-click meant that you want to enlarge a small image to fill the whole screen. Actually, I do like to do that on occasion, but I do NOT like having my ruler disappear in mid-measurement. So, we shut off the 1:1 thing, and my ruler works properly. Why this design was left in place, I don't know.
We actually could not reproduce the situation wherein the wrong prior is selected, so perhaps that was fixed by increasing the number of priors pre-fetched from near-line storage. Whatever. The series bar will be docked at the top of the screen with smaller images, I think. It will work better than it does now in that configuration. Refresh problems may be due to the individual workstation hardware.
The Search problems will be solved in a forthcoming update by making the Simple Search available with Advanced Search afterall. Why wasn't it there before? Well, somebody assumed that clinicians would be the only ones who would want to do simple searches, and that rads would want to do advanced searches, so they made it an either/or proposition. The Agfa folks were rather surprised to learn that the vast majority of my searches are simply by patient name. Just ask me, I'll tell you!
Hanging protocols became an interesting topic on many fronts. I pointed out that the new and improved hanging protocol setup was still impossible to use by the average rad, like me. There was considerable surprise that I would want to do my own hanging protocols. With a bit of frustration, I demonstrated how Amicas does it (I don't think I violated any NDA's....), which is basically drag the series to where you want them, and save this as a named hanging protocol. Wow, what a concept. As it turns out, one of my partners had a similar conversation, and the Agfa guys actually set up a protocol for him. But, once he logged out, and in again, it was gone, something we have seen with some of the other settings. No clue what's wrong here, although there was suspicion on some of the other items that the settings are not circulating between our three parallel production servers. Now, that's another interesting point, if I may digress. I was assured that the whole enterprise could run very nicely on one production server, with one more for testing, and one for fail-over. That's how Amicas does it. No one seems to be quite sure why we went with the belt, suspenders, and staple-gun approach to keeping our pants, I mean our PACS up.
Getting back to a study you have lost is a problem, especially if the machine crashed, because you lose some changes that were made before the crash, or if you use the master "exit" button for that matter. There is a list of the last several studies that you have marked as dictated, which you can access if you happen to know that right-clicking over a particular black spot at the bottom of the viewer will get you there. Rather like playing Doom. Hopefully, there will be some sort of indicator placed here for the unintuitive like me.
The Voxar re-re-re-deployment problem would be helped markedly if the cursor at least showed some indication that Voxar was selected, and I'm told that is an easy fix.
Clone windows and tool toggling are here to stay. The concept of any series in any viewport just didn't seem to impress anyone.
One of the biggest problems we are having is one I neglected to mention in my list, that of multiple people accessing one study. Amicas and even (gasp) Centricity solve this logically: If you touched it first, it's yours, and if someone else tries to get in, they can look, but they can't touch. Not so with Impax. I can be reading happily along with the dicatation status button clicked to "Dictation Started", which should knock the study off of my partners' lists, but it doesn't always, mainly due, I think, to the fact that the worklist hasn't refreshed yet. But instead of telling him to get out of my study, it tells me that he's in it and would I like to give it up? Totally backwards. Add to that, my partner could accidentally click the dicatation button again, and mark the study as dictated, when he just intended to start on it. Try as I might, I could not seem to get the concept across that this was really, really bad for us and needs to be changed ASAP. I finally just said, "I want you to do it like Amicas does it. Period." It seems, that some of Agfa's academic customers want the ability for a resident to start a dictation, and an attending to finish it, so they don't want to lock out this function. Well, I was just told that the easiest way to keep your customers happy is to give them all the options they want. Fine. I absolutely want to be able to lock down a study in the manner described above. Please make that happen. And by all means, give the academs what they want, too, but let me turn it off.
And so, I'm back to where I started. I really need to say that Impax 6.x is a monumental achievement, despite it's flaws. To port a huge program from C++ over to .NET and to make it web-deployable ain't easy. (I say that like I've done it 17 times last week....) The Agfa team should be very proud of what it has accomplished. Now, let's build on what we started this week. Impax 6 was developed somewhat in a vacuum, that is, there was not adequate influence from users of other products, and there was not adequate testing in a production environment. What we did this week should be absolutely mandatory for all new PACS products: have the programmers and such sit next to a radiologist while he uses the system, and get instant feedback for improvement. Do this with at least 100 rads, and not only will you iron out the bugs, but you will discover newer and better ways to do things. And you may find out that toggling of buttons, and text screens, and cloning of windows just isn't the best solution.
So, what do I say now to potential buyers? Frankly, I think you need to wait, although I am very confident that our crashes will be fixed, and that the repairs and upgrades outlined above will happen in a very timely manner. I will let you know as soon as this occurs. In the meantime, Happy Thanksgiving, eh?
Monday, November 13, 2006
Saturday, November 11, 2006
This morning, I received the following comment on my "Good, Bad, And Ugly" post:
I just want you to know that your problems are not isolated. I have been watching an Impax 6.0 rollout since last summer at another institution and have not exactly like what I have seen. To me (an IT/business person) Impax 6.0 is a shiny new wrapper on the old Agfa PACS. Yes there is a new front end and yes there is the ability to tie into the system using webservices, but I am not sure any of that matters. Many of the radiologists do not like and want the old version back. To me AGFA really needed to hit a homerun with this version. Anything short would not be enough. I just don't think that they did.
Wow. This is what I have been saying for a while now. Agfa ported the viewer pretty much in toto from Impax 5.2. Some of my partners are showing some nostalgia for 5.2, but in the end, I don't think Agfa changed a lot overall. Sadly, they brought forward most of the bad as well as the good.
My whining may have had some effect, although our hospital's chief PACS administrator really wielded the heavy club for us, and I am forever grateful for her efforts since she finally realized just how much trouble we are having. I don't know all that was said to Agfa, but I can guess, and as a result we will be visited by some of my good friends from Waterloo this coming week. (If nothing else, they will enjoy the weather down here.) I'm very glad they are coming, and what I hear of the composition of the group, they will actually have the power to do something about some of our problems. Personally, I hope they have the ability to do a near-complete rewrite of the system, because that may well be necessary. Sitting here, on call on an otherwise lovely Saturday morning, pounding away at Impax 6.0, it is pitifully obvious that Agfa did NOT test this program in any sort of high-production environment with rads that were familiar with other products. Agfa has told me differenly, but I just can't believe it based on what came out the other end. (And that is a deliberate allusion.) Here is a partial "doo doo" list (hey, this is a family blog!) that I hope to see addressed:
- Crashes, crashes, crashes. We have found one or two things that will trigger a crash, but for the most part they happen randomly. I thought CRL and .NET were so very much more stable than JAVA.....
- As often as not, the wrong study among a series of new and old studies will be selected for on-stage status. More often than not, the wrong comparison will be selected. I spent 10 minutes with a clinician poring over a mass that had apparently grown rapidly, only to find that Impax 6.0 had brought up a much older comparison. Egg on my face, and on Agfa.
- Series bar...a very poor implementation indeed. The series bar holds thumbnails for a study that has several different series, such as an MRI. The bar has inconsistent behaviour, usually pops up over what you want to see, gives unintuitive control over distributing the series, etc. This needs a big revamp.
- Things like rulers and elipses may not stay active long enough to actually use them. There is nothing so frustrating as placing the measurement cursor over a nodule, clicking, and having the whole ruler revert back to the window/level tool or something before the measurement is placed.
- TOGGLING....Please tell me who approved of the "toggle" concept, and I'll make them listen to my poetry until they beg for mercy. This, of all the Agfa approaches, is the one that makes me tear my hair out. It leads to lots of other problems, probably including number 4 above, as well as constant re-deployment of Voxar 3D in an otherwise excellent integration. By toggling, I mean that if you click a button, it is still active until you unclick it. This leads to a ton of problems, trust me, and Agfa is, to my knowledge, the only company doing this. It needs to be ditched, and brought back to the way everyone else does things, that being only one tool at a time. If I click window/level, my tool should stay that way until I click something else. Actually, the window/level tool may have been the impetus for the design in the first place: Click the tool, then click in the image, then manipulate the window without another click until you like what you have. But why not just do the click-and-hold thing that EVERYBODY else does? Yes, getting rid of this is a major rewrite, but you guys really should have thought of that before inflicting it on us.
- Window Toggling is another major problem. The color or outboard monitor shows a state-dependant display, geared to which exam is selected in the viewer. Even after several months, it is still disorienting, and it can lead to problems like those in number 2 above.
- If two studies or exams are displayed, tools will only work on the one in the leftmost monitor. Applying a tool such as window/level to a study or series may cause it to shift to another monitor.
- The screen is rather slow to refresh or repaint when moving to a new study or series. If reading from a worklist, and for some reason, you didn't read the first study, that first study flashes briefly on the screen before the next study in line loads.
- The "Search" function is a complete disaster. Either a simple search (which I have never seen) or an "Advanced Search" is available, but NOT both. Really shortsighted move, boys and girls. What do I search for about 95% of the time? A patient's name, and to get to that on the advanced search, I have to scroll half-way down a list of two dozen possibilities, then set up a search. This was probably the brainchild of a brilliant engineer, who had absolutely no idea of how we actually do things. It is incredibly powerful, but incredibly frustrating the vast majority of the time. Please just give us the simple search in addition to the advanced extravaganza, not instead of.
- There is no easy way to get back to a study you have bombed out of, say due to a crash, unless you happen to remember the patient's name. Even 5.2 had the old bookmark that held the name of the last viewed patient.
- The concept of clone windows as opposed to being able to drag any series to any viewport is a pain. How about doing what the other folks do?
- Hanging protocols are still unusable by the average doc. There has been an improvement in their set up, in that one no longer needs to understand machine language, but the new and improved drop-down interface is still going to be the domain of programmers. Sorry, we need something we can actually operate at the user level.
- Table position linking works fairly well, although I much prefer the Amicas method wherein you press one button and that's it. Sadly, Impax 6.0 has a very nasty tendancy to, ahem, toggle back and forth between one-on-one and multiple windows at just the wrong time, such as when I'm trying to link two windows. There seems to be some sort of a mouse click timer issue here. Please fix it! I've almost smashed my mouse five times in disgust over this one just this morning.
- Hot-key programming seems to be retained only intermittently. I'm wondering if there is a problem transferring the settings between our THREE application servers.
- "Sticky" window settings, column resizing, and the like, is not always, well, "sticky". Perhaps this relates to 14 above. Possibly related is the fact that sometimes window/level changes will apply to the whole series, and sometimes not, requiring the reactivation of the series-wide control. Why doesn't it just stay put!
- As noted in previous posts, we have been thrown for a loop by the fact that things that were supposed to be individualized are not in the production model. Having items such as window/level presets, precanned comments, etc. set up as global for a user-class, i.e., radiologists, has led our own PACS people to take the control away from us, leading to more problems. In particular, the button to add precans still exists, but because we can't use it, it bombs the program. Give me back my individuality!
- The measurement tool works differently than any other in the business, mainly because it places the measurement right in the middle of the line you have just drawn. Now there is a little handle to grab to move the number out of the way, but if you are measuring a small item, that handle is impossible to access, and the number is left to obscure the lesion. How about throwing that number off to the side? Even ScImage does that!
- And lest I forget, there is no workable spine-labelling tool.
This is only a partial list...my partners are helping me put together a much longer and more extensive tome. I have high hopes for the impending Agfa/Mitra visit. I just wish they had come by to see how an average group operates BEFORE they wrote Impax 6.0. But they didn't. So, we are in a jam. We have a system that is no better, and in many ways worse than the old one it replaces. The only real improvement is web-access, and that is indeed a step up from good old Web1000. Still, we are left with few choices. We can suffer through these problems, waiting for Agfa to fix them at their leisure, we can demand to revert back to Impax 5.2, or we can insist on a forklift replacement and go with another PACS. At this point, none of those are really acceptable. I can only hope that the Agfa/Mitra team is committed and empowered to fix this thing, although I'm not too optimistic given the fact that it took over three years of development to get it to this point! Still, if things are not going to be fixed in a very timely manner, option three starts to look better and better.
In the meantime, patience on the part of prospective buyers is still advised.
My friend quoted above sent the following comment about the above post:
Hi Dalai,I will take issue with your first point about .net/CLR stability. So Agfa picked a good infrastructure to use. But just because they did does not excuse them from writing good code, which in my estimation the code quality is probably poor. There are many rock solid .net applications out there. Impax just isn't one of them.You mention testing and I really agree. But it isn't just an Agfa problem. The development practices of PACS software run a gamut from good to bad, but most lean towards bad. I have observed issues that should have been caught in testing. If there is an extensive test plan in place and these issues are still being had then something needs to change internally.Let us know what happens.
Rather a harsh indictment of the programmers, but.... I certainly agree about the testing aspect. Note to vendors: Get a wide range of users to beta-test your latest and greatest. You might learn a great deal. Note to buyers: Do whatever you can to test your intended PACS product in a production environment. The more you live with it, the more you will come to know its good and bad points. Simple advice that no one follows until it's too late.
Monday, November 06, 2006
Saturday, November 04, 2006
The oncology clinic we cover makes a really big deal of Halloween, with the various departments competing over decorations and such. Since I was assigned over there on Halloween, I had to join in the fun. Notice the ears, Star Fleet insignia, and phaser. Add the scrubs, and you get Dr. Spock, right? No parenting advice, please!
Thursday, October 26, 2006
I want to differentiate between a glitch and a design problem. When my workstation crashes periodically due to an "application server error", that's a glitch. When Voxar 3D keeps launching and relaunching because the "Volume" button is pressed, that's a design error. More on those later.
The workstation crashes are intermittent today, although another (or maybe the same?) application server error brought the whole enterprise down for two hours a few nights ago. BIG glitch. I don't know if this is meant to fix that problem, but a hardware upgrade is planned for the weekend which will add "more processors" to the servers. Keep in mind, our enterprise required three complete application servers. Beyond the crashes, there is often a very perceptable (in other words, long) delay between clicking something like the "mark dictated" button, and the action occuring. Is this a network problem? A .NET problem? A Doctor Dalai problem? I don't know, but it is annoying, and can lead to multiple clicks which then can cause other problems, like prematurely marking a study as read.
Some problems lie somewhere between design errors and glitches. Bringing up a study that has a prior, or alternatively looking at a patient who has multiple studies can be an exercise in frustration. The Text pane on the left monitor shows the information for only one study at a time, and this is where one types in comments to the ER or whatever. You have to be very, very careful to ensure that the study that is selected in the Text is the one you wish to alter, because Impax does not seem to decide this in any logical fashion. The fetching of priors has, at least, improved considerably, but sometimes the study will open with an old exam presented on the primary monitor instead of the new one.
One major problem we are having is with the Series bar, which contains thumbnails of the sequences available, say for a multisequence MRI. Perhaps this problem would be solved with hanging protocols (which have not been made for us as yet), but we often find ourselves struggling to be certain that all sequences have been read. Amicas has a similar, but permanent bar (Agfa's can be closed), but somehow, it works better. Perhaps it is because Agfa's has all sorts of arrows and such, but just doesn't let you see all the thumbnails at once, even if you make them fairly tiny. This needs work. I'm still not too happy with the toggling, and the toggle-on/toggle-off nature of the Impax controls. This leads to the Voxar 3D problem. The integration of Voxar to Impax is almost perfect, and I have to say works much better than the integration of full Voxar to Amicas (which really isn't integrated at all.) The problem is that once the "volume" switch is toggled "on", every time you click over the image, Voxar is restarted. Who ever signed off on the doggone toggling mentality anyway?
I am hoping that all of the glitches and at least some of the design errors outlined in this and other posts will be addressed by RSNA. Until then....patience, young padawans, patience. In other words, wait a bit before you jump.
Tuesday, October 17, 2006
I have lots of friends throughout the PACS world (and a few enemies here and there, too). Because of one friendship established several vendors ago (for my friend, that is) I have the rare honor of introducing a new ad campaign for Dynamic Imaging. Rather catchy..."Don't Just Read, Read Well".... That is what we are supposed to be doing, right? (Forgive me, but being on a constant diet makes me substitute the word "eat" for "read", but that only enhances the attractiveness of the catch-phrase.) The ad goes on to ask what your patients might think if they could look inside your PACS. For some of the systems we GEt to use, that could be a real joke.
I've tried to get Amicas to create a campaign around my slogan, "It doesn't get in your way", but so far I haven't seen any ad copy, nor have I received any checks in the mail. Perhaps I forgot to send in my address.....
If you click on the ad above, you will see an enlarged version. The PACS station on display is NOT running DI's Integrad Web software, but there is a sort of "generic PACS" using color bars on its worklist. Hmmmmmm. Does that remind you of anything? To my knowledge, there is only one system out there that uses color bars for its worklist, and we all know who that is. I did ask about this, and I was told that there are indeed others out there that do so, like RamSoft, so this was indeed meant to be "generic":
Look, Ma, no colors! I can't come up with anyone else doing color worklists at the moment.
Upon very close perusal, the ad shows the PACS station to be shot full of holes. The gist of the ad is that if your patients were well-enough versed in the PACS field, and could see your system, they would realize as you should realize that your system is full of holes, and should be replaced by DI's Integrad Web. This is a little darker version of the 1989 introductory Infinity ads where you could see babbling brooks and streams, but not the doggone car! Personally, I'd like to see the Integrad Web in action.
Sigh. PACS is a dog-eat-dog world.
Wednesday, October 11, 2006
I think I'm going to name my next dog Impax, or maybe Mitra, and create a website just for the dog. How about www.HereImpax.com?
Saturday, October 07, 2006
Let's start with the Bad, some problems with functionality, then move on to the Good, and close with the Ugly, the problems with the actual upgrade.
The Bad isn't much worse than I have already reported, but there were a few unsuspected little problems. First and foremost is the fact that worklists and window/level settings are class-wide, and not individual. By that I mean that all users of any class, say, radiologists, have to share worklists and window presets, and probably some other stuff I haven't discovered yet. The worklists are indeed highly customizable, but now, I have to depend on our PACS people to create them, instead of just doing so myself. And if I don't like one of the window/level presets, that's too bad. Minor problems, true, but still annoyances for a tinkerer like yours truly. In fact, there is a troubling lack of individualization at several points. The Configuration screen, pictured below, gives its user access to EVERY machine in the enterprise. You can see the list of machines on the left. Because of this wide open access, our IT/PACS people won't let lil' ol' me into this area anymore.
Why do I need to be in there? Two reasons. First, Impax 6.0 is a RAM-hog, or it will be if you don't change its default settings. It will sequester the majority of RAM available on your computer. That's OK if you aren't doing anything but running Impax 6.0, but at home, I need to run Amicas as well, for the other hospital system, and I need to have some memory, or I'll have to just shut off one program when I activate the other. There is a control within the Configuration screen that lets one adjust how much RAM is available for other (obviously unimportant) programs. Monitor configuration is a little problematic, too, and it is also controled from the Configuration screen. To make a long story short, 6.0 just doesn't work right with a four-Barco monitor setup. We tried it, and it sucks. Impax 6.0 is very, very dependent upon the text/list screen. However, monitor setup requires that you tell the program which screen gets the text, where the images are to start, and whether you want the images on one, two, or four monitors. Note that three wasn't included. Attempting to use all four Barco's for images resulted in tons of toggling between text and images for the first monitor, and also yielded some very strange glitches such as duplication of the study on monitor 1 over to monitor 3, and blanking of monitor 2. It just doesn't work. So, Dr. Dalai, in a rare blast of intuition, suggested making these four-bangers act like three-bangers, in other words, use the first monitor for text, the middle two for images, and shut off the fourth. I had to beg our IT folks to do this, but they did with the express understanding that it was my idea, and my fault, and that I made them do it. Well, it worked quite well, and my partners prefer it for the time being. We eagerly anticipate the arrival of a fifth monitor and bracket thereof for the four-bangers, which will again allow images on all four Barcos. (For some reason, it took over a month to decide what bracket to use, and they still haven't been ordered...seems we need to go through all the proper channels to cut a P.O.)
Other problems include the lack of migration of older reports to the system (it's now brokerless, so I guess the reports have to go to the Mitra context server?), lack of retrieval of the proper prior (e.g., old hand radiograph is displayed to match new chest radiograph), and a rather annoying but transient flash of the "Available Series" bar into the middle of the screen when changing studies. Also, the "cine viewer" control keeps popping up inappropriately. Unlike the Amicas RealTime Worklist, which updates instantly, the Impax 6.0 worklists update only periodically. Ours is set to go every 5 minutes, but I'm convinced it doesn't cycle anywhere near that often.
Now, some good news. Without citing numerous specifics, I have to tell you that Impax 6.0 really does work, and once some of the glitches are fixed, it will work better than Impax 5.2. The toggling of windows is still disorienting, but I'll get used to it.
And now, the ugly. A major upgrade such as this is never trouble-free, and ours was definately no exception. The procedure was done over a weekend to lessen the, um, impact, although our weekends are about as busy as weekdays. The weekend crew operated from a temporary server which could not be user-customized, and only had 2 weeks of priors. Still, the weekend went OK without major problems. Now, Monday was a different story. I was off for a religious holiday, so I didn't have to participate in the fun, but I sure heard about it. To make a long story short, the whole thing slowed to a crawl, and there were well over 100 exams that couldn't be read. This included at least one positive scan that could not be viewed for over six hours. The culprit was, of all things, a virus scanner on a server. This was removed around midnight, and two additional processors were placed in the Oracle server, and things improved. But on Tuesday, we had more problems that shut everything down. It seems that there was a problem on the database side where a database cleaner didn't activate, but Agfa fixed this and says it won't happen again. Then we had a problem with the IIS (Internet Information Service) on one of our three servers (yes, it took three application servers to make Impax 6.0 run on our fairly large enterprise.) The service sometimes didn't work at first, but would do better if bounced. Agfa thinks they have this one fixed, but they are watching it anyway.
OK, we got through all this, and everything is running well at this point. But, to have 100 studies stuck in ethernet purgatory is to us a disaster. The positive study that languished for six hours is quite literally a disaster. We failed in our mission to provide patient care, and we could have caused harm to the patient. And there may have been more cases like this. This is where sometimes IT just doesn't grasp the mission-criticality of what we do. When I used the word "disaster" to describe Monday's events, I got this response from the IT heirarchy (italics are mine):
Actually, the performance issues have been taken care of and I feel"disaster" is a pretty strong statement. I would call it more of an unexpected set back. Impax 6.0 is functioning extremely well and we are moving forward with the upgrade as planned. If you are receiving feedback today that is not as we have experienced it, please do let us know. Any system upgrade of this magnitude is expected to have some issues,we are just working our way through them. We appreciate all the support and cooperation from the Radiologists staff as we have been working hard to make this a reality for them and (the enterprise).
This came in on Tuesday, just before the other problems became apparent. Now, I do want to congratulate and thank our PACS people, and the Agfa folks, too. They all worked very, very hard to get this upgrade accomplished, and they didn't stop until it was complete. Agfa folks are still around to make sure we are comfortable, as some of my illustrious partners never bothered to go for training, and then they expected to be brought instantly up to speed. But the whole "unexpected setback" thing troubles me greatly. As I have said many times, once a department goes filmless (and paperless, for that matter), the PACS is the department. It dictates what you do, how you do it, and when you do it. If PACS croaks, the entire radiology department is dead, and the hospital has lost critical functionality. Sorry, when we lose PACS as we did Monday night, that's a disaster. Plain and simple.
I posted a poll a while back to see who owns PACS at various places. The results were:
I have to think that the majority position is the ideal in this venue. Radiology obviously understands its own workflow, and brings incredibly valuable knowledge to the table. IT, of course, brings tremendous expertise to the picture, because PACS at its essence is a network of computers. IT folks get to play with the shiny new computers with the blinkey lights, and you would think they would be anxious to move ahead as rapidly as possible. But somehow, IT often gets really bogged down in bureaucracy. This may have its rewards, as a disproportionate number of CIO's seem to make it to CEO level. I get the distinct feeling that the IT folks want to protect their computers and networks from us, the Great Unwashed. And, as above, there can be a significant disconnect when it comes to our mission-criticality. A computer is just a computer after all, and if it croaks, you simply replace it. Would that we could do that with patients. (Maybe some could be replaced before they croak? Just kidding!) The bottom line here is that a partnership between Radiology and IT is ideal if not critical for PACS to function properly. Yes, PACS is just a mess of computers and wires and such, but my patients' health (and my livelihood) is at stake if things don't work right (or at all). Everyone needs to be on board.
Sigh. Now that I'm in the PACS business myself, I can see how easy it is NOT to be all things to all people. But as the boss, I get to make sure things work the way I want them to work, and that's a good start. Impax 6.0 won't ever work exactly as I would have specified, but it will do the job. Stay tuned for more reports as we progress with the great experiment.
Friday, October 06, 2006
Images courtesy of www.christies.com
Sale Title: 40 Years of Star Trek: The Collection
Location: New York, Rockefeller Plaza
Sale Date: Oct 05, 2006 - Oct 07, 2006
Lot Number: 493
Sale Number: 1778
Lot Title: DEEP SPACE NINE MODEL
Estimate: 8,000 - 12,000 U.S. dollars
Lot Description: A principal visual effects model of space station Deep Space Nine, the highly-detailed fiber-reinforced cast resin construction on a steel armature with internal fiber optic illumination [untested], with ceiling mount bracket -- 72in. diameter -- featured in every episode of Star Trek: Deep Space Nine
Lot Notes: The "hero" Deep Space Nine station model was designed by Rick Sternbach under the supervision of Herman Zimmerman. The design reflects a strongly alien architectural style, while maintaing a simple, yet distinctive overall form. This model was built by master model-maker Tony Meininger and was seen in every episode of the series.
To celebrate the 40th anniversary of Star Trek, CBS and Paramount have emptied out their warehouses of anything and everything that ever had anything to do with Star Trek. Being a loyal Trekkie, I registered with Christies.com, which required producing all sorts of information including my bank account number and a contact at said bank (no kidding!) I actually did put down a few bids on some small items, and I was blown away in the first 3 seconds of bidding.
I guess it's a good thing overall. Those of us nerdy little guys (and girls) who grew up with Star Trek have apparently become rather successful in our adult lives. Picard's Captain's chair from the Enterprise E went for $68,000, and the six-foot long model of Deep Space 9 went for an incredible $110,000! As of this writing, they haven't even gotten around to selling the model Enterprise itself...I wouldn't be surprised if it hits $250,000 or even $300,000.
I won't editorialize about the wisdom of spending these amounts of money on dusty old movie and TV props. I certainly can't do it (even if I had that kind of cash laying around, Mrs. Dalai would have my hide if I thought of spending it in that manner), but I guess I envy those who can. Perhaps the bidding frenzy represents a desire to be a part of something bigger and better than what we have now, and what could fit that definition better than a piece of the Star Trek universe? Of course, if I had hundreds of thousands of dollars to spend of this sort of thing, my universe would be a lot better, too!
I guess the only thing left to say is: Live Long and Prosper! (CBS certainly will!)
Here are some of the final results:
Partially destroyed Enterprise from Star Trek III: $40,000
Enterprise C: $40,000
Regula 1 Starbase from Star Trek II: $42,000
Space Dock from various movies: $65,000
Enterprise E: $110,000
Enterprise B/Lakota: $132,000
McCoy's Space Suit from "The Tholian Web": $144,000
Enterprise A: $284,000
Klingon Bird of Prey from Star Trek III: $307,000
Enterprise D: $576,000
Image courtesy of www.christies.com
Total take for CBS/Paramount: $7,107,040, including commission, far more than double what had been expected.
What else can I say? I canna' take it anymore, Capn'!
Friday, September 22, 2006
I’m not the only one who has noticed some gaps or glitches in Impax 5.2 and even 6.0. One Agfa user mentions these problems (rewritten for clarity) on APUG (the Agfa user’s group) with reading MRI under 5.2:
1. Triangulation - the localization tool in Impax 5.2 doesn’t work as well as some of the more simply designed tools in eFilm or Amicas. With the latter two, you just click on a point, and all other windows lock on to the same level. With Impax, the corresponding tool does work, but not on images that are linked by position to other windows. Good, but not quite there. As with lots of other tools, you have to click it again (actually twice) to turn it off. The soon-to-be-famous Agfa toggle.
2. Speaking of linked sequences, it is possible to link a bunch of sequences together. We even have a wizard button that will sync all the planes of an MRI together. Unfortunately they all scroll at the same time, and you can’t just click one button and link everything together. Amicas links the planes individually and intuitively, as do others, and with one button.
3. There is no easy way to display location of a slice on every other orthogonal plane, and have it update as you scroll through slices, without a "scout" window, nor is there a way to show the first and last image on other planes. The scout scroll tool in Impax is by contrast extremely cumbersome and finicky. Amicas and others do this with a single button.
4. Measurement tools - dragging across an object, clicking to get a measurement, then moving the number aside to measure the perpendicular dimension (to avoid the numbers overlapping right in the middle of the lesion being measured) is simply too many steps for what should be a much simpler process.
5. Too many functions in 5.2 require several mouse clicks, which is frustrating for many rads who are used to the functionality of tools which require a single mouse click.
6.What passes for a spine-labeling tool and hanging protocols are essentially impossible to use in 5.2.
The list ended with this: “One wonders how much end user (i.e. radiologist) input was sought at the time of development.” Someone else comments, “Perhaps enough voices will together prompt the necessary improvements in functionality. It is apparent that no working radiologists were involved in the development of the initial product.” Now, I was told that there were 12 radiologists on the Agfa advisory panel that approved Impax 6.0, and yes, they had experience with other systems. Still, given that Impax 6.0 does things in very similar fashion to Impax 5.2, I have to wonder a little bit about that. The majority of these difficulties persist into 6.0, which has a viewing component that is very similar under the hood to what we have with 5.2. Keep in mind for CT triangulation and whatnot that the "simple MPR" tool has been removed, but it may be replaced at your option with Voxar 3D.
The good news is that at least some of these things are to be fixed by RSNA 2006, or so we hear. That would be nice.
A friend of mine on the other coast has been having a world of trouble with his 6.x installation and migration from another vendor. “The doctors’ workstations crash all the time, AGFA applies a patch and says this will fix it and in a couple of days the stations are crashing again. The rads say AGFA sucks! Even so, they do all agree that we are in a better place than we were with the old vendor.”
Obviously, Agfa needs to work on a few things.
I am probably a bigger fan of Agfa's than they are of mine. I do believe I got several of their execs rather upset with some of my blog posts on Impax 6.0, but I'll stand by most of what I posted, and I corrected the areas that were inaccurate.
Agfa's big push with Impax 6.0 was the migration to the .NET architecture, a laudable goal. The "front end" to the interface was completely revamped from Impax 4.x-5.x. The new interface is very different overall, for those of you who have not sampled it. There is a great deal of "toggling" between screens of information. I liken it to a control panel on the Enterprise (the starship, that is) where a wave of the hand would load in a different set of options. Having used Impax 6.0 as a web-appendage for call purposes over the last several months, I still find this quite disorienting. I like having a worklist constantly visible on the third (or fourth or fifth) monitor. (As an aside, we are having to add a fifth monitor to our four high-res monitor stations to accommodate the eventual migration to Impax 6.0 from 5.2.)
While the main interface was revamped, the Impax 6.0 viewing component is really a re-skinned port of the viewer from Impax 5.2 with all its good and bad points. The main deficiency I find (beyond the lack of usable tools as others have outlined) is the persistence of the clone-window concept. With other systems (and Amicas I think does this quite well), one can drag any sequence to any viewport or window. I like to view my CT's with multiple window settings, for example. Now this can be done, and I even have a wizard to do it, but it requires spawning a clone window to do so. I want to be able to do this within the main viewer itself. I could go on, but you get the idea.
As I mentioned above, Agfa told us last RSNA that "12 radiologists" were on their panel for approval of Impax 6.0, and they ultimately agreed on the final release. I suggested at the time that these radiologists must have been exclusive Agfa users, because of the stasis of the viewer; I was told that was not the case. Having sat on advisory boards of other vendors, I can attest to the difficulty in getting more than two radiologists to agree on anything, so I can see how things might have gone in the Agfa meetings. Still, now is the time to fix and revamp Impax 6.0, before it gets entrenched as it stands. We can only hope that Agfa can fix some of these problems by RSNA, or I’m going to be “toggled” to death.
Tuesday, September 19, 2006
I'm sure there are those out there that view me as somewhat of a terror, if I've even reached their threshold of attention. Well, maybe I'm more of a terrier than a terror...I sink my teeth into an issue and then I just won't let go. As I love my Jack Russell Terrier dearly, that's a compliment. Much more to come!
Thursday, September 14, 2006
First off, the Wikipedia informs us that "Voice Recognition" is the task of recognizing people from their voices, and this might be done electronically for identification purposes, among other tasks. What we are really interested in is Speech Recognition which the Wiki says "is the process of converting a speech signal to a set of words, by means of an algorithm implemented as a computer program." Now, this has been one of several Holy Grails for computer science since the dawn of time.
SR should be great for radiology, given that our main product is the typed report that is based on our talking into a microphone all day long. The old timey approach was to have a human listen to all that blather and type a report into a typewriter (remember those?), or into some computer or another. Now, if I can get said computer to actually understand what I'm saying, we eliminate the middleman, or woman, i.e., the transcriptionist. But is the technology there yet? In 1968, the movie 2001: A Space Odyssey told us that we should have had conversant, artificially-intelligent HAL 9000's, as well as commercial space flight, a Hilton hotel on a space station, a moon base, and exploration of Jupiter as of 5 years ago. Oh well. We don't even have Pan Am anymore. But, we do have VR, I mean SR, right? Here's a citation from a Journal of Digital Imaging article out of Mass General by Mehta and Dreyer, et. al.:
Great article, and it was written in 1998! The italics are mine, by the way. So here we are, eight years later; why isn't everyone using VR/SR?
Voice recognition--an emerging necessity within radiology: experiences of the Massachusetts General Hospital.
Department of Radiology, Massachusetts General Hospital, Harvard Medical School, Boston, USA.
Voice recognition represents a technology that is finally ready for prime time use. As radiology services continue to acquire a larger percentage of the shrinking health-care dollar, decreasing operating costs and improved services will become a necessity. The benefits of voice recognition implementation are significant, as are the challenges. This report will discuss the technology, experiences of major health-care institution with implementation, and potential benefits for the radiology practice.
The problem seems to be that the technology really isn't there yet. Matrad6781 posted this on an AuntMinnie.com forum, and it tells the story in a painfully accurate manner:
My problem with our voice recognition system is that commands that used to be triggered by the thumb on a microphone are now voice commands. Often the software doesn't recognize my voice and I end up having to repeat myself several times. That never happened in the "buggy whip" days. Throughout my department you can hear radiologists saying: "Defer report...defer report...DEFER REPORT, dammit!" or "delete that sentence, DELETE that sentence, delete that SENTENCE!" Also, when I say "parentheses" or "quote" or "paragraph", my transcriptionists know what I mean. This system actually types out the words "parentheses', "quote", "unquote", etcetera. How clever is this? Is this what is meant by artificial intelligence? I have alot of "canned" reports, both normals and intro paragraphs for MRI protocols, interventional procedures, etc. At last count, I had 150 such "normals." Before voice recognition, all I had to dictate was, "Normal MRI of the left knee" and the transcriptionists called it up from their macros and sent it for my electronic signature. Now I have to remember the name I gave the normal report (ProVox calls them "Macros") and enunciate it properly (so I don't get a "Normal chest" appearing when I said "Macro Normal CT Chest Enhanced". But it happens, all too frequently. And I have to always keep an eye on the voice dictation window, the way you would a toddler to make sure it's doing what it's supposed to and not getting into trouble. By the way, that window, even when minimized takes up valuable real estate from my PACS work station (and I have four monitors!) I'm always moving the window around because it's obscuring images or the worklist. Very inconvenient. The worst is when the system thinks that I (or someone in the background) uttered a voice command that is one of the "nuclear option" commands, like "finalize report", "delete that paragraph", "cancel report." Then, poof, five minutes of dictation are gone, just like that, and I have to start from scratch. Are you guys telling me no one else has experienced any of these problems? Is it just our manufacturer? Lastly, the voice recognition is so bad, that everything ends up getting deferred by all the radiologists to the transcriptionists, so that they can correct the errors before sending to the task list for finalization. So we have as many transcriptionists as before. Last point: We have some great transcriptionists who catch errors that a voice recognition system would never recognize. I used to get electronic notes like "You said LEFT in body but RIGHT in impression." Or: " You gave a measurement of 3.5 mm in the body, are you sure you meant "mm" and not not "cm"?" These folks have saved my butt many times. I'm kind of glad that the voice recognition dictations still go through them as a fail safe mechanism. Also, one of our transcriptionists makes really good carrot cake! Let's see a VR system do that!
The bottom line is that these very expensive systems (think hundreds of thousands of dollars) do not have human intelligence behind them. No, I'm not saying bad things about the programmers! It's simply that there is a very rich background to our communications, and no machine has risen to the level of understanding, or perhaps I should say intuiting, what we put into it. The left/right and cm/mm problems are good examples. I suppose you could program the machine to count how many times you say "left" and how many times you say "right", but then what? Should there be an equal number? Not necessarily. So what is a poor machine to do? The human transcriptionist can easily find the discrepancies of this sort, but a machine just can't do that yet.
What are the advantages of SR that make it worth the kind of trouble Matrad describes? I can think of only two: time and money. If all works well, the SR system can have a report available online the instant you sign off. That's a good thing. Which can be equalled or even surpassed by having an adequate pool of human transcriptionists on-line and ready to do their thing. But speed doesn't seem to be the main impetus in many places. Sadly, what SR allows is the shifting of work onto the radiologist. The transcriptionist's job is really two-fold: she (or he) commits to the screen what the rad has dictated, and then she edits out the errors that may have occured. SR can do a passable job of typing (if one trains it to one's voice for a very long time), but it just can't do the editing. Since the radiologist is ultimately responsible for the report, some administrative types have decided that the rad should do the editing as well! Wonderful idea, if you are trying to rid yourself of transcriptionists. Unfortunately, this adds a lot of editing time to the rad's day that he or she should be spending reading studies. Another poster, Jack (Dr. Death) Kervorkian puts it in these terms:
(S)orry guys, in my book - time is money. If I have to spend 20% of my time correcting reports and looking for content, syntax, grammatical and/or spelling errors, that is 20% which I am not productive. Furthermore, it now makes me not a radiologist, but an editor of reports. Just think, in an 8-10 hour day that amounts to an extra 1-2 hours of agonizing editing. I'd rather have a second set of eyes and ears - which know my dictation style to look over me. Can't tell you how many times a transcriptionist has saved my ass from looking stupid, with the usual 'right/left" errors, or at the 12th hours calling a CT scan an MRI scan.. Although voice recognition will catch spelling errors, it won't catch content, grammatical or syntax errors, as mentioned above.
So everyone loses in this scenario, except for the bean-counters who justify the expense and the pain to the rads with the savings in personnel. Just great. Those who support SR call those of us with doubts "Luddites" and "buggy whip makers". AuntMinnie member Frank Hartwick suggests that we stick to the principles of the "OODA Loop" for decision making such as this to keep from being left behind. OK, what's an OODA loop, you ask...is it like a Fruit Loop? Not quite, and it really is germaine to this discussion. Click on the diagram below to blow it up...
The OODA loop (Observation, Orientation, Decision, Action) is simply a way to describe a decision-making cycle, designed by a retired fighter pilot, Col. John Boyd. Basically, it describes a dynamic process that one should go through to evaluate evidence and make choices, and how those choices are dependent on your background (even your "genetic heritage") and the information you get. The decision impacts your observations, changes your orientation toward the problem, and you remake your decision.
Got all that? So, I think Frank H's OODA loop tells him that SR gives good service and should be implemented. But MY OODA loop observation is that there are a lot of complaints about SR, and with my genetic heritage of worrying, and previous experiences of getting burned on buying some of the latest and greatest, lead me to the decision that SR isn't ready for me as yet, and thus the action of, well, inaction. I'm digging in my heels on this idea. I have told our administration that I and my group will not accept SR unless they promise us total human backup. In other words, if they want to spend $300,000 or so on a fancy microphone for me, that's just fine. As long as they realize that we rads refuse to become editors, they can go ahead and spend the cash. But don't wave the expenditure in my face when it comes time to replace some of the worn-out scanners that really need to go.
Am I really being a "Luddite" on this? I think not. My job is to interpret my studies, not edit the reports. No one has yet convinced me that SR technology has reached the point of really being ready for prime-time. And I don't make buggy whips...to really stretch the analogy, one could say we use buggy whips in our trade. SR could then be likened to an electric cattle prod, I suppose. But to carry this to its logical end, SR will eliminate the horse, and I'll be forced to use the cattle prod on myself! No thanks, guys. I'd rather walk.
I just had to add this from a post from William Fife on the AuntMinnie.com thread...
For those of you who love VR here is something one of our physicians did one day on call. I will note that this physician had been using VR exclusively for MONTHS (a few words have been deleted (deleted) to protect the guilty). This is not a joke, this is an actual VR transcription of that the physician was saying (in bold).
Indicating this using (deleted). (I am dictating this using (deleted).)
Mr. date of 01/02 help recent films time.(Yesterday I went to help read a few films on my own time.)
A family cells. In some (deleted). there for over and out or.( I found myself stuck in some (deleted) error for over an hour.)
The year cannot: 5 hours report was (The ER kept calling to find out where the report was.)
This did not seem to encourage may help my colleagues and the films. (This did nothing to encourage me to help out my colleagues and read films.)
Today came in early to try again had.(Today I came in early to try and get ahead.)
Instead I am now line. Out of on the nodule was noted least 15 times. (Instead I am now behind. I had to run the audiowizard 15 times.)
I had to call the past / (deleted) to support. (I had to call the PAC/(deleted) support staff)
12 joules was helpful and white, there was nothing ET tube from home. He has new trials were to things year defects at myself. (While Joe was helpful and polite, there was nothing he could do from home. He asked me to try all sorts of things here to fix it myself.)
Spent there are might time to ingest fat rather than reading films. The CT scanner post I am not expected fixed fat.Lysis any different. (I spent an hour of my time doing just that instead of reading films. When the CT scanner goes down I am not expected to try and fix it myself. Why is theis any different?)
The patient or best served 1 international unit films not tried fixed (deleted) problems were transcribed unknown reports for distended noxious females. (Patients are best served when I read films, not try to fix (deleted) problems or transcribe my own reports or send obnoxious e-mails.)
Kilohertz it is line, we need better on slight support. (When it works, it is fine. When it doesn't work, we need better on-site support.)
This was just posted to AuntMinnie.com by "breastguy", hopefully a mammographer, and I think it really seals the deal against SR:
I heard of one rad at a children's hospital in PA who was trying to get a lawsuit together against Dictaphone for their false claims about the product. Every so often our chief circulates examples of gibberish that was sent out and cautions us to look at what we are siging - but it still happens -- one major problem is there is no "undo" button or delay- once you hit sign report it is gone and as it disappears you see "clitoral history" fly by and there is no delay to catch it. The quality of the reports clearly suffers. And you cant say "known Carcinoma" it comes out "No carcinoma" -- I curse the Powerscribe apps people that spent days with us yet never called attention to possible pitfalls like this - they never pointed out the weaknesses- we had to stumble over them ourselves. Sure you can save the reports and review them later, or send every one to the editor (be sure to keep some transcriptionsits to edit) but I can tell you, in our large group , with editors, crap still gets sent out and ref docs gleefully call you up to say "Did you mean Clinical History instead of Clitoral History?" Certainly makes us look foolish. As far as it not understanding the instructions to call up a macro- it was driing me crazy! I solved that - instead of my saying "Mammo Heterogenous Normal Compared" I renamed it "Hubert Nancy Carol" Dense mammo is " Denise Nancy Carol" etc and so on for the many screening mammo macros I created- here it does save time.
I really think that's enough. Frankly, after looking into this, I'm inclined to say "NO SR" altogether. The machines seem to compound the possible errors, making the transcriptionist/editor's job that much harder. This is a really, really, REALLY bad idea.