HIStalk Quotes
Guest Article by Nurse Janus - From the Hospital to the Vendor World
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.
excellent piece. very helpful. very honest and important. we need more
like this!!
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?!!!!
Great article by Nurse Janus. A real world perspective that those of us
who are cloistered in hospitals do not get to see.
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.
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."
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.
My old website "Sociotechnologic issues in clinical computing: Common
examples of healthcare IT failure" might be of interest to readers here.
