Sign-Off Icons We'd Like To See...

Some new sign-off icons...
"Sign and go to next exam", "Sign and quit", "Unsign and return exam to unread status"

Kinda cute, huh? I'm just a frustrated graphic artist, I guess...

The Ideal GUI...It Doesn't Get In My Way

For me, the reading radiologist, the GUI, or the Graphic User Interface, IS the PACS system. I don't (usually, anyway) tap into the service areas or play with the RAID, or even shove a CR cassette into the reader. What I do, day in and day out, is sit at the workstation and interpret images. As a Nuclear Radiologist, and not an interventionalist, I spend about 80+% of my working time with the mouse in my right hand and the microphone in my left. If I'm not talking into the mike, I'm not making money for my group, right?

It is no secret that I do like the Amicas LightBeam system, and Agfa Impax 4.5 to a lesser extent, and I don't like GE Centricity or ScImage. I won't bore anyone with a feature-by-feature comparison, and I don't want to reveal anything proprietary anyway (although I would be bloody surprised if any major company out there doesn't know most of the details of the competition's products). So, what makes a good GUI? In my humble opinion, the key is to provide functionality without breaking my concentration on the image itself. In other words, the system needs to help me do my work without getting in my way.

There are a lot of little functions Amicas provides that really speed things along. Let me cite just one: the spine-labeling tool. I can label an entire MRI of the spine in less than 5 seconds. Amicas seems to have been one of the few companies to notice that three-dimensional localizing data is included in the DICOM header; they use this to propagate the label to all other planes after you have manually labeled the levels of one image of one projection. With Agfa, this simple procedure is painful and takes several minutes instead of seconds.

But I digress. To avoid getting anyone (more) upset with me, let's stick to generalities. The following description includes elements of systems I've worked with, demo'd, or read about, as well as some elements I've just made up all by myself. The guts beneath the system are left to those better versed in such things, but I think there is no turning back from the web-based or TCP/IP approach. It makes sense not to reinvent the wheel. The web was designed to move data back and forth seamlessly and safely. True, the old ARPANET could never have envisioned transmission of gigabit-size datasets, but today, this is routine.

The Dalai-PACS system has two main elements, the worklist and the viewer. Both have to be customizable to user sign-on. The worklist has to show important information, name, exam, priors, etc, have some alert mechanism for status, such as color-coding, and must of course let other users know if an exam is in use. Many vendors have something like this today, and Amicas has the best implementation in my humble opinion. The distribution of exams to individual sign-ons makes no sense today, even less-so distribution to designated workstations. That made sense back in 1997.

The viewer is what makes or breaks the thing. The Dalai-PACS viewer is intuitive, and as automated as possible without taking control away from the user. Automation basically is a step beyond most of today's implementations of hanging protocols, though some hanging protocols are getting pretty smart. I want my system to know what prior(s) I need pulled and how to display and link them to the viewer. Obviously, linkage of CT's must be done by table position. With today's technology, the user will still have to match the position manually. I have heard about an attempt to use surface mapping and contour matching to do this automatically. That would be most welcome. I should be able to link studies with a minimum of effort; select matching slices and click a button. I have this with Amicas today, with instant, one (maximum two) click synchronization even if I have 3 different windows of the same exam, or three different sequences for that matter. With Centricity, just linking a dual-window study with its prior takes about 10 clicks on a good day: you must go to a little drop-down menu, and select link or break link, and you have to have each and every window set at the proper level, or you're not going to get what you want.

The next question is the display of 3D. Do we launch a Voxar or TeraRecon window, or should it be incorporated as window within the regular viewer? I personally like to view an exam with simultaneous displays of soft-tissue, bone, and lung windows; in a 2x2 display, the fourth window could be a volume rendering or a coronal reconstruction. The major 3D programs from Voxar, GE AW, TeraRecon, Siemens InSpace/Leonardo etc., can all be set up to do this, with varying degrees of difficulty. (Note that I don't mention Vital Images...We own three Vitreas; one blew a hard disk drive, and Vital would not respond to TEN calls requesting service. They won't be considered for anything in my place again.) One of my former colleagues believes that dual 3D display is the way to go for each and every CT, with isovolumetric voxel acquisition. Personally, I tend to be a little hesitant about acquiring sub-mm sections and doing full-fledged 3D analysis on a 500-1000 slice dataset on every single abominable pain witch-hunt. To my knowledge, dual 3D display is available today from ScImage, GE AW, and Philips, and is said to be in development by Siemens. Honestly, I don't use it when I have to use ScI, since setting up a viewing session is a pain, and keeping the two exams synched is a bigger pain. My former colleague who believes in this approach I think does it more for speed, and probably syncs the axial images only with a thick MIP. To me, 3D is for problem-solving, and new and old studies can be satisfactorily compared for now with linking of the axial images. I'll likely change my mind when someone comes up with the automatic matching thing.

Every system has to have the requisite markup, windowing, series and image tools, and these just need to be logically arranged, not scattered like one of my son's LEGO constructions. The most often-used functions should be available with a right click; the user should be able to determine which those should be. However, I'm not sure I like the approach of having ALL functions user-customizable. Agfa 4.5 gives me literally 500 tweakable features, and these change with the modality; in the end, most would be better off with a bit narrower set of options. Likely 95% of users would want very similar deployments. There should be integration with the HIS/RIS and instant availability of prior reports and demographics, and in the age of the IHE, perhaps Pathology and other results as well.

It goes without saying that the thing has to work every single time, without losing studies repeatedly in transmission, or requiring the three-finger salute 20 times a day. If I click something as "Dictated", it had better stay clicked. The "skin" of the GUI should look professional, but not distracting. I really don't need the bridge of the Enterprise, unless someone can include a transporter in the whole package and beam me to the beach in time for my sunset margarita. The buttons and icons need to be similarly clean and clear, and not done with Microsoft Paint by a junior-high student. It is clear that some companies expend a great deal of their graphic arts dollars on their web-sites and AuntMinnie.com ads, and very little on the interface of their products.

There are about a thousand other factors to include, not counting all the tiny little details that are critical to making a system a success. Consider this a primitive first-pass at a very complex topic. I would welcome your comments.

Empiric RIS

I have been perusing a demo of the Empiric Systems Encompass RIS, and I just went over some of the details via WebX presentation. So far, this is an impressive product. Its interface is clean, simple, and intuitive, and it actually does much more than I need it to do. Still, it seems like a good solution for managing reports with our erstwhile virtual PACS system. More to come.

Going Independent With PACS..Guru Needed

We have the very beginning stages of our own PACS system, an Amicas spoke server tied to the Amicas PACS database of one of our hospitals. While this seemed like a great idea at the time, we are thinking of going independent for several reasons:

