Respiratory Medicine (1993) 87,491-494

Topical Reviews

A computer system for a respiratory medicine department

C. BEECH AND C. F. A. PANTIN

Department of Respiratory Medicine, City General Hospital, Stoke-on-Trent ST4 6QG, U.K.

Introduction

All departments of respiratory medicine (DRM) in the United Kingdom are involved in the increasing use of information technology in their work (1). When computers are introduced into an organization, the work pattern is changed. If care is not taken, it is altered adversely (2). With careful planning, com- puters can improve patient care when installed in a DRM, but only when the staff who will use the system are fully involved in its introduction (3).

Any respiratory department offers patient care in wards and clinics. It performs investigations, provides support services, teaches, audits and researches that care. All these functions are underpinned by adminis- tration (Fig. 1). The department acquires data about patients and the delivery of care. These data are processed and released as information. The successful introduction of a multi-user computer system to sup- port these functions should provide benefit by the computer’s ability to recall information quickly and aggregate and review data (1,3). The staff will become more efficient by the removal of mundane paperwork and calculations, giving more time for patient contact. This can help with coping with an increased workload. This paper offers a framework for the guidance of staff in a DRM through the introduction of a computer system.

Stage 1 -User Requirements

It is vital to remember that the computer is no more a tool than a spirometer. To enable the appropriate choice of tool, a DRM must know its own business thoroughly so as to have a clear vision of where its information needs may be met by using a computer. The first step is to draw up a plan of the departmental organization (Table 1). The department’s functions

0954-61 I l/93/070491 +04%08.00/O

A Patient Care

Support Services

/ Education/Research/Audit

\

Administration

Fig. I The pyramid of healthcare.

will have the structure of the pyramid of health care (Fig. 1). How this care is delivered will vary from department to department. Therefore it is essential that all users are consulted from the start. This gives the feeling of ownership, gives a chance to examine current working practices, and to recommend and agree changes that will occur with the introduction of the computer system (4). Evaluation and documentation of the present working practices will enable a compari- son with the post-computerization working practices.

As the work of any DRM is patient centred, the review of the department’s functions should lead to a computer system that is patient based. A patient may come in contact with more than one of the services offered by the department (Fig. 2). In general, a service equates to a module of the computer system. This underlying structure enables potential users to write down what information is required for each module (Table 2).

A list of the department’s user requirements should now be ready for more detailed analysis, usually with a computer professional, perhaps from the hospital computer department.

@ 1993 Baillibre Tindall

492 Topical Review

Table I Departmental Organization-What you must know

Departmental Functions(s)

staff

Number and type of patients Departmental management structure Functional relationships with other departments

i.e. what is your business, e.g. in-patient and out-patient care, lung function, bronchoscopy numbers, type (clinicians, secretaries, etc.), who manages staff etc. i.e. per annum, in-patients, out-patients, specialties (Cystic fibrosis, sleep, bronchoscopies) organization tree required, present and future

actual, mandatory, desired, etc.: what are the data, information and workload/process flows?

Tuberculosis - Bronchoacopy

and other tests

Teaching

I Administration

Fig. 2 The possible structure of a computer system for a respiratory department.

Table 2 Information for a module

What Why When

information is input and output from the module? is particular information needed? is information needed, with what frequency and at what times is it collected and/or produced?

How is data input and output, how should it be aggregated, interpreted? Where has information come from and to where will it be sent? Who inputs, outputs, produces, interprets, uses, manages the data?

Topical Review 493

Stage 2 - Detailed Plans

DATA INPUT AND STORAGE

The information a computer can produce is only as good as the data entered. Each data item needs defin- ing according to it’s type e.g. alpha numeric, numeric or date; and its size e.g. a surname is 25 characters in length. What form inputs are received, e.g. verbal or source documents, defines how they enter the system e.g. keyboard, optical scanner, data transfer from computer systems. Data entry is most accurately done by the member of staff collecting it, and at the time of collection. The order of data entry can significantly affect the smooth running of the department. Con- sideration should be given to what should be done with information that pre-dates the computer system. It is possible to employ someone to manually enter the information, or use optical character recognition (OCR) software to ‘read’ paper documents. This is likely to be expensive.

The number of each data item to be stored should not be underestimated, e.g. 14 000 blood gas tests per year (3). How long data is stored, bearing in mind any mandatory requirements (S), should be decided. Paper documents may also have to be stored as part of the working practice.

INFORMATION OUTPUT

A list of the information the system is required to provide should be made, e.g. reports, letters, infor- mation sent electronically to another system. For each ‘report’ the following should be noted: (a) the infor- mation contained; (b) whether the format or content is already specified, e.g. getting the system to print on a pre-printed form; (c) whether there are special require- ments for stationary; (d) how flexible reports should be, i.e. whether the format, content, or criteria the report is built upon is alterable by the user; (e) the time scale in which reports are printed, i.e. whether the report is required immediately, or whether it can be printed in bulk later; (f) whether graphics are required.

CODING

While the British Thoracic Society is helping to develop the Read coding system (6), the hospital might have a different coding standard or coding rules. It is advisable to ascertain whether the Read coding system is acceptable. Wherever coding is required, the mem- ber of staff who classifies any data item should ideally code it, e.g. a doctor who gives a diagnosis should give its code.

PROCESSING POWER REQUIRED

