System requirements for a computerised patient record information system at a busy primary health care clinic

Sam evatting A prototyping approach was used to determine the essen­ tial system requirements of a computerised patient record information system for a typical township primary health care clinic. A pilot clinic was identified and the existing manual system and business processes in this clinic was studied intensively before the first prototype was imple­ mented. Interviews with users, incidental observations and analysis of actual data entered were used as primary techniques to refine the prototype system iteratively until a system with an acceptable data set and adequate functionalities were in place. Several non-functional and user-related requirements were also discovered during the prototyping period. ‘n Prototiperingsbenadering is gevolg om die essensiële s te lse lv e re is te s van ‘n g e rek en arisee rd e p asiën trek o rd s te lse l v ir ‘n tip iese “ to w n sh ip ” p rim êre gesondheidsorgkliniek te bepaal. ‘n Loodskliniek is ge i'd en tifiseer en die bestaand e h an d ste lse l en besigheidsprosesse in dié kliniek is deeglik bestudeer voor die eerste prototipe gei'mplementeer is. Onderhoude met gebruikers, toevallige waarnemings en ontleding van werklike gestoorde data is as primêre tegnieke gebruik om die prototipestelsel iteratief te verfyn totdat dit oor ‘n aanvaarbare datastel en voldoende funksionaliteite beskik het. Verskeie nie-funksionele en gebruikersverwante vereistes is ook ontdek gedurende die prototiperingstydperk. Introduction “As professional nursing moves to meet the challenges o f a second millennium, extensive nursing information systems are required. Nursing information systems o f the future must do more than simply support various tasks. They must provide strategic resources fo r clinical nursing practice. These sys­ tems must be data-driven and nurses must make decisions about their design, development and evaluation ” [Manning & McConell, 1997:141], Today’s nurses are faced with serious problems of providing care to patients with increasingly complex conditions in a shorter period of time as well as administrative pressures to improve productivity and quality. Sorrentino [ 1991:23] advo­ cates that automation can provide them with an opportunity to direct their time and effort to meaningful patient care. Tedious administrative tasks can be eliminated using computerisation. According to Neame [1995:4-6] the benefits of an electronic medical record are numerous. Information is available from every computer that is connected to the database and entries made by multiple providers in different locations can be linked to create a single record for an individual. Data can be checked as it is entered to ensure adequacy and accuracy. The same data can be viewed in different ways and links to knowledgebased tools are also possible. Adderley et. al. [1997:45] maintain that “computerisation has allowed more time for personalised patient care and patient/ staff interaction”. They also concluded that “it (computerisa­ tion) has made information readily available for acquisition and analysis of data” . Anderson et. al. [1995:767] also argue that a computer-based patient record could improve health care in several important ways. It could provide practitioners with rapid access to more reliable patient data. It could also support clinical decision making, clinical reminders and alerts, quality assurance and outcomes research. When a health information system is computerised, the world­ wide trend is to combine the statistical processing with the patient record system into a single health information system [Leske et.al. 1992:260: Neame, 1995:11; Pulliam, 1992:123; Wallace, 1994:1]. Such a system will keep a permanent record of individual patients and simultaneously increment the number of cases without the service provider even being aware of it. At regular intervals the statistical data will be summarised and presented in a format that will be useful to both the service providers and nursing management at regional, provincial and national level. In previous studies the author has examined the effects of computerisation on primary health care specifically in South African townships. The automatic capturing and processing of statistics seemed to be the single most important aspect that would alleviate nurses’ administrative workload [Blignaut & McDonald, 1997(1): 122; Blignaut & Me Donald, 1997(2):27], Despite these presumed and proven benefits of the computeri­ sation of health care, the process is not without its pot-holes and computerisation of primary health care specifically should 68 Curationis May 2001 be approached with caution. The current study is an attempt to determine the system requirements of a computerised pa­ tient record information system for primary health care clinics. Some of the lessons learnt regarding the development and im­ plementation of such a system in a pilot clinic is also discussed. The results of this study could be used as a starting point for health authorities when contracting system developers to de­ velop a patient record information system for primary health care. M ethodology The processes that were used to determine the functional re­ quirements of a computerised patient record information sys­ tem are discussed here. These processes should not be seen as a series of steps that were executed sequentially, nor are they necessarily mutually exclusive. Furthermore, each proc­ ess involved several techniques such as prototyping, inter­ views, and surveys. Selection of a pilot clinic The community health centre of the Mangaung-University of the Orange Free State Comm unity Partnership Program (MUCPP) agreed to act as a pilot site. This clinic has been used for previous studies [McDonald & Blignaut, 1998:8-13] and was ideally suited for this study as well. It is a typical busy township clinic and serves about 500,000 people from an un­ derprivileged community. The MUCPP clinic can be regarded as representative of typical primary health care clinics in township areas. The most of the permanent staff members were from an African culture with no previous computer experience. The services provided included all basic primary health care services. The patient throughput per service provider per day was actually more than in the most other clinics (±30 pa­ tients per nurse per day). Definition of the data set The data set forms the basis o f any so ftw are system [Hettinger, 1992:112]. The data set should comprise all the essential data elements without being over-compre­ hensive. All documentation of the current manual system at the pilot clinic was studied to determine an initial data set. These include all kinds of pa­ tient cards, files, tally sheets, reports on s ta tis tic s , etc. Completed records, not blank cards and files, were used. Potential users (nursing staff as well as clerical workers) w ere in terview ed and ob ­ served w hile at w ork [Shneiderm an, 1998:145], M any of the requirem ents were discovered incidentally rather than formally. The data set was documented as an entity-relationship dia­ gram. Microsoft Access® proved to be a good, though inex­ pensive and readily available, tool that could be used to docu­ ment the data set and define relationships between entities. A study of the business processes A primary health care clinic has a fixed routine. Answers to each one of the following questions were obtained by study­ ing the current manual system and interviewing the potential users. • Where are the patients registered? • How are patients identified? • Where do the patients spend the time waiting? • What primary health care services does the clinic cater for? • Where are special investigations such as urine and blood tests done? • Where are the consultations done? • How are consultations done? Is there a specific proto­ col according to which consultations are done? • How are referrals handled? • Where are follow-up treatments such as dressings done? • How are statistical reports compiled? • Where is medicine handed out? • How is stock control done? • Where are the patient files stored? How are they filed? Figure 1 : C uratives screen in the first prototype (P a tie n t name removed for privacy purposes)


