Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

175 by stariya


									                         Transcript for 2008 VeHU Session #175

Implementation of New Nursing Technologies

Regina: I'm Regina Alexander Reis. I'm the BCMA coordinator and the nursing CAC at
the Eastern Colorado Healthcare System, Denver Campus.

My partner today is Kathryn Sapnas from VISN 8, Miami VA Healthcare System. She's
a chief nurse for nursing research and informatics.

Okay. All right. For the last decade or so, nurses in the Veteran's Health Administration
have seen an ever increasing use of computer technology in patient care. From charting
and nursing progress notes to smart IV pumps, bar code medication administration to
name just a few. Processes that were formerly carried out on paper are now done via the
computer. The movement toward computerization continues due to the benefits of
electronic processes in improving patient care. Recommendations such as those put forth
by the institute of medicine in their report, To Err is Human, continue to drive the move
to develop safer systems and processes through the use of information technology. In
order to realize the benefits in any information system, user acceptance is essential.
Implementation of computer-based processes will continue for nurses throughout the VA,
whether we want it to happen or not. In order to realize the benefits of any information
system, we must have these systems that are functional, useful for the end users as well as
safe for the patients. This can all be greatly facilitated through systematic

Kathryn: Safety, quality, and informatics; they are inextricably linked. You will want to
know why is informatics, nursing informatics specifically, a leadership position in your
organization. Although, it may not be titled as such, it is a key leadership position in the
organization. Nurse informaticists are at the table making decisions with their chief
executives constantly. It might be the way you think it is at this moment, the way you are
seeing it. I will share with you, you are critical to chief nurses in the implementation of
any process, project, or technology. The role of informatics in safety I don't have to talk
to you about. You know about that related to the BCMA initiatives, care management

175.doc                                                                                        1
                          Transcript for 2008 VeHU Session #175

initiatives. They are too numerous for me to add. We know that patient safety is the key
of what we do to keep our veterans safe. The clinical excellence initiatives that are in
progress, every one of these things are inextricably linked and informatics is the common
denominator across all services that are - that is the quality driver. The interdisciplinary
collaboration that nurse informaticists must demonstrate, must seek out, must engage,
much nurture are tremendous. The efficiency of the organization and the effectiveness of
the organization are all held in the realm of what the nurse informatic staff do, the data
they collect, the data they clean and screen, the data they analyze, the reports they
prepare, the walking up and down the halls looking at bar code and wireless connectivity.
The everything that we do.

So now that we're talking about implementations, I'm gonna bring up the ugly topic.
Let's talk about some failed implementation, 'cause generally we talk about the successes
that are had. How many of you have ever been part of a failed implementation? Who's
gonna admit it, right? Well, in - if you've lived through one of them - I'm interested in
failed implementations because I aim to have successful implementations. So the smart
person who wants to succeed says, "Let's look at what systems have failed. And there is
a fairly decent body of - I don't wanna - literature. There are Internet postings in varieties
of information technology journals which cite a range of failed implementations. They
go out to the business world and then they funnel through into health information
technology. And one of the first - I guess, one of the first readings that I did, I was
actually out searching the literature last night. I'm still on Asia coast time, so I'm still in
Asia. At 1:30 this morning I was looking at the literature, funny that it is, and I actually
found an entire paper that was written by Peter Bause in 2004. And he worked for
University of West Virginia, the College of Health Services Research. And he actually
has written beautiful paper that I can give a reference for. It's not attached to this. But as
I say, I found it last night. He does a beautiful paper on the reasons that health
information technology systems and their implementations fail. And he calls it, and I'll
quote, "the gap between the quality of care improvements made possible by the ability or
willingness among healthcare professionals to use them." So you're all nodding your
head, right? We can have the greatest things in the world, but if we don't have a

175.doc                                                                                           2
                         Transcript for 2008 VeHU Session #175

readiness to adopt, we don't have the literacy to begin, there are problems. So I think that
it's important to look at some of the failed implementations. One of the major examples I
found out in the business literature was the example of Hershey in, I think it was 1999.
Does anybody remember that? Did anybody have their chain pulled around Halloween in
that time? Well, Hershey implemented a new business model, a software model. But
what they did was they selected the wrong timing. It was around Halloween. They were
looking at their ordering, their billing, their delivery, and what happened was the software
did not perform the way it should have performed. They took approximately a 19 percent
failure in their income. They lost 19 percent of their revenue. It then affected the Jolly
Rancher distribution and Hershey Kiss distribution for Christmas time. So the timing of
an implementation is everything. So there were a lot of unhappy people, and probably a
lot of chocolate lovers really sad. So that's one of the biggest business cases that is
discussed freely in the literature. The US healthcare, there was a major of failure, if you
will, unfortunate for the gentlemen who led the initiative but it was the Santa Barbara
County Data Care Exchange. And there were problems that they had not foreseen about
related to the privacy and the data security. And that's also well-published on the
Internet. So when you think about some of those reasons of that systems go up and you
have something that you must implement, it's really valuable to look at those. So I'll be
happy to provide those references for anyone who is interested in them.

So what does it take to have a successful implementation? Firstly, a leadership team that
recognizes the value of nursing informatics. Nurse informatics staff perceiving
themselves as leader in the organization with informal and formal power. And you could
have a positive impact on patient safety, staff satisfaction, and patient satisfaction. And
on the left is a model that we looked at that's taken us probably six years to come to.
What does it take to work together, to be patient centered, outcomes driven? And who is
it that you have to work with to get this positive outcome? And so we find that we work
with data management. We work with IRM. We work with pharmacy. We work with
fiscal. We work with patient safety. We work with all the services within nursing
service. And so we do have a patient-centered outcomes driven model.

175.doc                                                                                       3
                         Transcript for 2008 VeHU Session #175

