PACS:
1. n. (acronym) Picture Archiving and Communications System.
A device or group of devices and associated network components designed to store and retrieve medical images.
2. n. (acronym) Pain And Constant Suffering.
Tuesday, July 17, 2007
Friday, July 13, 2007
OOPS, I Did It Again....
Dalai's Laws of PACS Published!
I'm published again! Auntminnie.com has graciously posted a revised and expanded version of Dalai's Laws of PACS, accessible here. I guess it was a slow news-day.
I'm waiting for the, um, comments from my friends in IT.
Tuesday, July 10, 2007
Teleradiology Spam
Hi,
TeleDiagnosys is a premier provider of offsite Teleradiology/Nighthawk Reporting Services from American Board Certified radiologists.
If you are a Imaging Center / Hospital - We can provide you with STAT and Routine reports 24 X 7 leading to cost reduction.
If you are a radiology group - We can take care of any additional / overflow work that you cannot handle, increasing your productivity
Our advantages -
1) Attractive Pricing - USD 8 for X Ray, USD 35 for CT and USD 45 for MR
2) Reporting by American board certified radiologists with State licenses and malpractice insurance
3) 24 X 7 X 365 coverage
4) Turnaround time of 30 mins for STAT and 12 - 24 hours for routine studies
5) Fully transcribed reports in required formats can be emailed/faxed at no extra cost
6) US telephone number for emergency calls
7) No minimum guarantees, No Setup fees
8) No PACS to send images??? We can provide you with a complete solution
More details are available on our website - http://www.telediagnosys.com
In case you need any more information including references or trials please contact me on dhawad@telediagnosys.com or US Toll Free 800-490-0509.
With Best Regards,
Dr Ashish Dhawad
Chief Operating Officer
Telediagnosys Pvt Ltd
US Tel no: 800-490-0509
US Fax no: 703-991-1426
Email: dhawad@telediagnosys.com
URL: http://www.telediagnosys.com/
I went to the website earlier this morning, and it was quite nicely done, with Adobe Flash titles and the like. However, this afternoon, I find the website is down, perhaps due to much traffic or angry complaints spawned by the spam email advertisement. But, the Google-cached version tells us:
TeleDiagnosys Services Pvt. Ltd. is India's pioneering and premier provider of offsite Teleradiology Reporting Services from experienced and eminent doctors with fast turnaround times. We partner with diagnostic centers, individual radiologists, hospitals, medical groups and other entities requiring remote, off-site reading of diagnostic imaging studies. Using a comprehensive approach, we provide the expertise to configure, install and maintain the digital technology necessary to implement remote reading of imaging studies. We also link our clients with well-qualified & well-trained radiologists who are available to provide remote reading and interpretation services. We have the necessary infrastructure and expertise available to provide round the clock, reliable and efficient service to our clients.
I had thought this sort of thing had not caught on in the US, but in looking around the web, there are dozens of companies in India offering similar telerad services. Most claim to use Board Certified U.S. trained radiologists. Perhaps they do. Rather hard to prove from here, isn't it? Does anyone really know who is on the other end of their teleradiology or night-hawk service? Have you actually met any of them?
No matter. What these companies are selling is cheap, available radiology. Whether all of their readers are rads from Haavaard, or if they are all students at the Bangalore High School for Health Sciences, what attracts their US users is mainly the cost savings. I can tell you that Telediagnosys' prices are lower than many out there, and if you look around, you can do even better.
I don't know about you, but to me, this lowest-bidder concept of Radiology is not a particularly comforting thought. Would you base your choice of a surgeon on who will cut on you for the lowest price? Well, as it turns out, lots of folks would do exactly that. There is a new trend of "medical tourism" that inspires those who cannot afford treatment here in the US to go abroad, often to India. This article from the Providence (RI) Journal tells the story:
The first such travelers were looking for cut-rate cosmetic surgery. But today, many include people seeking necessary procedures, including heart bypasses, hip and knee replacements, cancer treatment and dental work. They are finding clean, well-equipped, even luxurious hospitals that meet accreditation standards and often are staffed by American-trained doctors. Catering to an international clientele, they provide procedures at roughly one-tenth to one-quarter of the cost in an American hospital.
Ouch. American medicine has somehow priced itself out of the market. Where did we go wrong? I have to think it is some combination of greed and fear, relinquishing control of what is still (but just barely) the best health-care system in the world to the government, and to third-party payers. The greed factor is obvious, when one looks at self-referral, and I won't bore you with that discussion again. Fear of loss of revenue is certainly a similar emotion that has driven costs up, and led physicians into areas not their own, such as (surprise) imaging, which leads to self-referral. I'm not certain if the government or the insurance company, or the uneasy symbiosis we all share with them has driven the whole system off the edge. What I do know is that costs are exploding, and if we don't fix it, our friends in Washington and Bangalore will do it for us.
Even as a physician, I'm not immune to the ravages of costly medical care. My son just had some diagnostic procedures (EGD, colonoscopy, small-bowel follow-through) for which the hospital bill alone (haven't got the physician's bills yet) was $10,000. Since his doc is in another state, and out of our insurance company's little local network, I might just have to eat that cost. I would not have taken him to India, but for someone who had no good choice, spending, say, $3000, including the trip to India and a little sight-seeing, would have been a very viable alternative.
All of us involved in the U.S. Healthcare field have to do something about this stuff, and quickly. Otherwise, Hillary-Care AND Bangalore General are going to be our future. Namaste!
Thursday, July 05, 2007
Is Speech Recognition a Kickback???
Image credit: http://www.jd-associates.com.au/author/garrydisher
I wish I had come up with this myself, but instead, this comes from one of the many brilliant folks that peruse this blog and otherwise correspond with yours truly. My colleague has suffered through a forced implementation of SR, and notes the following:
Do you know if anyone has ever tried to construe the adoption of voice recognition technology as a kickback to the hospital in violation of federal antikickback statutes? It would seem to me that transcription services are traditionally provided for free by the hospital to hospital-based physicians (except of course the cardiologists and administrators don’t have to use it!) and that the cost of transcription is covered by the technical fee collected by the hospital. In essence we are providing free services to the hospital in return for a hospital contract. I wonder what the lawyers would say.
So do I.
Wednesday, June 27, 2007
The Inmates Are Running The Asylum
I have stolen my title from a book of the same name by one Alan Cooper. Mr. Cooper is Founder and Chairman of the Board of the Cooper company, which is devoted to leading-edge, customer/user oriented product and software design. From the company website:
For over 30 years Alan Cooper has been a pioneer of the modern computing era. His groundbreaking work in software invention, design and construction has influenced a generation of programmers and business people—and helped a generation of users. Alan is the author of two best-selling books, About Face: The Essentials of User Interface Design and The Inmates Are Running the Asylum, and his visionary ideas and outspoken style make him a popular speaker. Whether you know him as the "Father of Visual Basic," the inventor of personas, or the guy who thinks software should be spanked, we know him as the man whose ideas are the foundation of what we do.
Mr. Cooper has a rather radical outlook on software and indeed other high tech offerings. From his "Inmates" book:
No matter how early in the development process specifications are drafted, they cannot substitute for interaction design. And no matter how hard they try, programmers cannot consistently arrive at a successful design. Not only are their methods, training, and aptitude wrong for the job, but they are caught in a strong conflict of interest between serving the user's needs and making their programming job easier. Yet, in company after company, software engineers are allowed to control the development process, often from start to finish. Sometimes, their control is overt, but more typically it is indirect.
Hence, the inmates (the programmers...no offense!) are running the asylum. This is more or less what yours truly has been saying for a while in reference to PACS. The vendors are allowing their engineers and programmers to create technological magnum opuses which allow too many permutations, and ultimately get in the way of my reading my studies. Why is this tolerated? Cooper compares this to a dancing bear: we are all so impressed with the fact that bear is dancing at all, that we fail to observe just how badly it is choreographed.
So few software-based products have exhibited any real dancing ability that most people are honestly unaware that things could be better-a lot better. Most people using spreadsheets and word processors on modern computers imagine that all the problems that a computer can solve have been solved, and solved adequately if not well...Bill Gates once observed, with uncharacteristic cynicism, that the way you made software user friendly was by making a rubber stamp and stamping each box with the legend "USER FRIENDLY." Unintentionally, his method has become the computer industry's real method.
Mr. Cooper's premier design company will help one create a software product (or hardware, for that matter) that does not suffer from these maladies. The company motto is: "Companies are more successful when their products help users achieve their goals." Accomplishing this gargantuan task takes several steps, including Planning, Research, Modeling, Requirements, Framework, Refinement, and Support. Of these, modeling may be the most characteristic of Cooper's contributions.
Are you frustrated by trying to develop a product that serves thousands--or even millions--of different users? Imagine if instead of trying to please everyone, you could design for three distinct people you knew very well. Wouldn't that make your job easier?
This is the power of personas, a technique for modeling users that we invented here at Cooper. As we interview and observe users in their natural habitats, we look for patterns of behavior and goals shared by multiple people. Each distinct behavior pattern becomes the basis for a persona: a description of an archetypal user.
Personas help everyone from programmers to executives understand users in a way no other tool can: at a gut level. Personas help guide design decisions, end those lengthy arguments about what users need, and get everyone to agree on what product you're building.
You don't need an enormous project to enjoy the benefits of personas. For short projects, personas may just be quick sketches based on limited data. For large initiatives with distributed teams, a well-researched and thoroughly documented set of personas can be an essential reference and communication tool.
In an article about Cooper, Allison J. Head further describes this process:
The gist of Cooper's argument is fairly straightforward: There will be far greater success designing an interface that meets the goals of one specific person, instead of trying to design for the various needs of many. At first blush, though, it may seem downright counterintuitive to design for just one person, whether hypothetical or not. How can designing for a single soul possibly ensure an interface that supports the needs of many users? But as an interface becomes more layered and complex and tries to serve an ever-widening audience base, Cooper's argument holds true.
As long as personas are developed with diligence, the planning and development tool has three key benefits for interface design projects of all kinds. First, personas introduce teams to hypothetical users who have names, personal traits, and habits that in a relatively short time become believable constructs for honing design specifications. Second, personas are stand-ins with archetypal characteristics that represent a much larger group of users. Third, personas give design teams a strong sense of what users' goals are and what an interface needs to fulfill them.
She goes on to describe what may happen if programmers and designers don't user personas:
One of the best arguments for using personas comes from some misguided design efforts at Microsoft. When the software giant geared up to redesign its well-known Microsoft Office Suite for a 1997 release, the research team soon discovered that many of the features users wanted already existed. In fact, four out of five of the features users requested for Office 97 came with Office 95. The outcome of Microsoft's design approach is just what Cooper warns against. In trying to support the diverse tasks of many conceivably different software users, Microsoft cobbled together a product that was bloated with capabilities and ended up satisfying few users.
I think most would agree. I am reminded of some PACS systems I have used....
Anyway, how might this approach be used to create a PACS? Can we assemble a "Joe Radiologist" persona that would cover most radiologists? Well, let's see.... What do radiologists do all day with respect to PACS? We sit in front of the darn things and read studies. That pretty much is all we do, except for the interventional types and the barium-slingers. The real question is how Joe Radiologist wants to interface with his PACS. That is indeed the question. If I were taking this approach, I would talk with all of my partners, and ask them what they like and what they don't like about the PACS systems we already use. In fact, I would post the question here on the blog, and open it up to as many rads as possible. I would then synthesize and distill this wide pool of answers down to a usable persona.
The key to this process is, I believe, to drop all preconceived notions, but not to forget lessons learned. If you are going to build a PACS (or a car, or a toilet-paper holder) you would like to make it usable, and comfortable. There should be adequate features to cover at least 95% of situations that will arise (easy with toilet-paper holders, harder with cars, easier than some think with PACS.) Many products out there are obsessed with how to handle something that Joe Radiologist might have to do once a week, or once a month, and pay little attention to the repetitive grind that makes up 95% of our work. And many vendors are stuck in the rut of doing things the same way, version after version. Therefore, it is critical to see how a wide swath of your potential customers would use your product, and it is very important to understand how they work with your competitors' versions of the same thing. When Saab designs a new car, for example, it is probably wise to determine if the 99% of the world that buys cars other than Saab's would appreciate having the ignition key on the center console, which is where Saab (and no one else) puts it. If you are a PACS company, it is probably not terribly wise to gear your Joe Radiologist persona to those who are mostly users of your PACS, and then proceed to come up with the next generation of a PACS with its ignition key on the center console. I should also add that real radiologists need to be reintroduced to the process; don't go with the stereotyped "Joe" for a prolonged period without a reality-check from the flesh-and-blood version. Trust me, if these caveats to the Cooper approach are discarded, the result will not be what "Joe Radiologist" wants at all.
One of my partners told me in all seriousness that I should create my own PACS system. I wish I had the time and the wherewithall to do so. Of course, out of vanity, my persona would be used instead of "Joe's" which would naturally yield the most wonderful system ever. Absolutely. Guaranteed.
Tuesday, June 26, 2007
40,000 Hits and Repeat Customers
Image Credit: http://www.scifi.com
This is a first, folks! I think Visitor 40,000 happens to have been number 20,000 as well. I'm assuming that there aren't too many folks in Montevideo, Uruguay who peruse this stuff, so I'm thinking this represents another visit from Rafael Sanguinetti of www.charruasoft.com. Thanks for your support!
Monday, June 25, 2007
A Survivor Of Voice/Speech Recognition Speaks Out
I will start by telling of our voice recognition (VR) experience.
About one and a half years ago we launched VR to our hospital system. It was an integrated “front end” VR product that resided on our PACS workstations. You may or may not have preconceived ideas about what quality we might have purchased, suffice it to say we purchased what for all intents and purposes, seemed to be the best VR product on the market. No we didn’t buy some outdated piece of garbage.
It was a planned 6-week launch with training provided primarily by the VR company. Initially, we were expecting things to be a little stormy; how wrong we were. First, we had scheduling problems with training, there were rads that were unavailable for training and the amount of time dedicated to each rad was short, only a few hours. In addition, the rads were learning while still having to attend to some clinical duties, which was a BIG MISTAKE.
So after a few weeks, the trainers left, there were still rads that had almost zero actual training. Our IT/IS support staff tried to help out as much as possible. It was just over a month when things in the department finally caved in. We were chronically short staffed, radiologist wise, and work wasn’t being finished. Those of us who took to VR somewhat well were being completely overrun by those who did not, both in having to field multiple near hysterical calls and a markedly increased workload. There were multiple unexplained system crashes (denied initially but fixed somewhat in a later patch) and a greatly degraded workstation performance.
We had numerous direct meeting between the administration, radiologists, and VR company. Here is what we got, repeated requests for the radiologists to document every occurrence of problems (yeah, right, like we weren’t totally swamped as it was what’s one more thing to do), repeated denials of their software being to blame for workstation slowness and crashes (of course later we would learn that yes it was their software causing crashes and system performance issues), repeated promises to fix the problems.
After almost 2 months of this I, being the “radiologist champion” for VR and about 2 seconds from a complete nervous breakdown, told myself “Either I stop using VR or I hand in my 90 day notice and look for a new job”. I turned off the VR product and told my fellow radiologists that I would no longer be fielding their questions about “how to make VR work”. The rest of the group followed suit immediately. It imploded over night. Problems that still existed at this time were:
1) Random crashed requiring a system reboot
2) Unexplained, or rather un-admitted, slowness of the workstation
3) Consistent patterns of errors in VR, it did not appear to be learning no matter how many times corrected
4) Almost no one in the department (IT/IS included) really knew how to use the advanced functions, macro generation was “trial and error”
5) Lack of advanced support, many question to our IS/IT people generated a response “I’ll send and email to VR company and see what they say”
6) Many errors sent for “transcriptionist editing” came back uncorrected, the error rate of “transcritpionist editing” was far greater than the old system. Many report errors escaped the radiologist review as well and went out finalized. Many, many months later I would learn we had some actual “transcriptionist sabotage” going on and this was NEVER disclosed to the radiologists.
7) A horrific loss of productivity in an already short staffed group.
It died for a long time; of course the hospital had a vested interest in making this work.
We recently had a visit to a “model group” for VR and got to see them in action. The model group watched us and decided to purchase the product anyway. They are a large group; they owned the transcription, PACS, and other things and “contracted” these things out to hospitals. This was a business decision by a group that owned the entire infrastructure. They did things very differently and claim a 90+% “sign off” rate. Here is what we observed and were told:
They began by sending their IT folks to the VR company for intensive training. They refused the VR company's offer to do radiologist training; they were going to handle that all in house. Prior to launch their entire IT/IS support staff had been using the product for “months” and were fluent in its use. This was before a radiologist touched it. After launch they had their trainers go back for additional training to learn to “hack” the word lexicon to overcome pattern of repeated errors. This has worked very well for them and is a process discouraged by the VR company. What we learned, to our dismay, was that VR was not just “appearing” to not learn certain repeated phrases or words, it REALLY WASN’T learning them at all, no matter how many times we made corrections manually. The "model group" placed skilled VR support staff available 24/7, to immediately respond and deal with radiologist problems with VR.
They began by doing a “staged” launch of VR, starting with sections and working 1 section at a time. Each radiologists was initially afforded a full half day of one-on-one training with no clinical duties (no phone calls, no tech interruptions, no exams needing to be read, NOTHING); after that they each received 3 full days of one-on-one training while working (they estimated a total of 24-28 training work hours for each rad). By one on one they mean the trainer was physically in the same room or sitting outside the radiologists door. They had section meetings every morning to discuss VR’s use and share tips; they relied on a lot of “peer pressure” to make things go smoothly. The entire launch was slated to take about 1 year.
The made sure their workstation greatly exceeded the VR companies recommendations. They made sure their transcriptionists were folded into other duties as they lost their need for so many of them. I would add here that prior to VR this groups report turn around was poor, over 2 days for routine stuff.
We were also told the group was now considering “financially penalizing” rads that are using too much transcriptionist editing, this was not implemented yet and the penalties they were considering was not shared with us.
We then got to observe some rads in action. It really wasn’t magic. First, they have employed radiology “assistants”. These folks do a lot of the “scut work”, phone calls and so on; they basically make sure the radiologists are not disturbed and the hospital pays for them. One rad was a “macro master” although he appeared to spend much more time looking at the VR than the exam. One rad absolutely hated the VR system, so all is not roses at this model group. The next few rads showed all the problems we have seen all along, lots of little annoying errors. Every rad admitted it slowed them down but they had “made up” for it through intense training, heavy assistant use, awesome IS support staff and excellent equipment. They did feel, well, most of them, that it was “worth it” for various reasons.
They did confirm many things we radiologists already knew. Things like the software’s inability to learn certain works on its own, or rather the pattern of making repeated patterns of errors. The VR company’s gross underestimation of the training needed and IS support staff needs. The performance issues on the VR companies “recommended” systems. Basically this is something the radiologists need to “buy into”. They did admit to the limitations of VR but that it is improving and “As long as the radiologists see continual improvement they will stick with it”. They also, on their own, identified and developed work-arounds for many conflicts the software was having with other office software products.
Where do we go from here? A few in my group had prior experiences with VR, all universally negative. I had a hope, as did the administration, that “This is such a superior product, it will be different this time”. It was very disappointing to see not only every fear confirmed, but also some new ones learned. Any trust between the VR company and the radiologists has been completely destroyed beyond repair. This experience has certainly made us much more cautious in trusting the word of any vendor, especially software vendors as I feel they may not fully grasp that they are selling a medical product and not a video game (i.e. doctors have zero tolerance for “buggy” software and more than they would tolerate a “buggy” CT scanner). So it stands with my group, many of whom now have the well justified attitude of “Hell will freeze over before I turn on VR again”. I am not sure this can ever be turned around. I hope, if nothing else, this review serves as a warning, to radiologists, administrators and most importantly VR vendors that VR is not something to be taken on lightly.
In a similar vein to Dalai Lama here are my 10 commandments for VR:
1) Voice recognition (VR) exists as only one of multiple possible solutions to address the problem of radiology report turn around time. The underlying problem being the near instantaneous distribution of images through PACS unaccompanied by the radiologist report.
2) VR will only see its maximum benefit (i.e. near instantaneous report generation) IF the radiologists self edit and sign off the majority of reports.
3) VR with or without self editing slows radiologists down. It costs productivity as radiologists are now forced to spend additional time either self editing or reviewing the VR generated reports for errors. Do not assume your radiologists are going to quietly eat this productivity loss.
4) The loss of radiologist productivity can be compensated, to some degree, by the use of radiologist assistants to do some tasks formerly done by the radiologist. Also there is a gain by the lessened need to re-review cases that have been dictated but not transcribed. Despite this there may still be a long term net productivity loss. Again, do not assume your radiologists are going to quietly eat this productivity loss.
5) Poor system performance is a guaranteed PACS/VR killer.
6) VR and PACS are by definition “beta” software. There is no such thing as a perfect PACS or VR software; there are only “acceptable” performance parameters that will improve over time. VR may never be perfect.
7) The hospital shall accept it’s responsibility for supporting VR by ensuring it’s IT/IS support staff are well versed in PACS and VR and available as long as the radiologist are working. The IS/IT support staff shall have a full working knowledge of VR and be capable of training radiologists before a radiologist ever touches the software.
8) VR requires far more IT/IS/training support that the VR companies will admit.
9) VR is not a big money saver if properly implemented. Any savings from transcriptionists will be quickly eaten up by the need for hardware upgrades, software upgrades, training and the needs for additional support staff.
10) Before implementing VR, ask yourself “Am I doing this for the right reasons and am I willing to commit additional resources, possible indefinitely, to the proper launching and support of VR?”
Friday, June 22, 2007
PACS Abuse
An observant AuntMinnie poster found this lovely little item from the Cleveland Clinic:
Sub-specialized medical care is the standard of care today. Only an orthopaedic surgeon would perform an anterior cruciate ligament reconstruction, and only a neurosurgeon would remove a brain tumor. It is still common however, for general radiologists with no sub-specialized training to interpret the images that lead to these procedures.
This lack of sub-specialized radiology interpretations previously was necessary because of the need to have a radiologist in close proximity to the imaging center where procedures were performed. Now, through the use of new developments in information technology systems, Cleveland Clinic’s Department of e-Radiology offers sub-specialized radiology interpretations to referring physicians anywhere in the country. Better quality of medicine is possible through the use of interpretations and protocols developed and performed by Cleveland Clinic sub-specialty-trained academic radiologists.
A number of factors made growth in e-Radiology possible, most notably the imaging explosion of the past few years, which is expected to grow at the rate of 8% to 10% per year into the foreseeable future. Two additional factors are the national shortage of radiologists and the rapid developments in information technology that have allowed image interpretation to occur independent of geographical restrictions.
A large portion of the imaging growth is in outpatient imaging, with an estimated half billion outpatient imaging examinations projected to be performed in 2008. In 2002, 84% of magnetic resonance, 64% of computed tomography and 98% of positron emission tomography scans were done on an outpatient basis, and these percentages are expected to continue to increase over the next ten years. Only 67% of imaging is currently done in hospitals, down from 95% in 1980. Outpatient imaging accounted for $14.8 billion in Medicare revenue for hospitals in 2001 and generated $3 billion in profits.
Radiologist shortages have been significantly resolved through the use of teleradiology. Over the past few years, dramatic advances in information technology and the availability of technology in cost-effective pricing, high-speed telecommunication lines have removed almost all geographic restrictions in interpreting images. It is now possible to send digital images securely over the Internet on a virtually real-time basis to radiologists located anywhere such telecommunication lines exist. The radiologist is then able to dictate the images using voice recognition software so that the images and report are available online for the referring physician within minutes via a HIPAA-compliant Web browser.
Monday, June 18, 2007
Stupid Pet, I Mean PACS Tricks
Image credit: http://www.skateboardingbulldog.com
It's amazing that a little glitch can cause a big pain. What's even more amusing is the fact that this particular glitch is shared by Impax 6.x and GE Centricity 2.x.
Here's the scenario...I'm looking at a CT, cine'ing through the slices. I want to change window settings, say from a mediastinal window to a bone window. Shouldn't be a problem, especially if I have the window/level preset to a keyboard shortcut. BUT...sometimes, only the slice that is on the screen will have the parameters changed, with all other slices remaining at the original level. And just why does this happen only sometimes?
Our Agfa PACS-admin actually figured this one out, and it turns out to be the explanation for Centricity's bad behaviour as well. If you did nothing else to the scan other than change with W/L settings, there is no problem, and such changes apply to all slices. However, if you happened to stop and measure something, then all bets are off. In their infinite wisdom, the programmers decided that a measurement should only apply to the slice on the screen. That makes sense, I guess, but their solution was to switch the tool application mode (my term, but it works) from applying a change to all slices to applying it to just one. And, it doesn't return to the "all slice" mode when you go back to the window/level control. This makes me do it, which as a lazy slug, I resent, and I don't even realize that I have to make this change until I'm flipping through the images and see one slice at lung windows and the rest at a different setting altogether.
I have to throw in one more little trick from Impax. At the bottom of the viewer, if you right-click on an UNMARKED point (even my Agfa PACS-Admin didn't know about this tool), you get a little sub-menu with three selections. The first is a limited history, which will bring up a list of the last 20 studies that were marked as Dictated. (This, of course, doesn't help if you lost something that was marked "Dictation started".) The second entry on this secret menu allows one to auto hide the toolbars, which I have never seen anyone use. The final entry, "Show Navigation Toolbar at the top of the screen" does just that. Sadly, there is a significant lag in the activation of any of the items, and the grouping is unintuitive enough that when I go after the history, I accidentally hit the "Show Toolbar at top" as often as not. I don't want the toolbar up there, and worse yet, it often disrupts the position of the other buttons at the top of the viewer, requiring me to log off and back on again to fix it. Really fun trick, guys.
How did we get these stupid PACS tricks? I will guarantee you that the developers didn't demo or test these options in an actual production environment. I'm sure these functions made perfect sense on paper, but they yield yet another hinderance to my workflow, out here in the real world of private practice.
Would you guys at GE and Agfa mind fixing this stuff, please?
Sunday, June 10, 2007
TWO $1000 Mikes Disabled By 3mm Piece of Plastic...
A bit of bad design
Our suburban hospital just replaced their antiquated tank with the modern, computer-based Fusion dictation system from Dolbey. This is a digital voice system, but it does NOT include speech recognition, thank Heavens.
I got there today to read out the weekend carnage, and what do I find? The laser barcode scanner on the microphone isn't working right. This microphone is a nice little piece of equipment, a Philips SpeechMike classic with barcode reader, which retails for over $1000. I asked the director of the department if we had another one, and yes, we did, but that one had a malfunctioning barcode reader as well. I peeked inside the little red window, and activated the laser scanner...yes, really bad idea for someone who makes a living with his eyes! I could see the laser, but it appeared to be hitting above the top of the window, and not getting out to scan the barcode. There is a tiny adjustment knob at one side, and this was a little loose, and didn't seem to change anything inside.
The Fusion system depends on barcoding at the moment; when we get this site on PACS later this year, the demographics should download from PACS automatically. Still, that is several months away. So, I could either figure out what was wrong, key in the accession numbers manually (by using the tiny trackball on the mike to select numbers on the on-screen keypad), or I could just do one long dictation, reading off the accession numbers and hoping for the best.
Being a tinkerer at heart, and having total disregard for warranty voidance, I took screwdriver in hand and disassembled the offending mike. Inside the bottom, pictured below, you can see the red window to the left, and a mirror to the right.
The next image is a little blurry (sorry, my phone doesn't have good macro capability!) but it tells the whole story. The black box at the top of the microphone is the laser assembly. The black bar-like thing next to the red crayon is a black diffuser, which is used to direct the beam a bit so you can hold the mike more naturally. It is supposed to sit atop the laser. But the little tiny black C-shaped thing between the two is one of two tiny brackets that holds the diffuser in place and allows the little knob thing to ratchet it and hold it in place. The problem is, this tiny $.001 piece of plastic broke right off of its base (the roughly triangular thing to the left at the top of the laser housing), and rendered the whole assembly useless. Bad design. Really bad design.
Being too lazy to do anything else, I simply left the back off of the mike, and used the microswitch that is at my thumb as seen below to activate the laser. It is a little bright, and must be pointed perpendicular to the barcode, but it works. Of course, normally the microswitch would be keyed by a plastic trigger in the base. Notice the high-tech rubber band that keeps the cord from detaching. Nothing like the feel of bare circuit board in your hands...
Saturday, June 09, 2007
You Knew Dalai Was Strange...
But this really takes the cake!
A few years ago, when my son was a Cub Scout, our troop held an annual "Dad and Scout" cake contest. The only rules were that moms were not allowed to help, and that all components must be edible (by normal people). My son and I decided to take a rather medical bent, although some would call it macabre. Thus was born the idea of the Scout Patient Cake. The cake itself is red-velvet, nicely simulating tissue. The brain and heart are composed of....marzipan! Yes, Dalai's brain is made of almond paste... The lips are of the classic wax variety, the eyeballs are strips of white "AirHeads" taffy rolled into balls and adorned with frosting. Large vessels are made of strawberry licorice, and coronaries are drawn in with liquid frosting. Now the hospital blue cover was by far the hardest part of this project. This was made from fondant, a thick frosting-like material that you usually see in cakes more like this one from Krista's Creations:
That darn stuff is very hard to work with, which is probably why the cake above goes for $300. I have a feeling ours would not command that price.
Back to the Cub Scouts... prizes were awarded in various categories. Our cake took second place overall. I think perhaps the judges were afraid to award us anything less.
You'll be glad to know that even though the cake went down the dispose-all years ago, I saved the brain and the heart in the freezer, where they remain to this day. You never know when you might need one, right?
Sunday, June 03, 2007
A-Wristing Technology
...but do they tell time??
We all remember the comic strip "Dick Tracy" wherein the razor-nosed detective wore on his wrist first a walkie-talkie, and in later years a video-phone. I don't know about you, but I really wanted one of these when I was a kid, and nothing much has changed.
Well, actually, something has changed...technology has caught up with fiction, and there are some expensive toys available that do approach this level of sophistication.
First, there is was a watch marketed as a "Dick Tracy" special, made by Fossil:
This little $200 gem uses the MSN Direct network, a subscription wireless service that sends accurate time to the watch, as well as sports scores, stock prices, news, etc. The downside here is that the service is expensive (~$10/month), and there is no uplink back to the Internet. I'm not sure if it's still available.
If you don't want to communicate, but do want the joys of watching videos and hearing MP3's on your watch, then this latest series of watches from China might be up your alley. (My son is considering squandering some of his allowance on one of these, and if he does, I'll let you know how he likes it.) Below is a photo from http://www.chinavision.com of this rather large contraption...it's almost a video iPod with a wrist strap:
These things are only $50-$100 or so, depending on how much memory you purchase with them (they are currently available with up to 4Gb of RAM!)
The Holy Grail of wrist machines is, of course, a real wrist cell-phone, and there is finally one for sale to the masses, although the masses would need to cough up $1000 Australian (about $850 US.) This feature-packed M500 comes from SMS Technology Australia, http://www.mymobilewatch.com:Look at these specs:
Model M500 Quad Mode, Touchscreen, Java and WAP enabled
Weight: 60g
Color: Silver or Black with Leather Strap
Screen: TFT 1.5 - inch colour touchsreen 120 x 160
Frequency: GSM850/900/1800/1900Mhz (GPRS), SIM
SMS: Full SMS and MMS functionality
MP3: Support AAC/MP3
MP4: Support Video Playing
Touchscreen with Built-in Stylus
Memory: 128MB Built-in Memory
Battery: 400mAh, Talk Time 200 Minutes, Standby Time 80 Hours
USB: For Data Transfer and Recharging
Bluetooth 2.0
This thing should work on any GSM network, including AT&T. The only downside (besides the rather outrageous price) is that one must use a Bluetooth headset, but that isn't much of a limitation these days.
There is nothing like being on the bleeding edge, especially if you can afford it! And yes, if you were wondereing, all of these wrist-marvels do tell time....
Friday, June 01, 2007
PACS Pioneers
...and my brush with greatness
In researching another post, I ran across this article from Imaging Economics about the history of PACS. It is a very brief synopsis of the path to today's filmless world of Radiology. I won't try to summarize the summary, but suffice it to say that PACS (although they didn't call it that until fairly recently) had its start at several centers around the world, with the perseverance of a number of true visionaries. Probably the most important single milestone was the development of the DICOM standard which (at least in theory) allows scanners from Manufacturer A to communicate with viewers from Manufacturer B. Before DICOM, everyone had a proprietary code for everything, and the PACS pioneers actually had to reverse-engineer and decode tapes, which must have been just a load of fun.
My brief contact with the "Great Ones" of PACS occured in 1992, and it was the idea of a local businessman. This gentleman owned the storage facility in which we archived the zillions of films taken over the years. He had heard of the work Bernie Huang, PhD, was doing at UCSF, and decided to see it for himself. He was so impressed that he took a couple of us radiologists, and a hospital administrator out to see Dr. Huang.
In 1992, there was no such thing as the PACS we have today. Dr. Huang's operation consisted of what we might call today a couple of mini-PACS operations, without much standardization. There was a tape jukebox sitting in the middle of the lab, workstations here and there, digitizers, and whatnot everywhere. But Dr. Huang's vision was clear...this was the future, and film was not.
When we returned home from UCSF, our "patron" asked what we thought of the whole thing. I responded, "It's great, it's obviously where we are headed, but.... The hospital isn't going to buy, let alone be able to maintain, a system comprised of loose pieces of technology. Someone has to put it all in one box before it will become practical." I'm not sure if our friend agreed or not, but he never did approach us with any proposal.
A year later, we were in negotiations with Agfa for our first PACS, and we were on our way to becoming one of the first filmless departments in the country.
Wednesday, May 23, 2007
Empiric's Encompass.NET RIS...
...The Amicas of RIS's
You may recall from a very early post that I had originally planned no RIS for our Amicas PACS. We were going to use paper and PACSGear scanning software to simulate a RIS, if you will. However, we ultimately decided that this would be rather tedious, and would not allow us to do some of the things we have grown accustomed to doing, such as editing reports. So, we went in search of a RIS. We didn't need a big bad hospital system, but we did need something. Basically, there were two requirements: the RIS had to be very easy to use, and it had to be reasonably priced. We found the the ideal combination for our purposes in Empiric's Encompass.NET product. Functionally, it is straight-forward, and easy to use, and most importantly, it doesn't get in my way. That's why I call it the "Amicas of RIS's". Amicas probably doesn't like that title, because they have their own RIS. We looked at it, and it is a great product, but it was more powerful and more expensive than we really needed for our little operation.
Now, I don't want to leave you with the impression that Encompass is underpowered, because it isn't. It is streamlined, and its interface is rather spartan. (More on that in a moment.) It does, however, have everything we needed. From the Empiric web site:
Primary RIS Functions:
Patient registration and scheduling
Embedded digital dictation
Transcription
Electronic report signatures
Auto faxing (direct or by eFax.com)
Multi-site support
Audit trails
PDA capabilities
Management reporting
Mammography tracking
Document scanning
Inventory tracking
Paper-less consent forms
Radiologist peer review functions
Film library management
Additional staff and equipment management tools
PACS/Imaging Functions:
Web viewer w/auto study retrieval
Image routing & archive management
DICOM worklist
RIS-integrated workstation
Referring Physician Functions:
On-line study requests
On-line report access
On-line image access
Optional integrated EMR
Complete Billing Functions:
Claim generation
Payment posting
Collections management
Credit card co pay capture
On-line eligibility verification
Obviously, there is a lot to this system. We have it integrated nicely to our Amicas PACS, and the two play nicely together. Encompass does have its own viewer available, and it isn't bad, but we are much happier overall with the combination.
The best part of the RIS, as with Amicas PACS, is that it doesn't get in our way. It can provide reports viewable from within PACS, which the clinicians love (and so do we). We are really thrilled with the simplicity of reviewing and signing off of reports. We log in to the system (from anywhere, as this is a .NET web-accessed program), hit the "batch sign" button, and all of our pending reports are displayed. There is the option to edit them if necessary, which is a rare need given our incredible transcriptionists, and then they can all be signed with ONE CLICK! We use Cerner at our Agfa hospital, and Meditech at the other places we cover, and the concept of "ease of use" has obviously never been heard by their developers. But it is the backbone of Encompass.
Now, I mentioned the somewhat spartan nature of the Encompass.NET interface, and indeed, it isn't particularly fancy. But I do have the honor of announcing their next interface, with screenshot below, which will make its official debut at SIIM next month. Empiric hired a "prominent West Coast GUI design firm that specializes in ergonomics" to revamp the front end. Notice the "at a glance" concept that will instantly show the user the status of each patient and exam. It's prettier than the functional design they have today (screenshots of which can be seen at their website.)
If you are in the market for a RIS, and you aren't trying to outfit the entire Mayo Clinic, have a look at Encompass. My partners and I like it, and we're rather hard to please.....
Wednesday, May 16, 2007
Dalai Gets Trumped!
When Mark, my PACS guru, got hold of this thing, he went absolutely wild with glee, and proceeded to access our Amicas server, which turned out to be just as easy as on any other laptop. You can see the results above. Note the quarter on the screen placed for a size reference. With the size of the image displayed, you might think we were using a scanner like this one:
Rest assured, however, that these are real human images from a regular old MRI. (The little scanner, image courtesy of Craig Woody, BNL, actually is a minature PET detector used for animal research.)
The screen resolution of the FlipStart is adequate for reading digital modalities such as CT, MR, NM, US, etc. I don't think I would try to read CR, but it might be possible in a pinch. Especially for rat radiographs.
Rick's prize for winning Trump the Dalai? An extra night of call! Just kidding.....
Friday, May 11, 2007
New Trix From Impax 6
In the last few days, I noticed that my profile on Impax 6.2.1.135 had changed in subtle ways. Different worklists than those I had selected were displayed, there were different columns of information within those worklists. Some of my tools and display settings were not as I had left them.
I thought I was crazy, which is probably true anyway, but now, some of my partners are noticing the same thing! Our PACS people are looking into this, but I see only a few possibilities:
- Someone is getting in there and messing up the settings
- There is some problem with the communication between our three production servers, and settings are getting tweaked somehow in that process
- The data tables are becomming corrupted...seems to me things would have deteriorated a lot more if that were the case
- The damn thing is haunted
Personally, I'm voting for #4. I'll keep you informed.
Saturday, May 05, 2007
Speech Recognition...Again
. . . speech recognition technology eliminated "significant delays" in report transcription and typing issues, leading to an improvement in service to both clinicians and patients. Researchers at Hammersmith Hospital and Charing Cross Hospital also concluded that a well-planned organization-wide implementation of speech recognition technology "can have a dramatic impact on radiology service delivery. . ."
In 2004, emergency room and primary care reports took three to five days to complete at Hammersmith Hospital. Finished inpatient and outpatient reports ranged from a low of three days to as many as eight days for inpatient reports in August 2004. With the advent of speech recognition technology, the time from report generation to completion declined to one to two days from January 2005 to February 2006.
Saturday, April 28, 2007
Here Wii Go!
...A new pointing device for PACS?
There has been much discussion of how to point at your CT on the workstation. Most of us still use the venerable old mouse, while some have graduated to trackballs, joysticks, jog-shuttle dials, and even roller-mice.
An Italian college student by the name of Giorgio has come up with something new, that I think has great promise. Some of you have probably succumbed to your kids' pleadings for a new Nintendo Wii, which isn't all that expensive at around $200. The Wii's claim to fame is its entirely different approach to game control: the Wii-mote, consisting of a wand or nunchuck, and a little joystick control on another little pod:
You control the various games by moving the nunchuck in a natural manner. For example, hold it like a golf-club or a tennis racket and swing appropriately. A tiny accelerometer inside the nunchuck translates the motion into control signals for the Wii. Note the included wrist-strap designed to keep the nunchuck in your hand after a vicious slice, thus avoiding injury to yourself, others, and your TV.
Giorgio has hacked the Wii-mote and via a control system called GlovePIE, he has made it operate a CT display. Based on his video, he hasn't yet tried it on 3D renderings, MPR, etc, but that would be the next logical step.
Now can I get a Wii, Mom?
Wednesday, April 25, 2007
OOPS....We had a little downtime today...
Fortunately, I'm on vacation this week, and I didn't have to deal with the joys brought about by downtime. According to Dalai's First Law of PACS, "PACS IS the Radiology Department," and so when PACS is down, the department is down, and the patients can just cool their jets (or their hemorrhages, or whatever) until it's back. The good news is that the rads can go on a prolonged coffee break if there isn't any way to get back up again.
I don't know all the details at this point, but I do know that our newly-upgraded Impax 6.2.1.135 went down from 8AM until 10AM today. Not the best time for that to happen, if there is a good time. We are assured by our vendor, however, that the same problem will not occur again (any time soon, I assume). I find the whole situation sort of confusing, because we have three parallel production servers, and I don't really understand what took them all down at once. Maybe the Oracle is at it again?
Since the upgrade was fresh, no one thought there would be any problem of this magnitude this soon (about 52 hours after completion), and so the backup plan wasn't fully on-line. Now, we do have a test server, which was used during the upgrade itself, but I guess the scanners weren't still pointing to it. We actually had to use the venerable old (gasp) Web 1000 to get anything read during the dark age of the downtime. Fortunately, the servers where good old Web 1000 live haven't been wiped as yet; I think they are going to be converted to Impax 6 servers eventually.
Well, we survived, and we are stronger for it. Can't wait for the next episode of "As the PACS Turns (Off)".































