This is an overview of how to design a hospital information system highlighting the fact that implementing an IT system invariably means a dramatic change in the way the various business processes are run. Broad discussions on requirements management and change management are followed by an overview of general requirements and functionalities where a tentative list of all the modules is presented. These are followed by some technical considerations that the stakeholders like system designers, implementation agencies, customers and end-users need to factor in for all such information systems.
A Hospital Information System (HIS) basically is a synonym for information management system at use in hospitals. Hospitals generate a wealth of data round the clock, 365 days a year, all of which needs to be well managed to ensure efficient functioning. Patients visit such establishments for outpatient care, in an emergency, or get admitted for either a short stay (a few hours) or long in duration (that may sometimes be indefinite). While in the past, the important modules of an HIS tended to be those that dealt with revenue management aspects, the recent trend sees a growing emphasis on improving overall efficiency and clinical management. It must be noted here that while some modules are required by all clinical establishments, requirement for others depend on the size of and specialities covered by a particular establishment.
In the requirements gathering phase, one should undertake an as-is study exercise to perform a comprehensive impact analysis of all business processes in order to identify the ones that will be affected by having the new system in place and the way this will occur. The various business processes that exist, the stakeholders involved and the systems / applications currently being used within the establishment that would be affected, albeit to varying degrees. A draft vision document should then be prepared and a visioning workshop should be conducted to create a blueprint for the future. Once his has been finalised and agreed upon, a requirements analysis followed by documentation needs to be prepared.
Several follow-up workshops are usually required — depending on the size of the establishment and complexities of the underlying business processes—coupled with general and focused meetings with various stakeholders to validate the requirements and manage the various expectations.
Once finalised, the software requirement specification and functional design documents should be prepared with proper functional architecture in place. These should be signed-off by the competent authorities on both the customer and the vendor sides. The documents should then be turned over to the system design team for further action to ensure that the required system is delivered as per the specifications.
Introducing a new information system, where one is already in place and is actively used, requires a certain degree of change management as this new system reflects a ‘new way’ of working.
However, it is equally important to view this new system as being only a part of the entire process of creating a new way of working and not its whole sole. The people who will interact with the system would need to get used to it and will require varying degrees of hand holding as the old system, which mostly still is anon-IT-paper-based system, is phased out. Furthermore, many of the business processes will need to be reviewed. This will result in some of them undergoing minor to major changes; others left completely unaltered; and the rest stopped permanently. This inevitably means a total redesigning of the entire business ecosystem of the establishment, which is a massive exercise in itself.
It is important to recognise that the change, whether insignificant or significant, needs to be sustainable in order to realise accrued benefits to the fullest extent. This will neither happen by itself nor can be expected to be enough. Implementing the change successfully demands that the solution (not just the system but the outcome of the implementation in its entirety) must fundamentally be designed differently.
Generally, the system should be safe and secure from a data management point-of-view. Highly sensitive data is handled by such systems and hence the comfort-level related to privacy and safety issues need to be addressed aggressively. The system should ensure efficient flow of information that provides interdepartmental support to the establishment, functional and process integration, be adaptable and flexible from a user perspective, and last, but not the least, be standards-based to ensure interoperability in terms of syntactic, semantic and process.
The following points need to be given serious attention in order to build and implement a viable solution that will be able to deliver true value-for-money on a long-term basis:
01. Use of a unique patient identifier like UHID (unique health identifier).
02. Quick registration in times of emergency – use of “break-the-glass feature”, with due record of who did what, when and why (the reason for this action).
03. Data security, patient confidentiality and privacy.
04. User-based-role-based access control with a sound and practical process using password/biometrics.
05. Eligibility check of all insurance and ability to accept an upfront deposit to cover the estimated cost of care.
06. e-prescription for outpatients, CPOE for others
07. For investigations, the consultant needs to know the total costs and the individual investigation charges. This would allow them to prioritise the ones that the patients must
08. get done right away irrespective
09. of the costs while leaving the
10. rest later when they can afford them.
11. The EMR needs to be integrated with LIS, RIS and PACS to allow all images to be viewed and compared with any archived images.
12. Secured remote access to view information and add notes.
13. Checking for EOQ and re-order levels and automated listing of near-expiry items at least 90 days prior to expiry.
14. Slow moving materials in the medical stores should be tracked and appropriate alerts should ensure that all stakeholders are aware of the situation.
15. Bar coding for tracking patients, services, material and medication.
16. MIS reports that serve as de facto registers will need to be maintained as per prevailing rules, regulations and legal requirements.
A tentative list of modules would be as follows.
At the outset it is important to note that many of the modules listed below can be merged into one larger module.Usually this is a vendor and system-specific decision, mostly based on marketing considerations.
A master code maintenance functionality needs to be provided for all modules. These codes may be non-standard or standard as required by the locally prevailing laws and regulations. It would be prudent to take a long-term view and incorporate the international best-practices in handling codes even if these are not specifically asked for by the customer.
Queries and reports is another functionality that needs to be provided for every module. Without these, the ‘management’ portion of management information system is missing from action.
This is business needs-dependent. While patient administration systems typically require around one to two minutes system response times, governance systems can be run in batch (asynchronous) mode or with around five minutes response times. However, clinical and nursing information systems require sub-second response times irrespective of data size, volume, type and location 24x7x365. Better than 99.9 per cent uptime for non-clinical and 100 per cent uptime for clinical systems is the minimum requirement. Accordingly, fail-safe measures, sufficient redundancies and fail-over support need to be built-in.
A fact that is frequently overlooked, mostly unappreciated and grossly underestimated is that it is the end-user of any IT system that makes or breaks it. It is vital to take them into confidence and actively engage them right at the planning phase itself and continued through each and every stage of the software development life cycle. Otherwise one is, more often than not, left to sincerely rue the decision.
Further more as a thumb-rule of sorts, the author would seriously advocate that only those IT implementations where at-least 80 per cent of modules (and their functionalities) of the system are being used by 80 per cent of the users 80 per cent of the time six months post-implementation after go-live be deemed a success. Else, it should be classified a failure.
The importance of training and retraining of all users can neither be over-stated nor over-emphasised and should not be just one-off. Furthermore, this needs to be periodic. One-off intense training followed by periodic re-training is vital. Every major upgrade or functionality change that would impact the business process should be considered equivalent to a new implementation. In all such instances, an appropriate training schedule needs to be prepared and rigorously followed to ensure the project’s success.
The final success of any such implementation lies in the overall buy-in and whole-hearted support of all stakeholders. Through active cooperation, enthusiasm and support by the departmental heads as well as the end-users, coupled with the belief and desire of the sponsors that the implemented IT system is exactly what they need is vital for the success of any IT system implementation.
The key success factors definitely are robust requirements management, successful change management and sensible business process re-engineering. Efficient management of these translates into the difference between success and failure of any such project.
Module: PATIENT ADMINISTRATION SYSTEM
Description: This functionality, also known by the acronym PAS, consists of RADT (Registration-Admission-Discharge-Transfer), pre-admissions and waiting lists, bed management, and bed charges. It needs to interface with nursing information module for managing bed availability.
Module: MASTER PATIENT INDEX
Description: This functionality is vital for any healthcare-related system that manages patient-related information and includes patient search (basic and advanced), patient merge and demerge (to manage multiple patient entries), and unique patient identifier management. This ensures that a particular patient is accurately and consistently identified and referred to for any patient-related transaction.
Module: APPOINTMENT SCHEDULING
Description: This module deals with appointment scheduling of all types like patient scheduling (for any purpose – visit, admission, investigations, procedures, etc.) and resource (human, equipment, facility, etc.) Scheduling. Pre-booking, booking, over-booking, cancellation, deferred booking, and patient tracking are some of the functionalities covered in this module.
Module: PATIENT BILLING
Description: Perhaps the most important of all modules from a hospital’s business perspective, this module deals with the aspects of patient billing including cash, and credit management. This includes dealing with chargeable items and waivers for reasons such as service not rendered, repeat services for faulty services (e.g. Investigation sample unusable; test result inconclusive or erroneous, etc.), discounts provided etc.
Module: FINANCIAL ACCOUNTING
Description: This module explains how to handle accounts payable, accounts receivable, cash management (of the hospital instead of just the patient), purchase order processing, cash book and general ledger, budget control, etc.
Module : EQUIPMENT MANAGEMENT SYSTEM
Description: A clinical establishment needs a large number of instruments, both clinical and non-clinical, that require regular maintenance and occasional replacement, all of which must be efficiently managed for its optimal functioning.
Module: HUMAN RESOURCE MANAGEMENT
Description: This module caters to the functionalities related to resource scheduling, payroll management, resource engagement and separation management etc.
Module: NURSING MANAGEMENT SYSTEM
Description: This module is for exclusive use by the nursing staff and defines functionalities for general nursing information management, bed management, orders tracking (of successfully posted orders), medication administration, patient assessment and classification.
Module: ORDER MANAGEMENT
Description: Also known as CPOE (Computerised Physician/Provider Order Entry), this module is for posting all patient orders / prescriptions related to medication, investigation, procedures, and other orders that the patient needs to follow as part of his / her treatment.
Module: MEDICATION THERAPY EVALUATION
Description: This module is for management of medications and is generally used in inpatients care settings. All ordered medications are listed according to their recommended doses, route and schedule. Whenever any medication is administered, a record entry is made to the effect. If for any reason it cannot be administered, like patient sleeping, no suitable injectable site found, patient refused, etc., the fact is also noted. This module is the follow-through of the Orders Management module and closes the loop by providing information about what the outcome was of all ordered medications.
Module: OT MANAGEMENT
Description: A specialised appointment scheduling system for operation theatres, this module deals not only with scheduling but also listing of procedures and personnel involved, documenting of procedures performed and charging for services rendered.
Module: LABORATORY INFORMATION SYSTEM
Description: Depending on the laboratory size this module can be subdivided into pathology, microbiology, biochemistry, haematology, serology etc. Generally, sample collection lists, specimen registration, work schedule, results management of entry, verification, and reporting. As investigations are increasingly carried out by semi-auto and auto-analysers, machine to system interfacing is required for sample testing and reporting. Charging for services rendered should also be handled within the module with the information being exchanged with the patient billing module.
Module: BLOOD BANK
Description: This module is only required if the establishment has a full-fledged blood bank. Functionalities such as donor management, blood stock management, departmental inventory management, departmental laboratory information management, charging for services rendered etc. need to be supported.
Module: RADIO-DIAGNOSTIC INFORMATION SYSTEM
Description: Although similar in concept to laboratory, radio-diagnostics has its own special requirements like the patient having to be physically present during the investigation, meriting a separate module of its own. Functionalities include procedure scheduling, investigations management, results reporting, charging for services rendered and interfacing with radio-diagnostic machines and such modules like patient billing, order management, EMR, nursing information systems.
Module: PICTURE ARCHIVING & COMMUNICATION SYSTEM (PACS)
Description: With storage systems becoming larger and cheaper coupled with almost all radio-diagnostic machines becoming totally digital increasingly PACS are becoming either de facto part of the machines or being available as a special module. The functionalities include management of the actual storage and archival process, image display through workstations, image management and printing on films, apart from interfacing with radio-diagnostics information systems and web integration.
Module: PHARMACY MANAGEMENT SYSTEM
Description: This is a specialised inventory management for medications and medical devices that have a definitive shelf-life and need control in terms of dispensing and patient education regarding how these need to be used. Interfacing with CPOE/order management, medication administration and nursing information system is required.
Module: CLINICAL INFORMATION SYSTEM
Description: This module is for use by the clinicians and consists of patient lists, electronic health records/electronic medical records clinical data entry, eReferral, clinical summary etc. It needs to interface with CPOE/Order Management, Nursing Information, Laboratory Information, Radio-diagnostics Information, PACS etc. Some special requirements in terms of management of medical certificates like fitness certificates, discharge summary, and treatment summary.
Module: ANAESTHESIA MANAGEMENT SYSTEM
Description: This module is for use by anaesthetists and needs to support functionalities related to pre-anaesthetic check-up, per-operative management and post-operative management.
Module: FIXED ASSETS MANAGEMENT
Description: This module deals with managing the fixed assets of the hospitals.
Module: INVENTORY MANAGEMENT SYSTEM
Description: This module deals with management of general inventory items of the hospitals including processing of purchase orders.
Module: SYSTEM ADMINISTRATION SYSTEM
Description: This needs to include such functionalities as Single Sign On, user management, roles management, privileges management, password management, and audit trail management, besides management of servers and periodic data backup management, contingency and recovery management; operating procedure management to ensure physical security, countering viruses and other software and hardware threats, data encryption, digital certificates and administrative panels for efficient monitoring and management of these.
Module: CENTRAL STERILE SUPPLIES DEPARTMENT (CSSD)
Description: A hospital’s primary business is patient care, in pursuit of which sterile supplies are required 365x24x7. This module helps in their management and needs to interface with OT Management and Nursing Information Systems for its proper functioning.
Module: LAUNDRY DEPARTMENT
Description: This module deals with the management of the laundry requirements of the establishment. A hospital houses sick people who may require several change of clothes and linen every day. Efficient management of these items is necessary and interfacing with inventory management and nursing information systems is required.
Module: DIET & KITCHEN MANAGEMENT
Description: Not only do patients need to be fed with many having specialised dietary requirements, the various personnel who provide round-the-clock service need to be fed too. This module manages meal orders, diet management, kitchen management, and inventory management. Interfacing with inventory management and nursing information systems is required.
Module: MANAGEMENT INFORMATION SYSTEM
Description: This module is for designing and running reports and displaying them as dashboards, onscreen, etc. as required by the users.
Module: TRANSPORT MANAGEMENT
Description: Both surface and air transport in the form of ambulances needs to be managed and this module is being asked for by many institutions, particularly those that deal with medical tourism. Having a large fleet of ambulances also requires efficient management to ensure that they are optimally used. Resource management of drivers and assistants and those vehicles that are in maintenance also needs to be taken care of.
-- Issue 33 --