Quantcast
Channel: Dalai's PACS Blog
Viewing all 249 articles
Browse latest View live

MGH Still Uses Old AMICAS!

$
0
0


Look familiar? This is a screen-shot from AMICAS PACS, circa 2005. That would be about 10 years ago.

But I just had a flash of deja vu...While watching tonight's episode of Save My Life on ABC, filmed at Mass General, I very briefly spotted a PACS client of this vintage...no, I don't have a screen shot, but I'll work on it.

I knew AMICAS PACS had been used as an overlay to IMPAX at MGH, put in place back when IMPAX couldn't handle multi-slice scans.

Apparently, a 10-year-old AMICAS system is good enough for Mass General. Maybe that's because after 10 years, it still works. Unlike, well, need I say it?

Here's the promised screen shot, although it's from last week:



A Post For Larry

$
0
0


My friend and colleague Larry tells me he has become an avid reader of the blog, so this one's for you!

For the record, I'm discussing our situation in this public manner in hopes of eliciting help from those who are smarter than I am, with more experience than I have, and who might actually have a clue about what is going on with our PACS and how to fix it. I believe this if anything REQUIRES discussion about a situation that is IMPAIRING PATIENT CARE. I have tremendous respect for privacy and security, and I will do nothing to compromise it. But as Mr. Spock might have put it, the needs of the many outweigh the needs of the few, and the need of the patients, and those of the physicians to care for their patients, outweigh everything. That is why the hospital exists, it is why the Radiology department exists, it is why IT and the vendors exist. Period. 

But back to Larry. He and other colleagues have been gathering interesting images from our PACS, some of which are reproduced below:







If we cannot show the patient, I guess we can all go have a three-martini lunch, since there's nothing else for us to do. Ha ha. 

This would all be funny if PACS was the conduit for Netflix or something equally frivolous. As our episodes of outage and electronic impairment (no, we didn't have a three-martini lunch!) demonstrate, there is a severe and immediate NEGATIVE impact on patient care, and we have to get a handle on it NOW. The good news is that we are really starting to see improvement. It's sad that we had to have a total meltdown of personnel and machinery for that to happen, but that's the way it is.

From the outside, and from rather minimal information often fed to me third-hand, I am not really seeing a concentrated, orchestrated effort to get to the bottom of this, but rather a lot of shot-gunning that has had little impact overall. Yes, we've seen some improvements, but clearly, we are far from fixed. (There are those out there who would like to get ME fixed, but we won't talk about that.)

I'm seeing three distinct but likely related problems.

1. General slowness of the system, which varies by site. Transmission tests I have managed to see show this variation. This must have something to do with the network. It was suggested early on to see if the client behaves properly on a station connected directly to the server. Has this been done? Connecting via the Internet outside of the enterprise yields good service. That's a big clue!

2. Client software and hardware crashes. Is this a software problem? If so, is it a problem with the local client, the server, both? Could it relate to the network? Is it a Windows 7 problem? The clues are all there.

3. Slow searches. This seems to relate to corrupt profiles. I discussed this with PACS people, and I'm told that the user profile is simply an XML file, just a list of parameters that tells the client how the particular user wants things arranged, etc. Supposedly, logging on to two or more workstations simultaneously corrupts the profile. So, rather than spend hours creating a new but still fragile profile, how about someone figure out why IMPAX is even capable of corrupting the old one? We simply don't have time to rebuild profiles during a hectic workday, and I'm not going to waste everyone's time doing so when we don't even know why it helps or whether the change will stick. And if logging on twice can create a patient-care-impacting situation, perhaps a hot-fix needs to be implemented to prevent this practice, and the FDA notified of such.

There is an interesting, illustrative little side show to tell you about. I heard third-hand that some were questioning if my little AutoHotKey script for keeping the RIS window active might be the source of some or all of our problems. The turn-around-time (TAT) of the final report is a very important metric for patient care, and of course quicker delivery of the report is obviously helpful. Our performance in this regard is tracked, and all of these factors led to my creation of the little macro that could...keep the RIS window open and keep reminding us to sign our reports. As it turns out, though, my little bitty AutoHotKey macro apparently became quite the topic of discussion. IT security got very upset at its very presence, calling it all sorts of nasty names, and apparently a few were directed at me personally. The punch-line, though, is that the use of the macro was APPROVED by that department in 2010, with the only reservation being that someone could conceivably use AutoHotKeys to create a script which would bypass the need for a password. Given that I'm the only one who knows how to do it, and I'm not about to create something like that, we should be OK. Fortunately, most of my colleagues have made it past the days of inscribing the password on the bezel of the monitor with a wax crayon.

