The anatomy of a clinical information system

Medicine is critically dependent on accurate comprehensive data for good clinical management, audit, teaching, research, administration, financial control, general management, and statutory and legal needs.¹ Computer technology offers solutions to the huge accumulations of clinical data in specialty and hospital medicine,² yet it has not been fully exploited.³

The UK Audit Commission,⁴ US Institute of Medicine,⁵ and government initiatives⁶ have stressed the importance of clinical information systems centred on the individual patient. Most hospital computer systems are essentially for administration, and there have been relatively few successful clinical systems,^7–9 with nephrology¹⁰ and intensive care medicine¹¹ having progressed furthest.

We describe a successful clinical system in nephrology based on an underlying flexible “generic” software package that can work in any specialty. The system is explained by reference to a general model of patient care.

Summary points

• The proper foundation for healthcare computing should be clinical information systems based on the individual patient

• An underlying generic software package has been developed which can be adapted to any specialty

• Such a system can facilitate many aspects of clinical management, clinical administration, and general management

• With such systems, paperless operation is possible

Model of individual patient care

The care of each patient can be considered to be a control loop (fig 1),¹² in which data from observations and investigations lead to decisions and actions designed to take care of a patient’s problems and their consequences in a safe, effective, and legitimate manner. This loop occurs in all specialties and is the source of all the activities of a healthcare facility such as a hospital. Though complex, these activities can be set out as four concentric shells (see box and fig 2).

Figure 1.

 Clinical control loop. Observations and results of investigations—including history, signs, and symptoms—are converted by clinical staff into decisions and appropriate actions. Control usually requires the use of records and external sources of knowledge

Figure 2.

 Hospital activity shells. The clinical control loop is at the core of a complex organisation represented by four “shells” that exchange data

Putting the model into practice

The software package used (Proton) embodies generic techniques and structures for cost effective production of information systems for clinical specialties. Proton is widely used in nephrology and is also used in 18 other specialties.¹³ Our information system has evolved since 1987 in the department of nephrology at Glasgow Royal Infirmary by a process of steady exploration and consolidation. Parts of the system are used by three other departments and another nephrology centre six miles away. The system presently holds records for about 10 500 patients and has capacity for several million patients.

The Proton database—installed on a Data General Aviion computer—manages records of patients’ personal information, histories, synopses, problems, investigations, medications, procedures, and treatment plans. Data are stored as text, binary numbers, dates and times, and as items encoded to clinical standards including ICD, OPCS-4, and Read.¹⁴ The database also holds information about staff, facilities, and equipment.

Wire and wireless¹⁵ networks provide access to the database at about 50 terminals and personal computers and link it to the biochemistry, haematology, microbiology, and tissue typing laboratories for automatic receipt of results about twice an hour. All staff understand that entering data is a vital element of their jobs. Subject to need and confidentiality, data are available to everyone involved in patient care, including allied professions, secretaries, clerks, medical records staff, and ambulance staff. In all, about 35 staff access roughly 5000-10 000 screens of data daily. Senior staff can access the database from their homes using secure modem connections. Information can be used simultaneously at many sites, and lost case notes are now just a bad memory.

Activity shells of clinical control loop

Clinical management shell—Assessment of observations and results of investigations. Formulations of decisions including those based on observations, investigations, and procedures carried out during a consultation

Clinical administrative shell—Administrative activities which facilitate the clinical management shell and link it to the other shells, such as arranging appointments and investigations, clinical correspondence, filing results, and clinical audit

Clinical services shell—Investigative, therapeutic, and general services provided by laboratories, imaging facilities, therapy units, operating theatres, wards, supplies departments, transport, etc

General management shell—General management of health care, by hospital managers, financial controllers, healthcare purchasers, and statutory authorities

The software provides immediate and reliable access to complete, up to date, legible, and organised clinical records, which are presented as text, tables, and graphs on screens and, optionally, on paper. Access can be grouped, for example, according to diagnosis, biochemical result, or individual consultant. The system uses a form of “spatial data retrieval”¹⁶ so that users can rapidly call any required data. This keypad interface is compatible with the use of a mouse but is quicker and less prone to error. New versions are fully compatible with the Windows system. Data entered are screened against clinical norms and criteria defined by users, and the system provides help and shortcuts for data entry. An inquiry language enables search and analysis of the database, export of data to other software packages, and user-programmable sequencing of operations. Security and confidentiality are ensured by passwords and by an automatic audit trail of all changes. A daily tape back up of the entire database is stored in a remote fireproof safe. Authorised users can add new types of data and can change menu functions and screen layouts as required.