So what does it take to have a successful implementation? We'll start with our
stakeholder communication. I've already suggested to you that nursing informatics staff
are leaders in the organization. You may not be called leaders, but you are leaders.
You've got to be part of the communication of stakeholders in that plan. You've got to be
at the table with your chief nurse executive. There is a very, very valuable relationship
that is underreported, under-discussed, but critically important to the success. And that is
the relationship of the nurse executive to the nurse informaticist. You must have the
strategic plan. You must conduct in the organization assessment. We call it a gap
analysis, 'cause if you wanna see where you're going, you look where you are and then
figure out what's missing to help you get there. So a gap analysis is an organizational
assessment. You must really have a framework. You know, that may seem esoteric to
people, but the framework is really important, because that's like the organization of what
you're doing. Gugerty and others, Rook and Miranda suggested an implementation, a
framework that discusses implementations in three distinct areas, the pre-implementation,
the go-live and the post-implementation. And they do have research that supports this
model and so I bring this to you as an evidence-based way to look at these
implementations. This framework - and he is listed in the references so that you can read
those articles. And then in some of the business literature and a text book from
University of Michigan, I noted the concept of going between and within, and so in our
context, in health care settings, in nursing, we know that we have to work with each other
in our own department. WE have to reach out across to others in other departments in
nursing when there's an implementation. So nursing inside has to talk to all of its
departments inside of nursing. But we have to talk across nursing to other services like
IRM and fiscal, and the other services that were in the model. So that concept of between
and within has - communication has three clear layers. And those are coordination,
cooperation, and collaboration.

But this is a text of looking at the evolution of nursing informatics in the VA and this was
published from a study that was done in 2004 by Oyweda Moorer and Cathy Rick. And
it's in a book that was edited by Charlotte Weaver for those of you who know the
informatics textbooks. And it's in Chapter 12. It's - they actually did a survey on the role

175.doc                                                                                     4
                          Transcript for 2008 VeHU Session #175

of nursing and informatics. And you can see the informatics nurses, there are four clear
descriptions of what work the nurse informaticists do, what are your current roles. And
they surveyed staff nurses, nurse managers, and nurse executives. And you can see that
the area - that there's almost like an inverse - a flip of what the specific roles are and I'll
read some of them to you. Informatics nurses saw that their current roles had a lot to do
with education, with being a change agent, a facilitator. They did consultation. They
were advocates. Now, look where they put leader. That's like halfway down the list on
the left. Let me flip over to the other side where the nurse executive is. That's to your far
right. Nurse educators saw nurse executives as educators, consultants, facilitators,
project managers, change agents, and they saw leadership way down low. It's probably
the fourth from - fifth from the bottom. So there's like an inverse relationship in how
nurse informaticists see themselves and how executives see themselves. And I'm
suggesting to you that it's time for us to balance that out and elevate this level from far
more into the leadership role. You'll see that also staff registered nurses and nurse
managers also had the rating, clearly education was one of the biggest roles, consultant
and then facilitator. And as I said, I apologize for this, but I do have a scanned copy of
that chapter, and if anybody is interested in that, I'll be happy to provide that for you.

Now, these are more self-described roles in CPRS and BCMA implementations in the
VA. And I guess, I'd like to step back and say when we think about nursing informatics
in the VA, oftentimes, we think of BCMA coordinators, ADPACs, we think of CACs, we
think of a VANOD coordinator. We sort of think about people by the programs that they
run or the things that they do. So I'm hoping to share a larger perspective of rather than
task or program driver, a larger conceptual view of what informatics is. And here you
can see that the educator role is still the strongest role that was reported. And 91 percent
of the self-described roles with CPRS was education and 84 percent in BCMA. We get
down to leadership, 45 percent for CPRS and 59 percent for BCMA. So that's a
significant statistic that I hope that if I were to survey again right now, and six months
from now and a year from now that I would see that percentage moving up, because I can
tell you the team in Miami sees themselves in a different role than that. Everyone is
smiling now.

175.doc                                                                                           5
                          Transcript for 2008 VeHU Session #175

Okay, continuing. So the chief nurse executives role is really critical in the success in
any implementation. It's critical in the selection, the implementation, and the evaluation.
They must be at the table. It is nothing that the chief - and I've already talked to the chief
nurses too in another section and it's really something - you don't give an implementation
to somebody. You have to - part of that implementation, as an executive, working hand-
in-hand because any implementation of the technology whether it's PCA pumps, whether
it's glucometers, whether it's software implementation, it will affect the entire
organization. Sometimes we forget about that but that's really critical. It's not just a
nursing thing that nursing informatics needs to take care of. Your executive has to be
part of the decision-making and the nurse informaticist rules to keep them informed. It
requires alignment with various departments that were in the model, in the starburst
model that we have. It's a very complicated process and the chief nurse must be part of it
all the time. Don't protect the chief nurse from what you're facing. They need to know it
as it's happening, even before it happens. The chief nurse must be actively involved in all
of the overall decision making and implementation process.

The Association of Nurse Executives has guiding principles that they published about
four or five years ago to help chief nurse executives understand their role in health
information technology implementations. That's how important this is. You can see
there are, I believe, ten categories that deal with the pre-acquisition, the acquisition
before and after; there are negotiations and contracts, how the implementation process
will go and how do you manage the process because you see there are change processes.
There are managing change, managing projects and managing process. There's a return
on the investment and managing the benefits. That's looking at outcome metrics. There's
a post-implementation evaluation that should be formalized that typically is not, and
really understanding the overall issues, the policy issues that are related to information
technology. There are survival tips for a chief nurse executive and they surely need them
because these are vey tricky. Many CEOs, actually that have less than successful
implementations, find themselves in other positions often times. And in the VA, you
might want to know what the relevance is in the VA - although we don't have the CEO