• The other, bigger hospital in town won't send images to our server for call purposes because an employee of the competing hospital might get cooties on their data. We absolutely HATE using Agfa Web1000 on call, and would love to have a unified AMICAS client for all call work instead.

• The Amicas hospital has had numerous delays in upgrading the communications lines, including ours, due to a complete move of the entire IT and telecom departments to another location. In the meantime, referrers who would like to use our system have been put off, in one case for well over a year. Of course some of the delay was due to the Agfa hospital deciding that they didn't have space for us on their database afterall about a year ago.

I have always felt that it is better to be one's own master, and in charge of one's own destiny. We have hitched our wagon to the hospital's horse, and I don't have hold of the reins. Time to get our own horse.

The problem, of course, is money. To set up a full-blown proper PACS with SAN's and redundancy and tape backup for 7 years and a RIS to go with that (hold the fries) will cost in the neighborhood of $300,000 to $350,000. That does not include a place to put the rack of stuff, the power to run the stuff, and most importantly, the people to make it all work. This is going to get expensive, but if I'm going to do it, I'm going to do it right.

I still need a guru to make it all happen. I have had a few leads, but with the various delays and what not, I still haven't found just the right person. If you are a guru (or a Jedi master of PACS for that matter), and you might be interested in all this, let me know! Use the comment button below. Please!

ITL Strikes Back

I received this response from the imaging center owner:

I've shared your thoughts with the ITL group that we met with on May 4,2005. The enclosed attachment is their response to your concerns. Based on their response as well as the points I've listed below, I feel that I must go forward with the purchase of this product.
* I've signed a contract
* (Imaging Center) has the opportunity to save a significant amount of money vs. other PACS systems.
* The product is on a single platform which has benefits that none of the others have.
* Several of the Radiologists in (your) group that I've asked about time saved, said 20% to 40%. If you weigh that against 4 or 5 calls a day until they get used to it, your group comes out way ahead.

Now, the response from the president of ITL:

Dear (Imaging Center Owner):
It was great to see you Wednesday, and we appreciated the time and courtesies extended to us by the entire (Imaging Center) team in discussing implementation of Image Technology Laboratories WarpSpeed seamless RIS/PACS. We are eager to see (Imaging Center) realize improved business efficiencies and quality through the deployment of the WarpSpeed system.
We appreciated the time, albeit brief, that Dr. Dalai afforded us, and respect his radiology expertise. While we are disappointed and disagree with his conclusions, it underscores the traditional distinction between image management products and information system solutions. Given his experience with, and knowledge of, particular image management/storage systems this is not surprising. While we don’t question the sincerity of his intentions, it does not provide license for him to make incorrect pronouncements as fact when commenting on RS/PACS in general, and ITL in particular.
Many of Dr. Dalai’s opinions may have certain relevance in his environment. We do not mean to trivialize them, nor do we wish to engage in a technology debate of image management products and our seamless RIS/PACS solution. However, please allow me to comment on some of the incorrect conclusions expressed relative to ITL:
Within the simple context of an image management system, one might understand some of his assertions. For example, while some image management products omit the “... computer between each modality and the main server”, RIS requirements generally dictate use of a computer at or near each modality. In a seamless RIS/PACS environment, a computer strategically placed at this important “pressure point” improves quality by automatically ensuring data consistency and integrity. Historically, non-seamless RIS/PACS data inconsistencies are handled by a manual downstream QA “exception” resolution step. Billing quality is enhanced by allowing the person closest to the procedure, namely the technologist, to provide the CPT codes as the study is pushed into the workflow from this computer. The technologist can also specify study priority, hold / preliminary push status.
Dr. Dalai’s comment that “...I am assuming that the radiologists with whom they partnered had little PACS experience “when he raised the issue of CT slice thickness when looking at comparison scans is incorrect as well. One of ITL’s founders was the radiologist assigned to bring PACS to Albany Medical Center. Moreover, within an imaging center or community hospital, the majority of the comparison scans are intentionally performed using the same protocol, including slice thickness. Slight differences in patient position on the table between scans, as well as the natural variations associated with the human respiratory cycle, were important considerations to our team when that area of function was designed. It is a rather trivial matter to automatically adjust the linked comparison scrolling based upon the DICOM Frame of Reference and Image Plane Module information. While this is not an issue in most installations, we are incorporating that change as part of our commitment to (Imaging Center).
“...data distribution structure is reminiscent of Agfa and Siemens designs from five to eight years ago” Our internal enterprise-class architecture uses many technologies that didn’t even exist five to eight years ago, such as transactional asynchronous message queuing, high-performance distributed file systems and distributed objects to implement a unique hybrid push-pull data model that is impossible to convey and understand properly in a short 10-minute drawing session. We are confident that no other industry player has implemented such an architecture. It is precisely this workflow architecture that gives us our strength in delivering value to the entire medical imaging business.
“The majority of systems today are web-based, relying on the architecture of the Internet itself, rather than reinventing the wheel” The Internet is an implementation of a homogeny of RFC (Request for Comment) “standards”. We utilize as many of these RFCs as is necessary and appropriate and our system can and does run within a LAN environment as well as across the Internet via VPN.
We constantly reevaluate “web-based” technologies (whatever one chooses that phrase to mean), especially those associated with Linux and Windows, such as the .Net infrastructure. It is not our intention to enter into a debate with Dr. Dalai over the virtues of thick-client vs. thin-client or two-tier vs. three-tier architectures, since it is a very complex set of issues, especially with respect to security, viruses/spyware and performance. The medical imaging community is just now waking up to the inherent security issues and starting to produce white papers and articles necessary to more widely appreciate these problems. Dr. Dalai stated “Most systems today use the web approach for remote access, which has proven to be safe if implemented properly.” This isn’t about proper implementation techniques, rather it really is an issue of security exposures in the underlying web-enablement technologies. See http://www.microsoft.com/security/default.mspx. We will be happy to discuss our web-portal capabilities with you privately under an NDA.
“From a hardware standpoint, I would be very concerned about their proprietary assembly of the core of the system” There is a distinction between configuring the “off the shelf” server systems we procure and integrate with our software versus Dr. Dalai’s allegation that we assemble the system around Intel server motherboards. Dr. Dalai mis-understood what we were trying to convey. We do procure our servers from a major rack-mounted “off the shelf” supplier. Our choice of servers happens to use Intel SMP motherboards, reflecting our positive experience with Intel, along with other standard components that we specify. There are no custom ITL components in any of the computers we supply. ITL is a software developer and systems integrator, and we deliver turnkey medical imaging business solutions.
“...their product is for all intent and purpose in beta” The ITL WarpSpeed seamless RIS/PACS system is employed and has been in production since 2001. The study volumes at each of these locations equal, or in some cases significantly exceed, the current volume at (Imaging Center). The reliability track record of these systems and our software has been excellent. Our comments regarding the Company’s dedication to always looking for feedback and improvements were misinterpreted as a sign of weakness and immaturity of the system. However, our years of experience while at IBM has instilled in our engineering team the value of seeking feedback as a means of ensuring a constantly improving product that provides real value. Any feedback from Dr. Dalai in such a context would be appreciated, obviously subject to his time constraints, but is not required.
Dr. Dalai’s group has evidently struggled through some unfortunate history with specific image management vendors. I share his irritation with systems that require additional personnel and resources to manage daily operation. These challenges are increased significantly when stand-alone image management systems attempt to incorporate RIS and workflow enhancements as add-ons. Our seamless RIS/PACS WarpSpeed system and commitment to (Imaging Center) will ensure that you realize an improvement in the efficiency of your business without experiencing the same frustrations.
Finally, SEC regulations on selective disclosure preclude discussions on the Company’s financial position beyond our public filings. ITL became a publicly traded company in 2000 and the management of ITL remains optimistic about its future.
The ITL team is excited about starting the installation as soon as possible and establishing a long-term productive relationship with (Imaging Center).

