Implementing Systems OverviewHealth information technology (HIT) e.pdf

Implementing Systems Overview
Health information technology (HIT) encompasses implementing a broad scope of applications,
technology, and operational activities (1.1 HIT Visioning and Strategic Planning), depending on
your organization and its goals (1.2 Goal Setting). This tool provides an overview of a typical
implementation of an electronic health record (EHR) system for a hospital. Use this tool to
understand the broad range of topics that you will need to consider during HIT implementation.
Overview of Implementation
Although specifics with respect to an implementation will vary by vendor and application, any
implementation should follow a similar high level structure:
1. Project management
2. Workflow and process redesign
3. Detailed plan creation
4. Issues management
6. Preparing for and installing hardware
7. Network development/refinement
8. Security risk analysis and controls
9. Super user training
10. Software installation and system configuration (a.k.a., “system build”), including report
writing, interfaces, data conversion
11. Testing
12. End user training
13. Preparation for go live
14. Go live
15. Benefits realization and recognition
16. Optimization strategies
Project Management
Even though your vendor will supply significant project support, you need to designate an
individual within your hospital to be the project manager, representing your interests and
ensuring that information learned during the process is retained within the hospital for future
reference. (1.2 Project Management, 1.2 Project Management Job Description)
Your project manager will be responsible for many activities:
o Managing your harmonized project plan, making sure the project gets completed on time and
within budget.
o Organizing your staff resources, team building, maintaining the project budget, approving

invoices, and handling other elements of making sure the hospital completes the designated tasks
on the project plan completely, accurately, and on time.
o Carrying out your communication plan (1.1 Communication Plan), including reminding others
to perform their necessary communications and potentially even scripting them for others such as
the CEO.
Workflow and Process Redesign
Ideally during the planning phases you will map current workflows and processes, using these to
initiate change management and create expectations to achieve goals, to help you identify system
requirements and select the most appropriate vendor, and potentially even to make adjustments
in workflows and processes today where streamlining or other improvements are feasible without
HIT. Mapping current workflows and processes gives you slightly less work to do during
implementation. This step is essential for configuring the system to your specifications and
anticipating changes with the new system.
Over just the past few years, the industry as a whole has come to recognize that not attending to
workflow and process redesign during HIT planning and implementation has led to less than
desirable adoption rates and sometimes even serious consequences, where unique considerations
for the hospital were not evaluated and addressed in system configuration. Some vendors now
strongly support the activity, while others still view it as largely an organization responsibility.
Whether your vendor supports workflow and process redesign or not, this activity has been
found to be an extremely important element of success. (1.2 Workflow and Process Redesign)
Create Detailed Implementation Plan
Every vendor will provide you with some form of implementation plan. This advises you of the
steps to be conducted to implement your system and usually identifies what the vendor will do
when, what the vendor expects you to do when, and what is performed jointly—incorporating
specific meetings and milestones. You need to take several important steps when you receive this
project plan. Hospitals often overlook some of these steps. Missing them may come back to
haunt you.
o Review the plan against the contract you signed with the vendor to make sure everything you
agreed to buy has been addressed in the plan and that nothing is in the plan that you did not buy.
Most vendors take a standard plan and make adjustments for each client, which can lead to the
discrepancies with your specific contract. (2.1 Project Plan)
o Review the plan thoroughly with the vendor’s implementation specialist, making sure any
discrepancies are addressed. Also, make sure you fully understand each item in the plan—
especially those you will be responsible for. Consider the staffing and other resources you will
need to complete the activities in the time allotted.
o Harmonize the vendor’s plan with your own. The vendor’s plan only identifies those elements

for which the vendor is responsible—directly or indirectly. You may need to conduct any
number of activities in relationship to the project. Some of these might be hiring staff or
contractors, finding ways to release time for specific staff members to work on the project,
remodeling a nurses’ unit to add workstations, adding backup connectivity to the Internet, etc.
Issues Management
Unfortunately, every project will encounter some issues: some large, some small. Some hospitals
don’t think about tracking issues until it is too late. Many vendors are starting to maintain an
issues management Web site for their clients to use. If this is the case, you need to use it.
Keeping your own issues list, of both internal and external issues, also can be very helpful. For
example, some issues that a project manager may want to track include if one person is
consistently late with assigned tasks, an end user has failed to master the training for an
application after several tries, a specific team seems dysfunctional when one individual is
present, or one printer keeps having problems. Many project managers note that many small
issues occur, and if they don’t write them down, they get lost and often are not resolved. (2.1
Issues Management)
Preparation for and Installation of Hardware
Many small hospitals will hire someone to prepare and install hardware for them, especially if it
includes establishing a larger data center than the one that currently exists. This may be a
contractor, or you may outsource your hardware to a hosting company. As with project
management and issues management, do not abdicate all responsibility for hardware. You need
to understand enough about the hardware to anticipate problems or pinpoint issues. In the future,
you will have to address maintenance and replacement issues. And, local hardware issues always
arise, even when a remote data center is used. (1.1 Visioning and Strategic Planning, 1.1 IT
System Inventory, 1.3 Input Device Planning, 2.1 Space Planning)
o Selecting input devices is a major factor in implementing clinical information systems. Study
the options and evaluate, in advance, to the extent possible. Many assumptions are made about
input devices that often prove false. (1.3 Input Device Planning)
o Printers and scanners are other considerations. Even though you want to minimize printing to
paper, some printing is still needed. Scanners are used extensively in hospitals, especially early
in the migration path toward an EHR system. Scanning paper chart forms is essential to fill the
gaps where the electronic applications that would replace the paper have not yet been
implemented. (1.2 Chart Conversion Planning)
o As many hospitals begin to adopt more barcode technology, use of radio frequency
identification (RFID) systems may be considered. Compare these technologies not only on cost
but utility.
Network Development/Refinement

