|
|
 |
| Implementing an electronic medical record (EMR) is a major initiative that should be undertaken only after a thoughtful analysis of the costs and benefits involved. |
| read more |
|
|
|
| ADA for exchanging data processing standards to the dental services of the health care industry... |
| read more |
|
|
| Barack Obama: In his Plan for a Healthy America, Obama calls for lowering costs through investment in electronic health information technology systems, acknowledging... |
| read more |
|
| |
|
 |
| |
| Implementing an EMR? Five mistakes you should avoid |
|
What dooms an implementation to failure? Size
can be a major factor, with smaller generally
being better. In my experience, groups of more
than three physicians often wind up with more
implementation problems, possibly because they
have more decision-makers to appease, more to
consider when planning and less flexibility to
respond to unanticipated events. But having a
small practice is no guarantee of success.
Here is a look at each
of these pitfalls - and some advice on how physicians
can avoid them. |
| |
1.
Vague Objectives
To say you need to know ahead of time what you
are trying to achieve seems like obvious advice.
But goals and objectives have a way of changing
when everyone is excited about getting a new computer
system.
One common mistake is to alter the scope of an
initial project after implementation has already
begun. Here's a typical scenario: A small practice
decides to add an EMR to its practice management
system, and it wants to be able to download lab
results from the main hospital to its EMR system.
The group presents its plan to the hospital administrator,
who is receptive and mentions the idea to other
practices. The hospital then decides to advance
its own information technology strategy and save
money by linking all local practices with a different
EMR. The practice that initially wanted to add
its own EMR is now part of a larger project -
under the direction of the hospital.
Changing the scope of a project after-the-fact-to
add sites not originally included or to expand
a system's functions - is guaranteed to sabotage
your implementation.
Vague or open-ended objectives are another problem.
This is usually the result of what I call a "technology
rush." Dazzled by an EMR demonstration,
key decision-makers decide that they must have
one of their own. The problem, of course, is that
they start to identify project objectives after
the software has already been selected. |
 |
2.
Bad Planning
There are several classic symptoms that an implementation
has been poorly planned, or that the money, time
and resources to pull off a successful launch
have been (usually) underestimated.
Critical implementation dates keep being missed,
for instance, or the cost of installing equipment
mushrooms beyond what was originally budgeted.
Key interfaces are not ready when the system goes
live, or staff productivity doesn't bounce back
because of insufficient training. Or the system
is only partially implemented, forcing you to
use both paper and electronic records.
Successful implementation requires a great deal
of planning. A partial list of concerns that must
be carefully mapped out ahead of time include:
wiring layout, equipment purchases, maximum load
response times, back-up strategies, staff training,
data migration, data security and disaster recovery,
and workflow alterations.
3.
Poor Project Management
.
Even with focused objectives and a comprehensive
project plan, many groups make a potentially fatal
mistake: They leave the management of the plan
up to their information technology committee.
Even worse, they may turn project management over
to the vendor, one of the partners' relatives
or the staff person who has the most time on his
or her hands.
Project management is an underrated skill and
is not an activity that can be handled by a committee.
Good project management requires a clear line
of authority, a sound grasp of project objectives
and sensitivity to resource consumption. |
| |
|
4.
Insufficient Senior Staff
This is likely to be a concern in very large practices.
You know your project lacks the involvement of
senior staff when a project manager is convinced
that some aspect of the project needs a major
overhaul - a different vendor or better equipment
- but can't even get a meeting with upper management,
let alone serious consideration.
Having senior staff on a project serves two purposes:
First, they may have overseen other technology
projects, so know ahead of time what can go wrong.
5. Poor supplier Performance
Even the best planned and a quirky wireless network,
flaky server, unreliable Web site or computer-to-computer
interface problems can plague managed projects.
Vendors often make promises that they cannot keep
or are blatantly false. The most egregious example
of this is unfinished software. Vendors, eager
to get a product to market, scrimp on testing
or leave out functions or features that they list
anyway in their glossy brochure.
Unwitting clients buy the software and then, under
the guise of customization, pay for finishing
the product. Or you discover that your practice
is the beta-tester for what was purchased as a
finished product.
The key to avoiding supplier problems is good
background research and detailed evaluations of
vendors and their products. Review the vendor
(as you would any company in which you're investing
a good deal of money) to assess its market
share, years in business and customer satisfaction.
Avoiding these mistakes will lead to a successful
implementation, something that is not a chance
occurrence. Instead, it is the result of quality
products selected according to detailed plans,
with clear objectives carried out by capable managers. |
|
| |
|
| |
|