Sincerely, President & CEO

Well. I guess I've been told, huh? I am rather disturbed by the whole thing, especially the total trust the owner of the imaging center places in this little company because they are willing to give it to him cheap. This comes after he promised he would not go through with the purchase if I honestly felt it was not a good idea. I guess money talks louder than most other factors. The CEO's response assumes either that I would never see his letter, or that my opinion has little bearing on the ultimate purchase. Seems to me it's probably not the best idea to refer to criticism as having a "license to make incorrect pronouncements". You know, the whole tone suggests a company at the edge. There are probably better ways to tell someone he is, in your opinion, filled with feces (even though I'm not at the moment). Perhaps that is the way business is done in the state of New York.
I'm not going to go through each point and re-refute it. I stand by what was said in the initial letter, and I am NOT convinced that any item was settled by the ITL response. I am most amused by the stonewalling behind SEC regulations as an excuse for not discussing the financial status of ITL.
ITL brought their entire engineering team down here. They took 20 minutes to get their demo running. Even then, they didn't bring a touch screen, which they describe as the key to navigating their client. Buying this product on this basis is like buying a car from a brochure without ever driving it, and that's being kind. Add to that equation that the car in the picture of the brochure has no steering wheel, but they promise your car will have one, and of course it will work perfectly.
This software, from my point of view, is just not there yet. It's cute; they made it look rather like the graphics from Star Trek, complete with appropriate sounds, and this is certainly endearing to me. But cute doesn't get the work done.
I am far from a PACS guru. What I know I have learned through a lot of research on the web, reading what I can about the various products out there, and various approaches. I missed SCAR last year, but I'll try to make it this year and learn some more from the real gurus. That being said, I do have some pertinent knowledge of PACS, and I know my partners. I conclude that this purchase is a very, very bad idea.

Paper Requisitions and PACS/RIS Reports

A site we cover (side by side with another group) is one of the most advanced clinics of its type in the nation, but still uses paper requisitions. These are being printed in duplicate, stapled together by the techs, and brought to the interpreting radiologist by the technologist performing the examination. The radiologist then has to rip the packet apart, sort the sheets from multiple exams if applicable, and slot one copy for the clinic and the other for us. This system adds a great deal of inefficiency for the technologists and to our radiologists. I would think we can do better than this. The techs are great (I knew most of them before they came to the clinic), and I really enjoy working with them. I would prefer, though, that we not have the continuous stream of people in and out of my office simply to deliver the paperwork. I need to use BOTH of my brain cells when reviewing the CT's, and the distractions just don’t help. I admit with some embarrassment that I find the traffic in and out of my office very distracting, especially while trying to read some of the rather complex cases we see at this site. To add to the situation, one of the techs thinks it’s cute to pirouette into the office and wave the requisition around like a fan.
The dual-paper system was originated by our own group’s business manager (who is no longer with us) in the belief that it was the "safest" way to ensure that we could account for all exams we interpret. I have a little more faith in the technology than he did. I am certain the PACS or the RIS system can provide a print-out of daily or weekly activity. They are not integrated per se, but are provided by the same vendor. The site administrators have been told that the system cannot generate a report of daily activity with a guarantee of accuracy.
Am I the only one out there who would rather NOT have somebody coming into my office every three minutes? Maybe it’s my ADHD coming through. But, is it too much to ask for a PACS and/or a RIS system to be able to generate a report of daily scans read by each group? Do I even need to name names?

ITL

One of the sites we cover signed up for WarpSpeed from Image Technology Laboratories. After meeting with just about their entire cadre of execs and engineers, here are my thoughts (sent by letter to the owner of the site in question):

I would like to thank you for yesterday’s opportunity to visit with the Image Technology Laboratories team. The meeting was quite interesting, and their engineers are obviously quite knowledgeable. I would go so far as to say that were I independently wealthy, with a lot of extra time on my hands, I would buy the company myself and with the expertise available, create a super product.

I promised you an objective assessment of the WarpSpeed product, and I will do my best to provide this. In brief, the software that is most important to me, the radiologists’ reading client or viewer, is not ready for deployment. In all honesty, based on our discussions yesterday, I would place their product about two to three years behind industry standard. While they have many good (even superb) ideas, ITL has not yet assembled them into a system that I would be comfortable using in day to day practice. There are a number of factors that lead me to this conclusion, and I would be glad to discuss them with you at length if you really want to take the time to do so. Let me cite one example which really tells the story. You might recall my question about linkage of two CT studies, and whether they use image number or table position. They really seemed to have no idea about the difference between the two approaches. The use of table position linkage allows the comparison of scans performed at differing slice thicknesses, which is a fairly common situation. Linkage by table position has been industry standard for at least the past 2-3 years. I think this is really telling of the entire direction of ITL. They are an assembly of very sharp and high-level engineers, but I am assuming that the radiologists with whom they partnered had little PACS experience. The entire approach ITL is using with their product shows innovation, but also near-complete isolation from competing approaches. Their data distribution structure is reminiscent of Agfa and Siemens designs from five to eight years ago. The majority of systems today are web-based, relying on the architecture of the Internet itself, rather than reinventing the wheel. Their concept of a thick-client viewer is still used by some systems, although many today use web-based clients or viewers. Placement of a computer between each modality and the main server is an approach very rarely seen today. Finally, the method that was outlined for remote access is close to unworkable. It attempts to isolate the user’s computer to “prevent transmission of viruses” and does so with a great deal of effort. Most systems today use the web approach for remote access, which has proven to be safe if implemented properly, and requires no significant modification of the remote computer.

From a hardware standpoint, I would be very concerned about their proprietary assembly of the core of the system. The fact that they use “Intel motherboards” does not assuage this worry. The majority of vendors have gone to using “off the shelf” servers, storage, and the like, lowering the cost and allowing easier service. A proprietary collection of components (even if those components themselves are common) could present a service nightmare.