Most hospitals have some form of network infrastructure, but this often needs to be upgraded as
clinical information systems are adopted. Network infrastructure—wired or wireless—goes
hand-in-and with input device choices. Usability and security are also major considerations.
Wireless can be slower than a wired network and more prone to drop offs, but enables greater
portability. Wireless requires more attention to security, although the wireless standards are
improving in their protections. In addition to the network within the facility, connectivity also
becomes an increasingly important issue as more clinical information systems are adopted.
Almost certainly you will need remote connection for some users; with local clinics; with the e-
prescribing gateway; for electronic data interchange (EDI) of claims, eligibility verification, and
other transactions; from commercial labs, etc. While, many small hospitals outsource the design
and installation of their connectivity, understanding the basics is critical to any necessary
troubleshooting later. If you are acquiring clinical information systems in an application service
provider (ASP) or software as a service (SaaS) mode, connectivity becomes mission critical.
This is one area you absolutely cannot skimp on. Slow response time does more to turn clinicians
away from using information technology than almost any other factor.
Security Risk Analysis and Controls
All security measures must be attended to as you approach enhancing your use of HIT (1.1 HIT
Security Risk Analysis). The public is becoming much more aware and concerned about
security. State and federal data breach notification laws have become more stringent. As the
hospital moves into more mission critical systems, backup, disaster recovery, and other
contingency planning becomes critical. The Health Information Technology for Economic and
Clinical Health (HITECH) Act enhances the HIPAA requirements for privacy protections, and
stronger access controls and audit logging capability will be necessary. Although the Drug
Enforcement Administration (DEA) has not yet finalized its regulations with respect to e-
prescribing for controlled substances, stronger authentication measures are becoming popular.
(2.1 Security Risk Analysis and HITECH Requirements) As clinical information systems are
implemented, a security risk analysis should be performed that:
o Identifies threats with respect to confidentiality, data integrity, and availability of data as there
are changes in the environment, such as new HIT.
o Identifies vulnerabilities or gaps in controls to address threats. While no one can provide 100
percent security, identifying where your systems, policies, and procedures are weak or lacking in
security services, including carrying out documented policies and procedures, is essential to both
remediating weaknesses and to supporting your security service level decisions.
o Considers the likelihood that a threat will exploit a vulnerability, and the level of impact from
such an exploitation. Although gaps in security should be filled to the extent possible, you may
find instances where particular vulnerabilities or gaps in security controls are very unlikely to be

exploited or that the levels of impact are not significant. In these cases, you may find suitable
lower-cost alternatives, policy, and other ways to address the gaps.
o Considers cost of controls and capabilities to implement them. The bottom line of the security
risk analysis is to identify the security controls most suitable for your organization. The HIPAA
Security Rule does not expect that every covered entity or business associate will apply precisely
the same controls.
Super User Training
Super user training may occur anytime after signing the contract for the application to just before
system configuration. A super user is an individual who will be using the application full time,
leans toward automation, and has a special interest in the potential value of information
technology. Super users are provided with the vendor’s special super user training to assist in
system configuration and helping other end users learn the system. Depending on the application
being implemented and size of organization, you may have several super users who acquire such
training and roles. In general, super users are provided some release time to perform their super
user duties, from 20 to 60 percent time during system configuration to 60 to 80 percent time
while preparing for and during go live. (2.1 Training Plan)
Software Installation and System Configuration
Software installation is the act of loading the software you are acquiring to your hardware (i.e.,
server) for it to run. If you are using a shared service model to acquire the software, installation
refers to establishing a specific version of the software within the host’s servers that will then be
configured with your specific requirements. Although software installation may take place
immediately after you have signed the contract for the software, especially in a shared service
model where you do not have to acquire the hardware and have it installed, a large part of the
total implementation process relates to the configuration of the software, often referred to as
system build. (2.1 System Build)
System configuration includes setting up the various system parameters that are unique to your
organization. These include filling database tables with the names of your specific employees,
physicians, and their user log-in processes; patient locations (e.g., north nursing unit has five
single-bed rooms, numbered 1 through 5, etc.); the inventory of the specific drugs the pharmacy
maintains; the diagnostic tests the hospital’s lab performs, the tests that are performed by a
specific commercial lab, and the tests for which patients must be referred to another facility; etc.
Building templates, order sets, clinical decision support rules, and reports is another system
configuration activity. While most vendors will supply standard sets of most of these, hospitals
generally want to review and approve these, or modify them to some extent, at least putting the
hospital’s name on the reports. Once these are designed, they are then loaded into the master files
and tables that make up the underlying database of the application. System configuration also

includes writing interfaces between disparate applications and data conversion where an existing
information system application may be retired.
While some configuration is essential for the system to operate properly in your environment,
recent implementers agree that you should resist the urge to do a great deal of modification of
standards provided by the vendor. Vendors now have considerable experience and have created
clinical standards that are based in scientific evidence and workflows that have been well-
implemented by numerous other organizations. Too much modification is costly because a
change in one template or function has a ripple effect, impacting other templates, functions,
reports, etc. Tracing the change throughout the workflow and making necessary adjustments is
tedious and error-prone. Also, many hospitals find that their users are urging modifications that
essentially result in returning workflows and processes to the old manual, comfortable way of
doing things—often not achieving the goals intended. (2.1 Incorporating Clinical Decision
Support)
Testing
As system configuration is performed, unit testing is needed—the checking that the specific
table, master file, template, screen, or other elements have been built out as desired. Just as super
users are critical to system configuration, they are usually the primary people engaged in unit
testing along with the vendor and should be expected to sign off on each of these tests. As
interfaces are built, their ability to integrate data from one system into another system needs to
be tested. And finally, the overarching system workflow and processes need to be tested.
Sometimes this is performed with the team of super users, and other times it is performed with
end users after they have had their training in a rehearsal mode. Vendors often perform tests they
are most comfortable with. Understanding the different types of testing and identifying how you
want the testing to be performed provides piece of mind that the system will be ready on go live.
Some hospitals prefer that their end users not be system testers, and expect a rehearsal to be
focused on the end users needs and reassurances, not fixing system configuration glitches. (2.1
Testing Plan)
End User Training
End user training should be performed in as just-in-time manner as possible. For this to work
successfully, end users need to be ready to accept training. This requires continual
communication and engagement of end users throughout the entire HIT process, including
system demonstrations, goal setting and expectations, change management, computer skills
building, assistance in reviewing standard elements of the system configuration, and much more.
Training is greatly aided by having the new workflow and process maps handy to illustrate
changes and any other tip sheets, screen shots, and other devices that are useful to end users. End
users must be reassured during training that direct support will be available during go live. Many

