Dalai's PACS Reading Room

Note the revised Dalai! Xtra-Normal, the site I use for these inane animations, needs to get some new characters, but in the meantime, I'll work with what I've got. It's the dialogue that's important!

Strike Up The Band(width)!

When I first became active in the PACS world, I adopted a goal from my senior partner/mentor: "Sit here, read there". This was to apply to every site, every examination in our enterprise. Today, we have met that goal, both with our group-owned system, and with PACS provided by the hospitals. I can indeed sit at any site within our realm, and for that matter, at any broadband-connected computer, anywhere, and peek at any particular study that takes my fancy. When you think about it, that is quite an achievement.

All of this interconnection requires, well, a connection! That would be the various networks and portals into the Internet. As I have pointed out in a previous post, aptly titled Disconnected!, when the network is down, thus PACS is down, and therefore the whole department sits idle except for extreme emergency cases.

We are feeling the pressure of the network in another way. One of our hospitals has somewhat suboptimal internet connections to the outside world. We have tossed blame back and forth as to why their web-based PACS can be viewed but slowly at remote sites, and why our web-based PACS (both Amicas, by the way) crawls when viewed from within their walls. Trying to view the Agfa Impax of the other hospital system from within the problematic facility is just that, trying.

As yet, we have no good reason for this to be happening. The IT folks at the institution in question have switched us back and forth on various lines and channels, this one having no net-nanny or port-blocking, that one having X speed, another having yet more different parameters. All we know is that the situation is deteriorating rapidly, and we have to do something. To use the buzz-words that get everyone's attention, our ability to deliver health-care is being impaired, and this needs to be fixed.

At this point, our main option is to buy our own network. Our system lives in a neutral spot, external to all hospitals. We are on the brink of purchasing Metro Ethernet lines, also called MetroE's, with point-to-point access for our system. This would also give us direct, very rapid access to our own PACS, and should significantly improve the connection to the hospitals, at least we expect it to do so. At a cost of tens of thousands of dollars per year, we don't want to do this and see no benefits!

There might be one last option. Our state is participating in the Rural Health Care Pilot Program (RHCPP) which is designed to link under-served primarily rural hospitals with fiber optic broadband. The network-challenged hospital has apparently signed on to this initiative, and anticipates a great boost in service. However, I'm not sure we would qualify to participate:

Palmetto State Providers Network ($7.9 million)—This project will connect healthcare providers to a fiber optic backbone to enhance simulation training, remote intensive care unit monitoring, and medical education in South Carolina.

I suppose we could sign up to read from any rural hospitals that are properly equipped to transmit out to us. That would be a win-win situation.

In the meantime, we're about to spend a lot of cash for some local bandwidth. At least one part of the economy will be stimulated. . .

DoctorDalai.com On Kindle!

Vanity knows no bounds. In the old days, to make it to print, one had to have an agent, and probably some reasonable amount of talent. Or, for the truly desperate, there were "vanity publishers", who would for a large fee print up a hundred copies of your version of the Great American Novel.

Today, all it takes to be published is a computer, a Blogger.com account, and the foolish notion that someone else might want to read what you're writing. Which is where you, my beloved readers, come into the picture.

There are lots of options for access to this, my favorite blog. First and foremost, you can find me with your computer, right here at DoctorDalai.com. This applies as well to iPhones, iPod Touches, PocketPC's, and even the occasional Blackberry.

But hold on to your shorts, and let loose your wallet. Today, there comes a new option: The Amazon Kindle! For only $359, you can have a pencil-thin slab of 1500 books, or for $489, you can have a larger screen DX version with enough space to hold 3500 books! Of course, if you already have an iPhone, you can download the Kindle app which does a pretty good job of simulating the real thing.

The Kindle has wireless access (with no extra charge) that lets you download books, magazines, newspapers, and so on, for a fee, of course. And now, you can download blogs as well! Here's the teaser for mine:

There is just one catch: If you access DoctorDalai.com through your Kindle, it'll cost you $1.99 per month. Of course it's worth it, right?!

Spock With Sex Appeal?

Image courtesy of: http://lostdiscsradioshow.myfastforum.org/

Things are getting a little out of hand, in the opinion of yours truly, a Centrist/Conservative Trekkie.

I accept the fact that the media is very enamoured with our new President; they helped him get elected, after all, so they might as well hide any buyer's remorse they might have. But Newsweek's Jon Meacham has gone waaaaaay over the line. In an article reviewing a conversation he had with Mr. Obama, Meacham quoted the President as saying, "he saw the new Star Trek recently because 'everybody was saying I was Spock.'" Argggggh! Not Everyone! But the sacrilege goes further:

