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.