Introduction
"As professional nursing moves to meet the challenges of a second millennium, extensive nursing information systems are required.Nursing information systems o f the future must do more than simply support various tasks.They must provide strategic resources for clinical nursing practice.These sys tems must be data-driven and nurses must make decisions about their design, development and evaluation " [Manning & McConell, 1997:141], Today's nurses are faced with serious problems of providing care to patients with increasingly complex conditions in a shorter period of time as well as administrative pressures to improve productivity and quality.Sorrentino [ 1991:23] advo cates that automation can provide them with an opportunity to direct their time and effort to meaningful patient care.Tedious administrative tasks can be eliminated using computerisation.According to Neame [1995:4-6] the benefits of an electronic medical record are numerous.Information is available from every computer that is connected to the database and entries made by multiple providers in different locations can be linked to create a single record for an individual.Data can be checked as it is entered to ensure adequacy and accuracy.The same data can be viewed in different ways and links to knowledgebased tools are also possible.Adderley et. al. [1997:45] maintain that "computerisation has allowed more time for personalised patient care and patient/ staff interaction".They also concluded that "it (computerisa tion) has made information readily available for acquisition and analysis of data".Anderson et. al. [1995:767] also argue that a computer-based patient record could improve health care in several important ways.It could provide practitioners with rapid access to more reliable patient data.It could also support clinical decision making, clinical reminders and alerts, quality assurance and outcomes research.When a health information system is computerised, the world wide trend is to combine the statistical processing with the patient record system into a single health information system [Leske et.al. 1992:260: Neame, 1995:11;Pulliam, 1992:123;Wallace, 1994:1].Such a system will keep a permanent record of individual patients and simultaneously increment the number of cases without the service provider even being aware of it.At regular intervals the statistical data will be summarised and presented in a format that will be useful to both the service providers and nursing management at regional, provincial and national level.In previous studies the author has examined the effects of computerisation on primary health care specifically in South African townships.The automatic capturing and processing of statistics seemed to be the single most important aspect that would alleviate nurses' administrative workload [Blignaut & McDonald, 1997(1): 122; Blignaut & Me Donald, 1997(2):27], Despite these presumed and proven benefits of the computeri sation of health care, the process is not without its pot-holes and computerisation of primary health care specifically should be approached with caution.The current study is an attempt to determine the system requirements of a computerised pa tient record information system for primary health care clinics.Some of the lessons learnt regarding the development and im plementation of such a system in a pilot clinic is also discussed.The results of this study could be used as a starting point for health authorities when contracting system developers to de velop a patient record information system for primary health care.