organizations develop a training plan that encompasses all elements of training. (2.1 Training
Plan)
Preparation for Go Live
Go live is the day end users use the system for the first time in actual work. Preparing for this
should be as carefully orchestrated as any significant event. Develop a checklist and validate it
the day prior to go live. (2.1 Go-live Checklist)
Go Live
Go live is the big day, and is the day when it is necessary to swarm users with support. Everyone
must be on the job (no vacations, meetings, time off, etc.). You are better to have many people
waiting to provide support and have nothing happen, than to have little support and new users
having to wait for help. Recognize that the day of go live is stressful. Do anything you can to
relieve such stress, for end users as well as patients and their families who need patience with the
organization while it is “under construction.” Build in specific time for breaks and de-briefings,
and be sure to celebrate any and all activities accomplished that day.
Benefits Realization and Recognition
After go live, ensure that the system is used as intended and goal achievement is not forgotten.
Sometimes organizations are so relieved to have the entire process finished that they do not plan
or carry out a benefits realization process. Despite lessons learned and significant improvement
in implementation processes, some issues will not be quite fully resolved, new issues arise, one
or two users will be resistant, or other matters will arise that result in less than perfect adoption
or use of these new systems. Taking the time to monitor that goals are being achieved is not only
gratifying, but provides direct evidence that the investment was worth it or issues can be
resolved. Benefits realization should engage all users and should result in recognizing success or
correcting course as necessary. Without such recognition, many members of the organization
may harbor concerns or resentment, which often translate into other issues, sometimes totally
unrelated. (2.2 Benefits Realization)
Optimization Strategies
Rarely does anyone use every conceivable function in sophisticated HIT systems, at least not
early in their adoption. Many organizations are finding that after the initial benefits realization
studies demonstrate appropriate mastery of basic functionality, moving into optimizing use of the
system is desirable.
Optimization is not simply a second step for phasing in system use. It is finding new and
innovative benefits to be achieved. This may be as simple as setting higher goals for quality
improvement than you have had in the past, or it may be as big an undertaking as adding a new
service line due to new-found efficiencies with the HIT. You may find that your patients are
particularly interested in your use of an EHR and you decide to add a PHR component. Your

physicians may find it much easier to acquire patient information from different sources and
decide to adopt a new model of care, such as the Health Care Home model. As time goes on, you
will have many ways to achieve more using your HIT, and the vendor is likely to be adding
enhancements.
After the intensity of implementation ends, optimization is only getting started and is an ongoing
process.
Healthcare organizations implement clinical healthcare information technology (HIT) to improve
the quality of care, enhance patient safety, and eliminate inefficiencies in order to reduce the cost
of care. Irrespective of the technology solution selected, however, implementing an expensive,
comprehensive clinical HIT system is nothing short of immensely disruptive to any organization.
Senior management teams stake hard-earned reputations on the successful deployment of these
very complex technology platforms. Failure not only wastes millions of dollars of scarce
investment resources, but also poisons, for a period of time, the goodwill among clinicians
needed to implement these critical information technology tools.
Current State Versus Future State Implementation
Most organizations choose to minimize disruptions caused by HIT implementation by applying
new technology to the current state of how clinicians deliver care. "Current state" describes,
through diagrams and descriptive text, what activities are presently done. Documentation of the
current state comes from clinicians and staff, at every level, who perform these activities and
follow the workflow of the current state.
Processes and workflows are redesigned once the technology is installed. Organizations often
choose to implement before processes and workflows are revised for several reasons, including:
desire for a shorter length of time to go-live, limited resources available to complete process
redesigns, and unclear links between potential redesigns and overarching organization objectives.
A few organizations, however, decide to reengineer clinical processes based upon their desired
future state before implementing the system. "Future state" defines what the current processes
and workflows would look like after relevant changes take place in those current processes and
workflows. This is usually developed with the involvement of those who participate in the
current state, experts in any new technology introduced, and trained professionals in quality
improvement and process redesign.
Organizations that decide to utilize current state for implementation must study their current
processes and understand the impact new HIT tools will have on those processes. In this
instance, processes are not actively changed in anticipation of the new capabilities afforded by
the HIT tools, but the new tools are used to facilitate current processes. For example, pharmacy
orders that were formerly handwritten are now — after implementation of clinical HIT —
generated by an order entry system and printed at the nurse station for delivery to the hospital

pharmacy. There is no electronic transfer of drug orders to the pharmacy.
An alternative approach is to study existing processes, but also creatively design new processes
that best leverage the capabilities of the HIT tools to deliver better processes, workflows, and
outcomes. Unfortunately, the development of these best processes and workflows cannot be
universally applied across any healthcare organization. Each institution is different, requiring
documentation of current state and development of a best future state that considers the realities
of plant, people, and resources. Finally, an organization's choice of either a current or future
state implementation is greatly driven by organizational goals, administrative leadership, and
existing change management capabilities.
Implementation Strategies for Success
Through efforts assisting with the implementation of clinical HIT systems at several
organizations located in North America and the United Kingdom, valuable insight was gained
into best practices for HIT deployment. This experience included organizations that approached
implementation utilizing current state and others utilizing future state. These strategies can be
applied irrespective of the brand of clinical HIT system implemented.
Whether your organization chooses to reengineer its processes before or after implementation,
successful deployment of clinical HIT depends upon three key factors: technology, training, and
change management.
Develop an organization-specific clinical HIT implementation model.Before the implementation
of a system, it is not obvious which clinical content and workflows, which appear to be
appropriate across all clinics or departments, may not work well at all in practice. Customization
should be expected at each site with clinicians providing effective solutions if engaged early in
the process.
Identify potential implementation problems with a mock go-live.Effective training requires a
realistic schedule of education, system testing under realistic conditions using a simulation (i.e.,
mock go-live), and processes to make changes before the actual go-live. Linking the education to
a mock go-live helps identify unforeseen problems in processes and workflows, allowing them to
be corrected before they can impact patient care. In addition, this approach builds confidence
among users that the system will work. Participation of physicians, nurses, and other clinical and
administrative personnel is essential to conducting a meaningful mock go-live.
Treat physicians and nurses equally. Regardless of setting, physicians and nurses work as a team,
performing a ballet of activities that deliver care. Although the primary focus is often to secure
physician adoption of clinical HIT, nurses play a very important role in securing and maintaining
physician adoption. If HIT implementation puts an additional burden on nurse workflow, nurse
adoption will surely suffer. In turn, this rejection of the technology impacts physician adoption.
Effective workflows require both physicians and nurses to use the same system. Without nurse