The demands put upon the system will fluctuate throughout the day. The system must have enough

processing power to cope with both the number of users and the applications they are likely to run. These two factors should provide the minimum processing power required. It should be noted that requirements for processing power never go down, so a system with more processing power than required should have a longer life span, and so has more probability of being cost effective. The response time of the com- puter should also be specified when under maximum workload.

LOCATION AND SECURITY

The location of terminals and printers should be marked on a floor plan of the department. Staff need easy access to terminals and printers but confiden- tiality requires restriction of public access. Terminals should be positioned to minimize glare and environ- mental hazards such as dust, water or blood splashes.

The security plans for both the hardware and data must be detailed. For example, the central machine - the server-of any network should be in a locked room, and levels of password access to the data assigned to the staff. Computer systems occasionally fail, perhaps due to power failure. Fail-safe equipment can be purchased to a level which almost eliminates chance of failure, but this has to be balanced against budget.

MANAGEMENT OF THE COMPUTER SYSTEM

A competent member of staff should be nominated to be a system manager, performing tasks such as creating security copies of data, issuing new pass- words, introducing new members of staff to the com- puter system and basic problem solving. It is useful to nominate an assistant system manager, in case the system manager is unavailable. Time and funding to attend training courses should be provided.

The system manager should chair regular meetings of users to enable views, complaints and new require- ments to be aired. As with any system initial problems will occur. A decision should be made whether prob- lems can be offset, e.g. by providing temporary staff to make up for the loss in productivity as staff learn the new system. A disaster policy should be made, if for some reason the computer system fails, e.g. keeping a paper copy of essential information.

TRAINING REQUIREMENTS

Users will not be able to take full advantage of software without training. A decision should be made on who gets training and to what level. Also, time needs to be allocated for training and for users to get

494 Topical Review

used to software. It can be useful if one or two staff become experts on each software package.

COMMUNICATIONS REQUIREMENTS

It should be noted whether the system is required to communicate with other computer systems to either input or output information and, if access to the sys- tem is required by staff when outside the department, e.g. from a clinic.

Stage 3 - Finding the System

At the end of stage two, the DRM has built its detailed description for its ideal computer system. Can it be found? The hospital computing department may have a policy on the supply of computing equipment, ranging from specifications on what hardware and software may be purchased to software development within their department. Their advice on the specifi- cations should be sought.

If examining systems already available, it is advis- able not to bend the user requirements to fit the system. The computer department should know of any systems that may match your requirements. A visit to a DRM already using the system is preferable to a demon- stration by a company salesman. A salesman has a set routine often without expert knowledge. From the DRM’s user requirements, a check list should be created of the tasks which an ideal system should perform. Members of DRM staff should use the sys- tem on demonstration themselves to review the tasks on the list.

If no existing system fits the user requirements, the system has to be developed within the DRM, possibly with the guidance of the hospital computer depart- ment. A great deal of time, effort, and technical knowl- edge is needed to build any system. Thus computing expertise must be bought in from either a contract programmer, software house or hospital computer department. This should allow the building of a system to fit your requirements. One of the possible benefits of local development is the use of a prototyping approach (7). As the software develops, users can try early versions, and adjust the specifications accordingly. Agreement between developer and user must be made about when to stop or tension will occur.

The system must be able to cope with current demands and future developments. It is impossible to predict what will happen, but the supplier needs to be pressed on their upgrade path and flexibility in meeting any future expansion.

Stage 4 - Costs

The cost of any computer system is high (1) both initially and continually in terms of money and staff time. Capital costs and other costs such as mainten- ance, training and consumables must be agreed. Also, consideration must be given to the hidden costs such as staff time and effort, which is continual. Be aware that as staff increasingly use the new system, user requirements will increase and the system will have to expand at a cost (3). It is estimated that in one DRM (1) it took 3 years before efficiency outweighed cost; however, in the subsequent 3 years, the system has been indispensable.

Conclusion

A welldesignedcomputer system for aclinical hospital department will benefit patients, staff and managers (3). This should never be forgotten during the instal- lation of a multi-user computer system. Patience is required of all members of staff as benefits are reaped only when the system is completely installed.

Acknowledgements

We would like to thank Mr Gilles Vincent and the resource management team of the North Staffordshire Hospital Centre for allowing us to use their checklist for computer system development.

References

1.

2.

3.

4.

5.

6.

I.

Pantin CFA, Beech C, Bradbury S, Evans E. Computers in respiratory medicine. Br J Hosp h4ed 1992; 48: 65&663. Mumford E. Need for relevance in management infor- mation systems: what the NHS can learn from industry. BMJl991; 302: 1587-1590. Beech C, Evans A, Hill V, Mali N, Bradbury S, Pantin CFA. Information technology in a department of respirat- ory medicine. Proceedings-of Healthcare Computing. BJHC Books. Wevbridae, 1992; 310-388. Hammer Ml Rkengineering ‘work: don’t automate, obliterate. Harvard Business Review, July-Aug: 1990: 104-l 12. KBemer E. First report to the secretary of state; Steering group on health services information. HMSO, London 1982. Cole RB, Pantin CFA. The clinical terms project and the BTS. BTS News 1993; 10: 6. Boehm BW, Gray TE, Seewaldt T. Prototyping versus specifying: a multiproject experiment. IEEE Transactions in Sofrware Engineering, 1984; SE-10,3.290-303.