Hospital Information System (HIS) Project Implementation

  • First Published: November 23, 2015
  • Latest Revision: January 19, 2024

This paper hopes to describe the steps necessary when acquiring a Hospital Information System. It focuses on the project of implementing a system in a new hospital from the perspective of both the vendor and the health care facility. It is in the process of being written.

INTRODUCTION

Information Systems are put in place to help run a business. The main aim of  a computerized system in healthcare is to help care providers do their work and for others in the facility/institution to assist them. The work of healthcare includes

  • care of persons who are sick,
  • the early detection of disease,
  • prevention of health problems and
  • promotion of wellness.

The term healthcare information system is the proper generic term when all these services are provided.  In a hospital, the principal function is patient care (managing the needs of persons who are sick) and the system may be called Hospital Information System.  The system should not be named as Electronic Medical Record (EMR) or Electronic Health Record (EHR). Such a name is a misnomer because it does not put into perspective the objectives of having a system. No industry puts up a system just for recording information. Instead, a defined part of the data generated from work that is captured in a database can be extracted and kept as a record of events (the Electronic Medical/Health Record). A system similar to the HIS may also be built or acquired for polyclinics, specialist clinics and day care centers because their functions are similar to that of a hospital.

Strategies and Approaches to Acquisition of a Hospital Information System

Acquiring an information system is a serious and formidable undertaking requiring expertise, skills and experience in its planning, preparation and execution.

Differences in Approach for Different Situations and Scenarios

The approach to implementation of a HIS depends on the degree of readiness of the facility to undertake HIS implementation which depends very much on its previous experience. A facility may be at any of these four (4) levels of readiness:

  1. A completely new hospital intending to be (fully) computerized
  2. A functioning hospital with some computerized modules wishing to upgrade to a full HIS
  3. A functioning hospital without a significant computerized system
  4. A functioning hospital with an existing HIS that requires replacement

Whether introducing an information system for the first time or replacing an existing one, the general approach is similar. However, there will be fairly significant differences in putting the system into operation i.e. whether it is staggered or simultaneous (big bang approach).

When implementing in a completely new hospital (a green field) how the facility is to look like and function must be imagined, thought out clearly and documented. It is desirable to study how existing fully computerized hospitals are being run, through the process of Benchmarking. As such the IT infrastructure can be designed to suit the facility and match the requirements the system to be acquired. A key step is to design policies and procedures that will optimize what can be accomplished by a computerized system.

For a functioning hospital without a computerized system, it is necessary to  change existing policies and procedures to suit the use of a computerized system through a process called Business process re-engineering (BPR). The management and users sometimes cannot fathom how  computerization and information technology can facilitate their work. Often, they are unwilling to part with previous ways and adopt new rules and methods. User resistance is an issue that needs to be addressed delicately. These issues are overcome through the process termed as Change management. This happens from the beginning and continues until use of the system is well and truly accepted by all within the organization.

If the hospital already has a system in place, the experience with its use must be taken into consideration by studying the benefits and shortcomings. The opinions and suggestions of various categories of users must be sought. Replacement of an existing HIS that is not as easy as it may appear to be. To achieve the full potential, business process re-engineering and change management still need to be done to:

  • redefine the scope of the project to cater for additions in functions and structural components of the facility.
  • optimize the functions offered by the new system and the advances in technology that comes with it.

In a hospital with an established system, data retention and migration become an extra undertaking. The hospital may also want to retain some legacy applications and need to consider the feasibility of doing so. Computer systems change continuously. Retaining modules using outdated programming languages, operating systems and hardware may not be a good idea.

Above all the cost of ownership of the system would in the end affect much of the decisions.

Phases of Acquisition

The activities involved are carried out in sequential steps although some steps may be done concurrently. The scope of work can be divided according groups of activities occurring in phases as outlined below:

  1. Project Planning and Oversight
    • Management decision and commitment
    • Decision on strategy for acquisition (all or in parts)
  2. Preparation prior to implementation
    • Appointment of the Project Management Team
    • Requirements study (defining scope and functions)
    • Business Process Re-engineering
    • Change management
  3. Choosing the Right Solution
    • Study availability of suitable solutions in market
    • Request for participation (Request for Information, Request For Proposal, Issuance of Tender)
    • Award of contract
  4. Customization of applications software and system architecture
  5. Installation of
    • hardware,
    • software and
    • network
    • system integration
  6. Testing
  7. Training
  8. Commissioning and Go live
  9. Operations and maintenance
  10. Handover
  11. Review at end of cycle

This division into phases is as depicted below:

Activities of Project Planning, Implementation and System Management

The activities within each phase will be discussed further.

Most tasks may be initiated only after the completion of the previous process i.e. sequentially. Often, unrelated tasks can be performed concurrently. Hence to optimize time, the tasks that can be carried out simultaneously by different teams or individuals can be are grouped into portions. In the preparatory phase if the system design is known, many activities can be done concurrently. For example, putting in place the hardware components making up the system architecture and the customization of software, software development where necessary and installation of system hardware may be placed in the same phase. Integration of software and hardware can only be done when both are ready (but not necessarily finalized). The acceptance test should be done on a fully integrated system. Training and the management of changes brought on by the use of the new system goes hand in hand. It is effective only when carried out on a stable functioning system.

PHASE 1: Strategic Planning and Oversight

This phase concerns with the following:

  1. Management decision and commitment
    • Decide on need
    • Assess capability (readiness)
  2. Commit
    • Allocate resources
    • Lead
  3. Strategy for acquisition (all or in parts)
    • Strategize
    • Organize

Management Decision and Commitment

Acquiring an information system is a serious and formidable undertaking requiring commitment, expertise, skills and experience in its planning and execution. As such initiation of the project must come from top management. What constitutes top management is different for organizations with different levels of complexity. In a conglomerate or enterprise, the this would be the board of directors. Big hospitals may have a director and an operations manager (CEO or COO). On the other hands, smaller hospitals may be managed only by an executive officer.

The involvement of top management in the acquisition may be assigned to one or more top level managers or to a steering committee. The formation of a steering committee has the advantage of:

  • encouraging participation of all relevant parties,
  • early participation of of those who will be managing the project
  • allowance for employment of third party resource persons and consultants,

The HIS acquisition project has to be managed at many levels by different teams i.e.

  • planning, oversight and facilitation (Steering committee)
  • preparation for acquisition (Project Planning Team)
  • actual implementation (Project Implementation Team)

The division into these levels may seem unduly complex and redundant but each level has distinct functions requiring input from people with special knowledge, skills and experience.

Employment of Experts and Consultants

Acquiring a computerized information system gives rise to many ramifications. The hospital may not have the necessary personnel with the knowledge and skills necessary to plan and execute activities at all the phases mentioned above. It may want to employ experts in various areas at all levels of the acquisition process to help it understand the issues and also act as its advocate when dealing with various parties involved. The hospital may want to entrust all the activities to one project management company to different companies for different phases. If one lead company is chosen, the hospital must ensure that it has the necessary capabilities or is willing to outsource the activities to companies with the necessary expertise and experience. The common approach is to offer the entire contract to the company from whom the solution is to be procured. Often the hospital wants to shorten the implementation period to only several months rather than a longer period of at least one year and a half. On its part, there is a tendency for the company to concentrate on installing its hardware, network and applications but give scant attention to the preparatory phase. It is not proper for the hospital to have a hands-off attitude. Instead for a proper system to be established, the hospital must be closely involved so that it is aware of the processes of implementation and the resultant system. This is pertinent even if the hospital chooses to outsource the operations and maintenance of the system to a third party after it has been handed over to the hospital.

Project Steering Committee

The function of initial planning, oversight and facilitation may be assigned to one person or a few selected individuals, but a better option is to form a Project steering committee. The committee decides on the direction to take and plan the strategy and control the implementation. Beyond the planning stage, the committee oversees the project implementation. It makes the decisions on how to resolve problems that prevent the project from moving forward and resolve conflicts between parties.

Members of the Project Steering Committee are made up of stakeholders including the top-level management, all departments in the organization and staff representatives. For the HIS project, it is essential that the directors and high-level executives like the Chief executive officer, Chief Information officer and the Head of clinical governance are involved. While a committee can be unwieldy. the composition of the committee encourages it to look after the interests of the organization as a whole. As such, the committee will have within its ambit working committees assigned to look at various issues and carry out various activities. Each working committee will co-opt staff from their functional areas.

