Strategies for development
Modular system
Dealing with resource limitations
Examples of successes and failures
I.R. DohooThe author's address is: Department of Health Management, University of Prince Edward Island, Charlottetown CIA 4P3, Canada.
This article is adapted from a paper presented at an Expert Consultation on the need for information systems to strengthen veterinary services in developing countries held at FAO Headquarters Rome, Italy, in November 1993.
Information system projects frequently run into difficulties and fail to meet their full objectives. Some possible reasons for this are unrealistic objectives and goals, inadequate human resources to support the effort and inappropriate development methodologies used to build the system.
This article looks at the commonly used and recommended methodologies to determine if they fit with the objectives set for information systems and if they are appropriate for the human resources available. In the first instance, it will deal with the development of computer-based information systems, looking at these systems for monitoring and/or surveillance purposes. While the principles outlined below may apply to systems designed for emergency response to exotic disease outbreaks, the requirements of such systems (primarily speed) are somewhat unique The focus will be on systems designed to support the making of animal health decisions as opposed to operational programmes that merely assist with day-today operations. For example, a system designed to support decision-making in a foot-and-mouth disease (FMD) control programme would be considered, but one that merely expedites the shipment of batches of vaccine from a manufacturing plant would not.
The article also covers systems of development strategies, the modular structure of such information systems and the problem of resource limitations in developing countries. Finally, a few specific examples of successes failures will be discussed. While the issues covered apply to information systems in developed countries as well, they become crucial in developing countries given the limited resources to correct mistakes and deal with problems along the way.
When looking at development strategies it is probably best to determine how systems are often developed, what the common recommendations for development strategies are and why neither of these approaches is fully successful, as well as to investigate at least one other option.
How systems are often developed
Anyone involved with information system projects in developed or developing countries can identify many projects that have followed roughly the development strategy set out in the Box. While this process may sound like a complete waste of time, probably some positive results can be obtained from the exercise. First, the investigator will become familiar-with many of the weaknesses and flaws in the data collected, and, second, it should highlight the problem of not knowing how to use the information generated.
A commonly recommended development strategy
Computer systems analysts often cite the following as a more appropriate development strategy:
· determine the needs of the users of the information system;
· select software and hardware environments appropriate for the task;
· write the programs and develop the system;
· implement the system, including training the user(s) in the operation of the system;
· use the system and revise as necessary.
While this approach is obviously superior to that outlined in the Box, following the five steps described above does not necessarily guarantee success. It is important to consider the many people factors that influence success or failure at each step of the process.
Determining needs. Who do we talk to when we want to define the requirements of an information system? For national systems, we talk to senior administrators and policy-makers. For local systems, such as production management systems for livestock agriculture, we often seek input primarily from veterinarians and animal production specialists. It is likely that neither of these groups has any substantial experience with information systems so it is unrealistic to expect them to adequately define their requirements. Such an expectation would be like travelling back in time to 1850 and asking someone to describe the features they would like to see in an automobile.
In general, the less experience an individual has with information systems, the greater their expectations and hence the stronger the desire to "computerize everything".
The second problem is that these groups may be out of touch with the activities and needs of the people who will have to implement and run the information systems, such as field veterinarians and producers.
|
BOX - Development strategy for information system projects · Design some data collection forms and proceed with the collection of lots of data on the assumptions that (a) someone will it and (b) the more data the better. · Become overwhelmed with the volume of data collected and buy a computer in order to 'computerize' the system. · Write some programs in the language or software package that is most favoured by the initiator of the exercise. · Enter all of the date end generate some statistics that primarily reflect the number of entries in the database. · Hire a consultant to determine what else can be done with the data This last step is optional and probably depends on the amount of resources invested in the first four steps. |
Identifying the hardware and software environments. In many cases, the selection of a hardware environment is no longer a crucial issue, although it may be more important for advanced systems incorporating geographic information systems, expert systems, etc. Most information systems currently use IBM-compatible microcomputers. However, limitations may exist in that the computers may already have been purchased and may not be of adequate capacity.
A much more serious problem exists with regard to the selection of software. Computer programs generate tremendous brand loyalty. Once someone has taken the time to learn how to use a program, they not only have a strong desire to see that program used in any information system for the sake of convenience, but they often feel quite strongly that it is the best program choice. Overcoming the reluctance to look at other options may be quite a challenge.
Systems development. One of the greatest obstacles to be overcome in the development of an information system is the ever-present "we-can-do-it-better" syndrome. For example, when choosing a disease coding system or nomenclature to use in an information system, many organizations shun the readily available systems (Dohoo and Palotay, 1985) and develop their own coding system on the assumption that they can build a better one. The same problem exists with computer programs. One country may not even evaluate an animal health laboratory information system developed by a neighbouring country on the assumption that it would not meet their needs and or "we can do it better".
There are actually a couple of advantages that can arise from this syndrome. First, it is possible that the situation being tackled is unique and cannot be solved using available systems. More likely though, the syndrome may result in a tremendous commitment of time and effort on the part of the developers trying to prove that they were correct. Second, the development of a system from scratch certainly generates a strong sense of ownership and commitment in the developing institution, yet the result may turn out to be inferior to other available options after what is certainly a time-consuming and costly exercise.
Photo/foto: C. Fraser, FAO
Woman extension agent discussing development and welfare schemes available to women - Une vulgarisatrice parle des programmes sociaux et de développement proposés aux femmes
dans un petit village delle l'Inde - Mujer extensionista ex en una pequeña aldea de la India los planes de desarrollo y bienestar disponibles para las mujeres
Photo/foto: J. Isaac, FAO
It is also possible that the computer program and not the resulting information can become the focal point of the effort. It is very easy to get sidetracked into worrying more about the program's look and level of sophistication than about the value of the information being generated. Development efforts suffer from some degree of creeping elegance and, while this is not entirely bad, it must be kept in perspective.
Implementation. Assuming that the implementation of the system goes well from a technical point of view, that is, the computers and programs function adequately, three components of the training exercise are necessary to successfully put an information system into effect.
First, users have to be trained in the specific details of the operation of the system. In general, this is a relatively straightforward/ask. As computer programs become more user-friendly, this task becomes increasingly easy.
Second, it is a much more difficult task to train users to use computers effectively as information-processing tools as it involves providing/raining in other aspects of computer-based information processing, for example, how to use spreadsheets, word processors and database management programs. Nevertheless, the value of an individual with such capabilities is much greater than one who knows only how to use the specific set of programs developed for the task at hand.
Finally, by far the biggest challenge and one that is frequently ignored completely is the need to train users to become effective information users. It is folly to assume that just because an information system puts large amounts of timely, accurate and appropriately analysed information into the hands of potential users, the information will be used effectively, or at all. It is unrealistic to expect people who have never had access to the information that is now available to know how to handle and utilize it effectively. The biggest error that was made in the development of the Animal Productivity and Health Information Network (APHIN) (Dohoo, 1988, 1992) in the Canadian province of Prince Edward Island was to assume that the user community (veterinarians in private practice and agricultural extension workers) would automatically access and use the information made available by the network. It takes as long or longer to train information system users how to use the information available as it does to complete all other aspects of systems development.
Using and refining the system. With the problems identified above, it is not surprising that many systems end up as storehouses of data waiting for someone to come along and analyse and use them. In some cases it may be worth while going through the standard development process described above under "Commonly recommended development strategy" in order to clarify in everyone's mind what many of the problems and pitfalls are. The danger is that the cost and effort of revising such a system may be prohibitive.
An alternative approach to systems development
Incorporation of research interests into information systems may result in the collection of too much data that will rarely, if ever, be used, making the systems unworkable. However, there is merit in looking at systems development as a research/learning exercise in order to start the process of training participants in the use of the information as soon as development of the system starts. The steps that would be involved in this approach follow.
Define a very specific objective. This is analogous to defining the objective or hypothesis of a research project. Maintaining a narrow focus will enable the participants to keep the final objective in mind throughout the system development process. For example, answering the question "How many doses of each serotype of FMD vaccine do I need next year?" as opposed to "Let's computerize the FMD control programme" is a much more attainable objective. It keeps the focus on the important question - number of vaccine doses - instead of on the computerization exercise.
Collect and process data manually. The second stage should be to involve the user group in the collection and processing of the required data manually. This will accomplish several objectives. First, it will integrate the user group into the process. Second, it will clarify in their minds exactly what data are required and what analyses have to be carried out on those data. Third, it will provide the user group with a clear understanding of the strengths and weaknesses of the data that might go into the information system. Finally, it will contribute to the development of the information-processing and interpretation skills of the user group.
Determine what data are available. One of the failings of many information systems is the developers' desire to produce systems that are self-contained. Developers often ignore information that may be readily available from other sources. Collecting and processing data manually in a small-scale pilot project should lead to the evaluation of data sources that might otherwise be ignored. It is important to avoid the duplication of data collection efforts.
Determine the needs of data collectors. It must be remembered that information systems often have one group of users contributing data to the system and a second group using the output. The needs of those who will contribute data to the system must be assessed. If the system does not meet their local needs, there will be no incentive for them to ensure that the data going into the system are accurate and timely. For example, in the development of a hospital record system at the Ontario Veterinary College, Guelph, Canada, the fact that the computer was able to print all of the instruction labels to be stuck on prescriptions dispensed by the pharmacy ensured that the appropriate information went into the system. In turn, this resulted in accurate medical records and appropriate charges on the bill.
Review available hardware and software and develop programs. If the focus of the system development exercise can be kept on the original specific objective, then the user group will want to meet that objective as quickly and easily as possible. This may help prevent the "we-can-do-it-better" syndrome, although there can be no guarantee of this Once the users have become familiar with the data, determined the needs of all involved with the system and begun to develop information usage skills, the development of the programs should be relatively straightforward.
Implement the system. At this point, the training requirements should be confined to the relatively simple effort of training specific user groups in the operation of the system. Those involved in the development should now have considerable skills in the use and interpretation of the information generated. However, there remains the big problem of keeping those people in a position where they can use both the new system and their new skills to help solve the original problem. There are two serious temptations that must be avoided. The first is to continually pull people away from these tasks and assign them to "fight other fires". The fact that they have improved information-processing skills makes them even more vulnerable to secondment to other projects. The second problem is that of reward and promotion. Mechanisms must be found to reward people for superior performance in the job that they started out doing, otherwise, there is a serious tendency to promote people with new skills and qualifications into more senior administrative positions, leaving the information system devoid of trained users.
It is hoped that the end product of the development process described above will be an information system with a very specific focus, function and set of goals. The system users will not only be trained in the operation of the system, but more important they will know how to use the output information effectively.
One serious potential drawback to such a development process is that it will result in a variety of systems with specific goals within the overall animal health programme. If the development of these systems can be adequately coordinated and integrated, then an overall animal health information system with a modular structure will result. If development is not coordinated, then a group of disparate programmes that may or may not relate will result. The most serious problem with uncoordinated development is that it will inevitably lead to the duplication of data-collection efforts and wastage of resources.
Regardless of whether an information system has been set up to provide small-scale livestock producers with management information or to serve the needs of a national animal health programme, it must be accepted that a single system cannot meet all of the very diverse needs of the various user groups. One of the key features in the development of an integrated system though is the effective use of data that have already been collected and are available in electronic format. The problem of ownership of information must be addressed in order to male these data available. Within the branches of a government administration this problem can be serious, but it may be evermore of a problem if private organizations are involved.
Although resource limitations are not restricted to developing countries only, they are more acute there. The biggest limitation is not the scarcity of computers and programmers, but the lack of animal health specialists with information-processing and quantitative problem-solving skills. Education programmes in developing countries often do not emphasize the development of problem-solving skills to the same extent that programmes in developed countries do. This problem is particularly acute in the area of handling and processing quantitative data. Consequently, it is imperative that these skills be developed in concert with the development of the information system.
As the price of microcomputers drops their availability becomes less of an issue, but it is still critical that resources be directed to the most effective users. Ownership of a microcomputer is still a symbol of prestige and potentially an indication of authority. Unfortunately, this often results in machines being claimed by senior administrators who may have no specific skills in their use. A related issue is that of "critical mass". The use and acceptance of computers is much higher if there are sufficient resources in the area so that a group of users can support each other in the learning process.
It is always much easier to review the information system development efforts of other people and criticize them for their failures than it is to develop a system and avoid the same pitfalls. Nevertheless, it is valuable to look at both successes and failures in order to identify the contributing factors. Consequently, the author will comment on the three information systems with which he has had some involvement, ranging from extensive to minimal, and offer some observations.
APHIN in Prince Edward Island
The development of APHIN in Prince Edward Island provided an opportunity to obtain some direct experience with the development of an integrated information system. The single most important factor contributing to any success this network has had was the effective integration of already existing data into the network. On the other hand, the single biggest mistake made was the underestimation of the magnitude of the task of training participants to be effective information users.
This underestimation became most apparent in the beef section of the network. When working with veterinarians and extension specialists in the beef industry, it was impossible to identify a specific user or user group with the level of desire and skills necessary to utilize summarized health and production data effectively. It was also impossible to work on developing these skills in parallel with the development of the information system. Much effort and many meetings with representatives of the industry resulted in the development of some fairly sophisticated programs, but there has been no one souse them. Consequently, the beef portion of the network has not met any of its original objectives.
On the success side of APHIN, the effective use and integration of existing data sources into a common database designed to serve the dairy and swine industries has been very rewarding. Although it was frequently cautioned that existing data would be of little use because "the industry already had access to them", it appeared that the integration of data and the presentation of summarized information in a convenient, easy-to-use form had contributed the most to the success of APHIN.
Laboratory data in Indonesia
Many people's perception of an animal health information system is the computerization of diagnostic laboratory data. While the limitations of these data have been widely discussed, they were used effectively in an active surveillance programme for brucellosis in Indonesia (Bedard, McClure and Akoso, 1991). In retrospect, it is felt that the reasons for this success were that a very specific, focused objective had been identified and that the system included users who were skilled in information management and able to effectively use the data.
The operation of this laboratory information system also provided an opportunity to learn from problems that became apparent. The system also processed data from routine submissions (passively collected data), but there was no one responsible or trained to effectively use this information. As a result, an outbreak of Gumboro disease that could have been identified at a much earlier stage was not, because no one was effectively using the information available. It is crucial that information collected on a routine basis be used effectively, otherwise enthusiasm for the collection of the data drops off rapidly.
FMD control programme in Thailand
As part of Thailand's ongoing effort to control FMD, it was determined that better information about the distribution of the disease in the country was required. With this in mind, considerable time and effort was put into the development of data collection forms as well as computer programs to store the data from those forms. While some useful information did come out of this exercise, it became apparent that there were some serious problems with the information system.
First, the group responsible for the development of the system had not received much specific training in the analysis and use of information in the decision-making process. In an attempt to be thorough, a wide range of data was collected. When it was discovered that it was still not possible to adequately plan the FMD programme, the response was to collect more data. This quickly resulted in a system that placed such heavy reporting demands on field staff, that any willingness to comply with the system disappeared. In retrospect, the first step in solving the problem should have been to determine very specific objectives for the system end to improve the information-using skills of those responsible for it. This, followed by better dialogue between headquarters and field staff, would have streamlined and improved the effectiveness of the information system.
The second problem was perhaps less serious and more of a technical nature, but it highlights the need to evaluate existing information sources. The most crucial question in the FMD control programme was "Is the vaccination programme working?" To answer this question an already existing database on vaccine distribution had to be linked to the one in which disease outbreaks were reported. While not difficult technically, it had not been identified as an option and, consequently, the disease-outbreak reporting system was also frying to capture information about vaccine administration in the area. This added to the data collection burden and contributed to the lack of compliance with the system. +
Bibliography
Bedard, B.G., McClure, L.H. & Akoso, B.T. 1991 The epidemiological function of diagnostic laboratories in developing countries. Proc. 6th Int. Symp. Vet. Epidemiol. Econ., 1991. Ottawa, Canada.
Dohoo, I.R. 1988. Animal productivity and health information network. Can. Vet. J., 29: 281-287.
Dohoo, I.R. 1992. Dairy APHIN: an information service for the dairy industry in Prince Edward Island. Prev. Vet. Med., 12: 259-268.
Dohoo. I.R. & Palotay, J. 1985. SNOVET/EPIVET Standardizing nomenclature. Proc. Int. Symp. Vet. Epidemiol. Econ., 1985. Singapore.