I do not claim to have the business expertise you possess, but a quick review of ITL at http://finance.yahoo.com/q?s=IMTL.OB&d=t raises several further concerns. According to SEC filings, they had a significant net loss last year in spite of increased revenue. The contract with you is very prominently mentioned, and it is rather obvious that there have been no other recent sales. This is a company operating at the very edge. Their future existence is really in question. They will depend on sales to sites with no PACS expertise, and those are becoming fewer and further in between as the technology continues to grow.

What concerns me the most with this company is that their product is for all intent and purpose in beta. It is NOT ready for a group with our level of PACS experience. To get them there will require an amount of testing, time, and patience that we simply do not have. Your operation is very busy, and your scanners churn out a rather significant number of images. We cannot just stop reading those studies to call up the folks in Kinsgston and work out
problems. We do not have the time (or in the case of most of my partners, the expertise) to develop this product. We have been down this road before with ScImage. When my former partner first brought it to us, it was buggy, it crashed constantly, and it was very painful to actually use. This was a company that should have gone out of business. My partner was enamoured with their 3D module, and was willing to ignore the poor programming of the entire remainder of the system. Rumor has it that he invested a substantial amount of his own money to keep ScImage afloat, and they are still around today with a more stable (though still poorly interfaced in my opinion) product. You may have seen our new computer in the reading room which we use for the orthopedic studies. This utilizes the StorComm MedView client, which is again very tedious and completely unintuitive. I am fielding about 4-5 calls per day from our radiologists struggling with this less-than-optimal software.

With the above in mind, I must urge you in the strongest possible terms to reverse your purchase of the ITL system. There are other alternatives which I would be more than happy to help you pursue. Please contact me at your earliest convenience so we can discuss this situation further.

Uncooperative Vendor??

chuckg writes on AuntMinnie.com:

Hello:
We are installing a PACS system in our smaller rural hospital. We do around 30K exams per year. Our HIS company has been very difficult to work with. They also offer a PACS solution we chose not to go with. Now they will not allow our PACS server to be accessed from their web based EMR program. The field appears to designed to be linked to the server. The answer we get from the HIS vendor is "We will not assist in the success of a competitors PACS product." Has any one heard of this attitude from a HIS provider?
Thanks.

Dalai Lama replies:

The words "uncooperative" and "vendor" should not have to be used in the same sentence. It certainly sound like they are being petulant about losing the sale. I have a philosophy about that: there will be other sales in the future, and your behaviour as the vendor NOT chosen is far more telling than that of the winner of the bidding. I would get in touch immediately with the president of the HIS company and let him know how his staff is behaving. If you get no satisfaction there, I would do whatever it takes to replace the system if there is any financial possibility of doing so.

We tend to forget that WE are the customers in this business.

Back to PACS....

I'm noticing that the Google ads above are governed by the uppermost postings, so they have turned to links for Peter Island and such. So, here is an attempt to reset the list:

PACS, Agfa, RIS, HIS, Amicas, Fuji, GE, Centricity, Radiology, CT, PET, Nuclear Medicine, Siemens, etc.

......These are a few of my favorite things......mixed in with a few of my UNfavorite things.....