It is desirable for the Project Steering Committee to form sub-committees or work groups to work on planning and implementation issues regarding administrative, operational and information management functions to provide input and advocate for their interests. Each functional area or service need to form teams made up of at least 2 persons from that service and an internal client representative. At each meeting, a member of our BPR team would be present. However, discussions can take place outside of meetings as long as suggestions made are brought up for consensus.

The Project Steering Committee

The functions of the committee and its terms of reference is elaborated below.

Deciding on Strategy for Acquisition

Several steps has to be taken by the hospital management (represented by the Steering Committee) before the solution is procured. This includes :

  • evaluating the readiness of the organization to make the move towards using a computerized information system
  • appraising the information management needs of the organization
  • envisioning the desired solution in terms of suitability, reliability, cost of ownership, and the risks involved
  • defining the scope of the project
  • produce a report (Information Management Policy)

Information systems are acquired in two ways i.e.,

  • purposely built for the organization or
  • through the purchase of a ready-made off the shelf product invariably with modification.

It would be nice if a fully integrated system that fits all or most the requirement of the hospital is already available. However, this usually not the case. The vendor may not have applications peculiar to the hospital within its inventory or the application is not suitable because the policies and procedures used for designing it do not correspond with those of the hospital. Because the information system for a healthcare system consists of many separate sub-systems, system integration is of major concern.

Defining Scope and Requirements

Systems are built to serve functions. The hospital has to define the scope and requirements of the system it wish to acquire. To understand them and to know the environment within which the system would operate, it is essential that hospital carry out the following trilogy of activities:

  • Situational analysis
  • Needs Assessment
  • Gap analysis

These steps can be carried out with the help of an information management consultant but with the involvement of all categories of staff at all levels of the organization.

Steps in Defining Requirements

This set of activities is aimed at envisioning the desired solution in terms of scope, requirements, suitability, reliability, cost of ownership, and the risks involved. It begins as a fact-finding mission to look at and describe the general situation. The needs are assessed and analyzed at first in general but subsequently become more focused. As the project move forward the phases, new issues, needs, and gaps may be discovered. Although conceptually these steps are sequential, in practice they can be carried out simultaneously as each area or aspect is examined. Because functions are interdependent, this set of activities occurs in reiterations by first focusing on pertinent aspects within each aspect or area but later looking at the organization as a whole. The final outcome would be the detailed requirements and that can be converted into specifications of the intended system.

Evaluation of the Readiness of the Organization

In evaluating the readiness of the organization to make the move towards acquiring and using a computerized information system, the committee must deliberate and acquire an understanding of:

  • the needs of the hospital with regards information management
  • the type and amount of resources (finance, human resource, time) required to accomplish the project
  • the managerial and technical expertise, skills and experience required to successfully plan and execute the acquisition.

Situational Assessment and Analysis at the Beginning

Rather than making assumptions, the hospital has to make an honest study of the way it is currently managing information. Computerization presents an opportunity to enhance whatever mechanisms being used. The aim would be to ensure that the future information system would be an asset that is harmonious and synergistic with the aspirations, policies, and methods of the organization. The design and workings of its information system must be in line with its vision, mission, objectives, functions, and business rules. What has worked previously and what surfaced as drawbacks are determined via SWAT analysis.

These findings must be analyzed and expressed as documents that will form the basis for the design of a better information system and the strategy for acquiring it.

Current Status with Regards the Adoption of Computerized System

With regards to the adoption of computerized information systems the hospital may be at one of these statuses:

  • A completely new hospital intending to acquire a comprehensive and integrated system.
  • A functioning hospital without a (significant) computerized information system and insignificant automation system
  • A functioning hospital with some computerized modules without significant integration
  • A functioning hospital with an existing HIS that requires replacement

Whatever the situation, the facility should consider the project as an opportunity to maximize or at least optimize the use of a computerized information system. The usual problems faced by a facility using a non-computerized system or an incomplete or poorly integrated system are:

  1. Inefficiency caused by:
    • need to repeatedly collect of administrative and clinical data 
    • delays in obtaining test results and other data
    • data management tasks taking time away from primary duties
  2. Poor communication between staff members leading to poor understanding of roles and objectives leading to poorly streamlined work processes
  3. Lack of decision support especially for clinical areas
  4. Difficulty in making available pooled and analyzed data (reports) that will help managers at different levels (managerial decision support)

In a scenario where the current implementation does not include some or most services, the facility should aim for a total HIS so as to eliminate the issues relating to the use manual processes and paper based documentation. Partial implementation leads to difficulties to obtain complete data both for carrying out services as well as for statistics.

The presence of disparate poorly integrated systems also lead to difficulty in data management and Information system management.  One major issue would be the wish to retain the existing software or the preference for a particular product for a particular service. This predilection often surfaces in areas such as Laboratory In formation System [LIS], Radiology Information System – Picture Archiving and Communications System (RIS-PACS) and Critical Care System. Choice of software should have been resolved at the point of award of the contract or during contract negotiation. It should not arise during project implementation.

Changes in goals, scope, policies, and procedures that has been introduced or occurred spontaneously from time to time through review of existing documents or discovered through further study. The facility should be aware of existing shortcomings or difficulties faced that it hopes to eliminate or lessen.

An important aspect of situational analysis is to determine user readiness and acceptance of a computerized information system. Their perceived needs and apprehensions should be sought.

The findings of the situational should be presented to different categories of staff of the facility so that the accuracy of findings made are verified and their suggestions sought.

Information Management Needs Assessment

The needs can be derived based on the conclusions arrived at during situational assessment and analysis. However, some additional needs must be freshly envisioned. Needs must be differentiated from wants. These must be voiced by both the management and staff (via representatives even if comprehensive staffing is not ready). With regard to policies, consensus on what is be done and how to proceed is reached through dialogue with managers especially heads clinical of units and departments and also specialists or specific professionals in various areas.
The amount of work and the duration to accomplish the desired future system must be estimated. The scope of work is determined by Identification of characteristics and components of the system. This should be as comprehensive as possible to avoid the likelihood of “scope creep” later and failure to budget the undertaking fully.

The full benefits of information technology can be realized if all functions of the healthcare facility are computerized where possible. Only processes that are better done on paper or verbal communication is retained, if at all. Managing data in a system that is only partly computerized is a challenge. Also, it would be very difficult to manage operations and data, if systems are not put in place in all departments and units simultaneously. Intentionally leaving out a department or unit from the computerized system is not a good option. It is possible to stagger the implementation despite the attending difficulties and this would be described.

For the actual provision of healthcare (clinical, supportive and administrative), it is best if the facility acquires a system that has already been designed to be integrated. There are systems that are very specialized and subject to rapid changes such as Picture Archiving and Communications Systems and Drug Database that are better obtained from specialty vendors. For these and for managerial and business functions, systems from other vendors can be incorporated. Integration of disparate systems is a difficult challenge and is one of the causes of project failure.

The main output of situational analysis is the identification of the policies and procedures requiring change and the degree of change required for successful implementation.  Based on the study of the facility’s objectives, polices and work processes discovered by the contractor or expressed by the facility at the situational analysis exercise, the BPR team identifies:

  1. the desirable objectives to be met
  2. actions to be taken achieve those objectives (Gap Analysis)

Envisioning the Desired Information System

A vision of the desired the desired information system must be crystallized to act as the benchmark when comparing with products on offer (the gap analysis). This vision should include a definition of the scope, objectives and attributes of HIS encompassing the abilities to:

  1. Guide and enable the performance of Patient Care Processes
  2. Facilitate communication between care providers through sharing of information
  3. Enable automation of work processes through links within it, integration with other components of the hospital information system and interfacing with machines/instruments
  4. Provide clinical decision support
  5. Gather, store and make available vital clinical information (individual and aggregated) for primary and secondary use
  6. Maintain a permanent record of events and all activities of patient care (as the Electronic Medical Record and other documents based on medico-legal requirements)