Methodology
The processes that were used to determine the functional re quirements of a computerised patient record information sys tem are discussed here.These processes should not be seen as a series of steps that were executed sequentially, nor are they necessarily mutually exclusive.Furthermore, each proc ess involved several techniques such as prototyping, inter views, and surveys.

Selection of a pilot clinic
The community health centre of the Mangaung-University of the Orange Free State Community Partnership Program (MUCPP) agreed to act as a pilot site.This clinic has been used for previous studies [McDonald & Blignaut, 1998:8-13] and was ideally suited for this study as well.It is a typical busy township clinic and serves about 500,000 people from an un derprivileged community.The MUCPP clinic can be regarded as representative of typical primary health care clinics in township areas.The most of the permanent staff members were from an African culture with no previous computer experience.The services provided included all basic primary health care services.The patient throughput per service provider per day was actually more than in the most other clinics (±30 pa tients per nurse per day).

Definition of the data set
The data set forms the basis of any softw are system [Hettinger, 1992:112].The data set should comprise all the essential data elements without being over-compre hensive.All documentation of the current manual system at the pilot clinic was studied to determine an initial data set.These include all kinds of pa tient cards, files, tally sheets, reports on statistics, etc. Completed records, not blank cards and files, were used.Potential users (nursing staff as well as clerical workers) were interview ed and ob served w hile at work [Shneiderman, 1998:145], Many of the requirements were discovered incidentally rather than formally.The data set was documented as an entity-relationship dia gram.Microsoft Access® proved to be a good, though inex pensive and readily available, tool that could be used to docu ment the data set and define relationships between entities.
A study of the business processes A primary health care clinic has a fixed routine.Answers to each one of the following questions were obtained by study ing the current manual system and interviewing the potential users.

•
Where are the patients registered?

Use of a prototyping approach
The basic principle of evolutionary prototyping [Sommerville, 1995:142] was followed.The idea was to develop an initial implementation, expose it to the users and refine it iteratively until an adequate system were developed.The first prototype (figure 1) was nothing more than a set of on-screen replicas of the manual system's forms and cards, but sufficed as a tool for discovering the format and contents of typical data entries made by nurses in a real-world situation.It was accepted that it is unreasonable to expect that service providers must remember everything about their daily tasks while they are interviewed or while they complete a question naire.
an assistant was always present, an on-line suggestion box (figure 2) was also included in the prototypes where users could enter suggestions as they were discovered.
The data entered by users during actual interventions was an invaluable source of information to give clues about the contents and format of typical data entries.Hundreds of stored patient records were studied in detail and with great care.