175.doc                                                                                      6
                          Transcript for 2008 VeHU Session #175

and the Board of Director. You have a Quadrad; you have a VISN and a network. We
have the DUSH and the undersecretary all giving us directives and mandates. There are
clearly legal aspects in an implementation that should be discussed. You might be
wondering why am I mentioning these. Because implementations are not only the
BCMA and CPRS patch-upgrades but you know they could be negotiations with Class 3.
For example, that you're going with a vendor for or an implementation of a care
management system, Pisces, Careview, something else. It could be purchasing mobile
medication workstations etc. There are significant legal aspects. The nurse informaticist
and the chief nurse really need to be understanding those together.

You are a dyad. You should function as a dyad in the pre-acquisition. All of these
elements that I've just highlighted to you, before the selection - and that's just a picture of
me and my chief nurse executive, associate director Ginger Ward-presson and we have
been a team all the way along.

The domains of nursing informatics practice were listed in the certification exam. It was
just a few months ago, in preparing for this presentation, that I checked them. There are
nine domains of practice that are identified in nursing informatics; system lifecycle,
human factors, information technology, information management, professional practice
and models and theories. Every time you implement any health information technology,
be it laptops or mobile carts, be it the glucometers as I mentioned, be it a new telehealth
implementation that the chief of staff's office is implementing, you must think of all of
these areas. There are significant workflow issues. You can't take paper processes and
automate them and think you have an implementation because there are ergonomic and
workflow and human factors issues that must be considered. Information technology
really deals with your hardware, your software, your network, the network infrastructure
and the quality of your network communication. Information management is data
cleaning, data collection, data analysis. Professional practice means are you doing
primary care? Are you doing team nursing? Do you have another kind of model of care
delivery? The other issue is models and theories which none of you have to remember
from when you were back in school, but it has to do with the different models of

175.doc                                                                                       7
                          Transcript for 2008 VeHU Session #175

information technology. That's a computer implementation, computer science model; it's
very human, computer interaction model. Is there the data becomes information becomes
knowledge model? Those are things that every implementation that you are involved
with you must think of these six domains. In the most recent 2008 nursing informatics,
the A&A Scope and Standard for nursing informatics, they have added nine domains.
When I talked to you about that leadership the role of nursing informatics and leadership,
they are clearly defined, but then again, that's out of the scope of this talk.

In 2007, the HIMs, Charlotte Weaver and Joyce Sensmeir did a survey looking at nurse
informaticists and their roles and in the survey there were 776 respondents. The top three
roles that they reported that they were involved in were system implementation, system
development, and being a liaison. That's a very narrow view of the role of what the
informaticist does. You do so much more. I've tried to illustrate some of those things to
you before. That was what was in the literature.

If you think about the roles that I described from the Kathy Rick and Owyeda Moorer
chapter, the role of facilitator, change agent, educator; it far exceeds the three roles that
were identified but maybe were just not so good about telling people what it is we do and
how we do it. What kind of skills do nurse informaticists need of in terms of leadership?
These are in the A&A Scope and Standards. You have to have superb communication
skills. You have to have change management skills. You've got to be able to perform a
risk assessment. You've got to be able to build coalitions. You have to have some
political finesse and know when to keep your foot out of your mouth. You have to have a
certain amount of business acumen, and you have to be able to strategically apply a plan
and manage that plan.

You're doing this. I just think that we also often don't have the words to this or we don't
go back to our scope and standards that say we don't do this and therefore we're not as
empowered to be leaders as we could be. When I looked at the Scope and Standards for
Nurse Executives I found these things are common to nurse informaticists, so you might
ask, "Why is she going through all of this? We're here to learn about implementing

175.doc                                                                                         8
                          Transcript for 2008 VeHU Session #175

systems." I'm trying to point out to you, to be successful in a health information
technology implementation; you must take a leadership position. You must help people -
give voice to your own authority and create your role in leadership. So, what are the
skills that the nurse executive and the nurse informaticist should have together?
Computer literacy skills - you've got to have information literacy skills, project
management skills, I'd also like to throw in change management skills, being able to be a
consultant and being able to make judgments based on data, trends, and patterns. Those
are just a few of the similarities in the Scope and Standards for Nurse Executives and
Nurse Informaticists.

In the analyst role which is a very important role for the nurse informatic staff, you have
to know how to manage your outcomes. I'm always asking my staff, "What's the
measure? What's the metric of how successful we were? What is our benchmark?
Where do we improve? Where do we know where we're going? What's the measure?"
Then we have to take all the facts, the field observations we make, the conversations that
we have with the staff, the conversations we have with the managers, looking at the data
and reports and we pull all of that together and we synthesize that information. We're
also, in the analyst role, maintaining integrity of the data and the reliability. We're
reporting on aggregate data and identifying benchmarks. We're giving the chief nurse
executive and the Quadrad information that they can make major decisions for the care of
veterans on and for the work environment of nurses. We develop performance measures.
We assess performance on the performance measures. We're assessing workflow. That's
the analytical.

The nursing informatics competencies that I really think we need to focus on for
successful health information implementations are leadership, innovation is the theme of
why we're here this week, initiating, innovation and educating, computer and information
literacy, change management, project management.

What it really is going to take is a shared vision. That nurse executive, nurse
informaticist dyiad, is what is going to give you a solid foundation to collaborate with the

175.doc                                                                                       9
                          Transcript for 2008 VeHU Session #175

rest of your healthcare system and your organization. Make the vision a reality. You
look to your future to create the reality that you want to live. You have to work through
people. You have to be supportive. You have to encourage others. You have to learn
how to laugh. I think if there's one thing that I've learned, 'cause I'm a fairly serious
person, fairly scientific, but I have had to learn how to laugh a lot and I wanted to know
why did my chief nurse exec have a magic wand in her office because when things go
wrong, she tries to make it better with magic. We try to laugh a lot. Use your lessons
learned to turn them into best practices and share your results with others. Get out on the
trail, put posters together, do abstracts and submit your work to others.