The system in operation

Clinical management—the inner shell

Patient encounters and consultations

—The computer is the sole data handling medium for seven specialised nephrology outpatient clinics and for nephrology inpatient care. During outpatient consultations, data are reviewed on the screen by both doctor and patient. Patients always welcome the chance to see their records, and no complaints or formal requests for release of information have been received from them. Observations, management plans, and prescriptions are entered by the doctor through the keyboard. During ward rounds, a battery powered, wireless terminal provides the clinical team with continuous contact with the database. Inpatient progress notes are dictated and typed into the database within a few hours. Voice recognition software is being evaluated. Dialysis nursing staff access treatment and drug prescriptions, and results of recent investigations, in order to adjust treatment, which they record on the database.

Clinical prompts and reminders

—The system presents prompts, reminders, and recommendations on the screen, based on the stored data and on agreed best practice, guidelines, and protocols. For example, the system is constantly monitoring the results of biochemistry tests, and when it detects preset levels of renal failure it issues reminders to consider various management plans, such as immunisation against hepatitis B.¹⁷ Important reminders are also printed out automatically at intervals throughout the day. This provides an excellent background for evidence based practice.

Group case review

—A report on about 150 patients is automatically printed and provided to each staff member at a weekly meeting, highlighting patients approaching dialysis, indicating the doctor responsible for care of each patient, and showing details of biochemistry, diet, dialysis fistula, suitability for home dialysis, potential for transplantation, operation scheduling, and other data needed for decisions and a smooth change to a life on dialysis. Preparing the report takes two minutes; previously, it took a secretary four to six hours. One terminal is manned during the meeting so questions can be answered and decisions recorded. Patients with specific problems are “flagged.” The flag or marker can be set at any terminal by any staff member, and stays “on” until it is dealt with at the meeting. Operation waiting lists, patient transfers, and deaths are also reviewed. Morbidity, mortality, and other statistical analyses are available.

Monitoring treatment

—Urea reduction ratio and urea kinetic modelling¹⁸ are used to monitor dialysis. The urea reduction ratio is the ratio of serum urea concentration before and after haemodialysis. Repeated manual calculation is onerous, but, on receipt of correctly timed blood results, the computer automatically displays a graph of the ratio. Before this facility was introduced, only 55% of our haemodialysis patients achieved a urea reduction ratio greater than 60%. This has now risen to 84%.

Calculation of prognosis

—The ease of access to extensive data has enabled us to investigate the use of adaptive neural network software in predicting outcomes.¹⁹

Clinical administration—the second shell

In the outpatient clinic

—All appointments are arranged through the computer terminals, which can display the appointments record of each patient. An appointments list flags patients taking part in clinical studies and trials who may require particular investigations. The system also prepares identifying labels for samples and laboratory request forms. A patient’s arrival is recorded into a terminal by a clerk. A nurse measures blood pressure, weight, and, if necessary, height; tests the urine; and enters the results into a terminal. At the start of consultation, the doctor’s initials are recorded. A blood sample is usually sent to the laboratories, using the preprinted labels. On leaving, the patient is handed a fresh prescription printed by the system and makes a follow up appointment. Any future need for ambulance transport is recorded, and a weekly transport request list is generated. The time of each event in the patient’s progress through the clinic is recorded automatically as data are entered, and this has been used to audit the management of the clinic and compliance with the NHS patient’s charter. After the consultation, the doctor dictates a letter to the patient’s family doctor. This text is later typed into the system and merged automatically with standard details such as the author’s name and with individual data from the database (age, address, diagnosis, results of investigations, prescriptions, etc), which may be processed (such as calculation of estimated creatinine clearance²⁰). Recall letters to non-attenders are generated, with further letters to their general practitioner for persistent defaulters. An inpatient discharge summary is similarly produced on discharge.

Administrative reminders

—As a patient progresses through the clinic the system prompts appropriate staff to complete outstanding tasks. Examples are reminders about missing diagnoses, telephone numbers, details of the family doctor or blood group, or to prepare an outstanding discharge letter. Correspondence and administrative chores are therefore kept up to date. As a final check, a list of missing data is produced daily for the unit administrator, who has a vested interest to keep the list vanishingly small.

