Compared to other industries, the healthcare industry has been relatively slow in adopting information technology. Currently, computerisation of medical care is in the process of evolution, being hampered to some extent by technology, since no perfect interface exists between medical care providers and computers. Medical care personnel are usually on the move, while computers tend to tie them down. PDAs and mobile notebooks have been tried but they have not achieved widespread adoption as yet. This is a big hurdle towards implementation of a HIS, since it requires care providers to start working differently than what they are used to. Although this is most obvious for clinical information system adaptation, it does affect the ease of implementation of other components of a HIS.
HIS implementations fail more often than hospital administrators would like to acknowledge. There are three common scenarios of HIS implementation failure. An implementation may start well but may never be completed. The common reason for this is inflexibility of the HIS software, inexperienced implementation teams or a weak administrative will. Another scenario is where the HIS implementation has been completed but only part of the HIS functionality has been implemented. It is also not uncommon to find that a year or so after a ‘successful’ HIS implementation, the hospital staff have stopped using the software. This might be either because the software was not user friendly or the workflows were not well planned and configured.
Pre-implementation assessment
A hospital administrator who is planning to implement a HIS software in his hospital may thus be apprehensive that the implementation may end in a complete or partial failure. Prevention of this eventuality starts even prior to purchase of the software. The software, the vendor, as well as the hospital need to be well assessed.
Software assessment
Many popular HIS software, have a common development cycle. Very often a software begins life as computerisation of a single hospital, either by an in-house team or by a local developer. Successful implementation leads to a vision of exporting this software to other hospitals. For this, some ‘de-customisation’ is done to allow the software to adapt to workflows that may be different in other hospitals. However, in spite of this, the second implementation site does experience problems. In order to get over this problem, developers tweak the software and apply multiple patches, which though it solves some of the problems, but only at the cost of disrupting the software structure. While the second site still struggles, a third and a fourth hospital get roped in. At some stage, usually years down the line, the developer, if he is still financially sound, decides to rewrite the entire software from scratch so as to increase its flexibility and customisability. This is the ‘second generation’ software. Hospital administrators shopping around for a HIS software should try to discover if their software is a ‘second generation’ one.
Another aspect for consideration is whether the software customisation during implementation is done primarily via master tables or it is via programming code. The former allows the hospital to make some alterations to the software setup on its own, should it be required later on. Programming code, on the other hand, necessitates the hospital to approach the developer each time they want to alter the software functionality.
A warning sign is if the vendor promises to implement a HIS software in an unusually short duration of time. Is the software being offered akin to Microsoft Office, which can be installed very fast but allows only limited flexibility? A proper implementation takes time and the hospital may do itself harm by trying to unnecessarily hasten the process.
Vendor assessment
Assessing the vendor is also not easy. Only a few vendor of national or international repute may easily be trusted, but with the drawback that a large vendor may not go out of the way to accommodate all the requirements of a small hospital. In case of smaller vendors, the hospital administrator may need to assess the vendor by indirect means, since vendors may not be direct about revealing their shortcomings. A good way to assess the long-term stability of the vendor is to try and discover their staff attrition rate. This can indicate whether the current implementation team will last the entire implementation cycle. Often, vendors have other business interests; HIS implementation being only one of the side businesses.
Visits to other implementation sites need to be properly planned to gain a real insight. Usually the vendor is interested in showcasing only the successful implementations. The hospital administrator would do well to get a list of all hospitals that have purchased the software and visit even the ones that the vendor is not keen on showing. It is here where actual problems are likely to come out in the open. During site visits, it is simply not sufficient to see what the software has achieved, but it is necessary to find what the site hospital wanted to implement but could not. This requires meeting the person who actually planned and spearheaded the HIS implementation, since others are unlikely to know what was planned that could not be achieved.
A good way to assess the long-term stability of the vendor is to try and discover their staff attrition rate.
Hospital assessment
Even if the software and the vendor appear to be satisfactory, issues in one’s own hospital could lead to implementation failures. Hospital related factors that could point to a difficult implementation are a multi speciality hospital, an ‘old’ hospital, a hospital with multiple power centres, a work overloaded hospital, a hospital with a physical space crunch and a fund starved hospital. Multi-speciality hospitals, in comparison to single speciality hospitals, tend to have more varied workflows, requiring very flexible software. An ‘old’ hospital, i.e. one that has been in existence for a very long time, tends to develop complex and varied workflows over time and hence is more difficult to computerise. Multiple power centres, with each departmental head running the department the way he wants to, introduces complexities for the same reason. Once HIS is implemented, certain processes may become slower, especially one where more data has to be entered than in the manual process.
HIS users expect to see more detailed information on their screens than during the manual phase and someone has to enter this ‘extra’ information; hence processes may be slow at points of data entry. The most affected area is the clinical information system where care providers may be expected to type in clinical data in a structured format where they were previously used to simply penning down sentences on paper. If the workload of the hospital prior to HIS implementation is such that it is heavily straining the resources, the hospital may not be able to withstand the excessive demand placed on it by the HIS. Care has to be taken to make necessary provision for this well in advance. A hospital that is short on space may find it difficult to find space for the additional computers and rooms that may be required to offset this excess workload demand. Hospitals that have allocated funds just enough to purchase the HIS software may run into problems when demands are created to recruit more staff for the above reasons. These expenses can be expected to be more than double the initial budgetary estimate. While software purchase is a one-time cost, the salary of additional staff inducted becomes a recurring cost.
What to expect from hospital computerisation
It is important for hospital administrators to have their priorities right when they go in for HIS implementation. Very often administrators, care providers, stakeholders, etc. have very different, and often incorrect expectations from the software. A common myth is that computerisation reduces workload and makes processes faster. In a well implemented system this is true to a certain extent. Even though the overall workload may become less, there are areas where the workload may be more than before, especially where extensive data entry is performed. Typing is always slower than writing and it takes time to get used to new user interfaces.
Unless it is a very small implementation, it makes sense to roll out the HIS in phases. This causes the least disruption to the working of the hospital and also places the least strain on implementing teams.
Stakeholders may be under the impression that computerisation will reduce running costs. The reality is, unfortunately, very different. Very few hospitals have been able to show a realistic return of investment on the money they have spent on the entire computerisation process. Hospital computerisation is more about better communication and data availability and about better patient care as a result
Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter, Instagram.