Regina: We've rehearsed this a few times and I still get fired up about changing my
image and my role as an informaticist because I think that in spite of ourselves, for those
of us that we're homegrown into these roles, in the VA system, you just accept the fact
that you're a technician but then when you really start looking around you realize that we
possess knowledge and paradigms and nobody else possesses and the more important
thing is that we have to apply that for our nursing staff, to advocate for them because
they're the ones that are going to be making these systems work at the point of care in a
variety of situations, a variety of experience levels and they all have to be successful and
because we are nurse informaticists, we understand that. We can take that message
wherever it needs to go. We get a little preachy about this but we're going to move on
now. If you go out there and talk to your staff nurses - and with mine, I don't even have
to talk to them, they just look at me. They're like, "What now?" Like the old saying,
"The hits just keep on coming." It seems like there's always something that's coming
down the road that ultimately is going to affect nurses and it's got something to do with
some computer or something this or something that. I think they just feel a little shell-
shocked at times. Why do we keep doing this?

One of the big reasons why we continue to go and look for new technologies to help us,
support us in our efforts is safety. I know you've heard this before but it can't be stated
too often. Safety of patients and staff, as well, for that matter, can be one of the most
important considerations in implementing new technologies. Computer technologies can

175.doc                                                                                       10
                          Transcript for 2008 VeHU Session #175

place safety barriers within high-risk processes in order to improve patient safety. When
the systems are used properly, these safety barriers can prevent the user from taking an
action that might put a patient at risk. This can take place by providing decision support
tools at key points in a process. For example, a pop-up box in BCMA that says, "Check
systolic blood pressure before administering medication," or it can prevent a particular
action, such as with a Smart IV pump with hard limits, meaning that you can't program a
certain medication out of certain limits. Both of those are safety technologies that we
hope will improve patient care.

Efficiency is another aspect that we look to when looking at computer technologies.
Computer technology can be used to help us manage data and evaluate our processes in
order to make improvements in our care. It also provides easier access to the data and
easier retrieval, much easier than flipping through old patient records which I was
actually very good at. I don't know what the problem was. The data can also be shared
between disciplines. As soon as you hit enter or sign that off, that data is immediately
available to a multitude of users that might have need for it. By the way, even though my
slide says efficiency, you notice that I didn't say faster because I think that as we've
learned that efficient isn't always faster but other benefits outweigh the speed of the

Quality improvement; information technology offers all kinds of solutions for quality
improvement efforts as well. It allows for auditing to ensure a consistent standard of care
is delivered. Some examples of auditing include the use of the TIU menu in VistA to
search for use of a particular progress, note title. If you're familiar with care
management, it has a query tool within it that allows you to send search results to a
spreadsheet. You can make graphs that can be used for comparison and analysis within
nursing and shared throughout the organization. Our work translated into numbers that
everyone can understand and utilize. Being able to use data in this way allows for
measurement of performance against standards of practice in order to identify systems
issues and opportunities for improvement. The phrase "opportunities for improvement"

175.doc                                                                                    11
                         Transcript for 2008 VeHU Session #175

wasn't in my vocabulary four years ago but it certainly is now. I think that learning from
mistakes speaks volumes.

Decision support is another element that we can build in to technology at the point of
care. Some of the examples - and you'll see me going back to BCMA a lot because that's
my heart and soul - but BCMA itself is essentially a double check, against the 5 Rights of
Medication Administration. When used properly, it's got some decision support things
built right into it that will prevent medication errors from occurring. Same thing with
PCA pumps or smart IV pumps. We use those limits, hard limits, soft limits to make sure
that patients don't receive harmful doses of a medication inadvertently because of a
programming error.

Systems lifecycle - this was a four-credit semester course when I was going through my
program, and that was a clue right there that I probably shouldn't have taken two classes
that semester. It was fascinating but very intense. I've had to go over this material, living
it and reading it and reviewing it several times since then and actually every time I go
through it I'm like, "This is actually extremely cool." It's right up my alley.

All right, here it is, whole semester, one slide. We're just gonna do this in ten minutes.
This is what I learned the first time around. The book was this thick. Don't know what it
said but this is all you need to know. The design and implementation or upgrading of a
clinical information system should take a systematic approach. Fairly straightforward
sentence but when I think back on some of the things that I did when I first became a
CAC, there was very little approach and certainly not a systematic one but here we go.
There should be some planning for the system. First step - definition of the problem. I
know you've seen this before but really, sometimes we do a pretty poor job of this, you
know, defining what that problem is. An example might be if you've got narcotic
discrepancies, too many, too few, nobody's counting, whatever the problem is going
forward you start to say, "Huh, that's a problem that we probably should address. What is
it specifically? We don't want to have any more narcotics discrepancies. Why can't we
have accurate accounts?" Next, you want to do a feasibility study which is clarification

175.doc                                                                                      12
                          Transcript for 2008 VeHU Session #175