Results and recommendations
The data set Figure 3 shows the data set that was implemented for the minor ailments module in the last prototype patient record system.

Functional requirements
Functional requirements describe a system's services or functions, how the system should react on particular inputs and how the system should behave in certain situations [Sommerville, 1995:118].The following generic tasks were identified for a system that should support the daily tasks of staff in a primary health care clinic: A modular, depth-first approach was followed.The prototypes implemented the services pro vided at primary health care level as separate modules.For example, separate modules ca tered for minor ailments, antenatal care, child health, and chronic diseases such as hyper tension, diabetes, and tuberculosis.
The computerised system was phased in gradually.Novice users had the opportunity to opt for the manual system in periods of peak workload when they felt that they were still too slow with the computerised system.
Obtaining users' feedback A continuous presence was maintained at the pilot clinic for at least two months.It was our experience that users had the confidence to be frank enough to tell about shortcomings in the prototypes only after a good working rela tionship was established.Users were given ample opportunity (more than three months) to discover their needs.It is generally accepted that novice or first-time users mostly blame their own inexperience for the problems that they encounter.Only after about a month were they able to identify short comings in the prototype systems.
Besides the fact that one of the researchers or

Patient registration
The system should make provision for a way to identify every patient uniquely.In the prototypes used for the current study a unique patient number was generated automatically for every new patient registered.This number was written on the pa tient's file and therefore it was available on subsequent visits as well.A search on a patient's surname could also be done on subsequent visits to obtain the number.
It might be a good idea to use a person's identity number to identify him uniquely, especially in the ideal situation where all the clinics in a municipal area are connected to the same data base.This would also minimise the well-known problem of clinic hopping -patients wander ing from clinic to clinic to obtain free medicine and use it in an un controlled way.
The system should make adequate provision for search facilities on the database.It should at least be pos sible to trace a patient on his pa tient number, surname or address.
The system should not enforce cor rect spellings on searches.
In order to facilitate summarised statistical reports, it is essential to record a patient's date of birth, gen der, occupation and home language.
Only users with the necessary ac cess rights should be able to re move a patient's record from the database.Updates such as change of address should be possible.It should be possible to trace all en tries and updates with regard to date and time and user.
The patient registration screen that was implemented in the prototypes in the current study is shown in fig ure 4.

Recording of m edical interventions
The system should make provision for all services provided at the clinic.It should be modular and flexible in that it should be pos sible to implement only relevant modules at a specific venue [Mandil, 1995:4], For exam ple, there should be separate modules for minor ailments, antenatal care, child health, chronic diseases such as hypertension, dia betes, tuberculosis, etc.It was found that nurses are sensitive to the fact that a computerised system should not encroach upon their professional status.It should not make decisions for them, but rather guide them through the decision mak ing process.System evaluators should ascertain them selves that a software system supports the protocols that service providers are used to.
The protocols should reflect the local cir cumstances.Nurses should not be forced to adapt their way of doing.The protocols should guide them through the processes that they are familiar with and are ex pected from them normally without being prescriptive.For the minor ailments module, the protocols according to which nurses are trained (GOSH: General history, Observations, Summary, Handling) [Van Vuuren, et. al., 1997:1-30] were found to be an acceptable basis for guiding them through the processes of history taking, examination, diagnosis and treatment (figure 5).
The protocols should not be hard-coded.Users with the nec essary access rights should be able to update the protocols dynamically to cater for different environments and services.All items listed should be according to the names that users  are familiar with.See the example of treatments in figure 6.
Lists should be accurate and complete -users experience im mense frustration if items that should be in a list are not there.
Users with the necessary access rights should be able to up date lists' contents (see example in figure 7).