(Feel free to click any and all ads...monies generated all go to my favorite charity, the Old Radiologist's Retirement Fund, me being said Old Radiologist!)

By the way, I have just discovered a new remote access program, "logmein", which can be found at: http://www.logmein.com. Think "Log Me In" rather than some weird Mandarin dish. The basic version (which allows full remote control, but does not include file transfer) is FREE! It is as functional, and is said to be more secure, than GoToMyPC, which is $15-20 per month. Yes, Windows XP does have remote access built in, but it cannot handle network access across a router as most of us have at home to split up our broadband access. Logmein has no problem with this. Give it a try!

Doc Sam's Virtual Colonoscopy Prep

I used to grow hot peppers in my back yard, habaneros, jalepeno's, seranos, and whatever else the garden shop had for sale. A few years ago, I put some up pickled in vinegar in small glass canisters, and labeled them appropriately. Still have a few if anyone needs some dynamite....

Peter Island

Deadman's Bay, Peter Island, BVI

My wife and I, as well as my 16 y/o daughter and my 10 y/o son just spent 5 days at Peter Island. It was a great experience, but there were a few glitches. Still, we will likely return someday.

First, the high points. The resort is the only inhabitant of an 1800 acre island. Most of the island is accessible only by boat and the beaches at that end are rocky. The main portion of the resort is nestled between the marina and Deadman's Bay, the latter containing a spectacular white sand beach. We stayed in regular hotel rooms, which are housed in two-story A-frames fronting on the marina, and opening onto the pool area in the back. We requested an upgrade to a junior suite, which sits at the edge of Deadman's Bay, but these were filled. The rooms are spartan compared, say, to the cookie-cutter luxury of a Ritz Carlton, but at the high end of typical Caribbean accomidations. Our rooms were immaculate, even the bathrooms, which we have usually not found in this part of the world. Beds were comfortable, though nothing spectacular (i.e., not one of the miracle beds the larger luxury chains are advertising these days.) Linens were clean and comfortable. The room was stocked with sandals, a flashlight, and a CD of island music which could be played in the CD/clock radio. There was no TV. For those that cannot escape completely from the outside world, the room telephone has a dataport for Internet access, though it was quite expensive at $2 for connection and $.75 per minute. (There was a spare office that was hastily converted into an Internet room; it had a huge desk with two computers hooked to the resort's T1 line, but only one worked. There was no charge for this.)

There were two restaurants, Tradewinds, which was near the pool and our rooms, and Deadman's Bay Beach Bar and Grill right on the beach. We ate breakfast and dinner each day at the Tradewinds, and had lunch most days at Deadmans. Breakfast included a wonderful Caribbean buffet with an omlette station, and there was ala carte available as well. Lunch at Deadmans usually had a buffet as well with various salads and entrees. Dinner at Tradewinds was always excellent, with the best food we have had in the Caribbean. Service was mostly superb, especially after our waitress, Maxine, took us under her wing. Under the American plan, all food is included, but alcohol is not, nor are the obligatory beach-side smoothies or even Cokes. The rooms are initially stocked with 6 sodas, two bottles of water, and two beers; they are supposed to be restocked during one's stay, but ours never were. Bottled water sometimes was free, and sometimes was not, but after a day we drank tap water, and there were no ill effects from doing so.

There is no nightlife at all, and that was fine. There was usually live music at dinner however. While the resort "discourages" children, at least half the guests had children with them, and this did not detract in the least from the ambience. We spent our days swimming, snorkeling, resting, eating, and hiking. A good time if that's what you expect to be doing. There are several miles of hiking trails, with one trail leading to a wonderful sunset view, and another to White Bay beach, a spectacular but secluded stretch of white sand and blue water. Snorkeling off the beaches was disappointing, but there were some interesting features here and there, with the best snorkeling actually off of Deadman's rather than White Bay as we had been told. We also chartered a deep-sea fishing boat for our last day there ($800/4hrs), and I caught a 65 pound mahi mahi!

And now, the "glitches".... Service was generally very good, but there was something lacking giving the rather high price of the resort and the exclusive reputation. The resort can hold a maximum of 100 guests, but I never got the feeling that any of the staff (beyond Maxine, that is) even knew our names. There was just no personal touch. I compare this to the Concierge-level service at a Ritz Carlton (which comes out similarly priced), where we were immediately made to feel totally at home. We had phoned the resort prior to arriving to warn them about my daughter's shellfish allergy, and we were assured that all restaurants would be alerted. This didn't happen and we had to remind everyone at virtually every meal to help us with food precautions for her. At one point, a different waitress at Tradewinds (not Maxine!) didn't seem to even comprehend what I was requesting, and I had to ask to speak to the chef (who was very understanding as well as a fantastic chef!) This exemplifies some of the problem...many members of the staff do not speak English as well as some of the others. I am usually good with accents and gently making myself understood (I try not to be a stereotypical American tourist!), but there were times I just couldn't get through. Some of the other glitches (and they were minor) relate to this, I think. We had ordered drinks to be delivered to us at the sunset lookout point, but the message did not get through. We had lunch packed for the deep-sea fishing expedition, but while there were four full set-ups with pasta salad and fruit, there was no cutlery, and two of four sandwiches never made it to the lunch bag.

Peter Island is a haven for yachters, and they were all over the place, some with children that were, ummmm, less well-behaved than the resort guests. They would crowd the bar at lunchtime. This was, however, a minor irritation.

Perhaps the most disappointing, or maybe just annoying, problem involved the attitude of the entire resort about the Spa. It is a beautiful building, but the services are very pricey, and you can't go in if you don't purchase a massage or some such thing. I was not going to spend $130 or so for my 10 year old to get a massage. The VERY WORST part of all this is that the spa has taken over Big Reef Bay, one of the most picturesque beaches on Peter Island, and those of us not using the spa are not allowed. Frankly, this might violate the laws of the British Virgin Islands, which declare all beaches public. Spa personel were minimally apologetic when tellling us we could not walk on the beach, and frankly the attitude left us with a rather bitter taste overall. I would urge the management (Sandra and Tom) in the strongest possible terms to reverse this policy. I don't know who they are trying to appeal to with this resort within a resort mentality, but it is generally not a good idea to shove aside part of your clientelle to appeal to a smaller subsegment.

So, the Peter Island experience is a good one, though with a few glitches. Some are just part of a Caribbean vacation. I prefered Peter Island to Caneel Bay, although my wife feels the opposite. It is definately more upscale than Bitter End, and has overall better service. We will probably try some other resorts, such as Little Dix, but I do expect to return to Peter Island someday.

Dalai likes the Amicas Real Time Worklist! 

Questions from a Like-Minded Rad

An email "conversation" about 3D, etc....

Hi Sam,
My name is A...... I'm an interventional radiologist and the designated PACS maven for our group which practices in a 400 bed community hospital in the greater ...... area. I've enjoyed and/or learned a bunch from many of your posts over the last couple ofyears and would really like to talk to you about a variety of topics including 3d, mdct, reporting dication and general workflow. I've spent the last three years reengineering all our departments processes during a Stentor PACS implimentation. Whilethe major stuff is done, there is a ton of tweaking left to do and I'd really like to just get some ofyour thoughts. Here are a few questions. If emailing takes too much time, I'd be happy to arrange a mutually convenient time to chat on the phone.

1. Does your Auntminnie "handle" have any religeousconnotation? I've been taking a Tibetan Buddhistmeditation class and just had to ask.

2. How much post processing beyond MPR do you thinkwe will be doing at our PACS workstations with MDCT? Should I make sure the techs stay real competent at all the 3D stuff or is it going to get so complicated (think coronaries) or fast (all automated) that we will do it? What are you using now?

That's a start. ....Hope this isn't too presumptious. Thanks, A....

A....:

Glad to talk with some like minded folks!

Actually, I am Jewish, quite reform, really. The Dalai Lama thing came about as an attempt to keep a vendor (ScImage) off my tail. I wanted a nickname that no one would ever associate with me, and the Dalai came to mind. I hope I am not showing any disrespect in this. Sadly, ScImage figured it out anyway. That's a whole 'nother topic.

I do Nuclear Med as a subspecialty; I'm one of the few who did a NM fellowship after DR. It is heavily computer oriented, and I have always enjoyed it. I'm an electrical engineer by training, although I never practiced as such.

I took over the PACs "guru" position in my group when the former guru got fed up with Columbia and went to Florida. He and I had a number of differences of opinion on how to do things. For example, he loved (and still uses to this day) ScImage, because they have one 3D module (Netra) that lets you view a whole volume with the sweep of a mouse. Basically it uses thick slap MIP reconstruction, and somehow loads it such that there is fast screen refresh. Sadly, the programming this one good module comes wrapped in is primitive, and it takes me longer to set up a study to be read than to actually read it. Bad sign. He insists that one must perform isometric imaging (thin enough slices that the voxels of a volume have all three dimensions equal), and then you have to visualize the new and old studies with a dual MPR program. Right now, ScImage and Philips are really the only ones that do this overtly. We have a GE AW (which I HATE!) but it can be conned into doing this as well. For what it's worth, I still do my comparisons with the good old axial images, though matched by table positions.

For 95% of what I do, the onboard MPR Amicas provides (I call it baby-Voxar) is adequate. Beyond this, I'll use the GE AW at the hospital that has that (If I really have to...) or full Voxar at the other. The other hospital has Siemens InSpace, and I really like that too, though I find I just don't make myself use it enough. (The GE hospital is in the process of changing from Agfa 3.5 to 4.5, and Voxar-based 3D tools are included as well as full Voxar...I'm not sure of how many "seat" licenses we will have...)

As to your question....We really haven't yet figured out the best workflow. My primitive thought is that still much can be handled with simple MPR, and I end up doing this on at least 50% of the CT's I read. My former partner says that you have to do the isometric voxel thing on EVERY SINGLE CASE, or you'll miss things, but I'm not convinced. I also must wonder if we are doing our patients a favor by picking up 2mm lung "nodules" that we end up following for years. Should the techs or the rads do the higher-level processing? That probably depends on your volume, your comfort level with the technology, the expectations of your referring docs, and a number of other factors. On more routine studies like angios and runoffs, where there is an easily-defined set of processed images, it certainly makes sense to have the techs take care of it. For the more esoteric stuff, it is probably wise for the rad and the tech to work together, at least until the tech is comfortable with it and the rad is comfortable with the tech's abilities on that particular study. All that being said, I find it incredibly valuable to be able to jump to full Voxar 3D and do a volume rendering and segmentation or whatever on those occasions when doing so will actually answer a question. It makes me wonder if I am asking the right question often enough, though!

That's a preliminary answer. I will attempt to hit SCAR this year and see what the rest of the world is doing. I'm thinking that no one has really found the perfect solution as yet. As with the adoption of PACS itself, it is a process everyone has to go through and mold (and be molded by) to reach the proper end. We are certainly not there yet!

I would really appreciate knowing your approach to all this!

Thanks for contacting me....

Sincerely,

PACS Selection Committee 2003, part I

I tried to convince the PACS Selection Committee to reconsider Amicas after they had eliminated all but GE, Fuji, and Agfa.....


To the Committee:

First, I would like to thank ........ for clarifying this issue. The minutes of a committee within a public entity may be subject to scrutiny, especially with a project of this magnitude, and they must reflect events exactly as they occurred.

Secondly, our experience with ScImage has taught me that one person should not fiat the purchase of a system as complex as PACS. The expertise of many has to be brought to bear. I was placed on this committee because of my Radiology experience, as well as my training in computers and electronics, and in addition, I have gathered a fair amount of information about PACS over the past several months. Even so, I was not allowed to review much of the data that came into the ........, and my opinion was not sought. To function as a committee, all members require full access to information, and full participation in the decision making process. I intend to participate in this decision; I would not try to make it myself even if that were possible. To that end, I will try to condense what I have learned into the next few paragraphs.

As I stated in the meeting of November 24, 2003, I have had the opportunity to test the products of all seven original vendors at the Society of Computer Applications in Radiology (SCAR) meeting earlier this year. I have been in touch with numerous friends, colleagues, and references concerning several of the products, both by phone and email as well as AuntMinnie.com. I have been on site visits sponsored by GE and Fuji. Although they were not made directly available to me, I have reviewed the Cap Gemini/Ernst & Young report as well as the replies to the RFI from Philips, Amicas, and GE. I have also reviewed recent KLAS reports and product comparisons from Reilly Communications, who publish Imaging Technology News/MEEN.

The Cap Gemini report narrowed the field down to Agfa, Amicas, Cerner, Fuji, GE, and Siemens, with Philips apparently being added later. (Most of us were not aware that Philips was already present within our hospital as a Cardiology PACS.) When I reviewed their report, much looked familiar; most of the information appeared to be either a recapitulation of the material we gave them during interviews, or alternatively a summary of facts from the vendors’ web sites.

As above, I have examined only three of the replies to the RFI. My read was significantly different, apparently, than that of others. Philips, GE, and Amicas all appeared to be able to fulfill the requirements. GE sent a veritable encyclopedia, fleshed out by dozens of pages of Xeroxed standard information. Many answers were in the form of long duplicate paragraphs that were copied and pasted into several locations. Amicas answered most questions too briefly, basically saying “yes” when they could perform a function. Philips’ response appeared to have been prepared the most carefully of the three.
The status of the individual companies in the PACS market may best be derived from the KLAS report; the most recent is summarized in these graphs, the first from 7/2003, and the second and third from 4/2003:


Klas Vendor Ratings

PACS Selection Committee 2003, Part II

Klas 2003
A comparison of market share, etc, may be found at the Reilly Communication site: http://www.reillycomm.com. Several trends are apparent, but the most critical is that of web-based technology. This is where all vendors are headed, and all will admit this fact. There are only three companies among the major players that are at this point NOW: Amicas, Fuji, and Stentor. Most of the other vendors have told me that they will implement a web-based architecture sometime in the future, though only Siemens gives the timetable of 18 months or so to do this. Count on a significant hardware change out within the server to accomplish the move. All vendors now use PC/Windows for their workstations, but some still use Sun/Unix computers for database/server applications. By individual vendor: AGFA: Obviously, we have history with them, and they have done a superb job of prolonging the capacity of equipment well beyond the end of its useful life. We currently are one of three remaining IMPAX installs in the world. The system cannot handle data from our GE LightSpeed 16 CT scanner, necessitating an emergency interim solution, which likely will be provided by Amicas. Two years after our system was installed, AGFA changed their workstation platforms to Windows/PC from UNIX. An upgrade would have cost $2M. However, the upgraded system might have handled the 16 slice data. Agfa was once the market leader; in fact it dominated the market for many years. Its market share has slipped considerably, especially in the US, with far fewer new installations than GE or Fuji, the new leaders. As above, Agfa does plan to convert to a web-based architecture, though I was not told when this would occur. There would have to be a complete change of the server hardware to accomplish this. I tested IMPAX 4.5, and the client is actually quite good from my standpoint. It uses a limited form of Voxar 3D. Several AGFA sites are now using Amicas for web distribution. AMICAS: Let me state in no uncertain terms that I do NOT think this is the perfect system by any stretch of the imagination. However, this is a very versatile product from a very innovative company, and deserves further consideration. Amicas was purchased in the last week by VitalWorks, a fairly large company dealing in web-based RIS systems among other products. The purchase price was a fairly substantial $30M. VitalWorks has pledged to maintain Amicas as a wholly-owned but independent subsidiary. Rather than cloud the future of Amicas, I feel this acquisition ensures Amicas’ presence in the marketplace for the foreseeable future. The product is totally web-based; it IS a web-server at its essence, and it uses a non-proprietary form of DICOM which allows far easier migration than with other vendors. The LightBeam viewing client is one of the more user friendly out there, and it includes a worklist function that is second to none. There are monitoring and administrative functions for the PACS administrators and remote monitoring from Amicas. This company deals with software only, and hardware must be maintained by the hardware vendor (Dell, IBM, Compaq, etc.). Sites I have contacted have had little problem with this. (I would personally want Amicas to interface with the vendors such as Dell, to initiate any service call.) They do not have a Cardiology solution of their own, but can accommodate several third party programs. There is a limited form of Voxar 3D, with new memory management techniques to allow very rapid deployment of the 3D module (or optionally the full Voxar 3D program) from the viewer. Cerner: This system does one thing quite well: it interfaces with their Cerner RIS. Otherwise, there is little in its favor. Apparently they claim 20 installs; I have only been able to confirm about 5, and rumor has it that they never even mention one very troubled site (Detroit?)

Fuji: Synapse was the first web-based PACS system. Their architecture appears very solid. The viewing client is rather esoteric; many like it, some don’t. I have spoken to one of the senior Fuji VP’s in charge of the Synapse project, and a new version of the front end is in development. I have been less than impressed with the regional Fuji representatives. They generally do not know the capability of their system, and have to call back to the head office to get the answer to any question. At SCAR, it was made very clear that Fuji would monitor usage and charge accordingly. Fuji users I have met have been satisfied overall, but note that “you will get what’s in your contract, and absolutely nothing else.” Our site visit to Austin was billed as an example of Fuji interconnecting several hospitals. The system did seem to work well, although there had been a 5 hour outage the day before that no one could explain. The interconnection, and really the main functionality, had NOT been designed by Fuji, even though they implied otherwise, but rather had been set up by the group in Austin and Time Warner Cable. There is limited integration of Voxar 3D; clicking a button launches it but that’s the extent of it. They may be replacing it with their own 3D program. GE: The largest company in the business. Centricity version 2.0 has been touted for over a year, and might actually ship in December. The client is very well done, except there is not a set 3D solution. GE actually started selling Voxar 3D as an option after I got the two companies together. The underlying architecture is very complex, and I’m not even sure GE knows how it works. I spent about an hour trying to get their PACS people to tell me if it was web-based; finally, we conclude it is not, but it is web-enabled. This means there is internet access into the main database, provided by yet another box attached to the system, but the system is not a web-server in and of itself. They will change over eventually, and a new server and other associated hardware will be needed. Centricity is acknowledged to be the most expensive PACS system of all. A system was to be placed at Emory, but after GE’s price went up by several $M, Siemens was brought in instead. (GE tells me that Emory asked for a much expanded system accounting for the increase.) Installs at (local sites) have had numerous startup problems, according to the docs and techs. Radiologists at the hospital are now more or less satisfied with the operation of the system. Philips: Their product is made by Sectra of Sweden. Philips has more world-wide installs than any other company. The user client is quite user friendly, though not really particularly distinguished. It is modular, and will accommodate third party software for 3D, Cardiology, etc. Service and uptime are extremely good by report. Architecture is of the old style, distributed database. As with AGFA, GE, and Siemens, there will be a web-based replacement, though no one at Philips could tell me when this will occur. Siemens: Sienet uses a very unique client, though it is a match to their other eSoft components. (CT’s, gamma cameras, etc.) The architecture is of the old model, and as above a replacement is planned for about 18 months from now. Of all the vendors on this list, Siemens seems to get the most complaints. Summary: Forgive the long discourse, but this is a brief distillation of what I have learned over the past several months. In short, there is yet no perfect system. Several companies were eliminated by the initial Cap Gemini survey that likely should have stayed in the mix, including DR, McKesson/ALI, and Stentor. Even working within the Cap Gemini suggestions, the review committee’s recommended cut keeps AGFA, apparently for no reason other than the fact that we are familiar with it, and removes Philips and Amicas, which are still very formidable players. I understand the limitations of time involved in site visits, but I feel any extra effort required will be rewarded with a more optimal decision. Therefore, I strongly disagree with the current recommendation. The roll-out date has already been pushed from February, 2004 to May, 2004. I recommend we revisit the choice of vendors, and take the time necessary to utilize all information available. There is much expertise on this committee which has yet to be tapped.

Amicas vs. Fuji 1/05

Posted to AuntMinnie 1/05...

I now have Amicas LightBeam PACS at two of the hospitals I cover. The other, larger hospital is upgrading Agfa Impax 3.5 to 4.5. A large oncology clinic we staff uses GE Centricity 2.0. We looked extensively at several systems. I will spare everyone the gory details, and stick to the question at hand. Maybe someday I will team up with Mike Cannavo and write up the whole search saga. It might make a good mystery novel....
I am very pleased with Amicas, and I would buy it again in a minute. All the rest is commentary, as they say. My partners now pay them the highest complement: when referring to PACS in general, they usually say "Amicaspacs", all in one word. In brief, the AmicasRealTime Worklist is incredible, and that is what sold me on them at SCAR in Boston in 2003. You see what you need to see at a glance; you know what needs to be read, what has been read, and the status of various things right there in a clear, color-coded format. The list can be customized any way you want it, even to the point of having a different set of lists for each user. The viewer itself is very straightforward and intuitive. The few major tools you need about 90% of the time (scroll, window/level, pan, zoom) cycle by a quick right mouse click, and all other tools are either on the menu bar of available through a right-click-and-hold pop-up menu. There is an embedded subset of the Voxar 3D tools, and there can be integration with the full Voxar 3D program or alternatively with a TeraRecon server.
As near as I can tell, the guts of the system are similar to Fuji Synapse, using Windows Server, for better or worse. Both are completely web-based, i.e., each image has its own URL. Both deploy software over the internet/intranet/LAN, i.e., the "thin client" approach. One's opinion on an interface is just that, an opinion. Some like Fuji's client; I am among those who do not. They use a folder analogue instead of a worklist; that is OK as far as it goes, but every time I tried it, I ended up with folders all over my desktop. Probably just user error, and I have been flamed repeatedly for disliking their system. I have been told by a senior exec at Fuji (who since left and went to another similar company) that I was far from alone in my feelings about their interface. In our PACS search, we actually hit two Fuji demo sites, one in Austin, Texas, and one in Virginia. The Austin site has a spectacular communications network, set up mainly by the experts within that particular radiology group and Time Warner Cable, and NOT by Fuji, again as nearly as I could tell at the time. Studies were delivered fully within 3 seconds of the request. This came at a tremendous cost in communications; thousands of dollars per site per month. One thing becomes clear when you talk with Synapse users: They like the product, but they seem to have to do most of the maintenance on their own. A common theme is that Fuji has not yet mastered the sales or the service on an otherwise good product.
Amicas has not yet reached the level of perfection, either, lest I leave you with that impression. Our install has taken longer to come up to 110% functionality than I would have guessed. Some of this is due to the fact that we have only one PACS administrator for two good-sized hospitals, and his helpers from IT have a thousand other things to do at any one time. Still, I am overall satisfied with what we have to date.
Agfa is a whole 'nother story. I am willing to slog through Impax 4.5 in hopes of eventually having 6.0 installed sometime in late 2005. (I urged that hospital to put some onerous penalties in the contract should 6.0 not appear, but I don't know if they did so...)
Bottom line: Amicas is a good company with a good product. They do have a significant number of "real" PACS systems installed in large hospitals. I recommend them highly. For what that's worth, anyway....

My SCAR 2003 Review

Posted on AuntMinnie.com June, 2003....

Many of us are in the PACS market, either to replace an existing system, or to dive in for the the first time. Hopefully, many of us went to the SCAR meeting, which provided a great forum for discussion and comparison of the various products out there. I want to compare observations. The purchase of a full PACS system represents a multimillion dollar investment, and we all want to find the best possible solution. Therefore, I shall post my own observations and I BEG you all to do the same.
General Observations:
1. Everyone is headed to "web based" architecture. This means for most that each image has its own URL. Some are already there, some are getting there, some are planning to be there someday.
2. MPR/Volume rendering on the PACS workstation is the up and coming thing. Most vendors use either some limited proprietary method, or bundle the Voxar 3D product in some form. See below.
3. The three monitor set-up is just about universal now. This entails two high res monochrome monitors (generally 3-5MP) with a small color monitor for the worklist and maybe some 3D stuff. EVERYONE had flat panels, usually Barco's for the high res. The vast majority used Dell workstations.

Company Specific (far from complete....):

AGFA: The grandfather of PACS..seems to have lost a tremendous share of the US market. Their client is very good. Sadly, their underlying architecture seems to be similar to the original (distributed databases, routing, etc.). The good: new product in the works... The bad: no one knows when it's coming.

Algotec: A good front end as it stands. The completely new client was not ready in time for SCAR. It is said to offer much 3D capability. Architecture is a little unclear; rep emphasized the "modular" capability of the system...ie, when expanding or upgrading, one box can be reconfigured or redesignated or reloaded to do the work of another box, thus preserving your investment.

Amicas: To me, this was the "sleeper" of the whole show. My personal opinion is that they have the best combination of client, worklist, 3D integration (with the Voxar engine), and web-based architecture. I would have placed my order then and there, but they do not have any installs as large as mine would be, and I have learned not to volunteer for beta testing. Frankly, I'm hoping they can convince me they CAN handle such a large project. They say that what they were showing was what they were shipping NOW, a nice change.
Fuji: Probably has the strongest web-based design. EMC reps felt that Fuji was best able to use their storage products for greatest speed and efficiency of all the PACS vendors. Again, a personal opinion, but I HATE their front end. The web/folder model is cute, but I find it much harder to work with than most of the others. Voxar 3d is thrown in as a free standing program, integration is promised, but wasn't demonstrated. They too say that what they show today is what they are shipping today. In speaking with other users, the general opinion is that Fuji delivers what is in the contract, AND NO MORE, so negotiate wisely. They are very price conscious, and make it clear that you will pay for what you get. Hopefully, you get what you pay for, too.

GE: Ah, the General! What can you say? They will probably supply more systems than any other company simply because they are GE. Centricity has a very usable front end, better if you have their VERY expensive RIS to go with it. Looks like their hanging protocols are great once you go through a rather lengthy set up process. I had a hard time pinning them down as to what ships when. Apparently, Centricity 2.0 will NOT SHIP UNTIL 12/03. They are flailing around with umpteen 3D solutions... I think the TerraRecon server box option will be available to ship with Centricity 2.0. They also showed their Advantage Workstation (AW) in a similar configuration (ANOTHER server box plugged into the network with "thin client" operation from the PACS workstation) which actually worked well, but won't be available for you and me until 12/04 (maybe). The 3D module of Centricity itself is a joke. I had heard something about a software port of AW to the Centricity platform, but all they had was an old AW package that didn't work too well. Underlying architecture is NOT web-based in the individual URL sense. They do however use centralized database structure, though it is two-tiered. Still should be functional and expandible. They do use UNIX in the central components...may be good or may be bad depending on your point of view. Personally, I still have some love for UNIX; I can't get it to crash anywhere near as often as I can Windows of any flavor. The General has acquired a reputation for running roughshod over us users about price. One big rumor abounds concerning a big academic install where GE was yanked out in the middle of the process and Siemens brought in. I had the opportunity to talk to one of the principals, and the truth apparently is that GE upped its price by several million and the institution decided to go with a cheaper alternative. I don't know if the institution changed its requirements or some such thing in the middle of the negotiations. I am anxiously awaiting comments from my GE reps....

Philips: Fairly good front end, most of the bells and whistles are included. I don't think they are web-based. Most of their main components appear to be from Sectra.

Siemens: Good client, but elderly architecture due for complete replacement in18-24 months.
Obviously, I didn't get to every last vendor. Please, please, please everyone, fill in the gaps and tell us what YOU think!

In the beginning.....

This was the post on AuntMinnie.com that started a war with ScImage and an Internet presence:


In a word, HELP! Our department was one of the first in the US to go filmless, umpteen years ago, using AGFA. Today, we are one of the last two departments in the WORLD still using AFGA 3.5. Our hospital didn't like the idea of a $2 million upgrade to AGFA 4.5. In the last 60 days, we have brought a 16-slice CT on-line at our main site, with 2 more to come. We also began reading 16-slice CT studies from an outside clinic. Needless to say, AGFA 3.5 chokes on these scans. It cannot handle the vast number of images in a timely manner. In addition, comparing a new scan to an old study with different slice thickness is an exercise in agony, as AGFA will not track the z-axis. We have been using a demonstation system from a small West Coast company to read the studies from the new scanners. (E-mail me if you really want to know which company....) In truth, we are beta-testing the system. There are numerous bugs, though to their credit the company will fix them within a day or two of their report. The system uses a lot of Java programming, and probably a lot of simple HTML as well for a web-based approach. The patient selection page is very cumbersome to use, but they have written a shell program to buffer this, and it is an improvement. The standard reading module is acceptable, with the usual buttons, and the obligatory right-click menu. The real selling point of this little system is its 3D module. We use the MPR portion of this component to read our 16-slice CT's. The program has adjustable slice/slab thickness for the MPR's, and the images appear to be MIPs...I'm not sure if they are really MIPped or if this is a perception from the slice thickness. One can "swim" through the MPRS as fast as you can move the mouse; the recon appears to be VERY rapid on a 3 GHz P4. The MPR module is still buggy, and is not integrated with the viewer. I can find a lung nodule fairly easily with the MPR, but then I have to wade through the source images to find the slice number to report for followup. The MPR module also has a backwards approach to triangulation; clicking on the lesion does NOT localize it on the other planes, but simply enables the plane you have clicked to scroll. I am one of the radiologists who has to use whatever equipment we buy for the next Gawd-knows-how-many years. I have some computer training (BSEE), and I see lots of bugs, shortcuts, and other danger signs in the small company's product. Not to air dirty laundry, but I find myself at odds with my colleagues about this. They love the (flawed) MPR, and they perceive the system to be cheaper than the big name stuff. They are impressed by the fact that the software gets rewritten for us all the time. (To me, this is like buying a Mercedes with a new, untested engine. Sure, the dealer will tweak it and redesign it and replace it when it misbehaves, but is this a way to function day in and day out?) So, my Forum friends.... 1. Is there a reliable system out there that combines all the necessary PACS elements with an integrated 3D/MPR program, AND z-axis matching to allow comparing old and new CT's? Might it possbly be reasonably priced? 2. How hesitant (or adamant) should I be about the small company product? Has anyone had good luck with this scenario? What happens if Mr. Small gets bought out by GE? Many Thanks!!!