of the problem and identification of the information needs, the objectives and the scope
of the project. Scope of the project is something that you really need to be careful about
too. Sometimes someone gets a little sniff of what you're working on and it's like, "Hey
could it do this, could it do that, could it do this, and why don't you?" It's like, "Because
we're just looking at this problem right now." Make sure that that's another part that's
well defined. Efforts to maximize the use of the current system and make process
improvements in managing it should be evaluated. It may turn out that you don't need a
new system. You just need to use the one that's in place better, another very important
step. Sometimes you hear that we throw money at a project hoping that all our problems
will go away. Same thing - sometimes we throw technology at a project thinking this
will fix it. Not necessarily. You just may be changing the errors or the problems in a
process from a paper to a tablet PC or some other device but what you really need to look
at is the process and fix that first. That should always, always be part of the process. One
project we were looking at some of our nursing documentation and some of the templates
- changed some templates. People still weren't charting often enough or at the quality
that we would have hoped and it finally dawned on us, "Maybe people don't know how to
chart." It's not meant to be facetious or affrontment but talking to some of our new
nurses, they go to nursing school, they come out and we're expected to teach them how to
chart and instead we throw a template at them saying, "Do this." You can make a very
nonsensical note if you don't understand the process of charting. That's just an example
of how you might have to improve the process first and then jazz it up with technology.
The next step is to make some sort of a recommendation, "This is our problem, we've
looked at our process, we're doing the best we can with what we have, we really need an
Omnicell system or a Pyxis system for our narcotics management." Then there's the
allocation of resources and that's always money. Don't forget the FTEE associated with
that. We BCMA coordinators kind of know how important personnel resources are as
our additional duties sometimes just seem to appear out of nowhere. System analysis
comes next. You want to do some data collection to start off this process. The data that
you should collect should support the existing problem and the goal of the project. Going
back to our Omnicell situation, if we're saying, "Hey, we're always having narcotic
discrepancies." Well, you need to systematically look at the counts and document the

175.doc                                                                                     13
                          Transcript for 2008 VeHU Session #175

discrepancies. Where are they? How frequently? What units? What shift? Agency
staff or VA staff? Look at all those elements to see what the nature of the problem is.
Sometimes we collect data that doesn't really relate to the problem because that's the data
that we have but again, as informaticists, that's our role to know what kind of data that we
have and to take that data and analyze it so that it translates into an expression of a trend,
a problem, a process, whatever it is. I think I got that idea from Katherine, she said that
too. It is pretty crucial and I think that we don't realize that we're the ones that can do
that. Not everybody can look at some of that data the way that we can. Little analysis and
the review of the data comes next. Hopefully, out of that process, you'll be able to weigh
the pros and cons and come up with some clear benefits to implementing a new
technology, whatever that is.

Then there's system proposal and development. When you're coming around to this
phase where you've got the data and everything's all laid out, this is where your nurse
execs, nursing leadership and whatever needs to be walking side-by-side with you
because you tell them, "This is what I found." They're like, "You're right. We do need
this. I will support you through this. We'll make this proposal and we'll demonstrate
how this will benefit the organization as a whole." System design. We need to come up
with some kind of functional specifications of what the system needs to do. This is a
description of the system inputs and outputs and business rules necessary to carry out the
objectives of the project. Eventually this will probably comprise in some sort of a
manual of some sort. So using your Omnicell example, this would be where you say,
"Okay, the nurse needs to be able to come up and put her user ID and password and then
when she comes up to this screen, we should have the patients that are actually on their
unit populating this screen." That's the kind of checks and balances that go on at this
phase. Technical specifications is when I kind of leave the room. How the system does
what it needs to do. You do need to have some end users and some clinical expertise in
evaluating the end product of that. Some of the other technical expertise is going to come
from some of the other members of your multi-disciplinary team. You might want to
think of the hardware involved, the software involved, interface systems and a conversion
to data from the old system into the new system. Even though I say that interface

175.doc                                                                                       14
                          Transcript for 2008 VeHU Session #175

systems are really not my forte, which they aren't, but they're becoming that way because
I'm the only one that is that go-between, between nursing leadership and that technical
crew to explain what needs to happen to make it work for everybody. So I'm getting
better at it but it's like, "I don't understand." Implementation planning, details the
personnel, the time frames, the cost, the equipment needed, the tasks in implementation,
human computer interaction considerations and a plan to test the system. This is kind of
the fun phase right here but we're going to talk a little bit more about that later as I look at
some nursing applications but don't worry about that. We're almost to the end of the
semester now.

Functional testing is the next phase as we go into that homestretch where we're looking at
testing and implementation and go live. Our functional testing is just basically
verification of the databases. If you go to this Omnicell and it shows up a list of patients,
is that actually the list of patients as it displays in the ADT thing and CPRS and
whatever? Those are the kind of data validation processes that go on here.
Integrated system testing; this can be testing between applications on the same system or
applications on two different systems; i.e., Integration between BCMA and CPRS or
integration between VistA and our Omnicell software. I think people kind of get that.
End-user training and this is critical. Our end-user training needs to be as good as you
can make it for that end-user, no matter how they react to you or what you're bringing
them. It needs to be hands-on and interactive whenever possible. They need to know
how it works. They need to know how it's going to be integrated into their environment
and into their work processes. "Well, I work on psych. Well, we don't do that down on
the community living center." I'm like, "I know and we will look at that." Any kind of
reference tools and support that you can give to them you need to look at providing
because the more - that nurse informaticist actually is the one that's going to be
supporting that end-user. I know my nurses in Denver trust me so if I tell them, "This is
going to happen or that's going to happen," I need to make sure that that's going to
happen and if it doesn't, they let me know and make me change it.

175.doc                                                                                      15
                         Transcript for 2008 VeHU Session #175

