In spite of considerable progress in user-directed flexibility, many off-the-shelf software packages still lack key real-world features and fail to meet the requirements of users, especially smaller ones. Unlike a new suit or television set, IT users can rarely afford to throw away an old system and start out wholly fresh. And in contrast to a GE or a Unilever, smaller firms do not really figure in the one-size-fits-all approach, which alas, happens to be the way most software products are designed.
And yet, most healthcare IT managers detest the word ‘customisation’, with all the unforeseeable extras that it entails – requirements management and analysis, development, interfacing, testing, quality assurance, re-testing, etc. – and then being blamed when things go wrong. And things do go wrong. Cases abound, for example, of a routine vendor upgrade, or even a patch, wiping out hundreds of person years of customisation, or rendering it meaningless (since many vendors offer to only support a patched release). At the other end of the spectrum is the challenge of previous rounds of customisation, which may not have been fully documented, and then pose massive challenges for future customisation.
Requirements Still Less Science Than Art
One of the major stumbling points, at the outset of any customisation project, is that requirements management still largely remains an art rather than a science. It is principally textual and based on natural language. There have been considerable efforts, not least by Carnegie-Mellon University’s Software Engineering Institute, to quantitatively define relationships among requirements and other software process specifications, but results so far have been mixed.
Certain subsets of requirements management have seen significant standardisation – for instance, in terms of traceability to monitor the life of a requirement from origin/originator to implementation, and back. However, such steps (although welcome in terms of removing healthcare IT managers from the line of fire of CFOs or CEOs), are expensive extras, and have done little, at least so far, to enhance cost-benefit ratios in customisation projects.
A Radical Transformation
Few nonetheless argue that the software customisation process itself has undergone a radical transformation in the past 5-10 years. Source code modifications, for example, are hardly ever employed anymore, although they were traditionally one of the first choices in the past.
Although there has been some growth in healthcare industry specific offerings, even the best of new-generation hospital information systems (HIS) continues to require a considerable amount of customisation.
As discussed in the next article in this issue, many are now turning to specialist firms to meet such challenges.
Complementing, Not Standardising
As in many other sectors, HIS software packages do not standardise business processes in hospitals but only complement them, and ideally make them more efficient. The only exception to this rule would be in Third World countries, where hospitals run on paper and do not have an IT system to begin with. In Europe, on the other hand, all HIS packages will require at least some major level of customising, and the best way to achieve this is by first understanding the business processes and operating procedures in place, and then to assess where customising could be most efficiently implemented.
Examples of Customisation
One of the biggest requirements in the healthcare sector is to adapt formats in reporting and bring them into line with local practices and traditions. Many of the latter have their roots not only in custom but in laws and legal practices too; these are not necessarily IT friendly.
Such adapting may sound simple to a lawyer but could be a nightmare for an IT manager drilling deep into a database to access the requisite bit of information, and thereby heavily taxing system resources. Other tools allow data to be validated as it is entered into the system, force entry of data in fields where it is legally required (and do so in a preset order) as well as run checks on data based on entries elsewhere
Some of the most common customisations in such a situation are to host datawarehouses on a dedicated thin-client server, thereby removing the load from the main HIS-linked system. Other workarounds involve ‘standardising the customisation process’, as one IT manager told HIT (only partly tongue in cheek). Examples of this include third-party or even vendor-provided add-ons, as well as integration with common front-end applications such as Microsoft Office which have themselves evolved to permit such integration, more easily and seamlessly. Current spreadsheet programs, for example, can be tailored to provide complex what-if scenario analysis, and these can be tweaked (standardised ?) to automatically trigger under pre-determined scenarios, and then run behind the scenes, thereby reducing demand on system resources.
Assessing Complexity and Impact
For healthcare IT managers, a twin challenge in customisation is to not only assess the level of complexity in the process but also conduct an impact assessment on other IT-related aspects of the hospital operation – both immediate and in terms of evolving requirements for the future.
Another issue involves quality assurance and testing – across the entire chain, from developer to end-user, as well as in terms of change control.
In this respect too, there have been several positive changes in recent years – such as dedicated test facilities to which the customised product can be outsourced for testing, alongside pre-modified code to revert to for ‘safe mode’ operation in case of failure.
Overall, the mission is to strike a Golden Mean between standardised HIS systems and customised versions tailored intelligently to real needs.