If the facility is not yet computerized, its main need is the transformation of processes from the manual to a computerized system. “Users buy-in” may be an issue but most healthcare personnel believe in the value of computerization. Indeed, the great majority of users would prefer to work in a computerized hospital. Managing expectations can be an issue and this need to be addressed with due care.  It is necessary to stress the values of using a comprehensive and integrated system. Opting out is not an option. Choices made by departments or units must take into consideration the need for integration.

The conclusions reached by the activity of Needs Assessment must be documented. The opportunities for improvement by acquiring a computerized system are identified. Ways and means of overcoming the existing shortcomings are proposed. These include changes in operational policies and processes. This is because in a computerized system strict conformance to processes is necessary. Even so, alternatives for different situations are anticipated and built in.

Many of the issues can be resolved with a system that provides access to a properly designed database where relevant data is made available as the need arises. Hence, database design is given serious attention by a database design expert or team so that the data needs of the service, their origin and how they are to be captured and made available are identified.

Achieving these objectives require good infrastructure, human resource, management and most of all well-designed processes. When a information management system like the HIS is adopted, there is an opportunity to:

  • Enhance the efficiency of some processes
  • Automate some processes
  • Improve communications between personnel responsible for putting in input with those that subsequently carry out processes to produce intermediate or final output.
  • Integrate processes across functional and physical boundaries.
  • Remove some processes which are made redundant or unnecessary by computerization.

During the needs assessment exercise, examples of systems available in the market and its components need to be demonstrated to the managers of the facility and the users. They should be convinced of the value of applications in enhancing their service or solve their problems. Queries regarding how the system is to be used in a real-life situation especially its usability need to be answered. The contractor, especially its the applications software vendor, need to obtain as much feedback as possible and findings should be documented.

How work is to be done using a comprehensive and integrated computerized information system must be envisioned. Needs must be converted to requirements and later specifications. The needs must take into consideration the content of the system as well as its features and characteristics.

The content and features of a system for a typical hospital is depicted below.

From Needs to System Design

Features and characteristics must be further developed into requirements and specifications which will be used for:

  1. description of scope and requirements in the Request for Proposal
  2. evaluation of proposals
  3. defining tender specifications
  4. project quality control.
  5. assessment of final product (testing and commissioning).

as envisioned and specified will be used when selecting systems available on the market or building them (request for proposal and selection).

Gap Analysis – Where to Go and How

Gap is defined as the deficiency that needs to be bridged in order to achieve the desired objectives. The aim of the exercise is to identify the opportunities for change that will enhance various aspects of service and solve problems. To perform a gap analysis the current situation is compared with the expected future scenario. It presupposes that the objectives and therefore the standards have been set by the facility. In most instances, the people within the facility are not fully aware of what can be achieved through computerization and use of an information system. It is the committee’s duty to highlight these benefits to enable staff of the facility understand them and be receptive to the changes planned. Lack of understanding and incorrect assumptions need to be addressed as part of the change management exercise.

Assurance of Commitment

The Steering committee must obtain assurance from top management on major decisions and actions

  • commitment to change
  • outlay of resources (funds, human resource, time)
  • staying power (meeting challenges, seeking alternatives, agility)

Establishing the steering committee is a once only commitment. Its duties persist through the implementation period and ends with its fruition.

Besides getting commitment from the top-level managers, it must also be obtained from heads of the various departments or units, and through them that of the rest of the staff.

Oversight and Liaison

In exercising its oversight function, the Steering Committee, is also responsible for appointing the teams executing subsequent levels i.e. Project Planning Team and the Project Implementation Team. The deliberations and resolutions made by the steering committee must be written as a policy document and passed down to these two teams. At the same time, there must be liaison between the committee and the teams and therefore the need to appoint a liaison officer. To this end, the officer should be a member of the Steering Committee and the link person between it and the other teams. He or she is the suitable person to be the project coordinator representing the hospital when dealing with vendors and consultants.

Appointment of a Liaison Officer

The Liaison Officer need not be a high-ranking officer. He/she must have time to be involved fully in the project from the start and be a part of subsequent committees and teams including be part of the project implementation team.

Documentation of Resolutions Made by the Steering Committee

The findings and resolutions made by the Steering committee should be documented as a policy document. The document would provide the guideline for what need to be done further by the Project Planning Committee. It would also be the source of reference for the Project Implementation Team.

Phase 2: Project Planning: Preparation Prior to Implementation

The steps in this phase is as outlined below:

  • Appointment of the Project Planning Team
    • Requirements study (defining scope and functions)
    • Business Process Re-engineering
    • Redesign of Operational Policies and Procedures
    • Change management

It is important that the preparation prior to implementation is taken seriously. To this end a team of people should be appointed to study the findings of the Steering Committee (the policy document). The results of the previous exercises of situational analysis, needs assessment and gap analysis must be studies and these exercises mist be continued to refine knowledge regarding the current situation in a more objective manner, identify the correction or improvements to be made and convert the needs into specific requirements.

An appropriate name for this team would be the Project Planning Team.

Prepare a Fertile Field

The Project Planning Committee – Roles and Responsibilities

Findings and resolutions made by the Steering Committee need to be analyzed and worked out in greater detail. by a core group of relevant persons. This can be achieved by appointing a Project Planning Team. The main objectives of this committee is to to respond to the findings of the Steering Committee with regards to:

  • envisioning the desired information system for the hospital
  • ensure that the hospital is prepared for the changes required in terms of policies, procedures and work culture.
  • planning the actions to be taken prior to acquiring a computerized information system.
  • establishing the method of acquisition

The objectives and therefore the tasks to be accomplished are interrelated and interdependent. Yet they need to be apportioned to smaller groups of persons who would then have to exchange ideas and come to a common resolution that will be clearly documented. This necessitates the organization of the committee into work groups or teams focusing on the following:

  • Business process re-engineering
  • Change management
  • Definition of requirements, specifications and standards

Organization Chart of the Project Planning Committee

Appointment of the Project Management Team

RESPONSIBILITYROLES OF SOLUTION PROVIDERROLES OF HEALTH CARE FACILITY
HIS System PlanningDefine system components,
and structure
 Provide input
Implementation PlanningLay out the schedule and responsibilities.Evaluate the plan and provide input
Project ManagementInitiate, put into effect, and supervise of all works.
Assign workers
 Cooperate with implementation team
Project CoordinationCoordinate between various teams and the facilityCoordinate between facility staff and implementation team
Project Quality ControlSet control limits.
Monitor progress.
Study Progress Reports
Business Process Re-engineeringAssist/Facilitate the Facility to maximize productivity, efficiency, and quality of its service.Develop policies and processes that take advantage of  a computerized system
Software CustomizationAdjust the structure and
content of software to suit the needs of the Facility.
Evaluate and provide input
Network 
Installation
 Install the networkProvide input and evaluate
Hardware InstallationInstall servers, storage
and peripherals
Observe and Facilitate
Software Installation Install system and
applications software
 Observe and Facilitate
System Integration Ensure components of the system are in sync Observe and evaluate
Testing of Application modulesTest each application in terms of usability for various functions. Observe and evaluate
Testing of Overall SystemTest all functions
of the system
 Observe and evaluate
Rectification of shortfallsIdentify defects 
and shortcomings
 Provide input
Documentation Document what has been done
and system specifications
Obtain and Examine document
Training & Change managementTrain users on how to perform tasks 
using the system
 Hands on trial of using system to perform various tasks
User Acceptance Testing Provide data from tests already performed.
Assist user to perform tests
Perform tests on various components of the system
Commissioning & Go Live Demonstrate and provide data on tests. Hand over system documentation.
Provide assurance on system usability.
Commission and accept the system
Monitoring & Rectification after Commissioning / Hand overProvide User Support (Help Desk).
Customer Satisfaction Survey.
Problem Identification & Rectification.
Provide Feedback

Terminology

The meaning of terms is given in this link:

Requirements Study

Information systems are designed to serve functions. As such the objectives, policies, and procedures of the hospitals and the various departments and units within it need to be known. This will be translated into the requirements, specifications and standards of the HIS and its various sub-systems.

Defining the Characteristics of the Desired Information System

The component and characteristics of the system must be deliberated and accepted before the procurement exercise. The requirements, specifications and standards of the entire system and its sub-systems need to be documented. To this end, the current work processes are observed through visits to worksites, interview of users and examination of existing Standard Operating Procedures (SOPs).

Learning from Past Experiences – Literature Review

