Hospital Information System

Implementation Guide
The setup and successful deployment of an HIS system in a new hospital goes simply
beyond the configuration of the HIS software. There is a need to have a holistic approach to
the HIS deployment which has to be done in conjunction with the hospital other operational
processes.

Introduction
People, process and technology form the cornerstone of a successful setup of a new
hospital operation. This document highlights several critical points that require detailed
attention in successfully deploying a Hospital Information System (HIS) in a new hospital.

In implementing an HIS at a new hospital, as people and processes are new, it is imperative
to go-live and make adjustments to processes where necessary. To attempt to get it right
100% of the time leads to the “analysis paralysis” syndrome where too much time is spent
on paper analysis and not enough time in progressing the HIS implementation forward. The
“analysis paralysis” syndrome will cause the hospital to delay its launch of HIS and the
hospital, resulting in increased cost and negative impact on its corporate image. It is
important to set aside some investment and a plan for fine tuning the approach and
resolving minor problems that will be encountered after going live.

People
Hospital staff form the basis of a functioning hospital. Hospital staff will have different
experiences discharging their duties. They may have experience in a totally manual
operational process where physical files and paper are used for recording and these files
are physically moved from one department to another. Others may have experience in a
totally computerized operations process where information flow is electronic without the
need for physical file movements. There will be other staff who have experienced a hybrid
of both.
These differing experiences have a great impact on an HIS deployment. The expectations
of one user will be different from another, which potentially lead to the acceptance or non-
acceptance of an HIS system. Therefore, change management is an important aspect
regarding people management.
The HIS system is the core of a hospital operation and its usage has to be consistent
throughout the hospital. There will be processes that are considered “out-of-band”, i.e.
these processes have to be completed outside of the HIS system. Users have to be briefed
and prepared to perform these processes. The HIS system and these out-of-band
processes form the entire operational process flow in a hospital.

Key users
When a new hospital is at its initial stages of being setup, a few key users such as the HIS
sponsor, key user for inventory, billing and financial accounting are important for
bootstrapping the HIS implementation process. The HIS sponsor adds stability to the
implementation process from the onset. The sponsor sets the tone of the implementation by
stating clear objectives, clears obstacles for the key users and the implementation vendor,
and works collaboratively with the key users and vendor to find practical and pragmatic
solutions without impacting the cost and duration of the implementation process.

Medicine supplies

The key users are needed for their domain expertise. The key user for inventory is
responsible for determining the hospital stock supplier (drugs and consumables), cost to the
hospital, prices, re-order levels, internal ordering processes (setting up of main stores and
sub-stores within the hospital).
The key user for billing is responsible for determining the services to be offered by the
hospital, services cost to the hospital, rates, concession level, patient category where
concessions can be applied, setup of business relationship with insurers, insurance claims
procedures. These items must be determined for outpatient, inpatient and emergency
departments. The key user for financial accounting (FA) is responsible for determining the
levels of accounting information required by the hospital’s financial accounting
requirements.

The information required will be tabulated into an intermediate medium (also known as the
FA staging environment) where the data concerned can be extract from the HIS and
inserted into the FA staging environment. The data from the FA staging environment can
then be extracted by the hospital’s FA vendor for insertion into the hospital’s FA software for
further financial accounting processing.

Hiring
The timing of hiring all other staff need to be planned early. HIS training for all staff need to
be planned according to the hiring schedule so that there is continuous training for new staff
in preparation for starting the hospital operations.

Technicians teaching on how to read heart monitor

Training
HIS training has 2 main parts, namely the functional training and system training. Functional
training are for the key users and general users to equip them with the knowledge and skills
in performing their duties using HIS. IT training are for the hospital’s Information Technology
(IT) staff. This training typically entails the imparting knowledge and skills in starting and
shutting down the HIS software, taking ownership of the Master data should changes be
required.

Change management
The introduction of any new system will encounter resistance from users due to the differing
experiences and background of these users. Proper change management identified areas
of concern, fear and biases and addresses them directly through training, stating clear
benefits to the hospital and mandate in adopting the system.

The change management strategy shall encompass the following:

1. The project sponsor and steering committee requires the executive mandate to drive
the project to completion. The steering committee ensure the HIS project is
progressing. It takes decisions regarding out of scope items, process amendments
and workarounds as part of the overall objective to ensure the system goes live
successfully.
2. Stakeholder management shall include key users who are identified as agents of
change.
3. Scheduled training plans shall be published in advance to remove any fear or
uncertainty the users may feel regarding their ability to proficiently use HIS in the
course of their daily work.
4. Process changes may be required where manual processes and out-of-band
processes need to be institutionalized. These processes, together with the HIS
system flows, form the hospital operational flows. These process changes need to
be documented and disseminated to all users early.
5. Assuring the users of support before and after go-live will allay their fear and remove
uncertainty. A go-live support plan with duty roster of staff to support the operations
at least for 1 week after go-live, shall be published for all users to view.
6. Regular communication from the hospital’s management and HIS sponsor helps
provide the assurance and the sense of progress of the HIS implementation.
7. Managing the expectations of the users that the new HIS system is not the same as
any other software. This implies that the new HIS system is expected to behave and
work differently. The users should not expect the new HIS to look like any system
that the users may have used before. Setting this expectation helps the user accept
the new HIS system.
Steering committee
The steering committee comprises of senior members from the hospital and HIS vendor.
From the hospital, the members are the project sponsor who has a clear mandate and
accountability for the success of the HIS implementation, the CIO and project manager.
From the HIS vendor, the members are the executive project sponsor, sales director and
project manager.

Process
Clear objective and scope
A clear and well defined scope at the onset of the HIS implementation leads to a smoother
implementation. The objectives and scope form the basis of the HIS system and hospital
operations. It also allows the users to determine the out-of-band processes to be employed.
Beginning the implementation on a clear and firm platform reduces the risks of delays, non-
acceptance of the system and gives confidence to the steering committee in making
decisions regarding the HIS implementation.

Scope creep forms a major challenge to the hospital key users and IT vendor. Key users
with different experiences may want features and functions they are familiar with. All
stakeholders need understand and embrace the scope of the HIS implementation and work
towards the objective with this scope, thereby removing unnecessary changes which only
serve to increase cost and duration of the HIS implementation.

Role of steering committee

The steering committee shall meet regularly. At the beginning and towards the end of the
HIS implementation, it is recommended that the steering committee meets every fortnight.
The project manager presents the progress update of the HIS implementation,
accomplishments in the previous fortnight, the activities and outcome expected in the
following fortnight and issues encountered by the project team that requires the steering
committee’s attention.
 Doctors and nurses plays a main role within a Healthcare
center

The steering committee, with its clear objective and understanding of the project scope,
helps to clarify and remove unnecessary scope creep and requests and provide the
direction for the way forward, which may be in the form of a workaround or out-of-band
process. The steering committee is responsible for ensuring that all necessary sign-offs are
done promptly, champions change management and continually tracks the timeliness of
critical deliverables.

HIS operational flow

Key users are required to be highly familiar with the HIS operational flows. The key users
are responsible for cascading this knowledge to their staff, determining other out-of-band
processes required for their respective operations.

The involvement of key users is critical because the operational flows are performed by the
key users and their staff. Therefore, the key users and their staff must be proficient in the
HIS operational flows and the hospital’s out-of-band flows in order to achieve an efficient
operational level. Since the key users are also the agents of change, their knowledge of the
operational flows will increase the confidence in their staff in using the HIS system.

Setting up Master data

The key users are responsible for determining the Master data required. The Master data is
the crux of the HIS system. It defines what and how the system will behave. Master data
templates will be provided in Microsoft Excel spreadsheets. The key users shall populate
the templates with the Master data. Examples of Master data include drug master, service
master, tariff master, insurance master.

Medical reports

The Master data will be imported into the HIS system for early testing. There may be
several iterations of corrections by the key users. The Master data will be used in the
training so that hospital users will see and use the hospital’s related Master data. This helps
the users to be familiar with the operational system and reduces the sense of shock and
fear when the hospital becomes operational.

Interfaces to external systems

The approach to interfaces shall promote a flexible and adaptable method of integrating
with external components. A few approaches are used:

1. Utilizing an intermediate medium known as a staging table. In this method, data is

extracted from HIS and inserted into the staging table. The format of the staging
table is defined after consultation with the hospital’s external component vendor and
it consists of fields that the external component vendor requires and these are fields
that are available in HIS. The external component vendor subsequently writes the
scripts to extract data from the staging table and insert the data into their
component. This method provides a level of abstraction which promotes flexibility in
interfacing with an external component. Should the external component change,
there is minimal need to change parts of HIS.
2. HIS can consume (utilize) coarse-grained web services or remote APIs. These web
services shall be coarse-grained so that a complete function can be accomplished
with one web service call. The web service may utilize other fine-grained APIs to
achieve its objective and this is transparent to HIS. This method promotes
adaptability because the HIS simply needs to invoke one coarse-grained web
service. Should the external component change, the same coarse-grained web
 service can be utilized. The external component vendor simply needs to implement
the fine-grained APIs to achieve the objective of the coarse-grained web service.
As much as possible, standards in messaging formats are used such as HL7. The hospital
has to ensure that there is a test environment for the interface testing. After going live, there
is no way to test the interface without an interface testing environment.