adoption of the HIT, physicians, no matter how positive their opinion of the HIT, are at a higher
risk of abandoning it to remain in step with the workflow used by their nurses.
Prepare for unique demands that complex clinical systems place on IT staff. Clinical systems are
orders of magnitude more complex than other hospital IT systems, such as financial programs. A
typical clinical IT system incorporates multiple single system functionalities into one integrated
application including scheduling, messaging, documentation, prescription writing, and results
reporting. It takes much more time for an IT department to figure out how such a complex
system fits into an already complex environment — i.e., the healthcare delivery setting — than
the department would for a hospital accounting system.
Invariably it takes more time for users to learn and effectively use clinical systems than users of
less complex systems. IT departments must expect to invest more time and resources bringing
these systems up and maintaining them in production mode. In addition, experience with
administrative HIT systems provides only a limited model for use when implementing and
maintaining clinical systems.
Forge a strong partnership with the vendor. Implementation of a clinical HIT system requires an
enormous investment of capital, professional resources, and clinical staff goodwill. Best viewed
as a marriage, it is important to follow a measured pace of courtship before settling on a
particular vendor. Once a clinical HIT system is deployed, it is terribly difficult to get divorced
from it. Beyond the expense of purchasing a new system or re-investing in training, much of the
valuable patient data that exists within a rejected system will be very difficult to transfer to the
new system. Excellent and honest communication coupled with solid trust must exist between
the healthcare organization and vendor. If this does not exist, "don't get married."
Practice patience to achieve a successful implementation. Healthcare organizations and vendors
alike, excited about forging ahead with a new system, often allow their enthusiasm to overwhelm
their professional judgment. In more rational moments, both know that extended and detailed
planning greatly increases the likelihood that a deployment will end successfully. Although
physicians and nurses, after viewing a demonstration of a clinical system, may be wowed by its
capabilities, organizations need to realize that live production systems do not match the
flexibility and response time of demonstration systems that are tweaked to deliver the best
performance.
Budgeting a minimum of 4 to 5 months to plan a deployment is both prudent and necessary.
During this time, information is collected to better understand how the clinical HIT system fits
into the existing technology infrastructure, physical plant, and clinical processes. In addition to
planning, this pre-implementation time can be used to stage the necessary equipment (e.g.,
computers, desks, electrical supply, etc.) while securing the additional IT services (e.g., data
center for backup) to guarantee a reliable system. Last, when developing an implementation

timeline, consider all forces that may be driving both your organization and the vendor at a
particular speed down a deployment path.
Let users play with the system. Often IT departments are reluctant to make a system available for
use in simulation mode due to concern about the resources required to support a non-production
system. Although it appears that users are "playing" when using a system in simulation, in
reality they are learning. Playing develops "super users" of the system, who then provide
invaluable supplementary support to help desks assigned to provide assistance to users. In
addition, these super users of the system become ambassadors working to convince their peers to
both use the new system and showing them first-hand how to do so.
Align IT department goals with overall project goals. Due to their professional training, IT
departments often become focused on getting the hardware and software "right" rather than the
entire project. Successful deployments are not measured by installation timelines, response times
or number of working systems, Measurements for successful deployment of clinical HIT systems
must be linked to an organization's specific patient care goals and objectives. These invariably
include quality of care, patient safety, and cost metrics.
Clinical departments may use medical error rates, clinician efficiency, and billing accuracy as
their metrics. In parallel, IT departments may use percent of clinicians as users, user satisfaction,
and average time using the system as surrogate metrics to measure success. The development of
a comprehensive deployment plan that includes rework of clinical processes and revised
workflow driven by HIT, in addition to the obvious hardware installation activities, greatly
increases the likelihood of securing expected outcomes from clinical HIT deployment.
Outpatient Deployment Is Easier than Inpatient
Although a successful deployment of a clinical HIT system requires detailed planning that
includes high quality clinician-user training, outpatient deployment invariably occurs more
quickly and with fewer problems. Intuitively this is expected as outpatient settings are
considerably less complex than inpatient settings. In addition, outpatient users interact with the
clinical HIT system on a more regular basis utilizing fewer system functions. This creates an
environment where the user learns a limited set of HIT system processes and is afforded the
opportunity to regularly practice those skills. In the inpatient environment, clinical users are
faced with a much broader set of HIT system processes and do not get to reinforce those
processes through regular use.
Summary and Recommendation
Without question, successful deployment of a clinical HIT system requires comprehensive
planning, exemplary team leadership, and organization-wide patience to coordinate all the people
critical to the project. Nevertheless, establishing a project's overriding goals and objectives, and
communicating those clearly to every person involved in the clinical HIT deployment, sets a

meaningful direction for the project that can be followed by everyone.
Processes and workflows drive outcomes with or without HIT. Whether these processes and
workflows are redesigned before or after deployment to take advantage of the capabilities of an
HIT system, the processes and workflows will require revision. Therefore, it is recommended to
include the revision of clinical processes and workflows in the pre-deployment planning so that a
major change process occurs once rather than twice. Although this may extend the planning
period, it decreases any post-deployment rework of clinical processes and workflows. In
addition, this approach will prove less confusing to clinical users as they are required only to
change their clinical habits once.
Organizations may be tempted to exclude the difficult task of revising clinical processes and
workflows during the deployment planning, and schedule it for the post-deployment time period.
Such a decision greatly increases the probability that this later revision will prove problematic or
not get done at all. Therefore, when implementing a clinical HIT system, take a comprehensive,
visionary approach, carefully plan the change management for revised processes and workflows,
and stay focused on the overarching project goals and objectives linked to patient care.
Solution
Implementing Systems Overview
Health information technology (HIT) encompasses implementing a broad scope of applications,
technology, and operational activities (1.1 HIT Visioning and Strategic Planning), depending on
your organization and its goals (1.2 Goal Setting). This tool provides an overview of a typical
implementation of an electronic health record (EHR) system for a hospital. Use this tool to
understand the broad range of topics that you will need to consider during HIT implementation.
Overview of Implementation
Although specifics with respect to an implementation will vary by vendor and application, any
implementation should follow a similar high level structure:
1. Project management
3. Detailed plan creation
4. Issues management
6. Preparing for and installing hardware
7. Network development/refinement
8. Security risk analysis and controls
9. Super user training

