Thursday, 11 September 2008
  0 Replies
  4.3K Visits
POST 01321E: DEVELOPING COMPUTER-BASED INFORMATION SYSTEMS: ISSUES TO CONSIDER FOLLOW-UP ON POSTS: 01312E, 01314E & 01315E 11 SEPTEMBER 2008 ******************************************* Over the years I have been involved in the development of several computer-based information systems in public health, including immunization monitoring systems and would like to contribute several observations. · There is a technology component to the development, introduction, evaluation and maintenance of a computer system supporting immunization monitoring systems. o Each level of implementation (facility based, district level, provincial level, national, international) should be addressed independently. Access to different levels of skills may vary, data sources, level needs, and reporting requirements certainly do. A system developed for one level will not necessarily translate easily or appropriately to another level. o Computer systems are often defined by a "higher" level (e.g., national) for installation and use by a "lower" level (e.g., province). It is not uncommon for the higher level to focus on "their" data needs – the data needed at the higher level – and pay insufficient attention to the data needs at the level where the software will be installed. When the higher level designs the computer system, users at the level where the software is installed are rarely consulted. Such consultation is useful to identify usability factors and data needs. Lack of consultation increases the requirements, team, technical, and political risks. The consultation process is not necessarily simple and a serious effort often produces interesting results. o Most computer systems are designed to: (1) input data (either through keying data from paper forms or merging data files sent from "lower" levels) and (2) produce reports (usually list, tables, graphs and maps). In most immunization monitoring systems, there is an additional step of providing reports to the next "higher" level. § In many instances, data previously entered into a computer are printed out and sent to the next level where is it reentered. In my opinion this is a complete waste of time and provides an opportunity to introduce errors. A better alternative is to ensure that data entered at one level can be formatted and transmitted to the next level in a way that the data files can easily be automatically merged without the data being reentered by hand. § It is not necessary that a common software package be used for one level to send data to another level. Most systems can be designed to accept (input, incorporate, merge) data different from the native format used at the receiving level. For example, an MS-Access application can input an excel file. A system based on MS-Excel can import a comma-separated value (CSV) file. § I have worked in several systems where one level (e.g., province) systems routinely report data to the next level (e.g., national) and the provincial system are very different: the underlying software are different, the data formats are different, the variables are different, and the coding schemes are different. Each system has a programme that automatically converts the local data to a data interchange format that is common across all systems. Data in the common data interchange format are then sent to the next level where it is merged with the receiving levels data. This allows independence and flexibility at the first level while providing a common data format at the receiving level. § For such a method to work two things are required: (1) the receiving level, in consultation with the sending levels, must fully and concretely specify the data requirements. This includes the variables, the coding scheme to be used, and the file formats. (2) the sending level must write a programme that automatically converts the data from their formats and coding schemas to the common data interchange format. This is a task that needs to be done initially and then when either the data interchange format changes or the sending levels data formats and coding schema changes. § Such data "reformatting" is one of the things computers do most easily and obviates the problems mentioned in POST 01315E. · Technology is not enough. o While advances in computer technology and software and decreasing cost provide an opportunity to improve data quality and use an information system is worthless unless the quality of data are "sufficient for use" and are actually used. o In many instances a computer-based information system is treated as a technology project and no attention is paid to the completeness, accuracy, and timeliness of the data - crap data are entered and nobody does anything about it. In other instances, the information system produces reports that is useless to the user - either because the report itself is poorly designed or because the user doesn't understand it. The key to understanding a report is to be able to answer the question "What do I DO if the report says "this" instead of "that?". Failure to design relevant and useful reports and to train managers to correctly interpretate the reports compromises the usefulness of the information system. · It isn't over when the computer programme in written. There is still testing, introduction, deployment and training. · It isn't over with the initial deployment. People change jobs and new users need training. The programme isn't perfect and requires fixing. Requirements change and the programme needs modification. Plan to support, fix and modify the system. · It is all wasted if the data are crap – missing, wrong, too late – or unused. Tony Burton ([[email protected]][email protected][/email]) Strategic Information Group
 Department of Immunization Vaccines and Biologicals
 World Health Organization Geneva Post generated using Mail2Forum (http://www.mail2forum.com)
There are no replies made for this post yet.