Our go live work plan is the part that everybody hears about. It's like, "Go live, go live,
go live." Do not forget the planning ahead of time and we'll look at some examples a
little bit later on about some implementation experiences that I've gone through where
you'll see how important the planning is. First of all we need a description of the
preparation that needs to be done. One thing that we've done recently is we put in new
vital sign machines that throw the data directly into CPRS but we mounted them on the
walls in the room. That was an infection control consideration. Some of the preparation
we had to do with that was we had to see if all the computer jacks were live in all the
rooms because there's a phone jack and there's a computer jack. Everybody uses the
phone jack, but we didn't know if the computer port was live and as it turned out, a lot of
them weren't, a lot of them needed to be changed. Actually, some of them had to be
moved. So that's some of the preparation. Where are they going to go? I had to go
around to three different wards with sticky notes and a pencil and mark on each wall
where they wanted them to go because our engineers would then know where to mount
things on the wall. What's the timeline going to be for this? If we're having to put in wall
mounts then how much time do we have to do for that? If all the ports are live then that's
going to change the timeline but that needs to be specified from beginning to end as much
as you can. You need indicators for completion of critical task, then who all is going to
pass on that information so the next phase can be activated. Again, going back to our
mounting of the vital sign machines, how are we going to know when all the ports are
live? I'm not an engineer. I don't work in FMS. We're not even near each other. Like
them, they're great, but we don't see each other. How am I going to know when all those
ports are live? The telecom guys are calling me, "Okay, they fix the port?" It's like, "I
don't know." You have to make those decisions and develop that communication
network so each phase can proceed. I'm good at passing messages so I don't mind doing
that. It's like, "I got the message. They're done." Activation of a new technology is
always an event for everyone. People try to take days off. I never understood that. I
actually always wanted to be there. "Dude, really schedule me, I'll come. I'll tell you."
There are four generally accepted methods for implementing and these are actual terms
that are in my reference which actually is not in the references. We changed our slides
around a few times, like 12 and I think I lost the reference page that one was mounted in

175.doc                                                                                     16
                          Transcript for 2008 VeHU Session #175

but this comes from the Essentials of Nursing Informatics, a great textbook that came out
'06. It's a nice encyclopedic reference for informatics nurses. I highly recommend it.
The first method is parallel implementation. This is where you have the old and the new
system running side-by-side until the users completely convert to the new system. Our
example that I can think of where we used a parallel system was with our IV pumps. We
got new IV pumps. We had these really ancient ones and we got these really new ones
and it was big change, tubing and everything but the actual pumps being changed on the
patients kind of happened in a parallel method. Think of the ICU where you've got this
guy that actually is getting ready to be transferred out so we're taking all of his IVs out,
change all the pumps in that room. However, the guy in the next bed, actually in the next
bed, has six pumps, critical things flowing through. Don't touch it or something adverse
might happen to the patient. They continued to use the old ones until it was safe to
change those out. Probably over about the course of a week, we got them all phased out.
Actually, it was one day and then two days of rest and they were all changed. That was
the best example of a parallel implementation I could think of. A pilot is where one or
two groups or persons will try new technology and then help others as they start to use it.
Back in the Air Force, we used to call see one, do one, teach one. It's kind of the same
idea. This can be either a super user where you'll have someone in the environment that
gets trained on the new IV pumps. It's like, "Okay, you're the new expert. Go and make
sure that all your people know how to use it." It can be where you're a pilot site. We
tested a VANOD skin templates so our feedback that we give to this central group then
goes on to help make the transition easier for subsequent users as they come on board
with it. The phased-in approach is where you have one unit or one group activated at a
time. I kind of use my people standing in line. I actually thought that was kind of a
clever graphic. I hope it is. That's the way it kind of happens, next, next. Example is we
had generic logins on our PCs and then one day they just put out a schedule, third floor
all your generic logins are getting turned off on this date, start logging in as yourself.
That happened on that date, a few days later, fourth floor, a few days later, seventh floor.
It was just this next, next, next kind of thing. That's an example of a phased-in
implementation. Big bang theory is where the old system is turned off and the new
system turned on. Everybody starts using the new system. Sometimes this feels like

175.doc                                                                                        17
                          Transcript for 2008 VeHU Session #175

there was poor planning, and you just kind of close your eyes and flip the switch and see
what happens. Actually, there's usually more planning than that and actually using of a
big bang theory has more to do with the nature of the technology that your implementing
rather than planning per se. Example that I thought of was our RDP migration in Denver.
We're part of that Region 1 regional data repository thing that went down on us a few
months ago. When we changed over, lots of preparation and sweating a head of time and
then we took it down. Four hours later when it came back up, everybody was on that new
system. Nobody knew but everybody's sweating, "Do the printers work? Do the reports
work? Does everything work?" You had that big changeover all at once.

I know I'm not as funny as I think I am but I like to stuff you guys myself. Just bear with
me here. System evaluation and maintenance is the last phase and it's really not the end
of the process because it's a continuous and an ongoing process. When you're evaluating
a system, you should be able to use the criteria that you established in the planning phase
to see if this system accomplished your state of objectives. You're not really going to be
able to evaluate it well if we didn't define the problem properly and do our data collection
and analysis sufficiently because you're going to be doing those comparisons. All that
work that you do on the front end is going to be used in the evaluation phase to see, did it
change? Is it the technology that it made it better or did we improve our processes or
maybe both? All valuable information. The system evaluation is continuous, and it's
associated with quality and improvement that is monitoring an assessment of the process
in question, like narcotic administration. It's also meant to continually evaluate the
meeting of the needs of the end-users. Can nurses effectively administer their narcotics
when they have to come back to the Omnicell and sign them out? Does that whole
approach work?

Application in the nursing environment. We kind of go through a little bit of the same
things that we listed before but just kind of stretch it a little bit more into the healthcare
environment. Where's the information coming from that's used and is it accurate? This is
one of the questions that gets answered when you were looking at functional testing. If
we're actually in a healthcare environment you know that exchange of information has to

175.doc                                                                                          18
                         Transcript for 2008 VeHU Session #175