10. Software installation and system configuration (a.k.a., “system build”), including report
writing, interfaces, data conversion
11. Testing
12. End user training
13. Preparation for go live
14. Go live
15. Benefits realization and recognition
16. Optimization strategies
Project Management
Even though your vendor will supply significant project support, you need to designate an
individual within your hospital to be the project manager, representing your interests and
ensuring that information learned during the process is retained within the hospital for future
reference. (1.2 Project Management, 1.2 Project Management Job Description)
Your project manager will be responsible for many activities:
o Managing your harmonized project plan, making sure the project gets completed on time and
within budget.
o Organizing your staff resources, team building, maintaining the project budget, approving
invoices, and handling other elements of making sure the hospital completes the designated tasks
on the project plan completely, accurately, and on time.
o Carrying out your communication plan (1.1 Communication Plan), including reminding others
to perform their necessary communications and potentially even scripting them for others such as
the CEO.
Workflow and Process Redesign
Ideally during the planning phases you will map current workflows and processes, using these to
initiate change management and create expectations to achieve goals, to help you identify system
requirements and select the most appropriate vendor, and potentially even to make adjustments
in workflows and processes today where streamlining or other improvements are feasible without
HIT. Mapping current workflows and processes gives you slightly less work to do during
implementation. This step is essential for configuring the system to your specifications and
anticipating changes with the new system.
Over just the past few years, the industry as a whole has come to recognize that not attending to
workflow and process redesign during HIT planning and implementation has led to less than
desirable adoption rates and sometimes even serious consequences, where unique considerations
for the hospital were not evaluated and addressed in system configuration. Some vendors now
strongly support the activity, while others still view it as largely an organization responsibility.
Whether your vendor supports workflow and process redesign or not, this activity has been

found to be an extremely important element of success. (1.2 Workflow and Process Redesign)
Create Detailed Implementation Plan
Every vendor will provide you with some form of implementation plan. This advises you of the
steps to be conducted to implement your system and usually identifies what the vendor will do
when, what the vendor expects you to do when, and what is performed jointly—incorporating
specific meetings and milestones. You need to take several important steps when you receive this
project plan. Hospitals often overlook some of these steps. Missing them may come back to
haunt you.
o Review the plan against the contract you signed with the vendor to make sure everything you
agreed to buy has been addressed in the plan and that nothing is in the plan that you did not buy.
Most vendors take a standard plan and make adjustments for each client, which can lead to the
discrepancies with your specific contract. (2.1 Project Plan)
o Review the plan thoroughly with the vendor’s implementation specialist, making sure any
discrepancies are addressed. Also, make sure you fully understand each item in the plan—
especially those you will be responsible for. Consider the staffing and other resources you will
need to complete the activities in the time allotted.
o Harmonize the vendor’s plan with your own. The vendor’s plan only identifies those elements
for which the vendor is responsible—directly or indirectly. You may need to conduct any
number of activities in relationship to the project. Some of these might be hiring staff or
contractors, finding ways to release time for specific staff members to work on the project,
remodeling a nurses’ unit to add workstations, adding backup connectivity to the Internet, etc.
Issues Management
Unfortunately, every project will encounter some issues: some large, some small. Some hospitals
don’t think about tracking issues until it is too late. Many vendors are starting to maintain an
issues management Web site for their clients to use. If this is the case, you need to use it.
Keeping your own issues list, of both internal and external issues, also can be very helpful. For
example, some issues that a project manager may want to track include if one person is
consistently late with assigned tasks, an end user has failed to master the training for an
application after several tries, a specific team seems dysfunctional when one individual is
present, or one printer keeps having problems. Many project managers note that many small
issues occur, and if they don’t write them down, they get lost and often are not resolved. (2.1
Issues Management)
Preparation for and Installation of Hardware
Many small hospitals will hire someone to prepare and install hardware for them, especially if it
includes establishing a larger data center than the one that currently exists. This may be a
contractor, or you may outsource your hardware to a hosting company. As with project

management and issues management, do not abdicate all responsibility for hardware. You need
to understand enough about the hardware to anticipate problems or pinpoint issues. In the future,
you will have to address maintenance and replacement issues. And, local hardware issues always
arise, even when a remote data center is used. (1.1 Visioning and Strategic Planning, 1.1 IT
System Inventory, 1.3 Input Device Planning, 2.1 Space Planning)
o Selecting input devices is a major factor in implementing clinical information systems. Study
the options and evaluate, in advance, to the extent possible. Many assumptions are made about
input devices that often prove false. (1.3 Input Device Planning)
o Printers and scanners are other considerations. Even though you want to minimize printing to
paper, some printing is still needed. Scanners are used extensively in hospitals, especially early
in the migration path toward an EHR system. Scanning paper chart forms is essential to fill the
gaps where the electronic applications that would replace the paper have not yet been
implemented. (1.2 Chart Conversion Planning)
o As many hospitals begin to adopt more barcode technology, use of radio frequency
identification (RFID) systems may be considered. Compare these technologies not only on cost
but utility.
Network Development/Refinement
Most hospitals have some form of network infrastructure, but this often needs to be upgraded as
clinical information systems are adopted. Network infrastructure—wired or wireless—goes
hand-in-and with input device choices. Usability and security are also major considerations.
Wireless can be slower than a wired network and more prone to drop offs, but enables greater
portability. Wireless requires more attention to security, although the wireless standards are
improving in their protections. In addition to the network within the facility, connectivity also
becomes an increasingly important issue as more clinical information systems are adopted.
Almost certainly you will need remote connection for some users; with local clinics; with the e-
prescribing gateway; for electronic data interchange (EDI) of claims, eligibility verification, and
other transactions; from commercial labs, etc. While, many small hospitals outsource the design
and installation of their connectivity, understanding the basics is critical to any necessary
troubleshooting later. If you are acquiring clinical information systems in an application service
provider (ASP) or software as a service (SaaS) mode, connectivity becomes mission critical.
This is one area you absolutely cannot skimp on. Slow response time does more to turn clinicians
away from using information technology than almost any other factor.
Security Risk Analysis and Controls
All security measures must be attended to as you approach enhancing your use of HIT (1.1 HIT
Security Risk Analysis). The public is becoming much more aware and concerned about
security. State and federal data breach notification laws have become more stringent. As the