C aptu ring, and reporting of statistics
On screen capturing of statistics should be quick and easy and not divert the user's attention off the main task, i.e. attending to a patient.Items listed should be organised in a way that is familiar and natural to the users.Figure 8 shows how such a list might look like.Users with the necessary access rights should be able to update lists' contents as new requests for information are encountered.
One of the main reasons why service providers tend to neglect statistics to a large extent is the lack of feed back from the health authorities.Serv ice providers cannot be expected to do a tedious task if they don't benefit from it themselves.Therefore, an information system should provide versatile and easy to use reports that fulfil in the needs of both ground level staff and health authori ties.An example of such a report is shown in figure 9.

Stock control
According to the policy of health for all the South African government has granted that certain basic medicines can be pro vided free of charge to patients who are not members of a medical aid fund.In or der not to make misuse of this privilege, extensive stock control is essential.
In order to prevent unauthorised handouts of m edicine, the inform ation system should automatically sub tract stock after it has been prescribed by a legitimate health care service provider.
The system should also com prise adequate security lev els to guard against unau thorised changes of stock levels.Users with the neces sary access rights should be allowed to enter new stock and define standard dosages, prescription units and stock levels (see figure 7).

Reporting
An information system is ide ally a tool that takes raw in put data and converts it to usable information.This in form ation should be pre sented in a usable and mean ingful way.Reports gener ated should be easy to use, though versatile and compre hensive.Reports such as depicted in figure 10 provide users with the ability to filter records both horizontally and vertically.This means that users can select to display only a subset of records as well as a subset of fields.Users can also decide on the sorting order of records displayed.Reports on statistics such as those depicted in figure 9 also provide users with the facility to count occurrences in groups.Reports structured in this way are easy to define though they present enough information to aid both ground level staff and health authorities in the deci sion-making processes.It should be possible to produce printed copies of all reports.
Non-functional requirements Non-functional requirements define system properties and constraints [Sommerville, 1995:130].Examples of system prop erties are reliability, response times and store occupancy.The Close capabilities of the hardware devices at tached to the system are system con straints.Some of the most crucial aspects for a primary health care setting are dis cussed below.

Connectivity
In the current study a peer-to-peer local area network was es tablished to connect the computers of 10 health care service providers, 2 comput ers in the reception office and 1 compu ter in the dispensary.This ensured that a patient's complete record was accessi ble from anywhere in the clinic.Although it was not the case, in this study, it is preferable that all clinics in at least the same municipal area are connected to the same data base server.The availability of a person's medical record at each clinic will enable service providers to have a complete patient record of every patient, regardless of which clinic is attended.

Equipm ent
It is important to acquire the best possible equipment with the avail able funds.In the current study we were largely dependent on dona tions and we experienced some frus tration with inadequate equipment.Cheap equipment caused slow re sponse times and unreliable net work connections.We recommend that a system that runs in a Win dows 95 (or later) environment should run on a CPU speed of at least 300 MHz and internal memory of at least 16 MB (preferably 32 MB).Since the database resides on a server, the hard disk space on the workstations is not critical.It is important to use quality net work cards to ensure a reliable net work.Co-axial cabling might be cheap but the risk exists that one bad link can let the whole network down.We found that a hub, capa ble of handling at least 10Mbps, and UTP cabling is preferable for a local area network.
A peer-to-peer network operating system such as that pro vided by Windows 95 or later would handle up to 15 computers well enough.In larger clinics with more computers a dedicated server running an enterprise network operating system such as Novell NetWare would be preferable.