. . . (H)e appears resolved to keep playing the role—Spock with global sex appeal—that has gotten him this far.

OK, that's just. . . WRONG! Raise my taxes, cut my income, but don't mess with Star Trek! And besides, if you wanted Spock with sex appeal, look no further:

Super Google!

I remember when AOL's WebCrawler and AltaVista were the best of the best for searching the 'net. Then came Google, and the on-line world was never the same. Google today has a huge web-footprint, if you will, dominating the search engine business, and most every other area of the net it touches via ad-driven accessories. Why, this very blog is hosted by Google!

Google can find everything, it seems, but the one thing it cannot do is answer a question. That seems like a daunting task, but there is a new approach with a fine pedigree.

From the Times Online:

A revolutionary new search engine that computes answers rather than pointing to websites will be launched officially today amid heated talk that it could challenge the might of Google.

Wolfram Alpha, named after Stephen Wolfram, the British-born computer scientist and inventor behind the project, takes a query and uses computational power to crunch through huge databases.

The service can compute the distance between two cities, the population of a country at a specific date and the position of the Space Shuttle at a given moment. The user does not have to search through links provided by the engine; the answer comes immediately and, if appropriate, is accompanied by charts or graphs. What it does that Google, at the moment, cannot do is provide answers to questions that have not been answered already.

Wolframs stated goals are anything but modest:

WolframAlpha's long-term goal is to make all systematic knowledge immediately computable and accessible to everyone. We aim to collect and curate all objective data; implement every known model, method, and algorithm; and make it possible to compute whatever can be computed about anything. Our goal is to build on the achievements of science and other systematizations of knowledge to provide a single source that can be relied on by everyone for definitive answers to factual queries.

WolframAlpha aims to bring expert-level knowledge and capabilities to the broadest possible range of people—spanning all professions and education levels. Our goal is to accept completely free-form input, and to serve as a knowledge engine that generates powerful results and presents them with maximum clarity.

WolframAlpha is an ambitious, long-term intellectual endeavor that we intend will deliver increasing capabilities over the years and decades to come. With a world-class team and participation from top outside experts in countless fields, our goal is to create something that will stand as a major milestone of 21st century intellectual achievement.

Uh, yeah. ALL SYSTEMATIC KNOWLEDGE??!! This is bloody amazing, and over-the-top ambitious. I think it's going to take a little while to get there. Still, this thing is pretty powerful already.

Try "Pi to 1000 digits" and you get

Result:
3.141592653589793238462643383279502884197169399375105820974944592307816406286208.
99862803482534211706798214808651328230664709384460955058223172535940812848111.
74502841027019385211055596446229489549303819644288109756659334461284756482337.
86783165271201909145648566923460348610454326648213393607260249141273724587006.
60631558817488152092096282925409171536436789259036001133053054882046652138414.
69519415116094330572703657595919530921861173819326117931051185480744623799627.
49567351885752724891227938183011949129833673362440656643086021394946395224737.
19070217986094370277053921717629317675238467481846766940513200056812714526356.
08277857713427577896091736371787214684409012249534301465495853710507922796892.
58923542019956112129021960864034418159813629774771309960518707211349999998372.
97804995105973173281609631859502445945534690830264252230825334468503526193118.
81710100031378387528865875332083814206171776691473035982534904287554687311595.
62863882353787593751957781857780532171226806613001927876611195909216420199

I checked, and it's the right answer. I put in my last name and found

Basic information for the United States:

Rank: 857th

Fraction: 1 in 7326 people 0.014%

Number: 36,833 people

Ethnic fractions:

White 96.54%
Mixed 1.26%
Mestizo 1.22%
Black 0.46%
Asian 0.4%
Amerindian 0.11%

But when I tried to search for Doctor Dalai, I get "WolframAlpha isn't sure what to do with your input." Which is probably appropriate.

This is one of those "works in progress" that is pretty impressive from the beginning. It isn't Google as yet, but sooner or later, WolframAlpha will surpass it's rival. In the meantime, it's a pretty darn good math homework helper. Give it a try at http://www.wolframalpha.com/. Happy computing!

Devilish Illness

Patient with chest pain. Perhaps there's a bit of a problem with a mortgaged soul as well?

DoctorDalai.com Reviewed!