Experiences from past implementations within the country or elsewhere in the world can be obtained from review of the literature. The key success factors from successful implementations and causes of failure can be identified.

Benchmarking

Facilities that have achieved a smooth implementation and successful use of systems can be chosen as models. It is worthwhile to learn about them through the process of Benchmarking. This can be achieved through site visits and discussions. Help can be obtained from the hospital itself or from the implementation team.

Facilitating Patient Care Functions

Computerization and the use of information technology, when used in clinical care, is expected to facilitate operations by providing care providers the following functions :

  1. Guide and enable the performance of Patient Care Processes and all other processes that support it
  2. Facilitate communication between care providers  through sharing of information
  3. Enable automation of work processes through links within it, integration with other components of the hospital information system and interfacing of the system with computers, machines, printers and scanners
  4. Provide clinical decision support at point of care
  5. Gather, store and make available vital clinical information (individual and aggregated) for primary and secondary use
  6. Maintain a permanent record of events and all activities of patient care (as the Electronic Medical Record and other documents based on medico-legal requirements)
  7. Export data to external systems/databases

The implementation team must be familiar with these objectives and continually use it as the guide to what the system should be able to do both at the design, building and implementation stage.

Facilitating Managerial and Administrative Functions

At the same time, the system should also be capable of facilitating managers at various to perform their managerial functions. The categories of managers and their functions is as tabulated below:

ManagerFunction
Clinical line managersPlanning and supervision of operations in their clinical departments and units
Clinical governance Leadership, advocacy, supervision of quality, resource utilization, clinical service delivery, training and research
General manager of the facility (CEO)general management (human resource, administration, materials management and finance) and in strategic management
Functions of Different Categories of Managers

This is realized by providing means to extract, analyze and to present the available data as views and reports.

If the facility is part of part of a cluster or a large enterprise then the system should be able to export to and receive data from external shared central databases e.g.  a data warehouses.

Constituent Parts and Functions of HIS

Choosing the Acquisition Method 

Information systems are acquired in two ways i.e., purposely built for the organization or through the purchase of an off the shelf product invariably with modification. It would be nice if a fully integrated system that fits all or most the requirement of the hospital is already available.

There are two possible approaches to the acquisition of a hospital information system i.e.

  1. Building a custom made system from scratch
  2. Procuring a ready-made off-the-shelf solution

The solution is the system that satisfies the needs of the hospital. The system consists of the hardware, system software, applications, the network ad the means to put them into operation. The first method involves product development followed by implementation. The second approach involves mainly implementation plus modification of the applications where necessary to suit the peculiar environment of the hospital

Building a Custom-Made System from Scratch