hospital moves into more mission critical systems, backup, disaster recovery, and other
contingency planning becomes critical. The Health Information Technology for Economic and
Clinical Health (HITECH) Act enhances the HIPAA requirements for privacy protections, and
stronger access controls and audit logging capability will be necessary. Although the Drug
Enforcement Administration (DEA) has not yet finalized its regulations with respect to e-
prescribing for controlled substances, stronger authentication measures are becoming popular.
(2.1 Security Risk Analysis and HITECH Requirements) As clinical information systems are
implemented, a security risk analysis should be performed that:
o Identifies threats with respect to confidentiality, data integrity, and availability of data as there
are changes in the environment, such as new HIT.
o Identifies vulnerabilities or gaps in controls to address threats. While no one can provide 100
percent security, identifying where your systems, policies, and procedures are weak or lacking in
security services, including carrying out documented policies and procedures, is essential to both
remediating weaknesses and to supporting your security service level decisions.
o Considers the likelihood that a threat will exploit a vulnerability, and the level of impact from
such an exploitation. Although gaps in security should be filled to the extent possible, you may
find instances where particular vulnerabilities or gaps in security controls are very unlikely to be
exploited or that the levels of impact are not significant. In these cases, you may find suitable
lower-cost alternatives, policy, and other ways to address the gaps.
o Considers cost of controls and capabilities to implement them. The bottom line of the security
risk analysis is to identify the security controls most suitable for your organization. The HIPAA
Security Rule does not expect that every covered entity or business associate will apply precisely
the same controls.
Super User Training
Super user training may occur anytime after signing the contract for the application to just before
system configuration. A super user is an individual who will be using the application full time,
leans toward automation, and has a special interest in the potential value of information
technology. Super users are provided with the vendor’s special super user training to assist in
system configuration and helping other end users learn the system. Depending on the application
being implemented and size of organization, you may have several super users who acquire such
training and roles. In general, super users are provided some release time to perform their super
user duties, from 20 to 60 percent time during system configuration to 60 to 80 percent time
while preparing for and during go live. (2.1 Training Plan)
Software Installation and System Configuration
Software installation is the act of loading the software you are acquiring to your hardware (i.e.,
server) for it to run. If you are using a shared service model to acquire the software, installation

refers to establishing a specific version of the software within the host’s servers that will then be
configured with your specific requirements. Although software installation may take place
immediately after you have signed the contract for the software, especially in a shared service
model where you do not have to acquire the hardware and have it installed, a large part of the
total implementation process relates to the configuration of the software, often referred to as
system build. (2.1 System Build)
System configuration includes setting up the various system parameters that are unique to your
organization. These include filling database tables with the names of your specific employees,
physicians, and their user log-in processes; patient locations (e.g., north nursing unit has five
single-bed rooms, numbered 1 through 5, etc.); the inventory of the specific drugs the pharmacy
maintains; the diagnostic tests the hospital’s lab performs, the tests that are performed by a
specific commercial lab, and the tests for which patients must be referred to another facility; etc.
Building templates, order sets, clinical decision support rules, and reports is another system
configuration activity. While most vendors will supply standard sets of most of these, hospitals
generally want to review and approve these, or modify them to some extent, at least putting the
hospital’s name on the reports. Once these are designed, they are then loaded into the master files
and tables that make up the underlying database of the application. System configuration also
includes writing interfaces between disparate applications and data conversion where an existing
information system application may be retired.
While some configuration is essential for the system to operate properly in your environment,
recent implementers agree that you should resist the urge to do a great deal of modification of
standards provided by the vendor. Vendors now have considerable experience and have created
clinical standards that are based in scientific evidence and workflows that have been well-
implemented by numerous other organizations. Too much modification is costly because a
change in one template or function has a ripple effect, impacting other templates, functions,
reports, etc. Tracing the change throughout the workflow and making necessary adjustments is
tedious and error-prone. Also, many hospitals find that their users are urging modifications that
essentially result in returning workflows and processes to the old manual, comfortable way of
doing things—often not achieving the goals intended. (2.1 Incorporating Clinical Decision
Support)
Testing
As system configuration is performed, unit testing is needed—the checking that the specific
table, master file, template, screen, or other elements have been built out as desired. Just as super
users are critical to system configuration, they are usually the primary people engaged in unit
testing along with the vendor and should be expected to sign off on each of these tests. As
interfaces are built, their ability to integrate data from one system into another system needs to

be tested. And finally, the overarching system workflow and processes need to be tested.
Sometimes this is performed with the team of super users, and other times it is performed with
end users after they have had their training in a rehearsal mode. Vendors often perform tests they
are most comfortable with. Understanding the different types of testing and identifying how you
want the testing to be performed provides piece of mind that the system will be ready on go live.
Some hospitals prefer that their end users not be system testers, and expect a rehearsal to be
focused on the end users needs and reassurances, not fixing system configuration glitches. (2.1
Testing Plan)
End User Training
End user training should be performed in as just-in-time manner as possible. For this to work
successfully, end users need to be ready to accept training. This requires continual
communication and engagement of end users throughout the entire HIT process, including
system demonstrations, goal setting and expectations, change management, computer skills
building, assistance in reviewing standard elements of the system configuration, and much more.
Training is greatly aided by having the new workflow and process maps handy to illustrate
changes and any other tip sheets, screen shots, and other devices that are useful to end users. End
users must be reassured during training that direct support will be available during go live. Many
organizations develop a training plan that encompasses all elements of training. (2.1 Training
Plan)
Preparation for Go Live
Go live is the day end users use the system for the first time in actual work. Preparing for this
should be as carefully orchestrated as any significant event. Develop a checklist and validate it
the day prior to go live. (2.1 Go-live Checklist)
Go Live
Go live is the big day, and is the day when it is necessary to swarm users with support. Everyone
must be on the job (no vacations, meetings, time off, etc.). You are better to have many people
waiting to provide support and have nothing happen, than to have little support and new users
having to wait for help. Recognize that the day of go live is stressful. Do anything you can to
relieve such stress, for end users as well as patients and their families who need patience with the
organization while it is “under construction.” Build in specific time for breaks and de-briefings,
and be sure to celebrate any and all activities accomplished that day.
Benefits Realization and Recognition
After go live, ensure that the system is used as intended and goal achievement is not forgotten.
Sometimes organizations are so relieved to have the entire process finished that they do not plan
or carry out a benefits realization process. Despite lessons learned and significant improvement
in implementation processes, some issues will not be quite fully resolved, new issues arise, one