Slowly but surely, the word spreads about my wonderful blog!

My compadres at the "Radiology Technician Schools" blog took on the difficult task of reviewing 50 radiology blogs

. . . by radiologists, sonographers and industry professionals (which) reveal the ups, downs and nitty gritty details that you would want to read before making a huge decision such as a career path. Check out these top 50 blogs and see if diagnostic imaging is in your future.

Wow. Now, I might be encouraging (or discouraging) someone from entering radiology, radiography, sonography, etc., etc. What responsibility! I'm not sure I'm worthy, but read the review of my site (which was only ranked #4, but to be fair, that's pretty darn good in this rarefied company):

4. Dalai’s PACS Blog – This humorous blog begins with an alternative meaning to the PACS acronym: “Pain and Constant Suffering.” Mixing tongue-in-cheek ad medical analysis, reasons to embrace or avoid medical technology, and more awful medical spam, this site is a buffet of entertainment.

Well, I might have gone so far as to say I'm offering a salad-bar of entertainment. Buffet does sound better, though (except when some relatives of mine pronounce "buffet" as BOO-FAY, but that's another story for another time.)

Many thanks for the kind words. It still amazes me that anyone actually reads this thing, but I'm really glad you do.

Star Trek

Kirk and the gang, although Spock was otherwise occupied.

You knew I would, of course. I went with my son to see the new Star Trek movie on opening day. Somehow, I was able to wait until 10PM to watch in the theatre with the digital projector. Since you've all been anxiously awaiting my review. . .

The very, very short, Twitter version: "GO!"

The longer version: This is a very, VERY well-done movie, at least from the standpoint of a long-time Trek fan. I've been watching Star Trek since I was in second grade, a wee lad of 7, and this is the best episode/movie of the entire franchise. Period. Some have said this is the best science fiction movie ever, and I might be convinced to go along with that opinion. This is what Trek would have been with the film technology of today. The essence of the show, its personalities, its relationships, and so forth are faithfully reproduced, and enhanced. And there is action, a heck of a lot of action. And lots of toys, equipment, and a shiny new Enterprise. I must confess, I had a smile from ear to ear when the new ship appeared, in a scene totally remniscent of the first Star Trek movie from 1978. At least this time, J.J. Abrams kept the pace going, far better than the counterpart from almost 31 years ago.

As you have probably heard in the preliminary reviews, two phrases have been bandied about, "Star Trek Reboot" and "This ain't your father's Star Trek." I'm not going to provide any spoilers, but suffice it to say, both statements are true and accurate. Mostly. You'll understand when you see it. And you should. Five stars from Dalai.

What's On Your Workstation? . . .And Visitors From Waterloo

Courtesy CapitalOne.com

The gang from Waterloo recently came down to come visit me, an average radiologist, at my average hospital in our average town in the South. No, the two gentlemen in the photo above are not our visitors from Canada, but serve to illustrate a different point which you will encounter below. Unlike the last visit, no one had any trepidation about visiting this adorable little fuzzball. In fact, someone actually whipped out a camera to document the event. A tiny liberty was taken, as you will note (click the image for a larger version):

