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.
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.
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.
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.
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 – something that is not easy to quantify in financial terms. Even these may take a very long time to realise. The banking industry spent a large amount of money on computerisation in the 1980s and has started reaping the benefits fairly recently.
In addition to computerisation of the hospital, the software must allow exchange of data across hospitals. This inter-operability aspect of the software must always be considered by hospital administrators. This is something that needs to be spearheaded by the government or national bodies.
Preventing a failed implementation
Once a software has been purchased, the implementation strategy must be worked out to prevent delayed or failed implementation. Often, it is only during the implementation phase that hospitals realise the ad hoc ways that had been in practice. Implementation often helps to redefine workflows and make them more efficient. At the helm of a HIS implementing team there need to be a person who not only has domain knowledge of the software, but also of the processes and workflows in the hospital. He is also required to be a visionary, lest the manual workflows be literally translated into inefficient computerised ones – something that happens too frequently. Workflows in a computerised setting may have to be different to achieve full benefits of computerisation.
Once new workflows have been charted, the biggest hurdle is collection of data to populate the master tables of the software. At that time, hospitals usually realise that they do not have complete data of almost anything. Hence, data collection becomes an important factor for delay in HIS implementation process. Hospital staff place low importance on submission of data pertaining to their department; their daily work comes first. The way out is to get a person from each department seconded to the HIS implementation team till the work is over. This is not as easy as it sounds, since departments may be facing staff crunch as such. It requires a very strong administrative commitment to achieve this – something that should be stressed early in the planning phase. Departments moreover tend to second their most dispensable person, one whose absence is least likely to cause disruption to the work in the department. Unfortunately, such a person is also least likely to know the workflows in the department and be able to redesign them for computerisation. It must be made clear to all concerned right at the beginning that the person in charge of the implementation team should have the right to chose who he wants from each department to work on the team. The implementing team should be lead not by a committee but by a single person. Unless there is a single person who takes ‘ownership’ of the entire process and is accountable for its failure and success, the implementation is likely to falter.
In any venture, there are persons who resist change. It is important to deal with this by ‘triaging’ all persons who are involved as users of the HIS. The first category in this ‘triage‘ is of persons who are supportive of the entire venture. Especially, if they are physicians they should be encouraged to spearhead a movement to gain support for the venture. The second category is comprised of persons who are neutral to the entire process. They can be safely ignored. The third category consists of persons who are opposed to the process. These people have the capability of upsetting the entire planning if not handled carefully. Ignore them at your own risk! HIS implementers need to spend extra time with them to truly understand and resolve their issues. Often there are genuine issues that need to be resolved during the implementation. At other times they are as trivial as a ‘fear’ of computers, especially amongst senior staff. A little extra care and a few extra training sessions can turn them from being the most opposing to one of the most vocal supporters.
Managing it in phases
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. On the other hand, implementation of some functionality, but not of others, can cause both computerised as well as a manual workflow to exist side by side. This will require staff to perform duplicate data entry and put an extra load on them. It is the responsibility of the administrator in charge of the implementation to plan the phases so as to minimise this issue. This is where in-depth domain knowledge of the software as well as of the hospital workflows is most useful. As far as possible, parallel runs should be performed at each location when that section is computerised. This allows for a fall back manual system, in case the implementation runs into initial problems and will prevent bad publicity, which could lead to internal resistance in other sections of the hospital.
At the end, HIS implementation is a collective responsibility of the entire hospital staff. A system that is configured by involving all users of a department is more likely to be accepted by the department users, than one where most see the system for the first time at the time of ‘go-live’.
Successful implementation is as much an exercise in public relations as in technology management.