be pretty seamless because we have people making clinical decision based on that
information and where it is at any particular point in time. For example, if we're pulling
information from the drug file with BCMA, is it consistent with the way it displays in
CPRS or any other part of the system where one might access the drug file? Work floor
analysis looks at the steps in a process as it was intended to be carried out. I keep
emphasizing that "as it was intended to be carried out" because I am a BCMA coordinator
and I will leave it at that. The process may be defined by some sort of practice standards,
a local policy or some other authoritative source like the deputy undersecretary of
whatever you will do this this way at this time. We do but there are standards by which
we define the process, and we just have to see how that works at the end-user level. If
you were implementing a program such as BCMA, you're going to want to look at the
process of medication administration and then see how well BCMA mirrors that process.
The most successful implementation is going to come when that technology mirrors the
actual safe practice that is in place. Documentation of policies and procedures is
something that we just can't get around. We just got to do it. Once we agree upon
whatever that process is going to be that involves that new technology, then we have to
document that in the policy and procedure so that the standards for monitoring and
assessing the system in the future will have some foundation. That was my very first job
when I took over as BCMA coordinator. I got to write the BCMA policy.
It was very cool. It worked out, people helped me. It's all good. Sometimes I can't
believe some of the things I did though with no knowledge but that's where it takes a
village. I had tremendous support by my ACNS and sometimes there was a certain way
that our ACNS for operations would just kind of walk towards me and just kind of come
in and, "Just sit down for just a minute." I'm like, "Oh no, I did something really goofy."
She was just very gentle with telling me what I needed to do. She didn't just say, "You
can't do that. That's wrong." She really sat down and said, "This is your job and I
understand what you're trying to do and this is the greater organizational structure that
we're going to work in so I need you to translate it into this form or that." That was
invaluable for me because I was pretty clueless. I was a great nurse, but I didn't know
what I was doing. Go live is our next phase. This needs to be structured so that all
nurses have the same level of support during the whole entire process, whether they work

175.doc                                                                                     19
                         Transcript for 2008 VeHU Session #175

nights, evenings, weekends, holidays or whatever it is. If everybody's expected to use
this system in the same way then training, education and support must reach all nurses.
Again, this is another part where you can bring in your nurse exec support discussing
with the nurse managers, "Look, I have to have these nurses in a classroom for two hours
before this date," kind of work that out. It might be necessary to call in agency staff
during the training phase. When you actually implement, there may be a need for extra
support and if you have VANOD data or some way of assessing hours per patient day
then your nurse exec can tell you, "Okay, we have this many nurses around during this
time of the day. We're going to need three or four of you around to support." Or on a
night shift, "Well, you only need to be two of you and you can be here or there." You
have a collaborative relationship in which to successfully implement your system.

Evaluation of an implementation process. We're just going to look at a couple of
examples that I've experienced. They're not bad examples, they're fine. We'll see.

First thing I'm going to talk about is our PCA pumps with programming software, where
our PCA pumps actually have a little cable on them and you connect them to the PC that
has a software on it and you do the programming within the software and then once all of
the checks and balances have been confirmed there, it sends the programming to the
pump when you're doing new medications. It was kind of cool. It wasn't flawless and
that's okay. We did have a systematic evaluation of the problem and potential solutions
for the problem and that problem being, medication errors associated with
misprogramming of PCA pumps. Now a PCA pump programming is an inherently
complex, high-risk process. It just is. The data in the National Center for Patient Safety
Database supports that. It's just complicated. You can't get around that. One of our
findings, out of Health FEMA on PCA pumps, decided that getting new machines would
be beneficial. Key stakeholders were involved on the team; safety, nursing, pharmacy,
education, had frequent meetings to stay apprised of all the aspects of the project and so
nobody kind of forgot about where we're going and what our projected timeline was. Got
approval for the funding for the project based on that group's work. They did a lot of pre-
planning, great data gathering and analysis. Staff were involved in a testing of the pump

175.doc                                                                                   20
                          Transcript for 2008 VeHU Session #175

as well and that's really key. I think we had two live pumps that we put in the ICU's for
a week and let end-users actually use it so we could evaluate that for them more
effectively. Education. I don't know how we did this but one of the reasons I wanted to
share about this one was because we got 67 percent of the nurses that would be using the
PCA pump trained before we went live. We really advertised it. We tried to organize it
really well. We had vendors there around the clock. I was there a lot of times just being
head cheerleader about everything. I did a little show and tell, "Here this is what's
coming. You need to know how to use it. Come on down to the training." That just
worked out kind of well. 67 percent might not sound a lot but that's a huge training
number for nurses. It's so hard to get at them. There are a couple of things that could
have been done differently in spite of all the good things that happened with this. The
software for programming the pumps actually was released after we got approval for
going forward with a purchase. I wasn't there when all this drama happened. Somehow
the software got slipped in to the final approval for the purchase. It was like, "Do we
want the software? Yeah, we want it. Okay you can have it." Sign and that was it. We
didn't have a chance to try to test the software beforehand because it hadn't been released.
We actually were the first people in the country to use this software so the vendors
actually were incredibly supportive because they really wanted to evaluate their product,
but we didn't know about that ahead of time and staff didn't get to test that so the trial that
we had done with the live staff didn't involve the software. Now we've got to teach a
different process. So a couple of lessons learned…I actually thought this was a great
implementation. It really went well but no matter how much planning you do, there's
always something unexpected that happens. The better you plan, the better able you are
to accommodate the unexpected. This little software deal, like I said, people were
meeting regularly, all the stakeholders were involved, light bulb goes on in a meeting.
We're fine but somebody said, "Does IRMS know that we have software?" Then
somebody called me to the meeting and they gave me that question and they said, "Does
IRMS know we have software with the new PCA pumps?" I'm like, "There's software
with the new PCA pumps?" Within 90 minutes we probably had talked back and forth,
evaluated what exactly it was and had determined it wasn't going to be an issue because
of the way - it just kind of worked out for us. With some key stakeholders involved, we

175.doc                                                                                     21
                          Transcript for 2008 VeHU Session #175

