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.
Important HIS Aspects to Consider Requirements Management
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.