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.
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.
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.
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.
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.
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.
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.
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:
- 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.
- Stakeholder management shall include key users who are identified as agents of change.
- 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.
- 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.
- 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.
- Regular communication from the hospital’s management and HIS sponsor helps provide the assurance and the sense of progress of the HIS implementation.
- 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.
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.
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.
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.
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:
- 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.
- 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.
Aside from the Master data, there are several other areas of planning that needs to be completed before launching the HIS.
Master data is to be imported into HIS again before going live. This is to ensure that the database is “clean” before launching HIS.
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?
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.
Testing the interface from HIS is required to confirm that there are no connectivity issues to the external component live system.
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.
The hospital’s IT team is responsible for the design and setting up of the technology infrastructure.
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.
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.
The IT team will be trained to install and deploy the HIS system.
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:
- 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.
- 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.
- 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.
- 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.