Subscribe to Updates

E-mail:
Name:

No title

Search HIStalk

 
WWW HIStalk
No title

Blog Status

  • 6 yrs 2 wks 1 days old
  • Updated: 9 Jun 2009
  • 915 entries
  • 2,022 comments

x
Platinum Sponsors










x
Gold Sponsors







HIStalk Quotes

Guest Article by Nurse Janus - From the Hospital to the Vendor World

posted 03/06/2006
HIStalk

Nurse Janus recently left hospital practice to join a software vendor. She's been keeping a diary of her experiences and offered to share them with HIStalk readers. Let me know whether you'd like to see more from her.

I thought IT would be a fun and interesting place for an old nurse to land when I left the hospital this past year after 20+ years. It has proven to be way beyond interesting, but not always in the way I expected.

Among my beliefs when I started: 1) software works right out of the box; 2) no company would sell a software product until it is actually finished (with one exception - another story - see below); 3) CIOs wouldn't be dumb enough to buy software without actually seeing that it works first; and 4) people who develop software know something about clinical workflow. 

It has been a 'long, strange trip' learning that none of these are accurate. Now, I'm not a young woman, and I love to read business stories (last two books - reread
The Smartest Guys in the Room and The World Is Flat), but it's the scope of what I've seen in IT that amazes me.

So here's the story I promised in the last paragraph. As a senior nurse, one additional project I worked on in my last hospital was our "computer charting." This was to have been implemented around four years ago. I was there two weeks ago for a visit and the place is still all-paper charting. The software engineer who went with me (it was a "follow-a-nurse" thing I had set up for my company) was appalled at the number of forms we use to document patient information by hand. But I'm getting ahead of myself.

Two nurses in every hospital unit were participants on the "Automated Charting Committee". We met with the IT company guys every week for a couple of months, and then every two weeks for another six months. The hospital was paying us nurses (hourly workers) for the overtime we were putting in on this project, but some of us were so excited that we even worked a lot of unpaid OT. What we did was create Excel spreadsheets with pick-list-type selections for charting assessment and flowsheet information to give to the developers, and also provided workflow scenarios for them. We were told that this information would help the software company "customize" our hospital's system.

At the same time we RNs started working on this, the hospital took out its old order/lab system and installed a new one. By some incredible coincidence, the company that made the new order/lab system was the same as the one which made the charting system! The new system was a little more cumbersome (slow screens, weird layout, and an additional step to enter orders), but we all put up with it, because we were told that once the new charting system was in, the order/lab system would work much better. We were all looking forward to the benefits of a nice, integrated system. (I can hardly keep from cracking up just typing this. But when I was looking for a job like this, I thought this company -- which rhymes with "Trick Messin" -- was just a fluke in the IT biz.) 

Nine months after its inception, our little committee had yet to see an actual screen on an actual electronic device, even though we were supposed to validate the "work in progress" starting at Month 2. We had finished our work. I couldn't help but wonder how much free clinical expertise we gave away (a LOT) but something went on behind the scenes which we weren't privy to. We were assured that the program was almost ready to be installed, and we would see it in the unit in eight weeks.

The hospital suddenly yanked out the new order/lab system (installed almost a year back in preparation for our wonderful new integrated system) and reinstalled the old one. Now all the people hired in the interim, trained only to use the fabulous new system, had to be trained on the old one. So did those earlier employees who had since forgotten it. Let's  see what this cost our "nonprofit" hospital:

  • Charting system cost (hope it was free, considering there was nothing in it)
  • Order/lab system cost
  • Charting system installation
  • Order/lab system installation
  • 18 RNs x 4 hours/week x 36 weeks x $30/hr (yes, we work cheap)
  • Training all staff on new order/lab system
  • Training all staff on old system once new one was unceremoniously yanked out
  • MD training time, and extra aggravation for the RNs who had to listen to them complain about the new system
  • Extra time and effort expended to get things like transfusions and bedpans ordered with the crappy new system
  • Many other items I can't even begin to guess at.

I won't even go into the whole intellectual property thing, but we RNs on the committee felt a bit used after the whole episode. I wonder if our combined expertise is still floating around that company somewhere? And by the way, not the hospital CIO but the next person down from him abruptly left her job.