or two users will be resistant, or other matters will arise that result in less than perfect adoption
or use of these new systems. Taking the time to monitor that goals are being achieved is not only
gratifying, but provides direct evidence that the investment was worth it or issues can be
resolved. Benefits realization should engage all users and should result in recognizing success or
correcting course as necessary. Without such recognition, many members of the organization
may harbor concerns or resentment, which often translate into other issues, sometimes totally
unrelated. (2.2 Benefits Realization)
Optimization Strategies
Rarely does anyone use every conceivable function in sophisticated HIT systems, at least not
early in their adoption. Many organizations are finding that after the initial benefits realization
studies demonstrate appropriate mastery of basic functionality, moving into optimizing use of the
system is desirable.
Optimization is not simply a second step for phasing in system use. It is finding new and
innovative benefits to be achieved. This may be as simple as setting higher goals for quality
improvement than you have had in the past, or it may be as big an undertaking as adding a new
service line due to new-found efficiencies with the HIT. You may find that your patients are
particularly interested in your use of an EHR and you decide to add a PHR component. Your
physicians may find it much easier to acquire patient information from different sources and
decide to adopt a new model of care, such as the Health Care Home model. As time goes on, you
will have many ways to achieve more using your HIT, and the vendor is likely to be adding
enhancements.
After the intensity of implementation ends, optimization is only getting started and is an ongoing
process.
Healthcare organizations implement clinical healthcare information technology (HIT) to improve
the quality of care, enhance patient safety, and eliminate inefficiencies in order to reduce the cost
of care. Irrespective of the technology solution selected, however, implementing an expensive,
comprehensive clinical HIT system is nothing short of immensely disruptive to any organization.
Senior management teams stake hard-earned reputations on the successful deployment of these
very complex technology platforms. Failure not only wastes millions of dollars of scarce
investment resources, but also poisons, for a period of time, the goodwill among clinicians
needed to implement these critical information technology tools.
Current State Versus Future State Implementation
Most organizations choose to minimize disruptions caused by HIT implementation by applying
new technology to the current state of how clinicians deliver care. "Current state" describes,
through diagrams and descriptive text, what activities are presently done. Documentation of the
current state comes from clinicians and staff, at every level, who perform these activities and

follow the workflow of the current state.
Processes and workflows are redesigned once the technology is installed. Organizations often
choose to implement before processes and workflows are revised for several reasons, including:
desire for a shorter length of time to go-live, limited resources available to complete process
redesigns, and unclear links between potential redesigns and overarching organization objectives.
A few organizations, however, decide to reengineer clinical processes based upon their desired
future state before implementing the system. "Future state" defines what the current processes
and workflows would look like after relevant changes take place in those current processes and
workflows. This is usually developed with the involvement of those who participate in the
current state, experts in any new technology introduced, and trained professionals in quality
improvement and process redesign.
Organizations that decide to utilize current state for implementation must study their current
processes and understand the impact new HIT tools will have on those processes. In this
instance, processes are not actively changed in anticipation of the new capabilities afforded by
the HIT tools, but the new tools are used to facilitate current processes. For example, pharmacy
orders that were formerly handwritten are now — after implementation of clinical HIT —
generated by an order entry system and printed at the nurse station for delivery to the hospital
pharmacy. There is no electronic transfer of drug orders to the pharmacy.
An alternative approach is to study existing processes, but also creatively design new processes
that best leverage the capabilities of the HIT tools to deliver better processes, workflows, and
outcomes. Unfortunately, the development of these best processes and workflows cannot be
universally applied across any healthcare organization. Each institution is different, requiring
documentation of current state and development of a best future state that considers the realities
of plant, people, and resources. Finally, an organization's choice of either a current or future
state implementation is greatly driven by organizational goals, administrative leadership, and
existing change management capabilities.
Implementation Strategies for Success
Through efforts assisting with the implementation of clinical HIT systems at several
organizations located in North America and the United Kingdom, valuable insight was gained
into best practices for HIT deployment. This experience included organizations that approached
implementation utilizing current state and others utilizing future state. These strategies can be
applied irrespective of the brand of clinical HIT system implemented.
Whether your organization chooses to reengineer its processes before or after implementation,
successful deployment of clinical HIT depends upon three key factors: technology, training, and
change management.
Develop an organization-specific clinical HIT implementation model.Before the implementation