Of course, two can play that game (definately click the image to see what mischief I've wrought):

The Team theoretically came to observe several of us actually use the latest update, the installation of which truly went really well. We did get to chat a bit, and they also were able to videotape my partner, Dr. Killer, use their system as only he can. Hopefully, they had a high-speed camcorder for the purpose. As it turned out, the day they were at the same facility I was at, they had the joy of watching they entire system come to a screeching halt. Literally. Agfa believes in automatically updating its client software, with a little sniffer program living on the client machine constantly on the watch for a new edition. All well and good. Now our update was on the weekend, and many offices are closed then. So, come Monday morning, 1,000 computers (give or take 100) went online and wanted their updates, bringing the system to its knees. This has apparently been solved by placing the software update on a new server separate from our three load-balanced production servers. My solution is to turn off the sniffer on my computer.

The gang did discover a glitch in the update: studies on the worklist will seemingly randomly select themselves, a minor annoyance. This has been fixed with a minor service release. It's nice to have the experts onsite at times like these!

My understanding is that our latest and greatest (6.3.1.409x) has fixes for stuff that is still broken in 6.4.x, which is still in testing itself. We might just wait for the first service release for 6.4 before taking that plunge.

When my Canadian friends first walked in the door, I had our Amicas client running on an Agfa workstation. I sheepishly closed it, but they just laughed and shrugged. Which brings us to the next topic, "What's On Your Workstation?"

Later that day, I attempted to load an updated Amicas client (our Amicas hospital finally upgraded to version 5.x) onto a different Agfa workstation, which required a new Java Runtime Enviroment (JRE). This was one of the few Agfa stations that had a partial lock-down: some software, including Java, could not be changed without permission from On High. When I sought such permission, I was told that Agfa would not allow this, because it would "affect the warranty on the workstation." Well. I guess I've been told, eh? But the story is somewhat deeper.

I don't have a copy of our site's service contract, or warranty, for that matter. A search of the Agfa site yielded this fairly generic warranty document. Here are the pertinent clauses as near as I can extract from the legalese:

2.6 The Service Provider shall be under no obligation to provide the Services to the extent that such Services are required for:

2.6.1 problems arising as a result of the Buyer's negligence or default or because of accident, neglect, misuse (including without limitation unusual physical or electrical stress) or the failure of power supplies, external electrics, air conditioning, anti-virus software, use of incorrect consumables, and any other causes (other than ordinary use) not due to the negligence or default of the Service Provider;

2.6.2 Equipment which has been maintained, modified, altered, adapted, developed, repaired or howsoever changed (including, without limitation, attempts to maintain, modify, alter, adapt, develop, repair or otherwise change the Equipment) by or on behalf of the Buyer by parties other than those that are authorised to carry out such changes;

2.6.3 problems arising from any changes unauthorised by the Service Provider that have been made to any software supporting the Equipment (including, without limitation, adding additional third party peripherals, adding RAM, modifying applicator software or upgrading third party software to non-supported versions); and

2.6.4 problems arising from the removal of or reinstallation of the Equipment at the Buyer's premises by parties other than those authorised to carry out such removal/installation.

I'm no lawyer (thank Gawd!) but my read of this legalese suggests that the warranty is intact if one leaves the primary software (and supporting sofware) alone. Since Impax uses .NET, and Amicas uses Java, you would expect no particular conflicts, and all should be well. In fact, we have been loading Amicas clients side-by-side with Agfa on our home machines for years with no associated problems. (And I think some of my colleagues have loaded Amicas onto some Agfa workstations at the hospital here and there, although I certainly have no further knowledge of such things....) If you were to walk into our reading rooms, you would find all sorts of amusing software on Agfa, Amicas, and even GE workstations. I'm sure this is the case everywhere else as well.

Like running your iPod on a plane before you reach 10,000 feet, I think this is sort of a non-issue. However, IF it is truly affecting the "real" software, beyond stealing some RAM here and there, the proper answer is to completely lock down each and every vendor-managed workstation, in every installation, everywhere. Otherwise, let's just carry on as we have been for years.

What's on YOUR workstation?

PACS Updates, The Best of Times, The Worst of Times

Well, OK, maybe it wasn't that bad, but it was close. Our largest hospital system just installed the latest Impax 6.3.x service update. This operation gives us 71 improvements over the last iteration, some of which include:

Cycle list redesign
When the Cycle list contains many patients, each with a large number of studies, the list can get quite long; finding the desired patient becomes difficult. To solve this issue, the Cycle list has been redesigned. Each patient is now listed with their studies hidden. To view the studies of a patient, click the + next to the patient. To open all of the studies for a patient in the Image area, in the Cycle list, click the desired patient. To open a specific study, expand the studies and select the desired one.

Wildcard for Keyword search in Advanced Search
Keywords are descriptive tags that you can add to a study. Later, you can search for the study using these keywords. To enable the ability to search on keywords without using an exact match, the following conditions have been added to the Keywords criterion in Advanced Search:
1. Contains
2. Does not Contain

Fixed issues:

Slow performance of IMPAX Client when selection of studies is opened in the Image area. When a selection of studies is cycled into the Image area, the amount of time it takes to display them significantly exceeds the amount of time to display a single study.

Series logic broken after combining series in Available Series palette and spanning from one to two monitors. Combined series jumps back to the first series after spanning from view one monitor to view two monitors.

Removing column from Text area Study List causes IMPAX Client to crash. Removing a column from the Text area Study List causes the IMPAX Client to crash.

Study level prompt on dictation interlock is not working correctly. Study level dictation interlock does not behave as desired. Active worklist does not function in this case. As well active worklist is using study based notification when it should not.

Unable to view priors when they are partially cached. Relevant priors cannot be viewed if the study is partially cached; these priors can be viewed after the study is fully cached.

Prior is selected instead of current study when Image area is opened. A current study has a prior study attached to it, the current study is in the local cache, and the prior study is not in the local cache. When attempting to load the current study into the Image area, the prior study is displayed instead.

Active Worklist does not work when cycled studies are also priors of newest study. Active worklist does not always perform correctly when cycling several new studies with relevance on.

User profile is corrupted, not able to see scout images. The user profile in ADAM is being corrupted after logging into the Client a few times. The Actual Width in ADAM for IMAGE_AREA_SCOUT is replaced with zero so the user is not able to see the scout images.

There are numerous fixes for Mammography as well. Obviously, this was a very, very necessary update, and so far this morning, it is functioning nicely.

So, from whence comes my acerbic attitude? I guess you had to be here, but for the six hours of the upgrade, my life was not as much fun as it could have been. I was stationed at our trauma center, the busiest hospital in our enterprise, where the normal workflow is hectic at best. There's nothing like the joy of clicking off the last study on your list only to find ten more have appeared. Obviously, any minor annoyance or disruption becomes major at a place like that.

I'm not going to go into the specific mechanics of the update, mainly because I don't have a firm grasp of them, and moreover, I'm not sure I care that much. I do believe the process involved our Oracle database, the heart of the operation, as it were. What I know for certain, however, is that for the six hours of the update, we were running off of the axillary test server (which had already been updated), and functionality was quite limited.

Because the central database, the Oracle, was out of commission, image data was limited to the new studies, and a preload of the last few week's worth of priors. Could I get a study from four weeks ago? NO. Were there any reports available? NO. Well, yes, but not on PACS. To get a prior report, AND to get an accession number, AND to get a history (if the techs didn't provide such, which they didn't), we had to log into our RIS, which happens to be Cerner RadNet. There is a reason we avoid doing so routinely, which has to do with the fact that it likes to crash, and it is rather unintuitive. Can you guess, even with tool tips, what these buttons do?

The fourth button from the left is the "Radiology Order Viewer", and that is where old reports live, in case you were wondering.

So, for six hours, we were functioning, but in a rather hobbled fashion. Every one of the roughly one hundred studies that came through during this time had to be augmented by this manual drudge though the RIS. You can just imaging how much fun that wasn't.

Now, I don't mean to cast aspersions on our PACS team, nor upon the people from Agfa handling this update. They worked very hard, and did a bang-up job getting us through this (although one of our people had a giant flyswatter ready to whack me if I got too whiny.) No, the problem is in the philosophy of how updates and upgrades work.

I will have you refer back to Dalai's Laws of PACS, specifically the First Law: PACS IS the Radiology Department, and the Third Law: Once PACS, never back. Alter the function of PACS, and you destroy your established workflow, and ultimately impede patient care. Taking PACS away, or even hindering it in the slightest is a really bad idea. The busiest radiology departments cannot have this level of disruption, even for an hour, let alone six hours, or longer.

Updates are necessary and even desirable. They fix problems and deficiencies, and at least sometimes enhance the product. BUT there has to be a better way to handle the upgrade. Frankly, I'm not aware of any particular company that has totally painless updates/upgrades as yet, but perhaps they will listen and learn.

There are multiple architectural issues that necessitate a partial shut-down as we experienced. Probably the most important factor is the existence of the single central database. Beyond this, the rather complex connections between PACS and RIS denied us the ability to hook up the test server to the RIS, even temporarily. Speaking from an only semi-educated standpoint, it seems that we need some additional redundancy, such as a back-up database for these situations. We should already have one, for disaster recovery, yes? So, why not press it into service for this particular non-emergent emergency? Reconciling the changes made to the backup during the downtime should be fairly straight forward. Now, this does assume that the backup is on spinning disk rather than tape. Perhaps what I'm proposing is the establishment of an intermediate database, that holds, say, the last year's worth of data. I don't think this would be all that expensive, folks. And, while I'm no HL-7 guru, I should think that an alternate connection to the test-server (or a fail-over server for that matter) ought to be possible as well.

Bottom line: PACS updates should be a lot less painful than they are now. I don't think it would be that difficult or expensive to make that happen. Like many other problems in this business, this probably hasn't been addressed because no one has yelled loud enough until now. OK, I'm yelling at the top of my lungs! Do you vendors think you could have this fixed by the time of the next update/upgrade? I would really, really, appreciate it. Otherwise, I might have to have a bigger tantrum, and that wouldn't be dignified. Or pretty.