Safety and Security
It was found in the current study that ignorant users, espe cially doctors, tend to tamper with the computers' configura tions, thus causing frustration for the next user who could not get access to the network or database.The peer-to-peer net working as offered by Windows provides little security and it is essential that a means exist to restrict users from tampering.The clerical worker who acted as on-site system manager had his hands full to reset computers' configurations on a regular basis.The need for an investment into a good anti-virus system is self-explanatory.The anti-virus software should also be up dated regularly -at least twice per year.If a local area network is used, it is essential to ensure that the database server is kept in a safe place against theft.Insurance can replace a computer but not the data that was saved on the hard drive.In the current study the computer in the dispen sary was used to serve as primary database server since it was locked up at all times behind iron security bars.The software should dispose of a facility to backup the data base regularly to a separate computer that is kept in another room.In the current study, one of the computers in the recep tion office was used as secondary database server.A stable power supply should be ensured and mechanisms should be provided to prevent people from accidentally switch ing off the power.This is especially important for the database server.We experienced tremendous problems in the winter when heaters caused frequent power failures.We solved the problem by establishing a separate circuit and circuit breaker for the computer equipment.The system should make provision for different levels of ac cess.Users should not be allowed to use the system without having to log on with a user name and password.Only se lected users should be able to update definitions, enter new stock or register users.Clerical users should not be able to read data on medical interventions.Service providers should not be able to update entries made by another service provider.
It should be possible to connect any entry to a specific user and date/time entered.An example of such a report is shown in figure 10.
The computerised system should replace the manual system with regard to the way of data capturing and reporting only.
The system of folders for each patient should therefore not be abandoned.The continued availability of hard copies of medi cal interventions is essential to ensure that it is possible to revert back to the manual system in cases of power failure or other system failures.The computerised system should there fore automatically generate a hard copy of every consultation.A proper filing system for these printouts should be in place.
In the current study, all intervention reports were printed to the dispensary.Upon acquiring their medicine from the chemist, the chemist took patients' folders, put the printouts inside and sent the folders back to the reception office where they were kept until the next visit.
If one workstation can be used by more than one service pro vider, for example in different shifts, it is essential to ensure that a user is not allowed to work in the name of another.A user's password is similar to his signature in the sense that it identifies the responsible person for updates made to the data base.In the current study, however, users found it frustrating to log on before every new entry due to the time that went into the action regularly.We solved the problem partly by forcing the users to log on again after periods of inactivity of 15 min utes or longer.

General com puter training and motivation
A prototyping approach towards discovering system require ments would not be effective if the prototype users do not have the basic computer-literacy skills.In the current study the users were trained in a word-processing package prior to implementation of the first prototype.This approach proved to be highly successful since the users were able to handle the keyboard and mouse with out being afraid of the com puter at the time when the first prototype was installed.
Computer users do not nec essarily become more and more positively inclined to ward the use of computers as they gain experience [Henderson, et. al., 1996:192;Marasovic et. al. 1997:96;Packer, 1988:102].In previous studies it was found that a novice or first-time user could take 3-6 months to become more efficient (i.e.spend less time on data capturing) with the computer than was the case with the manual system [Blignaut, 1999:182].Continuous support and motivation along with the secondary spin-offs such as eliminating manual sta tistical processing and stock control motivated the clinic staff to persevere through this period.

System specific training and support
In an earlier study [Blignaut, 1996:33] a prototype was installed in several pilot sites.The users were trained in a single half hour session and were left on their own thereafter.It was found that users do not use the computer if the researcher does not show continuous involvement.In the current study, one of the clerical workers showed a keen interest in the research project.This person was then trained to act as on-the-spot system manager.This person had access rights to register new users, maintain the system configuration and update the contents of lists when necessary.He was also responsible for daily backups of the database.Most impor tantly, this person was available on a permanent basis to sup port users continuously, train new employees and attend to basic day-to-day problems.Users should never feel that they have been left in the lurch.Frustrated users are inefficient users.It was found that users preferred that system-specific training be done on a one-to-one basis.The users gained confidence while working with the system in an actual consul tation.Trainers should be patient and friendly with userstrainers should never sound irritated.Although the prototypes used in the current system did not dispose of the facility, the need was experienced for a contex tual on-line help facility to guide inexperienced users through the system.A training package that exactly mimics the opera tional system could also be very helpful.Such a package should include a training database that can be used for training users without any effect on the operational database.