were able to mobilize the proper resources. Just so you don't think I'm completely goofy,
I wasn't on the Health FEMA that talked about the PCA pumps but once they said
software then I put myself on the team and everybody's cool. It was all right. The other
lesson was that we need to use every method available to train users and to also support
them through implementation. We had posters. We had classes. We had roving just in
time training. We had announcements. Every time a vendor came into our building, I
took them to a unit because he always had the stuff and I'm like, "Can't we just go show
these girls? I don't think they saw it last - or come on we can catch the evening shift guys
in ICU, they're the ones that really like the gadgets and we can kind of get them up on
board with that." That was another lesson that we learned.

Another practical application is the clinical flow sheets where a test site for a VA clinical
flow sheets product, this is a very cool project. I'm very excited about it but our primary
principle going into this project was to keep the stakeholders informed, and that is the
nurses that are going to be using it, the technical staff that's going to be supporting it,
anybody that we knew. I told our biomed engineer about it. She's like, "Do we have a
role in this?" I'm like, "I don't know but you know about it. I don't know. I don't think
so. Maybe you will. Who knows but here, come to the meeting. It's okay." She was
very cool about it; unit managers, staff, technical personnel, nursing leadership,
everybody. Functional testing has been kind of a fun way to kind of give people a sneak
preview of it. Bring them into the little training room. We'll show them the test account
and what we've built so far and what we changed, and it's nice to get a preview of that so
that the final product will be accepted by the end-users. Workflow analysis and I have
this text sort of graying out to kind of show where we are in the process. What we
learned very, very quickly is the nurses were not impressed by the technology of it. Their
concern was their workflow and it was everybody. "Well look, right now I just take my
sheet to the bed side and right from the monitors. Am I going to be able to do that with
this?" I had a nurse come to me, "Regina, you bring this stuff into the unit, I'm quitting.
I'm through." She was extremely serious. I just said, "Okay." I don't know what to say.
She was very definitive but that taught us something right away. Yeah, it'll be cool if we
can have the best flow sheet possible structured but nobody's going to use it if it's not

175.doc                                                                                       22
                           Transcript for 2008 VeHU Session #175

convenient for them because we don't have a clinical information system in place now so
we are testing the manual entry aspect of that. That brings a whole new realm of it and a
couple of them brought that up, "Will this automatically download from the monitor into
the sheet?" We're like, "We'll try to see that it happens." It really helped us to establish
our priorities and we listened to them and we haven't shown it to them anymore until we
get some better solutions or something that will be useful to them. They're scary people.

Whatever the technology, we want it to be successful, whether it's for the nurses, for the
patients, for the VA, for our organization, for nurse informatics in general, so Kathryn is
going to take over now and we're going to just finish out with a little talk about how we
measure success in nurse informatics.

Kathryn: Thanks Regina. Well, now that your blood sugar is 45 after lunch, and I've
given it enough time, I think we're going to just look at the evaluation. I wanted to make
just a few summary points as you evaluate information technology implementations.
First important, these are the little pearls, manage your scope creed, your time, your
budget, etc. Always consider that staff need to understand why you're implementing
whatever it is you're implementing. If they understand that it's to help keep the veterans
safe, if they understand that they can be a part of it, they're going to adopt it a little bit
better rather than just being faced with it. Consider students, faculty and the community
as part of your implementation plan because that will come back to get you at the end if
you don't. When you select the activation method, have a risk management strategy
because Regina mentioned, something will go wrong. The best implementations have
something go wrong. Think of whatever could go wrong and plan for that. Remember
the example I gave you with Hershey's, timing is everything. It's best not to implement
during a holiday. Anyway, now that you've got those summary pearls, I'm going to show
you an evidence-based measure of an implementation and evaluation. Briar and Gugerty
developed a tool and he presented this at the nurse informatics conference in South
Korea, I believe it was in 2006, and it's really a nice tool and it's a 37 item questionnaire
and it's marked on a Likert scale, whether you strongly agree or disagree. It's valid and
reliable and anybody who's heavy into statistics and would like to read this psychometric

175.doc                                                                                          23
                            Transcript for 2008 VeHU Session #175

validation of the properties I do have the papers and have read them. I'll be happy to
share them with you. They're really not that bad. The bottom line is the total score on
the 37 items will give you the likelihood of a nonproblematic or a great implementation.
When I looked at this, and I've embedded it for those of you who want to look at it.

But the tool is in here. Just 37 items, it's like a fold out brochure and he has one dark and
one light, and I'll just show you how it looks.

I've made some slides. It's free. It's available for use. The web link is in your handout.
What I think is important about this valid and reliable measure is that Gugerty developed
this in a VA that will not be named during the implementation of the BCMA project.

He was very grateful to be able to give back to VA and say that this is actually his
dissertation research but because it was a little hard to read, I just wanted to show you
how the brochure looks like front and back but there are examples of the questions. I
think about taking these questionnaires before an implementation and talk to the staff. I
would say, "How do you think the system's going to improve your practice once you talk
to them?" Take the questionnaire that you would measure at the end of an
implementation and just ask those questions to people before. That will give you an
indication. Another example of a question is, "Were there adequate resources available
when I was learning how to use the system?" Ask the nurses. "I feel the use of the
system has improved my patient outcomes. The system takes into account specific needs
of my patient care areas. Members of other discipline should receive more training on
how their entry information affects my use of the system." Overall, the introduction to
the system has been effective. Here's another example of an item. "I am physically
comfortable when I use the system."

Those are the kinds of questions, as I say, there's 37 items that can be used. I call it an
education tool, a screening tool. If you're looking to move to evidence-based practice,
this would do it for you.

175.doc                                                                                       24
                         Transcript for 2008 VeHU Session #175

I would use it as a pre-measure and as a post-measure and you have exceptional nurse
researchers out in your areas that would be very interested in doing things like this for
you. Anybody who's looking at doing additional graduate work, this would be a great
work kind of project.

175.doc                                                                                     25

To top