A robust, functional and usable HIS is very difficult to design and takes a long time to realize. Facilities should never attempt to develop systems and software on their own. Developing it requires an outlay of large amount of funds, human resource and time. To produce a working system (creating the software and designing the hard ware architecture to support it takes as much as 4-5 years. Even large organizations with seemingly unlimited funding and resources may find it uneconomical to build an in-house comprehensive system. In building the systems many analysts, programmers and database designers need to be employed. Programmers must have expertise in programming and the building of the front end user-system interface. The system would multiple databases to cater to the needs of various applications. Furthermore experts in system management with building and managing the Database Management System (DBMS), knowledge regarding system integration and interfaces with machines are need to employed.

In this approach, the development of the applications and the design of the databases must precede implementation.
Because of the complexity, the tendency is to build components of HIS in a piecemeal  manner by different teams. This often leads to subsequent problems of integration.
Many of the applications for clinical support functions may not be built by the same company. It may be outsourced to third parties or an existing application is procured and modified to be incorporated into the intended solution. Each of these component applications may be built using different methodologies in their development (e.g. Waterfall, Agile, Lean Development, Prototype Model, Scrum Development and etc.) must be chosen.

Procuring a Ready-made Off-the-Shelf Solution

If the organization decide on procuring a ready-made off-the-shelf solution, the work of applications development and database design is considered done. Project activities are focused around implementation.
Fortunately, the objectives, policies and procedures in patient care services are quite uniform. Many products complying to those requirements are available in the market. Therefore, it is feasible for the facility intending to implement a system to appraise and select the system appropriate for its use. The solution can can be constituted using two different approaches i.e.:

  • a solution made up of components that are already integrated and shown to work at other facilities (tried and tested solution)
  • putting together existing applications and system components that would serve the peculiar needs of the hospital (best of breed approach)

Preferably, a system built to be integrated (by a single vendor) is preferred. However, this is seldom the case. It is likely that the system is a combination of sub-systems from different vendors. In that case at least, they should have been shown to have the potential to be integrated successfully based on experience at at other facilities and instances. The work of integration which is both complex and time-consuming would be a major part of the implementation activities.

Definition of Requirements, Specifications and Standards

In this discussion, it is assumed that the software and the attending system components being implemented is one that is ready-made (off the shelf product, rather than being developed by the facility itself). It does not mean that the software and system components are to be used as they are. In choosing the system being offered, the facility manager needs to be convinced that it is suitable for the facility. Decision for the choice of various components (and vendors) can be made by either the hospital or the system integrator. However, the hospital must supervise the project e.g., via a Steering committee or Project Director. The choice of vendors/suppliers can be made via issuance of a RFP, tenders or Request for Quotation depending on the components or services to be acquired
A careful study of the HIS product being offered by the the supplier (solution provider) should be carried out by the facility’s own experts or a consultant hired for the job. In addition demonstrations of the application, simulations, proof of concept exercises (POC) and visit(s) to a facility where the software/system has been successfully implemented should be requested for. The vendor must be asked to demonstrate Proof of concept i.e. Various scenarios where and when the system is to be used should looked at. Using dummy data, the system must be shown to facilitate each function end to end. Any doubts regarding the software/system should be clarified. Normally, product suppliers are ever willing to show off their product (publicly e.g. at trade shows or for just the potential customer) and this should be taken advantage of.

One of the failings of the selection process is a lack of full understanding of solution being looked for. Often the Request for Proposal document (RFP) is prepared in a cut and paste manner with portions copied from vendor specifications rather then thinking out the overall needs of the organization itself. Often requirements are based on submissions by users or their units. This will manifest in the RFP as duplication, inconsistencies and contradictions. There is a tendency to ask for features that does not add much extra value to the solution. Instead it may inflate the price inordinately. The preparation of the RFP is not just cobbling together requests from various parties but a concerted effort at coming up with a unified, and comprehensive set of requirements.

Assessment of Products and Vendors

Vendors have different approaches to marketing their product. Some vendors offer a standard product to every purchaser and are willing only to make minor changes. Another category of vendors provides a framework with essential components and offer solutions that tries to serve all the  peculiar needs of the customer.
The procurement team must assess the product being offered carefully and determine whether the solution provider has rightly interpreted the user requirements. On the other hand as long as the requirements are met, the system design and specifications (software and hardware) should be left to the vendor. One important requirement that is key to usability of a system is that it is designed to be integrated from the very beginning or has been shown to be capable of being integrated if disparate system components are to be put together. This is especially true for integration between the Clinical Information System and clinical support systems such as Pharmacy Information system, Laboratory Information system, Diagnostic Imaging (Radiology) information system and the Critical Care Information System. Because clinical care is done by teams consisting of various professionals, the Clinical Information System itself should facilitate the clinical work processes in a uniform manner across departments and units plus have similar look and feel across them.

Limitations of an Off-the -Shelf Product

An Off-the -Shelf Product is built based on certain assumptions in the way care is provided. A valid assumption is that care processes in modern scientific medicine is similar through out the world. Often, the solution provider tries to abide by universal standards such that the facility is better off following these rather then insisting to retain their old ways. Differences would be in naming conventions, units of measure, range of services and tests etc. It is expected that the solution provider should be able and willing to cater for these differences.
Usually the vendor will provide solutions to common functions and tasks. Their adequacy depends on the range of services provided by the health care facility. The facility must not expect that all forms, charts, orders, tests, views and reports to be ready in the product is purchased. The vendor must be willing to add what is missing as part of customization. The function that is often different between facilities is the charging and billing function. The solution provider must be willing to address this and this agreement should be mentioned in the contract

Requests for additional scope or components should have been made during project negotiation and addressed by the vendor before the contract is signed. In most instances, the supplier (solution provider) of the each component product need to and usually is willing to change the product (customize it within limits) according to peculiar needs of the healthcare facility. However, the facility should not impose unreasonable or too much constraints on the software vendor or the contractor. It is not uncommon for organizations to dictate certain architecture or configuration that is in conflict with the way the system has been designed. As far as possible, they should be given the leeway to use components that they have tried and tested or is familiar with. 

Intellectual Property Rights (IPR)

An off the shelf software product is made available to the open market. As such, many organizations are likely to procure it. The economy of scale make it possible for the price to be reasonable. The developer of the software would wish that their product is not replicated and then sold. If the IPR e.g. source codes is given away,  they would have lost the rights to the product they invested much to bring to the market. Also, every user  organization would expect that other organizations are not privy to the source code used to build the software because otherwise their system can be tampered with (hacked).

It is fitting that the intellectual  property rights remain with the company that develops the system. To request for the IPR to be transferred to the buyer is unreasonable. It is also unethical for the developer to hand over the source code because it would put other organizations using the same software at risk. Anyway, in most instances healthcare organizations are unlikely to be able to utilize the source code by themselves without the help of the developer.

The worry regarding the source code stems from the possibility that the company which developed the software is unable to provide support for the software if and when the software become corrupted or otherwise cannot be used.  This can happen if for example the company is no longer in business. This can be avoided by ensuring that the company hand over the codes when or if they are unable to support the continued use of the software. Another way is to get a third party (escrow) to hold the codes and release them only when the situation mentioned above arises. This service has substantial costs and would add to the total procurement cost.

Escrow
An escrow is a contractual arrangement in which a third party receives and disburses money or documents for the primary transacting parties, with the disbursement dependent on conditions agreed to by the transacting parties, or an account established by a broker for holding funds on behalf of the broker’s principal or some other person until the consummation or termination of a transaction; or, a trust account held in the borrower’s name to pay obligations such as property taxes and insurance premiums.

Nevertheless, even for an off-the-shelf product, the user organization is entitled to full documentation describing the system including the data models, data structure, data dictionary and other relevant information concerning the databases (DBMS), the system architecture and system management. The solution provider/vendor is obliged to provide user guides and technical guides for operations and maintenance.

The only situation where the IPR can be retained is if the system is built from scratch with features unique to the organization and fully funded by it.

Preparing for the Anticipated Changes required: Change Management

Change management is “the overarching approach taken in an organization to move from the current to a future desirable state using a coordinated and structured approach in collaboration with stakeholders” (definition by Association of Project Managers).
In any project, the process is better understood by answering the question : Change from what to what?

Identification of the Need for Change

This activity occurs at the initial phase of the project. The identification of the need for change is derived from of the outcome of the following activities:

  • Situational Analysis
  • Needs assessment.

Readiness of the Organization: User Buy In

The approach to implementation is quite different for a facility depending on whether it is:

  • moving towards use of computerized information system for the first time (a green-field project)
  • replacement of an existing system or upgrading of an incomplete system

If the facility is introducing a computerized information system for the first time, it must be sure that there is user buy-in i.e. willingness of users to use such a system. This must be achieved by the facility before the solution is identified and procured. This involves the activity of Change Management which is initiated at this point. The intricacies of working in a fully computerized environment may dawn upon users and managers only when they are first introduced to the system. Therefore, change management continues during training and all users become familiar with the system.

It is as much the role of the facility to explain and educate users as is the provider of the system. However, any resentment or disquiet regarding the way the HIS is designed or any other perceived shortcomings need to be addressed by the system/software provider in an amiable manner. An adversarial attitude should be avoided by all parties.

Business Process Re-engineering

Business Process Re-engineering (BPR) refers to the introduction of changes to the way service is provided by the facility in order to make full use of the possible benefits of the adoption of computerization and information management technology (IT). This exercise is the responsibility of the Steering Committee. At the beginning, consideration is given to how a computerized system will affect policies and procedures. However, subsequently operational policies processes have to take into account the actual system that is to be procured. This can be achieved through the customization and modification of the applications software and system architecture to adapt to the needs of the hospital. In areas where the design of the system being acquired does not make certain changes feasible, then some compromise may be inevitable.

The intended changes must be presented to users and explanation given regarding:

  • The alteration of policies and procedures,
  • the underlying reasons, and
  • the anticipated effect on current work practices.

As a response, users may suggest better ways of performing processes that will suit their ways, knowledge and culture. These will be incorporated through customization of HIS.

BPR Activities

The BPR exercise will encompass the following activities

  1. Detailed situational analysis.
  2. Needs assessment.
  3. Gap analysis. Comparison of difference between the needs of the hospital and the degree of compliance of the system proposed are determined and the means of bridging the gap identified.
  4. Mutual consultation aimed at reaching a consensus on changes to be made regarding  objectives, policies and procedures as agreed by the hospital.
  5. Formalization of agreement made re: above consensus.
  6. Designing Standard Operating Procedures (new policies, workflows, processes and standards)
  7. Customization of the HIS to be acquired to suit the SOP and vice-versa.
  8. Introduction and testing of customized HIS
  9. Assessment of  the proposed HIS in terms of effectiveness, safety, efficiency, cost effectiveness, ease of use and acceptability through tests, simulations and surveys.
  10. Improvement or rectification where necessary

Beneficial changes can only be instituted after these a new design has been identified, proposed and demonstrated to be feasible, by the contractor and accepted by the facility. The objectives of BPR is realized in three stages:

  1. Identification of requirements for change in objectives, policies and procedures
  2. Incorporation of these changes in system design and in software customization
  3. Gaining acceptance and  training user on the new objectives, policies and procedure

The changes to be adopted should be on all aspects of the facility’s service but should focus on the core business of patient care. The expected benefits of the changes made at BPR are improvements in:

  1. Productivity
  2. Efficiency
  3. Quality
  4. Safety

Enhancement of Processes Based on the Intended HIS

Achieving these objectives require good infrastructure, proper management, human resource and, most of all, well designed processes. By adopting information management systems i.e., the HIS, there are opportunities to:

  1. Enhance the efficiency of some processes by devising methods that:
    • Simplify them
    • Integrate processes across functional and physical boundaries
    • Obliterate some processes which are made redundant or unnecessary
    • Automate them
  2. Improve communications :
    • between the management and staff
    • between personnel that creates the input to those that use the input subsequently to carry out processes that produce the intermediate or final output
  3. Use data collected in the database to provide information to assist in:
    • decision making in carrying out tasks
    • operational managerial decision making
    • strategic management decision making

Therefore, an essential requirement before procuring systems is to develop clear policies and procedure for all services and document them as Standard Operating Procedures.

Vendors supplying products must show whether these features are already in place within their system or affirm their willingness to introduce these enhancements in the solution that the propose.

Choosing the Right Solution

The steps in this phase are:

  1. Define requirements.
  2. Set specifications.
  3. Evaluate cost of ownership,
  4. Study availability of suitable solutions in the market,
  5. Request for participation from potential suppliers (Request for Information, Request For Proposal, Issuance of Tender),
  6. Award of contract

Establishing the Procurement Team

An information system for a hospital is a product consisting tangible and intangible items the entirety of which is best termed as a solution. The task of choosing the right solution is the role of a Solution Procurement Team.

Evaluating Cost of Ownership

In evaluating the cost of ownership, the entire product lifecycle needs to be considered.

Study of Availability of Suitable Solutions in the Market

The solution is not the just the hardware or software but constitute how it functions, how it can be managed, its characteristics. Currently, many software and system developers have products ready to be used. Implementation then equates with installation plus customization of applications software plus the hardware that makes up the rest of the system architecture rather than fresh development or design. Hence, it is important that both the facility and vendor is sure that the system fits requirements during the bidding process and during the contract negotiation process. Additions to the scope should only be for minor functionalities that is deemed necessary during the implementation but has been inadvertently omitted. A major addition would be subject to a variation order. ‘Scope creep’ is a common cause of delay and failure of project implementation.

Request for Participation: Request for Information (RFI), Request for Proposal (RFP), Issuance of Tender.

It is assumed that the scope of work is known when a contract is signed between the facility and suppliers.

Selection of Suitable Solution

Award of Contract

Because the information system for a healthcare system consists of many separate sub-systems, system integration is a major issue. Therefore, the appointment of a System Integrator or entrusting the function to the Project Implementation (Management) Team is of paramount importance. The job of the integrator is to ensure that components of the system (client workstations, servers, the database, and the network) work seamlessly to optimize all functions. the project implementation.

Phase 4: Implementation of the Project

Distinguishing roles, supervision. the liaison function, managing the implementation.

The steps in this phase are:

  • Negotiation prior to award of tender / contract
  • Review and Agreement on System Design
  • Customization of Applications
  • Customization of System Architecture
  • Installation of System
  • System integration
  • Control of project
  • Testing and Commissioning
  • Training
  • Start of Operations (Go-live)
  • Routine System Operations and Maintenance

Role and Organization of the Project Implementation Team

Information systems are acquired in two ways i.e., purposely built for the organization or through the purchase of an off the shelf product invariably with modification. It would be nice if a fully integrated system that fits all or most the requirement of the hospital is already available. Because the information system for a healthcare system consists of many separate sub-systems, system integration is a major issue. Therefore, the appointment of a System Integrator or entrusting the function to the Project Implementation (Management) Team is of paramount importance. The job of the integrator is to ensure that components of the system (client workstations, servers, the database, and the network) work seamlessly to optimize all functions. the project implementation.

Therefore, the appointment of a System Integrator or entrusting the function to a Project management consultant is of paramount importance. The job of the integrator is to ensure that components of the system (client workstations, servers, the database, and the network) work seamlessly to optimize all functions. the project implementation.

Outline of Steps in Implementation

The outline of the various tasks and the sequence by which it is to be performed during implementation is given as a flow chart below. Concurrent tasks are indicated separately as text boxes but on the same line. Sequence and direction is indicated by arrows. Satisfactory completion of a work segment is determined by a test indicated by the type of test (in a text box) followed by a question in a diamond shaped decision box. The resultant answer i.e. Yes/No determines the decision on how to proceed.

Implementation Workflow

Project Implementation Team

The roles of the teams involved in implementing the project is discussed below.

Work Breakdown

In defining the implementation schedule all the tasks of putting in place a information system need to be laid out in detail. The main tasks of implementation is as outlined below:

  1. Review of System Design
  2. Software Customization
  3. System Hardware and Network Installation
  4. Software Installation
  5. System Integration
  6. Application module testing
  7. Overall System Testing and Rectification
  8. Documentation
  9. Training and Change management
  10. User Acceptance Testing,
  11. Commissioning and Go Live
  12. Handover
  13. Operations and Maintenance
  14. Post-implementation monitoring and rectification
  15. Upgrade or Replacement

The term implementation as used here assumes that the product (system and applications) has already been developed i.e. a complete ready-made off-the-shelf product has been identified as a solution. There the steps in the acquisition project will be:

  1. Choosing the Right Solution
  2. Organization of the Project Management Team
  3. Preparation prior to implementation
    • Business Process Re-engineering
    • Change management
  4. Customization of applications software and system architecture
  5. Installation of hardware, software and network
  6. Testing and Commissioning
  7. Training
  8. Go live

Leadership and Overall Supervision

Project Director (Facility)

The facility need to appoint a Project Leader (Project Director) to represent the facility and its stakeholders. He can be the facility’s Chief Operations Officer or any other person with a senior executive position well versed in project management. It is his duty to communicate the value of the system to users and its broad objectives. He needs to demonstrate commitment of the facility and gain user commitment to the project. Although his/her involvement does have to be ‘hands on’, he/she need to supervise the activities of the project closely. 

Project Implementation Management Consultant

The contractor or solution provider may or may not appoint a Project director. In any case, the person that the Project Manager answers to need to be identified.

Overall Project Management

Project Manager

The contractor or solution provider should assemble a Project Implementation Team headed by a Project Manager. His/her tasks are to:

  1. Work together with other members of the project team to detail out the Project Implementation Plan in terms of scope, objectives and sequence of tasks to be done and the timeline.
  2. Organize the project team by assigning various tasks to persons or teams and defining specific objectives for each of them.
  3. Be responsible for overall supervision of the progress of the project by obtaining progress reports and conducting planned Project Progress Meetings at regular intervals based on requirement. Besides that ad hoc meetings are called when urgent issues arise.
  4. Be responsible for making decisions in the determining the ways to resolve all issues relating to implementation
  5. Institute changes to ensure the smooth progress of project implementation.

Organization of Project Implementation Team

The organizational structure and membership of the Project Implementation Team, reflects the involvement and cooperation of the various teams employed by the contractor as well as contributions from the facility. The organization structure can be divided based on functions, into the

  • Project Management Team and
  • the Project Execution Team

Under both of which will be specific teams.

Each team will depend on the contribution and products of other teams. For instance, the BPR team is required to present their findings to the software development team. The latter is responsible for making available a product, suitable for the facility, which will be installed by the software installation team. However, they should report any weaknesses or inconsistencies back to the software design and customization team and suggest improvements. The change management and user training team may be derived from the BPR team. Otherwise, a separate team consisting of persons with training and communication skills is constituted. The training team may include suitable personnel from the facility. The system integration team will depend  a lot on the team that installs hardware be it servers, network equipment, peripherals or other equipment (such as laboratory and radiology equipment/instruments).

Despite this interdependence, the role and objectives of each team have to be clearly delineated and the lines of authority (chain of command) defined.

Organization Chart

The organization chart for the Project Implementation Management Team is as shown below.

Project Organization Chart

Project Control

The success of the project depends on adhering to or staying within certain limits  relating to completeness which in turn  and are dependent on the constraints of costs, and time. Proper planning and compliance to a strict time line is essential. Despite that, issues will arise. These usually relate to:

  • delay in supplies
  • adequacy and competency of human resource
  • poor cooperation from users
  • project creep
  • non-acceptance by users

The status of the progress of implementation and the issues that arise need to be known and addressed.

Project Controller

A Project Controller is appointed to be responsible for:

  1. Setting timeline (deadlines) for various tasks, and monitoring their completion time
  2. Identifying Quality Control indicators, measuring various parameters and comparing them with preset objectives and standards.
  3. Identifying the risks of implementation failure at the beginning and as the project goes along.
  4. Carrying out preventive measures by resolving problems and instituting improvements.

Project Coordination

Because many individuals as well as teams are involved in making the implementation a success, a purposeful coordination of efforts  is essential. First of all there should be coordination between the contractor/solution provider and the facility. Then there is a need for coordination between all members of the project management team and the project execution team employed by the  contractor/solution provider.

Project Coordinator (Contractor/Solution provider)

The contractor/solution provider need to assign a person to take on the role of the Project Coordinator. He/she will also be the principal contact person between the contractor/solution provider and the facility. He/she should work closely with the Project Manager, the Project Execution team and Project control team in order to coordinate their activities and the status of their progress.  Project co-ordination meetings between Project Controller and the facility is the main mechanism for sharing concerns, resolving issues and deciding on schedules. These meetings are on a regular basis but ad hoc meetings are called when required.

Project Facilitator (Facility)

On its side, the facility appoints a person familiar with project implementation as a the coordinator on its side whose function is to bridge the lines of communication between it and the contractor/solution provider. To avoid confusion, he/she may be called the Project Facilitator. Users should voice concerns through the facility’s Project Facilitator except when there is an open discussion. If the facility has a Chief Information Officer he/she is suitable for this job. Otherwise the head of the Information Technology Unit, the Chief Record officer or a clinical champion with some knowledge of information management can be appointed for this role. During the project, the job of coordination/facilitation will take up most of the person’s time and he/she need to concentrate on this job. He/she will also need to be assisted by other coordinators/facilitators and an advisory team. The advisory team should consist of various clinical and administrative committees, heads of departments/units or individuals who have special expertise in various areas served by the information system being developed.

While it is convenient for project teams to gather information directly from users, it is best that discussions on implementation issues are dealt with only by the Project Coordinator and Project Facilitator. This will prevent misunderstanding and conflicts due to miscommunication.

Resource Persons – Domain Experts

Healthcare information management consultants or Health Informatics experts are valuable resource persons who can provide advice regarding policies, procedures of healthcare and how best to accommodate them to the application software and vice versa. Such a person has knowledge regarding care provision as well as how information technology works based on interest and experience. He/she can keep ‘a watching brief’ over the project implementation. He/she should either be independent or employed by the healthcare facility.

The vendor must have various categories of care providers (so called domain or subject matter experts) within its team. The facility should match these experts with their own. Such persons should be chosen based on their experience and interest. The management need to make arrangements that will free some time from their day to day work to devote themselves to the project when needed.

Record Officers are usually conversant with record keeping and data management. Many are competent in information technology. They should be co-opted into the advisory team of the facility.

Advisory Team (Facility)

The facility need to identify various persons within the facility to provide input to the project implementation team on various policies and procedures within their departments or units. It is best if these individuals are identified and organized into teams. As in a hospital, the functions are divided mainly into clinical, support and administrative divisions then corresponding advisory teams should be created. They should work together or separately under the leadership of the Project Facilitator.

Staff of the facility need to be ready to facilitate  They need to cooperate with and facilitate the  implementation activities, be aware of their progress and provide information or advice when required. They should also be involved in the monitoring and evaluation exercises conducted by the facility (e.g. functionality appraisal, user acceptance tests and commissioning) .

Special Role of the Information Management/ Information Technology Department/Unit of the Facility

Most facilities will have an Information Technology (IT) department of varying size. They need to facilitate their counterparts in the contractor’s team. At the same time, as part of the technology transfer exercise, they should learn as much as they can about the workings of the system and how it is to be managed

The term implementation as used here assumes that the product (system and applications) has already been developed i.e. a complete ready-made off-the-shelf product has been identified as a solution. It is assumed also that prior to the implementation of the chosen the solution, negotiations has been made such that agreement has been reached regarding the major modifications to be made and the costs involved . This does not preclude further minor modifications during implementation when the needs for changes and additions arise during implementation. The parties concerned must agree on the extent of these changes. The extra work entailed by major modifications may be subjected to variation orders, additional charges and alteration of the timeline.

Customization of Applications Software and System Architecture

Software Customization is guided by the outcome of the process of Business process re-engineering plus any pointers that show up during the implementation process. The latter can arise from the user training and testing activities. The customization should not be to the extent of revamping the system or applications. Consideration must be given to how changes in a particular part of the system will affect other components of the system in terms efficiency, interoperability and integration. Care must be taken so that it does not result in scope creep.

Installation of System

The steps in this phase are:

  • Installation of network
  • Installation of hardware,
  • Installation of software and
  • System integration

Installation of Network

Installation of Hardware and System Software

Installation of Applications Software

System Integration

Because the information system for a healthcare system consists of many separate sub-systems, system integration is a major issue. Therefore, the appointment of a System Integrator or entrusting the function to the Project Implementation (Management) Team is of paramount importance. The job of the integrator is to ensure that components of the system (client workstations, servers, the database, and the network) work seamlessly to optimize all functions. the project implementation.

Testing

Testing of Modules and Functionalities

User Acceptance Testing of an Integrated System

Training and Change Management

Training of Trainers (Core Personnel)

Training of users

Change Management

Commissioning and Go live

Commissioning

Start of Operations (Go-Live)

Phase 5: Operations and Maintenance

Operations

Maintenance

Review of System

Information System Life-Cycle

Upgrade or Replacement

Learning fro the Experience

Project Execution

Execution of the project refers to the performance of activities relating to the supply of goods and the carrying out of certain services by individuals and teams each of whom have defined objectives, tasks and timeline. Each of these tasks will be discussed in greater detail later.

Project Execution Team

The project execution team refers to the entire technical and advisory personnel employed by the contractor/solution provider, other suppliers of goods or services appointed by it including consultants, software vendors, hardware suppliers,  builders, installers, fixers and etc.

The composition of the Project Execution Team caters for the provision of expertise in the following areas:

  1. Business Process Re-engineering and Change management 
  2. System Design and Management including Network Management
  3. Data and Database Management
  4. Hardware procurement, installation and maintenance 
  5. Security management
  6. Software expert for various Applications Database Manager / Administrator
  7. Domain / Subject matter experts (Clinical, Laboratory, Pharmacy, Patient Administration)Health Information Management Consultant
  8. Data migration
  9. Clerical staff

These personnel can be full time or employed on consultancy (third party) basis. 

Transfer of Technology

The facility should have  a plan for the subsequent operations and maintenance of the system after handover by the contractor. A Operations, maintenance and Rectification period (of at least one year) should be built into the contract so that the contractor demonstrates how the system is to be managed and also to allow the contractor to rectify faults or shortcomings identified. The facility have the choice of handing over the subsequent operations and maintenance of the system to another contractor or to use its own resources. Arrangement should be made for whichever team that is taking over to understudy the contractor during this Operations, Maintenance and Rectification period.

Deficiencies voiced by the facility, actual or perceived, relating to software and proposed policies and procedures need to be taken seriously, listed and addressed in the proposal.

Proposal of Changes

Gaining agreement from the facility and all its staff to proposed changes to overcome the gap identified is a delicate process. It is achieved by two approaches:

  1. Change in  existing policies and procedures (SOP) to meet the needs of computerization
  2. Redesign of the system and customization of applications software and system architecture proposed by the contractor to accommodate / cater for the needs identified.

The facility need to be convinced that what is being proposed is workable and will lead to benefits.

Change of Policies and Procedures (SOP)

Since the proposal involved changes in policies and procedures it is incumbent on the BPR team to help the facility to rewrite its Standard Operating Procedures which should incorporate operational policies within it. This is a tedious process but it has to be done. Quite often the BPR team, as part of the user requirement assessment exercise, puts up the workflow with the intention for their own use in software customization. This is inadequate because a firm SOP is needed to to clarify the proposal as well as for later use for the change management and training exercise. It is also wasted effort because it is does take advantage of the BPR exercise and the expertise available.  A proper SOP avoids the need for the facility to write the SOP again on their own.

The proposal with regards the changes in SOP should cover all areas include

  • all areas in patient care and
  • some areas in management of the hospital as a business entity and
  • the provision of hospitality services:
    1. Pharmacy Information System
    2. Operation theatre and Anaesthetics Information System
    3. Critical Care Information System
    4. Dietetics services and Food-Beverage Management System
    5. Central Sterilisation Services

Key applications

 

Enhancement of Processes based on the intended HIS

To put in place these enhancements in actual practice, we will demonstrate our solution to users and explain their features, the underlying reasons and the effect it will have on current work practices. On the other hand, users may suggest better ways

Review of Policies and Processes of Various service Areas

The BPR team, who is familiar with policies and processes of all aspects of patient care and hospital management, will study the current setting, organisation of services, work flow and work processes of each of the services for which an information system need to be provided. We do not expect these to be very different from universal standards that is adhered to in our Yasasii HIS modules.

The following methods will be used to redesign the work procedure:

    1. Familiarization of users with our respective modules through Proof of Concept sessions based on simulated scenarios and patients using a Mock system
    2. Obtaining acceptance or suggestions from users
    3. Changing of work processes and operational policies when necessary
    4. Adoption and rewriting of objectives, policies and procedures agreed by HS
    5. Customization of the relevant modules and integration with other parts of HIS

In would be necessary to rewrite Standard Operating Procedures of the clinical services and our team are ready to assist PPKUKM in this exercise.

Customization of HIS

 

Procurement

The goods or items to be procured needs to be identified, costed, procured, received and commissioned. They include both software and hardware. A list of these items are created (often called the ‘Bill of Quantity’).

List of Items

table items hardware corresponding software

Role of Administrative Team

The Administrative team is responsible for planning the purchase, scheduling their delivery .

Role of Hardware Team

A technical team (the hardware team) is responsible for

    • receiving, inspection and commissioning
    • proper storage
    • installation
    • their maintenance  during the project

It is best that items are received in a just in time manner to avoid damage or pilferage. For items they are installed in user areas, the responsibility of looking after them is as much a responsibility of the contractor as the users.

Network cabling and configuration

Hardware Installation

e. OS setup (VMWare, Linux , Windows) and patches update in virtual server
f. DBMS and Supporting Tools (Manage Engine IT360) installation
g. SAN storage installation
i. Determine storage requirements for MIS
ii. Installation of new SAN
iii. Attach both old and new SAN to same SAN switch
iv. Transfer MIS data to new SAN via vMotion
v. Creating LUN and configuration
h. Dry run of Hardware and Review and Sign off

Testing of Hardware Function

Strict testing of hardware is done each time it is installed. Testing of a particular application module is done when both the system software and application software has been installed.  Test results should be documented and vetted by a quality control team. Users should be involved in testing of functions early rather than at the very end of the project so that usability and acceptability issues can be detected and corrected.

SOFTWARE PROCUREMENT, CUSTOMIZATION

Software Procurement

System Software Procurement

The system software required to enable servers and storage hardware to work should come with the hardware. The system operating software (System OS, platform) need to be identified and procured. An agreement can be made for the supplier to provide the expertise required for their installation. Their presence will be required also at the time of integration with the rest of the system.

Applications Software Procurement

The applications software are the most important item in determining the usefulness of HIS. Besides deciding on which software to procure, there is a need to negotiate the licenses required for their use. Different vendors offer different types of licenses. These must be understood so that sufficient licenses are obtained to ensure maximal productivity and efficiency.

Database Software (DBMS) Procurement

Customization of Software

It is assumed here that the software procured is a tried and tested  product proven to be usable and acceptable to users. It would be an advantage if it has been demonstrated to be successfully implemented in reference health care facilities. Even so, much alterations and additions will have to be made to the original software to accommodate with the policies and procedures the health care facility. For this purpose a situational analysis and needs assessment of the facility need to be done.

Situational Analysis and Needs Assessment

Bridging Applications

Installation Of System

DATABASE SETUP

During this process, data from client’s existing HIS is transferred (provided necessary technical support and documentation are made available to Contractor) into proposed HIS Solution to reduce setup costs, accelerate system launch and ensure fast adoption.

Master data

Data Migration

Contractor will apply their experience to assist the client in data migration, cleansing and conversion process. Strategy for switching over from existing system to the proposed HIS Solution:
• Study the existing database and software
• Identify the data that are to be ported to HIS Solution (refer to Appendix 16 and 19)
• Prioritize the modules that are to be ported to HIS Solution
• Map the existing data with the fields and tables in HIS Solution
• Create utilities to port the data from the existing system to HIS System wherever required
• Test the ported data by comparing the data with the data in the existing system
• Have parallel run of both the old and new system and clear problems, if any

Creation of Test, Train and Analytical Domain

Not separate hardware

Domain controller

User Access Control

Separate Databases (not necessarily storage systems)

System Integration

Change Management and Training

Change Management

Institutionalisation of Changes Suggested at BPR

The art of BPR is to reach a consensus that would benefit both parties.

This goes hand in hand with training. It would be expected that changes would relate not only to the change from paper to digital but also changes in ensuing policies and processes. As such involvement of PPKUKM top and middle managers are essential.. It is aimed at

    • Explaining how work is to be carried out using the applications and other functionalities within the system
    • Explaining how alteration of some processes are necessary in a computerized environment to their satisfaction and acceptance,
    • Managing expectations
    • Amelioration of user dissatisfaction and anxiety, if any, resulting from glitches and setbacks.

Our personnel will use the utmost tack in the spirit of cooperation rather than confrontation.

Formation of Teams

For this purpose, the BPR team from our company will have regular interactions with various teams formed by

It would be desirable for the hospital to form an oversight team made up of administrators, clinicians and IT personnel to provide direction to the other teams. Each functional area or service need to form teams made up of at least 2 persons from that service and an internal client representative. At each meeting, a member of our BPR team would be present. However, discussions can take place outside of meetings as long as suggestions made are brought up for consensus.

All suggestions and changes shall be documented.

Training

Training will be carried out based on a complete integrated HIS application. The interaction between trainers and users will be used to obtain input from various care providers with regards to suitability of workflow being followed and usability of the applications. Improvements will be made based on these feedbacks.

User Training

We are willing to provide assistance to WCH in their periodic training programme for the new staff or refresher training of the WCH as part of the Operations and maintenance services at nominal cost.

Technical Training and Technology Transfer

Will ensure that staff onsite have a  good knowledge of the HIS components and are capable of providing training on all the existing HIS components during the Implementation Period. Subsequently we are willing to  provide training on new releases, upgrades of the Yasasii HIS and also to provide advice on issues relating to replacement of hardware, software, application, network or any components when requested at reasonable cost.

Training Program

The training programs shall run throughout the contractual period and PPKUKM reserves the right to decide or choose any suitable training   based   on the needs, relevancy and   appropriateness at any one time as mutually agreed. 

Our staff who are people involved in health care are currently being trained on the use, functionalities and characteristics of the YASASII HIS.

Train the Trainer Program

Once the HIS has been customised, the policies and procedures has bben affirmed and the system is stable, he project staff from Kameda Informatics will train the hospital staff. This will occur after a functioning system and integrated HIS software is in place. This later start will ensure that users are trained on a system that they are going to use causing less confusion.

Training of Users

The type of training approach and subject matter depends on the functions, subject matter and staff category. All staff will be familiarised with matters regarding the proper use of networked computers, data management (security, validity, completeness, availability), use of help resources etc.

Staff will not be trained according to modules but rather on how to perform their job facilitated by various applications at their disposal.

Intensity and Frequency

This will depend on how far users are able to familiarize and understand applications and processes to perform their tasks. Assessment will be made by trainers as well WCH mangers. Repeat and refresher sessions will be provided if necessary and on request.

 

Training

Training and change management goes hand in hand but must be introduced in phases, moving from the general to the more specific. In the earlier phase users are exposed to the changes in workflow brought about by computerization plus the necessary prerequisites and consequent benefits.

Testing

At implementation, User Acceptance Testing should be thorough; initially on a Development/Build version of the system in a simulated Operations environment, and subsequently on the actual Operations/Production Version. After implementation the system has to be appraised continuously and improved upon if necessary.

If a tried and tested product is used, the  system architecture that best suits the software as recommended by the software vendor should be followed after taking into consideration other third-party applications to be used.

 

Acceptance  Testing and Commissioning

The penultimate chance of obtaining feedback from users is at the instance of User Acceptance Tests. Any feed-back or complaints and any software failure will be used as the basis for rectification of the software and also on need for further training.

16.2.2.1The project Quality Assurance program will be built on the trilogy of:
a. Quality Plan
b. Quality Measurement and monitoring
c. Quality Improvement
The features of the end result of good implementation to be measured include:
• Timeliness
• Degree of disruption to ongoing operations
• User satisfaction
• Achievement of goals of productivity, efficiency, quality of services and patient safety

make the system ready at the middle of the third year. The latter half  be devoted to testing, refinement and user training.

The Operational Support Phase

continuation of review of Sytem and Software in the Warranty and Rectification Period

Patches and upgrades will be provided as part of service support. Reports and complaints made to Helpdesk will be used to further enhance HIS.

The Operational Support Phase begins after commissioning which is expected to be successful at the end of three (years). During the ensuing two year period, the system will be in full use. Our own Operations and Maintenance team will take on the System Management responsibilities. Close monitoring and documentation of issues will be done. During this period we will provide warranty for all hardware and software. Any shortcoming or non-conformance will be addressed and rectified.
The Project Plan is detailed further in the Gantt chart as an Addendum “Appendix 17 – Gantt Chart”.

Deadlines will be set for various tasks. Conformance to completion time will be monitored. Standards of Quality Control indicators will be pre-set. The project team shall determine whether a satisfactory output has been achieved. Any non-conformance will be investigated.
Complaints received through the helpdesk shall be categorized and analyzed
Efficiency of services shall be carried out through time-motion studies.
User Satisfaction Surveys will be carried out.
Improvement activities may include:
• tweaking functionalities of applications,
• completion of lists to include missed orders / diagnosis / drugs / tests etc.,
• creating additional forms
• addition of data elements in data collection forms and database
• improving system integration
• re-training

Final Testing and Commissioning

Commissioning although done after final complete installation must also be based on the analysis results documented after every test performed throughout implementation. Indeed, tests performed by the vendor should be compiled and presented to the commissioning team well before actual commissioning exercise.

Timeline

Timeline

Phase 6: Upgrade or Replacement

Life-Cycle Of an Information System

System Upgrade

Replacement of the System

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.