Being a cantankerous, semi-retired, cranky old lout, I will simply note that this episode demonstrates how things don't get accomplished.  Accusations fly, fingers are pointed, and some of the real issues don't get the attention they deserve. It would have taken literally 2 minutes to go to a station where this complied script is running, and activate Task-Manager to see exactly how many resources are being utilized. But I saved everyone the trouble. I've run task-manager (on those machines which don't have it and right-click disabled) and found minimal impact. (In addition, it shows that IMPAX is in a non-responsive state during some of those hour-glass generating waits. There's another clue for you. Anyone notice this before?)

To prove my point on the machine I was using at the time, I had to use Microsoft's Process Explorer, as it was felt too dangerous to allow radiologists access to Task Manager on some machines. Here's the result for my little script NewSigner3.exe:


The compiled script NewSigner3.exe utilizes 0.04% of CPU time on the IMPAX client workstation

Yup. Wasting 0.04% of CPU time could have devastating effects.

Once I made these results available, I was told: "Oh, no one was thinking that the script itself was the problem; but it keeps the  RIS window open, and that's what's wrong!" But like a bunch of Greek philosophers of old, sitting around the Parthenon contemplating how many teeth a horse should have, rather than actually finding a horse and counting its teeth, no one checked this. So I did:

Citrix window executables for RIS window use 0.15% of CPU time

Oh, but it turns out that wasn't what was being considered either. No, it seems that the fact that the RIS window was being clicked automatically every 20 minutes or so to keep it active and to remind us to sign our reports "creates downstream problems in that it allows for people to be logged in on multiple stations." (See discussion about profiles, multiple logons, and XML files above.) Someone please help me understand how keeping the RIS window open has any effect on the PACS. It seems pretty clear that some folks in the loop haven't tried to understand just what this little script accomplishes, and maybe somehow think it tweaks the PACS client. But it doesn't, as would have been discovered with 30 seconds of effort. Or a 30-second phone call to me.

You would think I had attempted to unleash the worst virus in existence upon the network.

Anyway. I did say above that some progress had been made, which is true, and some of the problems have been identified. Eventually, some of those will be fixed, too. One server had not been updated in a long time and it was delaying arrival of prior studies. No, I don't know why it wasn't updated. Very large individual disks had been used for storage which might have been beyond the recommended size. I don't know how that happened either.

You might recall me saying something about image skipping or rotten scrolling performance if the annotations were on. Apparently, this relates to the five-year-old version of software we are using, and should resolve once we upgrade.

Progress is progress, however slowly it might, well, progress. Perhaps we can Git 'R Fixed sometime soon. Larry? 

And Another New Pres For TR

$
0
0
Looks like TeraRecon has a new CEO:

(from radiologybusiness.com)
TeraRecon, a global medical image management company, announced that Jeff Sorenson is the company’s new president.
Sorenson has been with TeraRecon since 2004. His most recent position with the company was senior vice president of sales and marketing.
“TeraRecon is unique because it offers a complete and truly vendor-neutral 3D advanced visualization suite which can be extended to serve the medical image viewing needs of the entire health enterprise," Sorenson said in a statement. “I am excited to serve our valued customers and to drive innovation in this new capacity as president.”
Meanwhile, Venkatraman Lakshminarayan has stepped down as CEO and CFO. Lakshminarayan had been TeraRecon’s CFO since 2005 and its CEO since 2014.
TeraRecon also reported that a successful August has led to an increase in iNteract+ interoperability and enterprise image-enablement projects.
As a (hopefully) valued customer, I'm looking forward to working with Mr. Sorenson as well as Fred and the rest of the gang. Congrats!

Turning Point?

$
0
0
Image courtesy thisfabtrek.com

There was a meeting involving everyone with a stake in our PACS problem. This included radiologists, IT folks, administrators, and representatives from the vendor. The purpose of the meeting was to outline where we were, where we are, and where we are going. I left the meeting feeling cautiously optimistic for the first time in quite a while.

I'll not delve into specifics much, as they probably won't help you with your PACS problems, nor will they help you help me with mine. The generalities however, should prove more valuable.

The bottom line is quite simple, really. Our problems stem in greatest part from lack of communication. This gap occurred primarily between IT and the vendor, but there was also a rather large chasm between the radiologist end-users and the other two entities. Let's talk about that one first.

As an electrical engineer, I'm well-versed in the concept of the feedback loop, particularly the need in a circuit for negative feedback:


You've all heard the screeching "feedback" from a public-address system going out of control. Most amplifiers have a negative feedback loop, illustrated by the wire above using some of the output of the amplifier to "tone down" the input. So it is with life in general. If you think you are doing everything properly, and you receive no negative modulation, you will keep doing the same thing whether or not your actions are correct.

We rads had (or more honestly, exercised) only limited feedback options when it came to PACS. We the rads never really put our heads together to create a grievance list. Yes, one rad here or there would get upset with slow speeds, workstation crashes, slow scrolling, etc. Sometimes these could be fixed by the PACS administrators, sometimes only marginally improved. Someone would get a personal profile remade, although we never learned why this would help, someone would get his worklists redone. And so it went. In this way, little problems propagated into big problems.

I'll take some level of personal responsibility. I was so, well, jaded may not be the word...disheartened? Complacent? Resigned? Well, I had more or less decided that nothing would change until we had a major upgrade, whenever that might be, and I found ways to tolerate the glitches. It took two of my former partners, now bosses, who recently started working nights, to say "ENOUGH!" The minor slow-downs become quite major when you're trying to pump out dozens and dozens of studies through the wee hours of the morning. To be fair, there was further deterioration of the system during their initiation into the dark side (I mean dark hours), to the point that the workstations crashed, and ultimately there were a number of system outages, which certainly brought the whole situation to a head. The newly-minted night-stalkers began the campaign that has brought us to the brink of...a solution.

Communication is paramount as always, and we've made some great strides in that realm. First, we insisted on having a call-team from both IT and the vendor. We were briefly relegated to the "Help" desk; when they actually answered, they were little more than a rather slow answering service for IT. Second, we streamlined the process for rads to report problems directly. This was prompted by a response to a complaint implying that no one had ever mentioned the problem before. When Donald Trump's cell phone number was published, instead of having a little hissy-fit as we saw with a certain Senator, Trump simply put a campaign ad on his line. This inspired us to create an email thread wherein any and all PACS complaints could be reported directly to the right people. And report we did. Initially, there were tens of emails per day; this has tapered off to only one or two. We have definitely made progress.

While we physicians can be quite problematic, the deeper institutional snafus lie with IT, the vendor, and their somewhat dysfunctional relationship. There will be yet another meeting to more precisely define just how that relationship will progress, and while I detest meetings, that is one that should have been held years ago. You see, there really wasn't a single point of failure, but there were quite a few, shall we say, lost opportunities for improvement.

It turns out that one of our major outages was a network problem, caused by an update push that got out of hand. Another slow-down was the result of the EMR grabbing too much bandwidth. There was a bug in a NetApp image server that took us down. OK, we assume these things happen and can be fixed.

But it took a village full of angry radiologists to bring to light that yearly service on some of the servers might not do the trick, particularly when a couple of the critical servers running SunOS/Solaris weren't touched at all. The latter had been running on an elderly version of the OS, and had a bug that was fixed umpteen versions ago. Update the OS, kill the bug. And here is where we had trouble. Putting it simply, everyone assumed the other entity was going to take care of stuff like this, if they assumed anything at all about it. And so nothing happened until the recent unpleasantness.

We found that hardware was sometimes purchased without consulting the vendor, and then retrofitted with the vendor's help when it wasn't quite right. Perhaps both parties could be a little more proactive here, so we can all ask for permission instead of forgiveness.

Computers are made by imperfect human beings, and are thus imperfect themselves. To assume otherwise is naive at best. And so in a mission-critical area such as PACS, one must be ready for the inevitable glitch. There has to be a downtime plan, and an out-and-out disaster recovery solution. Guess what? We have neither. To my knowledge, the downtime plan hasn't been changed since I spoke at RANZCR in Perth in 2010: after four hours of outage, we start printing to film. Unfortunately, we no longer have any film printers. The next best thing, which we have been having to do, is to read directly from the modality's monitor. It isn't optimal, but it works, sort of. As for a full-fledged disaster, data is stored offsite as required. But it's on tape and recovering might take a very long time. If we could muster the resources. Let's hope it doesn't happen.

PACS, as it turns out, is the only Tier One service that does NOT have a proper downtime solution. Why did we get left out? Money. It was hard to justify a complete, mirrored, automatic fail-over that would only be used a small fraction of the time. Unless you happen to be a trauma patient in the Emergency Department, where life-and-death decisions are put on hold while someone fiddles with the server. Then it seems perfectly justified.

In the end, we all serve one customer, and that is YOU, the patient. Everything we do in this business, every decision we make, every scrap of hardware and line of code we purchase and use is meant to promote your health and well-being. It was said by some that we radiologists were "paying the price" for the various challenges I've outlined. That's true to some extent, but the real victims, at least potentially, are the patients, and that CANNOT be allowed to happen.

I've been blogging about PACS for almost 11 years, and my basic message hasn't really changed much. PACS IS the Radiology Department, and the hospital cannot function without it. Making this all work, and work properly, is in huge part a matter of communication. You have seen what happens when the discourse fails or doesn't happen at all. The downtime plan, or lack thereof, illustrates what happens when one of the groups involved in PACS, the rads, becomes disenfranchised with respect to the decision process. One of us could have very easily convinced the powers that be that we cannot tolerate a four-hour gap in service. We weren't asked to do so; we didn't even know the question had been posed. Now we do. And I am cautiously optimistic that this will improve, as will the rest of our experience.

I would be remiss if I didn't take the opportunity to excoriate the majority of PACS and EMR vendors while I'm on this particular rant. You are still not making user-friendly software. We all know it. PACS is bad enough, but our EMR and its CPOE (Computerized Physician Order Entry) is so very poorly written and implemented as to drive a good number of physicians into early retirement. Seriously. This garbage is served up as caviar to, and purchased by, those who DON'T HAVE TO USE IT, and again the physicians are disenfranchised. This too will negatively impact patient care, and it CANNOT, well, it SHOULD NOT be allowed to happen. But it is.

Let's have a meeting about THAT, shall we?

Connectivity Consanguinity

$
0
0
Tonight, there was semi-emergent IMPAX downtime to allow for the updating of the Connectivity Manager. The 6-8 hour anticipated impact on PACS was planned about 8 hours before it happened, and is necessitated by our imminent move to IMPAX 6.6.1. The system is due back up in less than one hour, and we'll see if we fare any better than last time. You see, this is all quite familiar. Here is a regurgitation of my post, "Connectivity Banisher" from January, 2009:

-----------------------------------------------------------------------------

In the world of Agfa Impax, a "Connectivity Manager" is:
. . . a middleware component in the integration between HIS, RIS, modalities, and PACS systems, linking patient and study data with images. To display the information available from a non-Agfa RIS in the Text area of IMPAX, connect to the Connectivity Manager. . .

The main purpose of the Connectivity Manager is to take data from one system, such as a HIS, and translate it into a format that another system, such as a modality, can understand. Connectivity Manager accomplishes this translation with mappings. The mappings tell Connectivity Manager how to translate incoming and outgoing messages to external systems. The following mappings must be configured so that Connectivity Manager knows which report source to go to for each study, and how to translate messages sent from IMPAX. . .

Map a reporting name into the Data Store by identifying the sending facility in the Connectivity Manager database. Identifying this value means it will work regardless of whether the sending facility sends their name along with the message or not. Also, if the sending facility changes their name at some point, mapping or configuration changes will not be necessary. The Default Assigning Authority identified in this mapping is the name of the report source entered in the Business Services Configuration Tool.

The sending facility is required to view reports in IMPAX. Connectivity Manager uses the Entering_organization and Requesting_Service mappings to populate the sending facility field. These mappings should include the Default Assigning Authority so that every report contains a sending facility.
Our Connectivity Manager was upgraded last night. And again this morning. From the rad's point of view, this means:
During this time Modality Worklists will not be available and Technologists will have to manually input ALL Patient Information. Studies sent to IMPAX will Fail Verification, and will not update with Reports until the downtime is ended.
I drew the short straw, and experienced the joys of the upgrade. Fortunately, the downtime lasted less than one hour, and not two. Of course, only a few of the techs got around to manually inputting ANY Patient Information. Still, we were OK. Until this morning, when this information (including the accession number by which we dictate) was suddenly absent once again. The culprit was, of course, the Connectivity Manager, which seemed to be confused by "multiple" inputs for the same patient. Now that's a problem, which we hope will be fixed by the experts before too much longer.

As usual, Dalai's Laws of PACS apply. In particular, the First and Third Laws are applicable:
I. PACS IS the Radiology Department.
III. Once PACS, never back.
When PACS malfunctions, the department malfunctions, and don't even consider asking anyone to go back to a manual process. It ain't gonna happen.

So, in the ideal land of Dalai-wood (Hooray for Dalai-wood!), PACS should never break. Since that isn't achievable, these thing need to be created with an eye toward simplicity and functionality. Based on what the "Connectivity Manager" is supposed to accomplish, I'm not really certain why it has to be a separate program or computer or whatever it is. Shouldn't the simple, basic, core PACS be able to talk to others? OK, provide a look-up table (user-configurable, of course), but do we have to have a big, separate, grandiose module that manages to bollux up the works when we upgrade it?

Yes, I know..."simple" and "basic" aren't in the vocabulary of a lot of PACS vendors. Neither is "easy". And "uptime" can be defined to the preferences of those making the definition. But as far as I'm concerned, if it isn't totally "up," then it's "down." (Which happens to be true for many things in life.) So, today, we were "down," courtesy of our dear Connectivity Manager.

---------------------------------------------------------------------

A party close to the 2009 update had this closing comment:

Please understand this is not normal hospital type workflow, and with the hundreds of other mappings to get right is an easy oversight, the missing "Cerner ID" should have been noticed during your sites testing and identified prior to the go live.

But once again an easy oversight by all involved.

This also was not a standard upgrade, Yes your CM software was upgraded to the latest version, But behind the scenes each and every interface was recreated from scratch, including the HL7 Feeds, all the modality’s (100’s) and each and every Impax device and client, There was months of work evolved with this upgrade.

On a different note, I truly enjoyed reading your blog, And can fully understand the frustration these upgrades cause the people working with the software. I do try my best to ensure as little impact to your job as possible.

I have yet to understand what, beyond me, makes our system any different than any other. And I'm not sure how we were able to squeeze "months" of work into 14 hours. Perhaps the process has been perfected in the last 6.5 years. Right.

A Question For You...

$
0
0
A very simple question...

Has this blog been helpful to you? Has the description of our trials, tribulations, and occasional successes with PACS led you astray or in the right direction?

Just wondering...

Another Question

$
0
0



Hypothetical question:

Which vendor/product out there is capable of (rapidly) overlaying an existing PACS?

So far, Merge, Intelerad, and Visage seem to be able to do so. Any others? Any experience in doing this?

And how well will they work if your networks aren't in good shape?






Thank you for sharing your thoughts.

If You Can't Beat 'Em...


Universal Improvements

$
0
0
I have referenced some of our trials and tribulations with the new GE Universal Viewer, which is technically version 5.x of Centricity.

We've found that some of our problems were of our own making, with the help of some unusual programming on GE's part. The disappearing measurements, for example, didn't really disappear. Rather, my hanging protocol created a clone of the main window, and if things are measured there, they won't show up, although they do live on as the Saved Presentation. Lesson learned. Various other "glitches" were due to our lack of understanding of something esoteric. Well, if they all worked the same, no one would buy the expensive PACS, now would they?

However, one problem has not yet been fixed, that of skipped images. We thought at first this was also due to the clone window handling, but apparently it is a coding error. Which is to be fixed. IN THE RELEASE AFTER NEXT!!  Um.....GE....a glitch that hides patients' image data is a VERY SERIOUS PROBLEM! This is the sort of thing that calls for emergency hot-fixes and mea culpas to the FDA. I do have to admit that the problem is not as bad as what we saw with Centricity 2.x, wherein scrolling would simply jump over images; UV 5.x tells us when it's skipping images by flashing "0% Loaded" in the missing frame. This is a definite improvement, but...you can do better!

Anyway, a team from GE came by the other day to show us how things will improve.

The two apps people who came to visit were well-known to me, one having demoed Centricity to us about 12 years ago, and the other having shown me the Universal Viewer for the first time at RSNA 2012. They brought a laptop-based workstation and server, and a cargo-load of monitors. Given the fact that we just redid all the workstations, couldn't we have simply, temporarily downloaded UV 6.x on our station, saving a LOT of time and effort? Oh well, I guess that's why I'm not in sales.

The team showed us a few things we already had that we didn't know about. For example, two CT series can be synchronized by "Image Registration" as well as position or slice number. The modifier was there all along under the Sync menu, but I never thought to look there. Perhaps theres also a "Sync by Phase of the Moon when Study Acquired" or "Sync by State of Consciousness" in there, too. I'm sure there are other little Easter Eggs hidden in the somewhat scattered GUI I haven't found as yet.

UV 6.x apparently plays nicer with Windows than 5.x. We had complained about the Navigator pane disappearing behind the Patient Folder; resizing the latter will solve this temporarily, but the windows all revert back to where they were upon opening the next study. Ah, Windows. Some problems scrolling through old reports after clicking somewhere else supposedly will be improved in the next release as well.

One of the main deficiencies in UV to date has been the lack of the promised ability to read PET/CT without adding the Advantage Workstation Server. We were shown the AW functionality, which is FINALLY tightly integrated into UV about 12 years after it was supposed to happen. It does appear to work as I would expect it to, with all windows, planes, 3D renderings, cartoons, and other stuff linked. Adjust one, the others all follow, whether on UV or AW. Very nice. This gives us the full PET/CT reading capability, matching that of the old AW upon which we now depend. Works for me. There's also a nice OncoQuant module which we may or may not get that will allow serial lesion measurements. That is, after all, what we do in oncologic imaging. Having a table of what was there before could certainly help us to be certain we measure all the lesions seen last time. Each. And. Every. Single. One.

I took a few moments to rant about the control layout of UV, which is not terribly logical, and can get worse depending on what buttons are pressed, and what the state of the viewer might be. For example, when using measurements (obviously the bane of our existence), the buttons for linear measurement, ROI, etc., are placed to the right of the "Study Dictated" button, which is otherwise nicely placed at the end of the line. Yes, said GE, you are not the first to complain about that. Well, gee, GE, how about trying these things out with real users before deploying them? Little problems could be caught before they become big problems. That would be nice, and few companies do it. My services are available for a very reasonable fee!

Having heard of our difficulties with another PACS, the reps approached me after the demo and wondered if this might be the time to present their wares to the troubled site. Since the problems there might not be the fault of the PACS itself, I urged patience. A LOT of patience. Like wait until I've fully retired patience... Some of my former partners have told me quite clearly that they would really rather not have to use UV anywhere else. To them, I urge patience as well; UV represents tremendous progress over its predecessors, and you never know how much better it might get...


PACS Wars

Making Mars Great Again!

Meeting and Networking

$
0
0
Cartoon courtesy of the NewYorker.com

Early July:
Radiologists complain about deteriorating PACS speed and function. Loudly. Note that access via Web from outside the enterprise over <50 MB line works far better than connecting within the enterprise.

Mid July:
Just completed the assessment of where the reading stations are physically connected to the network. Confirmed that not only are they connected to newer switches, but every connection between the core switch and the actual devices are clean. All connections are running 1000 Mbps and Full Duplex, there are no errors on any of the ports between the core switch and the reading stations. Checked the WAN connections and those links are clean as well.

Physical network connectivity has now ruled out as a source of slowness.

Early August:
The overall global performance issues have been resolved through updating servers, workstations, and tweaking settings according to best practice configurations.

Early September:
Radiologist insists on plugging workstation directly into server at datacenter. Voila! Perfect performance!

Mid September:
  1. Network: Switched Virtual Interfaces migration to new core infrastructure (removes extra hop/loop in datacenter - to be completed by end of September). We do not know if there will be any perceived impact or benefit, but it is within the realm of possibility. 
  2. Network: Installation of additional 1 GB connection between campuses and data center (escalated with vendor requesting to have completed by mid-October)
  3. Cisco engaged to perform network assessment (to begin after above network changes are in place) which will be analyzed and Radiologist feedback obtained to determine next steps for long-term measures if image retrieval performance is not resolved through the accomplishments by the end of November.

Late September:
Switched Virtual Interfaces migration to new core infrastructure removes extra hop/loop in datacenter.  Likely that the change will not be seen by the end user. WAN Upgrade with installation of additional 1 GB connection between campuses and data center waiting on date, anticipating mid-October.   Improved bandwidth will improve network performance.

Mid October:
“We don’t need Quality of Service (QoS) for PACS as PACS only uses 30% of the existing 1GB bandwidth, and that hasn't been a problem.  The additional 1GB upgrade had been planned since last year.



Draw your own conclusions.

@AgfaMinions

$
0
0


Cute! I'm sure we've done the proper licensing with @Disney. Right?

IBM Goes Mac!

$
0
0
From FoxNews.com:

IBM, at one time a Windows PC heavyweight, is now deploying Macs internally and is seeing a precipitous drop in helpdesk calls.

How precipitous? Only 5 percent of Mac users call the helpdesk, compared to 40 percent of PC users, according to Fletcher Previn, VP of Workplace-as-a-Service at IBM, who spoke about the program at a conference held recently in Minneapolis.

Based on the positive results, IBM is now rolling out Macs to its employees at a rate of 1,900 devices per week. The tally so far for the four-month-old program is 130,000 Macs and iOS devices into the hands of IBM employees, according to a post from JAMF Software’s user conference, where Previn was speaking.

And IBM is managing all of those devices with a tiny staff of 24 people, which comes to one helpdesk person for every 5,400 devices. . .

One of the ironies is that IBM was a PC pioneer in the early 1980s and subsequently became one of the largest Windows PC suppliers in the world. IBM eventually sold its PC business to Lenovo and over the last decade has become a software and services company.

This on the heels of IBM's purchase of Merge Healthcare to feed images to Watson. Talk about a string of really good decisions! If it weren't for antitrust laws, the next logical step would be for Apple to devour IBM and then gobble up Microsoft just for grins. Take that, Bill Gates!

"EHR State Of Mind"

$
0
0
ZDoggMD WHO????  From Dr. ZDogg's website:
ZDoggMD is a physician, off-white rapper, and the founder of Turntable Health. He’s not a businessman. He’s a business, man. OK we stole that line from Jay-Z but you get the idea. A hospitalist at Stanford for almost 10 years, Dr. Z currently resides in Las Vegas—a city he finds simply adorable.

Dr. Dogg, actually, Dr. Zubin Damania, in his copious spare time, creates poignant, biting rap videos that cut right to the heart of what's wrong with medicine today. His latest offering, "EHR State Of Mind," targets, you guessed it, EHR's, and by proxy, electronic medicine in general.

Without further ado:



Watch the whole thing. Then watch it again.

Yes, it's funny, but it's sad, and it is spot on. Here's the bottom line: Most medical software programs, EHR's, PACS, etc., are VERY poorly written. They are hard to use, they get in the way of patient care, they don't communicate well if at all to other systems, they were designed to appeal to CIO's and IT types, and ignore most anything to do with how physicians and such actually use them. Or try to use them.

I'm just waiting for the first class action suit against one or more of the companies who have shoveled these steaming piles of poor coding and even worse interfaces upon us. All it will take is the deaths of a few patients that can be directly attributable to these embarrassing excuses for software. Mark my word, it will happen. Of course, these multi-billion dollar companies will pay off the plaintiffs and keep doing what they are doing. That worked for Ford and the Pinto cases; Ford committed corporate murder rather than pay $100/Pinto to fix a fatal flaw. So it will be here. And most tragic of all, CIO's and IT folk will continue to buy from the vendors who promise the best prices, the least work for the support people, the biggest installed base, and just generally anything and everything EXCEPT being usable for the end-users. That would be us.

There are very few rogues out there such as myself and ZDogg who are alerting the public to the fact that the electronic emperor has no clothes. Clearly, we are not getting anywhere, and that is because we physicians have completely lost control of this situation. And I doubt we'll ever get it back.


EMR's Suck Epically!And I'm Not The Only One Who Says So...

$
0
0
When something in the health-care field reaches the attention of Conservative columnists, it must be either really wonderful, or very, very bad. This time, it's the latter.

I'm a big fan of Michelle Malkin, a very articulate Conservative writer, who appears periodically on Fox News broadcasts, and the pages of Townhall.com. In her latest column, she notes quite clearly that "Doctors Agree: Obama's Electronic Medical Records Mandate Sucks". This doctor concurs.
For the past several years, medical professionals have warned that the federal electronic medical records mandate—buried in the trillion-dollar Obama stimulus of 2009—would do more harm than good. Their diagnosis, unfortunately, is on the nose.

The Quack-in-Chief peddled his tech-centric elixir as a cost-saving miracle. “This will cut waste, eliminate red tape, and reduce the need to repeat expensive medical tests,” he crowed at the time. In theory, of course, modernizing record-collection is a good idea, which many private health care providers had already adopted before the Healer of All Things took office.

But in the clumsy, power-grabbing hands of Washington bureaucrats, Obama’s one-size-fits-all EMR regulations have morphed into what one expert called “healthcare information technology’s version of cash-for-clunkers.”
Indeed. "I'm from the Government and I'm here to help you!" are some of the deadliest words in the English language. Few if any of the promises have proven to be accurate.
In 2014, RAND researchers interviewed doctors who spotlighted “important negative effects” of the EMR mandate on “their professional lives and, in some troubling ways, on patient care. They described poor EHR usability that did not match clinical workflows, time-consuming data entry, interference with face-to-face patient care, and overwhelming numbers of electronic messages and alerts.”

{snip}

In Massachusetts last month, physicians decried the failure to achieve true “interoperability” between EMR systems despite a $30 billion federal investment through the Obama stimulus. Dr. Dennis Dimitri, president of the Massachusetts Medical Society, noted at a rancor-filled town hall that the mandate has “added significant time to the daily life of most physicians in their practices,” WBUR reported. “It has not necessarily lived up to expectations in terms of its ability to provide cues to physicians to make sure that necessary treatments are not being missed. It has certainly not been able to swiftly disseminate information from one clinical setting to another.”
The most ironic thing is that what was pledged was truly desirable and eminently achievable. Sadly, what has happened in the private world of medical software is magnified ten-fold when the government jumps in. I have bemoaned the sorry state of PACS software in particular for over 10 years on these very pages. The poor excuses for life-and-death patient-care software can be attributed at least in part to the fact that the end-users generally don't buy the software, and so it is written for those who do. Make the government that customer, or at least the entity that writes the RFP, and you have a recipe for disaster.

The EPIC failures of the most ubiquitous EMR tells us a lot about what really happened:
(The problems are) in no small part due to the cronyism embedded in the federal stimulus “incentives” – a massive chunk of which the White House doled out to behemoth EMR company Epic Systems, headed by Obama crony Judith Faulkner. As I’ve noted repeatedly in this column the past three years, Epic continues to be plagued by both industry and provider complaints about its creaky, closed-end system and exorbitant fee structure to enable the very kind of interoperability the Obama EMR mandate was supposed to ensure.

Now, even left-wing Mother Jones magazine reports this week that “instead of ushering in a new age of secure and easily accessible medical files, Epic has helped create a fragmented system that leaves doctors unable to trade information across practices or hospitals. That hurts patients who can’t be assured that their records—drug allergies, test results, X-rays—will be available to the doctors who need to see them. This is especially important for patients with lengthy and complicated health histories.”
Worst of all, physicians have been bribed to accept the concept of "Meaningful Use" which is simply the ability of their shiny new EMR's to transmit "anonymized data" (nudge, nudge, wink, wink) to Washington, and they are fined if they don't put the spyware in place. The American Medical Association, whose membership now comprises less than 10% of U.S. physicians, sold us out for figurative bowl of pottage, but now, too late, realizes its huge mistake:
The American Medical Association, which foolishly backed Obamacare, is now balking at top-down government intrusion into their profession. Better late than never. The group launched a campaign called “Break the Red Tape” this summer to pressure D.C. to pause the new medical-record rules as an estimated 250,000 physicians face fines totaling $200 million a year for failing to comply with “meaningful use” EMR requirements.
Malkin closes with a modest suggestion:
The Obama White House has responded by doubling down on its destructive EMR rules that punish both patients and providers. Congress must intervene. Rep. Steve King (R-Iowa) introduced a bill Thursday to repeal the draconian penalties “so that providers can get back to the business they are uniquely trained to do—utilizing their skills and knowledge to heal the sick and support the continued vitality of the healthy.”

Prescription: Butt out, Washington. Primum non nocere
Primum non nocere, by the way, is Latin for First, Do No Harm. Indeed, this is the one of the Prime Directives of medicine. Those who provide fractured software should take note. Pandering to IT and CIO's with programs that ignore the needs of the physicians who use them is tantamount to "doing harm" to patients. Abusing one's relationship to politicians in high places to sell exorbitantly-priced, crappy, dangerous spyware is even worse.

From the original Hippocratic Oath:
With regard to healing the sick, I will devise and order for them the best diet, according to my judgment and means; and I will take care that they suffer no hurt or damage.

Nor shall any man's entreaty prevail upon me to administer poison to anyone; neither will I counsel any man to do so.
Rather Epic advice, don't you think?

Creeping Improvement

$
0
0

This is a real product, by the way, available on Amazon. If PACS cures could come in a squeeze-bottle, they might look like this:


But sadly, the only sectors that get squeezed when the PACS malfunctions are the radiologists, the techs, and, most importantly, the patients.

IMPAX 6.6.1.x was installed last weekend, along with a plethora of hardware and network renovations. New cores, various new servers, some of which sport SSD's instead of spinning disks. The new dual 1Gb lines have yet to be installed.

I can report significant improvement overall, but I'm afraid we aren't quite there yet.

The good news first. We are seeing overall faster loading and transition between the last study and the next. Most of the time. We are seeing tremendous improvement in searches, which used to take up to 60 seconds, now clocking in at no more than a second or two. Images scroll faster, mostly, and are no longer slowed by having demographics/annotations activated. 6.6.x has a newer study list which will filter in the relevant priors. There is an MPR module (which is nothing new but we didn't have it before). There is now a button to save a layout as a hanging protocol.

But the picture is far from rosy as yet. As reported by the users:
  1. When pulling in a group of studies to dictate, about 50% of the time the patient data did not load correctly onto the left screen. It got progressively worse as I worked over night.
  2. Shortly after I began at 2:00 a.m. the system slowed, not to the point of before but it was clearly slower than earlier in the day. It remained this way until about 7:30 this morning. the system would periodically not accept mouse inputs for about a 5-10 second intervals as the system cycled from one study to the next, regardless of modality. The system did that "thumbnail updating" during those intervals.
  3. Approximately 10 times overnight the system would bring in the comparison study as a micro thumbnail image in the left upper corner of the screen. 
  4. We had a study pull in the wrong patient demographics/study on the left screen for a study he was dictating on the right. It pulled in the data from a study done a year earlier.
  5. Also, intermittently the proper prior did not load correctly. Example, I loaded right hip film  to read and a left foot loaded as comparison, then on third screen was a prior hip film.
  6. And finally, studies that were suppose to go into failed verification were showing up on the list to dictate and listed as new even though there was no RIS ID for the study. 
This is being addressed, and hopefully these things will be resolved. In fact, some fixes are well underway as they relate to a look-up table of body part and modality priority for the relevant prior pulls. But the business of incorrect matching of patient demographics and images is really, really serious, and in fact represents an FDA-reportable event. Need I say more?

6.6.1 still suffers from the legacy of how IMPAX does things. Tools are toggled on and off as we've seen for many, many years. I have NEVER heard ANY IMPAX user praise this approach, unique in the industry, but Agfa persists in being "special". Similarly, we still must endure the backward approach to claiming studies. EVERY other system out there give ME control of a study once I open it; IMPAX lets someone else open and snatch it away from me. I was told years ago that this was to accommodate academic sites where the professors must grab things away from residents. Guess what? WE don't HAVE residents. We are NOT an academic site, and we really don't like this machine behavior, which incidentally can lead to studies not being read because someone accidentally closes something someone else has clicked as "Dictation Started". Bad move. There is still no way to display the same series in multiple active viewports so as to show it in different window settings. The only way to do this is with a "clone" window, separate from the main display.

IMPAX 6.5.x and earlier versions supposedly had hanging protocols, but the implementation was so very bad that it couldn't be used. 6.6.1 has a new and improved version. It works, but it is severely hobbled. Unlike every other drag-and-drop hanging protocol implementation (Merge, GE UV, etc.), we are limited to displaying within the preset modality parameters. If you've set CT to display in a 2x2 format, that's the only way your protocols will work. You may NOT have the same dataset in multiple viewports. And so on. I'm quite unimpressed. It does work a bit better with MR than CT in my hands, but I read a lot more CT than MR. 

IMPAX 7, a.k.a. IMPAX Agility, will solve at least some these problems. Once it is approved as an upgrade for 6.x, that is, which has yet to happen. 

Believe it or not, I don't expect perfection. What I do expect, and even demand, is communication and  interaction. I have whined for over 10 years on this blog about the disconnect between the vendors, IT, and the physician end-users of PACS. (Same thing applies to EMR's, but that's another post.) 
Our experience is a classic example of how things go wrong when we rads are taken out of the loop. We had no good lines of communication to IT, who assumed a lot of things were OK when they weren't, and who didn't think to ask us to champion absolutely critical upgrades and expenditures. This allowed system-wide deterioration which nearly shut down a hospital. 

We had no good feedback loop back to the vendors. Since we are NOT their customers, they take their cues from IT and C-suiters who generally have no concept of radiology workflow. The hanging-protocol thing is a great example. Clearly, Agfa had no clue as to how I wanted it to work, and frankly I can't imagine anyone finds it useful. Contrast this with AMICAS PACS which had a very simple, working solution back in 2003.  Listen to your customers and they will tell you what they need. Except I'm not the direct customer, am I? 

For the past 10 years, I've tried to be the feedback loop, along with a very few others. Clearly, I haven't succeeded. We finally made progress when my colleagues who took back the night got sick and tired of the decaying situation. I tip my hat to them for this tremendous accomplishment.

Hopefully, our PACS experiences will inspire others to rise out of their complacency. Things CAN be better. You simply have to reach this point, as did someone who suffered from a different "Network" outage:


Am I communicating this properly? 

The Law Of The Instrument

$
0
0

We've all heard some variant of the meme about hammers and nails. It can be attributed to two gentlemen coincidentally named Abraham, Abraham Kaplan, a philosopher, and Abraham Maslow, a psychologist. From the Wiki:
The concept known as the law of the instrument, Maslow's hammer, Gavel or a golden hammer is an over-reliance on a familiar tool; as Abraham Maslow said in 1966, "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

The first recorded statement of the concept was Abraham Kaplan's, in 1964: "I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding."

Maslow's hammer, popularly phrased as "if all you have is a hammer, everything looks like a nail" and variants thereof, is from Abraham Maslow's The Psychology of Science, published in 1966.
Those of us who peruse AuntMinnie.com have seen this concept acted out by a fellow we'll call PACSGenius. Mr. Genius says he works for a radiology group in Florida who has solved all of their problems with a system from Singular Medical Technologies (SMT). Mr. Genius is so enthused about SMT, he has proposed it as a substitute for VNA's, and a solution to my own troubled hospital PACS installation.

If only it worked that way.

First, let's review some of PACSGenius' claims as posted on the Aunt Minnie PACS Forum. Here is the opening spammy advertising volley:

We currently use them at 12 central Florida hospital locations and our rads are also using them from home. The only issues we had were broadband from the Rads homes but once we had them on 80mb/s things smoothed out. Leadership swears by them. The turn around times were significantly lower with these. 1 month to setup too, barely any issues with hospital IT.
{snip}
I am a PACS admin, have been for 12 years. Prior to that I worked for GE healthcare. We have a rad group with 40 rads and 12 facilities none of which had 1 single PACS database that were merged in any way. Our first solution was a Cloud Based PACS over lay. that was 3 mill for all facilities and it was a total disaster. They are now bankrupt. We found these guys SMT, they build workstations that are configured to work with multiple clients. This let my RADS access all the sites they needed. I didn't know this was an issue until I ran right into it. No disrespect, just wanted to share my experience. AGFA, GE, MCKESON, MERGE. Not one was able to do what these guys did. GE didn't want to talk to AGFA, AGFA hates MckEsson. It was a bloody nightmare to get images to even transfer. Much less to actually work together. If you know of 2 major PACS systems that work hand in had I'd love to hear about them. That's all.

{snip}

Average cost of an HL7 $25,000 plus support usually about $1400.00 a month.
We tried that. In fact we leased Fuji PACS and a Powerscribe 360 server. Cost for that was $27,000.00 per month. That required 2 HL7 interfaces and it only worked with 2 GE and AGFA which I will add was a nightmare to get them to work with us. Worse part was when we were done instead of decreasing turn around times our turn around times increased.

See the not so beautiful fact about HL7 is that instead of speeding thing up it slowed things down. It's basic network topology. The more hops and the more servers your images have to hit the slower things get.  Our standard study availability after the HL7 and Fuji Pacs for a plain film to show up on our diagnostic screens was selected went from 2 to 6 seconds to 27 seconds. Multiply that times 1000 plain film a day and you get the picture.

So while HL7's give you the ability to access they kill your turn around times. For most locations we deal with the broadband is weak and limited. Adding on all of this back and forth was horrendous.
So HL7 was a huge FAIL.

Then we tried an overlay (Compressus) at 4 Million that was not a real solution. It took 2 years and never got off the ground. Because, drum roll..... HL7's would not work properly causing the patient ID's for several of our sites were different the interface was too complex and created duplicates of patients and studies were missed and some took forever to appear in the right work-lists.

So here are the numbers:
HL7 interfaces, up front about 78k, plus support.
Fuji Pacs was close to 890k for 2 years.
Compressus 4 Million.
Average time it took a plain film to show up with this awesome HL7 tech: 23 to 25 seconds.

Cost to implement Singular at all our locations 459k, plus support about 32k a year. Savings: Dropped 3 Rads off our schedule to the tune of 1,489,000 in salaries.

Turn around times using these guys for 1 plain film to show up: 5 seconds. CT's are just as fast as being at the hospitals.

Our practice is currently on the 99th percentile with MGMA and we are turning plain films and imaging cases within 17 minutes.

So if you like spending money, and making things slow down then these guys are not for you. I recommend a hefty HL7 or 2.

These units let the RAD sit in front of 1 set of screens rather than rolling up an down a hallway full of 7 to 14k diagnostic screens. I know for a fact that saved us a ton of money just in hardware alone. We used to have 10 reading stations in one room now we have 2. It may not be groundbreaking because it's not a phone app that talks back but it just WORKS.
In response to our malfunctioning PACS, Mr. Genius suggests:
This may help: singularmedicaltechnologies.com developed a system that we use every day at 12 facilities. It's helped us read for sites we never had access to on an active work-list and we are able to read for which ever PACS the facility has. No lag, instant real time radiology without a third party overlay system.
Yeah, that's going to get me back up and running.

And finally, Mr. Genius declares the VNA another nail to be hammered:
Check this system out. We don't need VNA. We access multiple sites directly from one station instantly. No lag, comparison availability, active master list no matter which PACS you use. We love it! It's helped us out tremendously. singularmedicaltechnologies.com

I can only go by my experience within the confines of the Radiology group. When the hospitals we work with decided to look at VNA to manage their imaging we were concerned about our situation. Although we were excited because one of the things told to us were that the VNA would solve all of our imaging problems. We would finally have a fully operational work-list. That is the things my RADS wanted the most. So we were all sitting there at meetings for over 2 years cheering on the VNA wagon. Well the wagon came and left. 2 million dollars in and everybody in the hospital was sharing images expect the Radiology group!. You can imagine what happened then.
We were told and I quote: The distinguishing characteristic of a VNA is that it can handle many different types of images and associated data without being locked into the products of a single vendor. We were so happy we couldn't stand it. The reality was that the system worked great for the ED's but all the PACS vendors said no. So back to the beginning for us. I was just saying VNA's at some point may fix this but it doesn't seem to work for RADS. That's all. I may have misunderstood your post. I read VNA's and was immediately ready to grab my pitchfork!!!

Quick question, what do you guys use to merge your different versions of PACS? I have looked everywhere but all I find are Overlays for the cost of the space shuttle program.
Apples and oranges. I'm sad to say that in my humble and non-litigatable OPINION, PACSGenius has completely and totally misrepresented the capabilities of Singular Medical. And to boot, he has disclosed the salaries of the radiologists for whom he works, which he should not know in the first place, and for us this public airing of private, inside information would have been a termination-level offense. His employer may be more forgiving.

Mr. Genius has probably done considerable damage to Singular with his wildly off-the-mark posts, but to be fair, let's look at just what SMT really does offer. Here's what it isn't: it is NOT a VNA. It is NOT a unified viewer that merges disparate PACS onto ONE worklist. It is NOT an overlay nor a cloud solution.

So what IS this revolutionary new technology? This:




Basically, it is a way to select which of multiple PACS you wish to activate on a single workstation. How this is done is not revealed, but it is reasonable to assume Singular uses some sort of virtualization and server-side rendering with a thin/zero footprint client, perhaps similar to Calgary Scientific's approach. Interesting, although not at all revolutionary. HERE is Singular's rather long-winded (non) explanation of how it all works.

The sad fact is, Singular is an expensive way to solve the multi-site problem, without actually solving it. It does allow monitoring of multiple worklists on the same 5th screen, and the toggling between PACS is smoother than might be accomplished with a multiport KVM. (The latter can be found supporting DisplayPort technology which might or might not properly drive your 3MP monitors.) Given the mini-rack to the left in the photo of the station, maybe all Singular has done is smooth out a software-driven KVM.

In many if not most cases, PACS clients can live in relative harmony on a single workstation, as long as it is robust enough. We generally run IMPAX, multiple AMICAS/Merge clients, and GE UV on a single station with minimal hiccoughs. To be fair, we don't have the added problem of PowerScribe, but if that's the only remaining problem Singular solves, well, it's a bit of overkill.

Does this $500,000 hammer work for the rather narrow nail it is really intended to hit? Yes, I suppose it does. I'm not ever going to be a customer, and I'm not going to grace Singular with my presence at RSNA. But in the end, it solves a problem that doesn't need solving.

PACSGenius went on and on about how he couldn't for love or (lots of) money bring the umpteen disparate PACS together in one reading list. In the middle of the diatribe, AuntMinnie regular DICOM_Dan (who claims not to be a reader of my blog but we all know better ;-{)} ) tells us:
That's the beauty of standards, DICOM/HL7, and of those systems should be able to interface with those. We do reading for multiple sites and all images come into 1 system. There's bidirectional HL7 interfaces to handle other information and send back reports. 1 single viewer for multiple institutions. Building a workstation that sounds like it's basically just able to provide the different apps doesn't seem like much of an feat (or even new tech). 
And that is how it SHOULD be done. I don't know precisely how Dan's approach is configured, but it has the potential at least for unifying patient records, i.e., finding a prior from a different institution than the current study, presenting one unified worklist, and so on and so forth, all things Singular cannot do.

I'm constantly whining about vendors who don't make products that fit radiologists' needs because it is IT and the C-suite occupants who make purchasing decisions. The flip side is that most rads are not well-trained in informatics, and might well be taken in by "REVOLUTIONARY NEW TECHNOLOGY" such as this. I've seen it happen, and it isn't pretty.

Caveat Emptor. Spend the $500K elsewhere and do it right.

PACSGenius did leave a parting shot on the AM thread:
You are correct about one thing you are one of those Rads who is "non-well trained in informatics". What is it? Fear that you may actually be wrong? I'm done. No need say more.
At least he's right about that last broken sentence. He finally found a nail.

If I Had A Hammer...The SMT Epilogue

$
0
0
PACSGenius has wiped all his posts about SMT and changed his name on AuntMinnie.com to Burt Stone, I guess an allusion to Burt Wonderstone, and his disappearing act. Mr. Ellery himself, the head of Singular Medical Technologies, put a bit of an explanation on the now-defunct thread, but that paragraph, and even Mr. Ellery, have disappeared.

The most poignant punch line of all comes from someone within the radiology practice that spawned this spawn:
They don't know what the Hell they are doing and talking about.

Basically the work station is 4 seperate computers attached to one set of monitors which you can toggle between systems. The worklists are each on a separate computer but you can't pick from it. You have to log on to each PACS separately.

The Powerscribe works with all because its essentially the same hospital system and they share license agreements.

It's far from grounbreaking and after reading their posts and knowing them I have to laugh because they are really wet behind the ears and have very little healthcare experience...

Too funny.
Sadly, the good people of Sunshine Singular won't think any of this is funny. But this is the risk one takes to bring a product to market. Have you ever watched Shark Tank? Those who make the cut to stand before the billionaires already have some degree of success. Even so, I've seen some poor schmucks torn limb from limb by the Sharks. They respect confidence and knowledge, but being superbly accomplished businesspeople, they can see right through bullshit and hubris, and won't tolerate it for a second. SMT wouldn't have survived 30 seconds. Well, I take that back. The Sharks are probably not familiar with this small niche-market, and could possibly have been convinced to invest in this limited, brute-force "solution". They, like many docs and administrative-types who don't have the slightest grasp of informatics, might believe the distortions and out-and-out mistruths that were told about this product.

SMT may well blame me when their little company crashes and burns, but they really shouldn't bother. They didn't do their due diligence before investing a lot of money their "solution". They found that GE wouldn't talk nicely to Agfa and some fly-by-night charged them millions to connect and didn't deliver, so they created this brute-force solution. Maybe it works in their environment, sort of, and maybe not all that well according to someone who actually uses it.  But it is an amateurish, even childish mistake to assume in an uninformed vacuum that such a "solution" is going to make zillions of dollars, and to invest your own and other people's money chasing that dream. I've seen this happen up close and personal, when a friend came up with software that he was certain he would sell to every medical practice in the nation. Didn't happen. Won't ever happen. He and his sponsors are out about $50K. I did try to warn them...

I don't know if self-delusion is uniquely American or not, but I seem to see a lot of it on shows like "Shark Tank" and "America's Got Talent," not to mention IT departments here and there.  You see people who are absolutely, positively, adamently convinced that they have found THE NEXT BIG NEW REVOLUTIONARY TECHNOLOGY or have the greatest act the judges have ever seen, and so on. When their puny accomplishments are rejected by those who know better, these poor folks are so fundamentally shocked and surprised, their facial expressions are absolutely painful to behold. Maybe this is the result of the liberal philosophy giving everyone a trophy for showing up and breathing, but it is pitiful to say the least.

But don't worry. When I get around to creating Dalai PACS, it will be the best thing since sliced bread. Investment opportunities will be limited, so act now!!

Paris...

$
0
0

I have no eloquent words of comfort beyond those many have already spoken. We have lost yet more innocent lives in the name of unspeakable evil. Paris faced the terror over the weekend that Israel faces every hour.  It MUST end. 

This is a war. Literally, the war between good and evil. There is only one possible outcome, but it will be painfully achieved. Prepare for some painful times ahead.

Viewing all 249 articles
Browse latest View live