User role/tasks/permission configuration

The IT key user has to define the user roles, tasks and permissions allowed for these users.
This important configuration determines the role-base access control mechanism within the
HIS system so that there is no breach in security protocols between staff from different
functions performing unauthorized tasks.

Depending on the size of the hospital, this will be an on-going activity as new staff are hired.
The definition of the roles, tasks and permissions requires in-depth thought process to
create the role-based access control and also not suffocate the system by constraining the
users too much that they are not able to perform their function.

Operational flow test

After the Master data is loaded into the HIS system, an operational flow test can be
conducted for the users or key users. During the operational flow test, several computer
machines are setup in a room where each computer shall assume the role of a hospital
user. The users normally are the front desk, outpatient doctor, biller, pharmacy, store,
nursing station, inpatient doctor, emergency room doctor.

The operational flow test mimics several scenarios within the hospital operations such as
outpatient treatment, emergency room treatment, admission/administration/discharge of
inpatient, pharmacy issues, stores P.O/GRN/returns and billing. These tests achieve the
objectives of testing the Master data in an operational scenario and increasing confidence in
the user by experiencing the system in action.

Go-live preparation
Aside from the Master data, there are several other areas of planning that needs to be
completed before launching the HIS.
Data setup
Master data is to be imported into HIS again before going live. This is to ensure that the
database is “clean” before launching HIS.

Contingency planning
The hospital needs to have plans for contingencies. For example, are there manual forms
for operations should the HIS system not be available due to massive power failure?

Location test
All PCs at all staff workstations need to be tested by logging into the HIS system from their
respective workstations. This test confirms that the network is functioning and the PC is
able to communicate with the HIS system efficiently.

Device configuration (bar code printers, printers)

Bar code printers, label printers and general printers need to be configured in every PC by
the hospital’s IT team. Users shall log into HIS system and do test print from the HIS to
check that there are no issues in printing.

Interface preparation
Testing the interface from HIS is required to confirm that there are no connectivity issues to
the external component live system.

Go-live support
In preparation for the HIS launch, a duty roster shall be drafted. The roster contains the
names and where these support staff are stationed for the go-live. The support staff are
responsible to answer questions from the HIS users, clarify doubts, and help trouble shoot
configuration issues. The number of support staff depends on the number of floors, number
of nursing stations, number of doctor stations and number of sites. It is not dependent on
the number of beds. There shall be a go-live control centre where critical issues are
reported and looked into for quick resolutions.

Technology
The hospital’s IT team is responsible for the design and setting up of the technology
infrastructure.

Infrastructure setup
Infrastructure setup includes the network, IP address assignment, PC configuration, PC
deployment, server room availability to host the servers. The IT team install the application
servers and database servers. The IT team will be trained to install the HIS application. The
IT team needs to ascertain the need for high availability. High availability can be achieved
by using hardware or software clustering.

Security is vital

The IT team needs to draft the backup and recovery procedure. Disaster recovery may be
part of the high availability design and implementation. Business continuity may be done
manually until the systems are back online. The need for these processes can be done
progressively.

HIS setup
The IT team will be trained to install and deploy the HIS system.

Summary
In summary, the setup and successful deployment of an HIS system in a new hospital goes
simply beyond the configuration of the HIS software. There needs to be a holistic approach
to the HIS deployment which has to be done in conjunction with the hospital other
operational processes. Napier’s HIS encompasses an end to end workflow that can quickly
operationalize a new hospital’s information system needs by adopting Napier’s HIS in-built
workflow. Napier’s HIS incorporates the best practices from various deployments that have
been done. Several significant advantages of using Napier’s HIS are:

1. Napier’s HIS is a comprehensive system with a flexible architecture that can fit into
both cloud and on premise requirements. The application suite of integrated modules
collaborate seamlessly between various departments of the hospital, bringing
operational excellence and enhancing patient care 365 days a year, every year. Its
flexible architecture enables HIS to grow with the needs of the hospital as the
hospital operations expands and grows. Napier continues to support the needs of
the hospital through our Voice of Customer program.
2. Voice of Customer (VOC): Napier constantly receives pragmatic feedback regarding
product features from customers who operationalize real world scenarios, making
Napier’s HIS ready for real world deployments.
3. Napier’s HIS is a single platform that is flexible and addresses the needs within a
clinical setting and can be easily integrated with 3rd party systems and devices.
4. Napier’s HIS utilizes modern technology and a flexible architecture that allows
Napier’s HIS to adapt to various environments.
A point worth repeating is that in implementing an HIS at a new hospital, as people and
processes are new, it is imperative to go-live and make adjustments to processes where
necessary. It is important to set aside some investment and a plan for fine tuning the
approach and resolving minor problems that will be encountered after going live.