U ser-interface requirem ents
Because of the approach of prototyping, it happened quite often in the current study that the user-interface was changed to accommodate new or changed functional requirements.It was found that users welcomed changes to the user-interface if it facilitated better control, saved time or solved a problem.Changes for the sake of experimenting were accepted less posi tively and had to be motivated very well.After four months of weekly changes to the interface, the users became irritated and explicitly asked that the experimenting must stop.I was also clear that it was crucial to pay special attention to user-interface design, despite the fact that it was only proto type systems.It became evident that it would be difficult to motivate users to use a full-scale system after they struggled to work with a prototype with a badly designed user interface.

Nurses' workload
In the current study, the researchers tried to be sympathetic towards nurses' workload.New versions of the prototype were time and again implemented in parallel with the previous version.In order not to put pressure on users in times of peak workload, users had the option to still use a previous version with which they were more conversant.It is important to en sure that use of the prototype does not cause an increased workload.This approach proved to work well to ensure the continued positive collaboration of users.

The w orkplace
Physical abilities and limitations play an important role in the design of the workplace or workstation.Workplace design is important in ensuring job satisfaction, high performance and low error-rates [Dix, 1998: 111;Shneiderman, 1998:20].
There should be enough desk space for documents and instru ments.The monitor should not obscure eye contact with the patient and should be placed in such a way that there is no glare on the display.The chair should be comfortable, though easy to manoeuvre -the service providers normally get up from their chairs to examine a patient more than once during a consultation.The height and angles of chairs, work surfaces and displays should be adjustable.Service providers should not be forced to sit too close to the screen.The user-interface should have large enough fonts to be readable also while standing at a distance of 2 m from the display.The consultation rooms should be well lit.
Figure 11 shows the layout of a typical consultation room in the current study.If there was glare on the display and also for the sake of privacy the curtains were kept closed throughout the day.This, of course, meant that the light had to be switched on to ensure adequate lighting.
The following points are proposed as specific aspects to take into account when developing and implementing a computerised patient-record system for primary health care in an urban township clinic: • The data set should comprise all the essential elements without being too comprehensive.• The system should support the ex isting daily business processes and not force the users to adapt their work ing habits.
• Users should be involved in the development and implementation.A good working relation with users is es sential to ensure users' goodwill and positive atti-tude.

•
Users should be trained in basic computer skills prior to implementation of a patient record information system.

•
Users should be introduced gradually into the compu terised system -the manual system should not be aban-doned at once.Users should be granted at least three months to achieve the same level of productivity that they could manage with the manual system.

•
The system should fulfil the minimum functional requirements such as patient registration, recording of medical interventions, capturing and processing of statistics and stock control.

•
The system should fulfil the minimum non-functional requirements such as connectivity, response times and safety and security.
In order to convince the advocates of the traditional paperand-pen-systems to change to computer technology, these as pects should be regarded as serious.We are dealing here with people who can be very good nurses but who are not neces sarily devoted to computer use.If the introduction of comput ers does not have a considerable advantage over the manual system that has proved itself over years of experience and evolution, the service providers might be negatively inclined with a resultant loss of job satisfaction and even accuracy of data-capture and statistics.

Figure 2 :
Figure 2 : O n-lin e suggestion box

Figure 3 :Figure
Figure 3 : Data set for the minor ailm ents module as defined in M icrosoft Access®

Figure 5 :
Figure 5 : Input screen for curative details, showing the list of possible data entries

Figure
Figure 6 : Plan/treatm ent screen P U N I TREATMENT Plan' List afl stock C List for selected diagnoses only {• Amoxil Counselling Dispiin Doloiol i m Mist Tussi Panado Refer to Sputum bottles To come back Administer.5 i n r 1 1.5 2 2 5 3

Figure 7 :
Figure 7 : Definition of treatm ents and strengths

Figure 9 :
Figure 9 : Report form of summarising statistics

Figure
Figure 1 1 : Typical layout of a consultation room