of a system, it is not obvious which clinical content and workflows, which appear to be
appropriate across all clinics or departments, may not work well at all in practice. Customization
should be expected at each site with clinicians providing effective solutions if engaged early in
the process.
Identify potential implementation problems with a mock go-live.Effective training requires a
realistic schedule of education, system testing under realistic conditions using a simulation (i.e.,
mock go-live), and processes to make changes before the actual go-live. Linking the education to
a mock go-live helps identify unforeseen problems in processes and workflows, allowing them to
be corrected before they can impact patient care. In addition, this approach builds confidence
among users that the system will work. Participation of physicians, nurses, and other clinical and
administrative personnel is essential to conducting a meaningful mock go-live.
Treat physicians and nurses equally. Regardless of setting, physicians and nurses work as a team,
performing a ballet of activities that deliver care. Although the primary focus is often to secure
physician adoption of clinical HIT, nurses play a very important role in securing and maintaining
physician adoption. If HIT implementation puts an additional burden on nurse workflow, nurse
adoption will surely suffer. In turn, this rejection of the technology impacts physician adoption.
Effective workflows require both physicians and nurses to use the same system. Without nurse
adoption of the HIT, physicians, no matter how positive their opinion of the HIT, are at a higher
risk of abandoning it to remain in step with the workflow used by their nurses.
Prepare for unique demands that complex clinical systems place on IT staff. Clinical systems are
orders of magnitude more complex than other hospital IT systems, such as financial programs. A
typical clinical IT system incorporates multiple single system functionalities into one integrated
application including scheduling, messaging, documentation, prescription writing, and results
reporting. It takes much more time for an IT department to figure out how such a complex
system fits into an already complex environment — i.e., the healthcare delivery setting — than
the department would for a hospital accounting system.
Invariably it takes more time for users to learn and effectively use clinical systems than users of
less complex systems. IT departments must expect to invest more time and resources bringing
these systems up and maintaining them in production mode. In addition, experience with
administrative HIT systems provides only a limited model for use when implementing and
maintaining clinical systems.
Forge a strong partnership with the vendor. Implementation of a clinical HIT system requires an
enormous investment of capital, professional resources, and clinical staff goodwill. Best viewed
as a marriage, it is important to follow a measured pace of courtship before settling on a
particular vendor. Once a clinical HIT system is deployed, it is terribly difficult to get divorced
from it. Beyond the expense of purchasing a new system or re-investing in training, much of the

valuable patient data that exists within a rejected system will be very difficult to transfer to the
new system. Excellent and honest communication coupled with solid trust must exist between
the healthcare organization and vendor. If this does not exist, "don't get married."
Practice patience to achieve a successful implementation. Healthcare organizations and vendors
alike, excited about forging ahead with a new system, often allow their enthusiasm to overwhelm
their professional judgment. In more rational moments, both know that extended and detailed
planning greatly increases the likelihood that a deployment will end successfully. Although
physicians and nurses, after viewing a demonstration of a clinical system, may be wowed by its
capabilities, organizations need to realize that live production systems do not match the
flexibility and response time of demonstration systems that are tweaked to deliver the best
performance.
Budgeting a minimum of 4 to 5 months to plan a deployment is both prudent and necessary.
During this time, information is collected to better understand how the clinical HIT system fits
into the existing technology infrastructure, physical plant, and clinical processes. In addition to
planning, this pre-implementation time can be used to stage the necessary equipment (e.g.,
computers, desks, electrical supply, etc.) while securing the additional IT services (e.g., data
center for backup) to guarantee a reliable system. Last, when developing an implementation
timeline, consider all forces that may be driving both your organization and the vendor at a
particular speed down a deployment path.
Let users play with the system. Often IT departments are reluctant to make a system available for
use in simulation mode due to concern about the resources required to support a non-production
system. Although it appears that users are "playing" when using a system in simulation, in
reality they are learning. Playing develops "super users" of the system, who then provide
invaluable supplementary support to help desks assigned to provide assistance to users. In
addition, these super users of the system become ambassadors working to convince their peers to
both use the new system and showing them first-hand how to do so.
Align IT department goals with overall project goals. Due to their professional training, IT
departments often become focused on getting the hardware and software "right" rather than the
entire project. Successful deployments are not measured by installation timelines, response times
or number of working systems, Measurements for successful deployment of clinical HIT systems
must be linked to an organization's specific patient care goals and objectives. These invariably
include quality of care, patient safety, and cost metrics.
Clinical departments may use medical error rates, clinician efficiency, and billing accuracy as
their metrics. In parallel, IT departments may use percent of clinicians as users, user satisfaction,
and average time using the system as surrogate metrics to measure success. The development of
a comprehensive deployment plan that includes rework of clinical processes and revised

workflow driven by HIT, in addition to the obvious hardware installation activities, greatly
increases the likelihood of securing expected outcomes from clinical HIT deployment.
Outpatient Deployment Is Easier than Inpatient
Although a successful deployment of a clinical HIT system requires detailed planning that
includes high quality clinician-user training, outpatient deployment invariably occurs more
quickly and with fewer problems. Intuitively this is expected as outpatient settings are
considerably less complex than inpatient settings. In addition, outpatient users interact with the
clinical HIT system on a more regular basis utilizing fewer system functions. This creates an
environment where the user learns a limited set of HIT system processes and is afforded the
opportunity to regularly practice those skills. In the inpatient environment, clinical users are
faced with a much broader set of HIT system processes and do not get to reinforce those
processes through regular use.
Summary and Recommendation
Without question, successful deployment of a clinical HIT system requires comprehensive
planning, exemplary team leadership, and organization-wide patience to coordinate all the people
critical to the project. Nevertheless, establishing a project's overriding goals and objectives, and
communicating those clearly to every person involved in the clinical HIT deployment, sets a
meaningful direction for the project that can be followed by everyone.
Processes and workflows drive outcomes with or without HIT. Whether these processes and
workflows are redesigned before or after deployment to take advantage of the capabilities of an
HIT system, the processes and workflows will require revision. Therefore, it is recommended to
include the revision of clinical processes and workflows in the pre-deployment planning so that a
major change process occurs once rather than twice. Although this may extend the planning
period, it decreases any post-deployment rework of clinical processes and workflows. In
addition, this approach will prove less confusing to clinical users as they are required only to
change their clinical habits once.
Organizations may be tempted to exclude the difficult task of revising clinical processes and
workflows during the deployment planning, and schedule it for the post-deployment time period.
Such a decision greatly increases the probability that this later revision will prove problematic or
not get done at all. Therefore, when implementing a clinical HIT system, take a comprehensive,
visionary approach, carefully plan the change management for revised processes and workflows,
and stay focused on the overarching project goals and objectives linked to patient care.

Implementing Systems OverviewHealth information technology (HIT) e.pdf

More Related Content

Similar to Implementing Systems OverviewHealth information technology (HIT) e.pdf (20)

More from anikkothari1 (20)

Recently uploaded (20)

Implementing Systems OverviewHealth information technology (HIT) e.pdf