Clinical audit

—The database inquiry language is used to produce automatically both ad hoc and preprogrammed clinical audit reports. Most Scottish renal units have computer systems with electronic links to a Scottish renal registry database, where national comparative clinical audit reports are produced.²¹

Tracking inpatients

—The changing locations of inpatients treated by the department are shown on a summary screen updated by clinical staff.

Other forms of clinical administration

—The system is used to ensure compliance with advice from bodies such as the Committee on Safety of Medicines, the office of the UK chief medical officer, and drug companies on issues such as on flu immunisation or withdrawal or substitution of drugs. The necessary letters to patients and their family doctors are generated automatically from the database, usually within 24 hours.

Many routine administrative tasks require attention to fine detail and may be unfamiliar to junior staff. For example, after the death of a patient a doctor may have to record confirmation of death, complete the death certificate, report to the procurator fiscal (in England, the coroner), meet relatives, request a necropsy, notify the family doctor, cancel prearranged outpatient visits, treatments, and transport, alter ward bed state, remove the patient from waiting lists (such as outpatient and transplant), update morbidity and mortality reviews, cancel current prescriptions, and initiate a discharge letter. These actions are all carried out or prompted by the system when it is notified of a patient’s death.

Clinical services—the third shell

Investigative services

—The most valuable interface is the automatic receipt and management of laboratory results, already described.

Treatment

—Inpatient and outpatient prescriptions for drugs, diet, enteral and parenteral nutrition, and dialysis are recorded, as well as changes to surgical waiting lists.

Pharmacy

—Inpatient prescriptions are entered by medical staff at terminals. The hospital pharmacists can review and advise on these prescriptions using terminals in their office.

Dietetics

—The hospital dietitians record dietary histories on the system, together with anthropometric measurements, results of indirect calorimetry, dietary prescriptions, and advice given.

Social work

—The system is used to provide information for and referrals to the social worker, who has access to appropriate areas of the system.

Transport

—Requirements for ambulance transport are entered on the appointment screen.

General management—the fourth shell

The system holds complete data about each patient’s status and progress and can therefore produce management information, including monthly workload reports of patients registered, admissions and discharges, consultations, referrals, durations of stay, severity of illness scores, procedures, and use of equipment, drugs, and disposables. The most common reasons for admission have been analysed and their use of resources calculated, costed, and used as the basis for contractual negotiations.

Discussion

We believe that the system has proved successful because it focuses on the individual patient, it presents data clearly and instantly at the press of a key, it helps staff to work more efficiently, and it is reliable and easy to use. It is therefore capable of acting as the department’s only records system.

Disadvantages have included some initial disruption on introducing the system, a continuing management task to ensure all staff remain committed to its use, restricted access to data during power cuts, and cost. The average annual capital and operational cost of hardware, software, and external services is estimated to have been about 1-2% of the annual operating cost of the nephrology unit. This excludes considerable hardware resources and cabling already installed in the hospital, and some five work years by department staff in detailed adaptations to local practice.

The software package initially installed at Glasgow Royal Infirmary did not provide the full detail of a nephrology system, such as prompts and reminders, but permitted stepwise adaptation. This avoided the well known hazards of a rigid and comprehensive preliminary specification,^22–24 reduced the risk of project failure,²⁵ increased the sense of ownership, and allowed close tailoring to local practice. Day to day maintenance of the system is now carried out by the information technology department of the hospital.

Such progressive refinement is, however, time consuming and therefore expensive, even with flexible software, and, because of differences in clinical practice, the tailored system is unlikely to “fit” another department exactly without some further alteration. The implication is that, although the ability to adapt a developed system to local practice will always be necessary to some degree, clinicians who want the advantages of a comprehensive clinical information system will increasingly have to consider adapting the way they work to the design of available systems.

It is now clear that a variety of clinical information systems for different specialties can be generated from a common foundation. The strongest advantages of flexible software seem to lie in providing this foundation. Future systems are likely to be “prepackaged” versions hammered out in clinical settings and built from generic software adapted for different specialties. This will allow quicker and more cost effective installations. Software components compatible across specialties and able to draw on departmental records will open the way to comprehensive electronic patient records.