Yes, Virginia, companies do sell bad software (or no software at all) and CIOs buy it. The software is bad because the people designing it have not "worked the floor" for years, if they ever did. The whole product/sales cycle is slowly becoming clearer, particularly after seeing HIMSS, which seemed almost Enron-esque to me. Everyone here got a short video of the HIMSS experience, and after watching it, I must say that all the display folks looked jim-darn-dandy in their lab coats and scrubs (OK, really I was nauseated, but don't tell anyone.)  

I would just like to raise awareness among the IT community of the other side of software - the low-level client side (nurses, nurses' aides, X-ray clerks, etc.) which has to muddle through trying to get medicine, lab results, and information regardless of what IT obstacles are put in their way. My wish is that perhaps engineers and marketing people will think of the night-shift Asian nurse working her 7th shift in a row because she needs the OT when designing software (and remember, she doesn't even know how to use a mouse, and no one will be able to understand her free-text entry.) No one wants the wrong blood transfusion or delays in getting their meds, but the situations I described can cause that.




1. Ross Koppel left...
03/07/2006 12:13 am

excellent piece. very helpful. very honest and important. we need more like this!!


2. dixie left...
03/07/2006 12:29 am

The Nurse Janus article was great ... when are CIO's & Hospitals going to see thru the vaporware and start getting in control of their decision making process and stop believing anything the vendors say unless it is in writing AND in the contract with solid and definitive performance guarantees?!!!!


3. reader left...
03/07/2006 7:38 am

Great article by Nurse Janus. A real world perspective that those of us who are cloistered in hospitals do not get to see.


4. Doctor Dalai left...
03/07/2006 8:48 am :: http://www.doctordalai.com

Excellent, very articulate essay. Nurse Janus' experience parallels a lot of the difficulty I have with PACS companies. It is clear that many of them let the engineers run wild, and maybe get an old radiologist or two to sign off on their latest production. I then have to get my least technical radiologist to understand what the engineers had in mind, occasionally an impossible task.

There is a tremendous disconnect for some manufacturers between the writing and the actual use of their software.


5. PM left...
03/07/2006 1:24 pm

Nurse Janus herself complains about the "extra aggravation for the RNs who had to listen to them (MD's) complain about the new system." For me, it was aggravating listening to her complain about this obviously mis-managed implementation and to then glean from her experience that "HIMSS...seemed almost Enron-esque." In addition, I would hardly say that anyone involved in the implementation of a clinical system could possibly ignore the "low-level client side." "Nurses, nurses' aides, X-ray clerks, etc." all like to bitch just as much as MD's when it comes to perceived "IT obstacles (that) are put in their way."


6. J Doss left...
03/07/2006 3:19 pm

Unfortunately what Nurse Janus reports is true in any "line of business" I have worked in IS for many years working with all types of businesses and am amazed at the people who buy a product based solely on their relationship with a sales person. My advice to anyone thinking of purchasing a software product for any line of business is to demand the following from the company and themselves. 1. Ask for a list of their existing users with names and phone numbers of people to call. Discuss their experience with implementation and use of the product and their perspective on ongoing support. 2. Find out how many users they have and compare that to the list they give for contacts. I worked for a small software company with over 100 users. Because our owners were customer service oriented, part of our "mission statement" was to always be able to provide our complete user list to prospective clients. 3. Ask for their financials - software companies have a real challenge managing cash flow. Find out how long they have been around. 4. Do some site visits if at all possible. Talk to existing users that are comparable to your size business. 5. Find out about their employees. What is their employee turnover rate. What are their backgrounds. 6. When you are negotiating your contract with the software company define timelines they are expected to meet and cost incurred by them if they fail to meet the timelines. 7. Before you go looking for a software package have a clear definition of your needs and expectations for the product and do not "assume" anything. And don't let them tell you it is coming in the "next release" (aka vaporware). Realize realistically that unless you can afford and want to develop custom software (which has its own headaches), no vendor application will do 100% of what you want. Identify the critical areas that must work as you expect them to work and have them show you those areas in detail. 8. Once you have narrowed down your choices, take the time upfront to get to know the application. Consider sending one or two people to training rather than viewing just a canned demo. Granted all of the above takes time and effort on the part of the business making the decision and people usually are busy trying to do their real jobs but if it isn't done then stories like the above will continue.


7. Scot M. Silverstein, MD left...
03/08/2006 2:44 pm

My old website "Sociotechnologic issues in clinical computing: Common examples of healthcare IT failure" might be of interest to readers here.

http://home.aol.com/medinformaticsmd/failurecases.htm