Why general practitioners use computers and hospital doctors do not—Part 2: scalability

The actions of the medical profession and the British government have encouraged general practitioners to embrace computing at the same time that hospital doctors were alienated. However, clinical computing for a general practice is technically much easier than for a whole hospital or health district. This review focuses on technical issues (patient record architecture, terminology, interoperability standards, security, and developments in computer technology) which prevent what works for general practice working well in hospitals. These issues, which are all related to scalability, present a major challenge to those responsible for delivering the new vision of integrated 21st century information technology support for the NHS.¹

Summary points

• General practice computerisation has been a success, but what works in a GP surgery does not readily scale up to work in a hospital

• Computer based patient records have a more diverse range of uses in hospitals than in general practice, and simple unidimensional classification schemes such as the original Read codes cannot cope

• In hospitals many different computer systems need to be linked together, requiring common interoperability standards

• Protection of privacy is a much greater problem in hospitals

• The number of potential users in hospitals makes substantial demands on hardware and networks

Methods

This article has had a long gestation. Much of the evidence comes from my experience over nearly 30 years, first as leader of the computer evaluation unit at the Charing Cross Hospital, London (1974-80), then as a general practice system supplier (1980-90), and as a supplier of clinical information systems for hospital doctors (1990-9). An initial version of the article was written in 1993 and extended for the NHS Executive's integrated clinical workstation project 1995. A later version was presented at the AMIA Symposium, Washington, DC, November 2001 (proceedings, pp 42-6).

Patient records architecture

Computer based patient records have long been seen as a goal of healthcare informatics, but the reality has proved elusive. The requirement is easily stated—to provide the right information, to the right person, at the right place, at the right time, efficiently and safely. The Audit Commission estimates that 25% of hospital staff time is spent collecting data and using information, yet the quality of data being collected is a cause for concern.² Patient safety is paramount.³

A key difference between using paper and computer based records is that the users of paper records do all of the work: “To use a paper-based patient record, the reader must manipulate data, either mentally or on paper, to glean important clinical information.”⁴ The computer should relieve readers of this effort, but this points to the root cause of the difficulty. The human brain is far more flexible than any computer program and can cope with an unlimited number of uses. The present generation of computer based patient record systems can handle only a limited number of predetermined tasks.

However, patient records serve an enormous range of tasks, including direct patient care, preventive care (call, recall, and follow up), clinical decision support, audit and accountability, legal evidence, management and financial control, clinical trials, research, and comparisons (local, national, and international). These uses have been classified as clinical management, clinical administration, clinical services, and general management.⁵ Furthermore, each group of staff has specific needs of its own. The Department of Health recognises 62 clinical specialties for doctors, with a similar number of nursing, scientific, therapeutic, and administrative specialisations. Each group has its own audit, quality assurance, decision support, and other requirements. This helps to explain why most successful patient record systems have been limited to situations where the scope of use is well understood, such as general practices⁶ or individual clinical units in hospitals. The unresolved issue is that patient record architectures needed to support general practices and hospital-wide applications are not commensurable.

General practitioners work mostly in their consulting room, normally seeing one patient at a time on a one to one basis, and their computer systems are designed for a limited number of uses. Hospital doctors work in teams and in many places—any ward where they have patients, outpatient clinics, offices, laboratories, and libraries, often at more than one hospital, and from private consulting rooms. Hospital medicine has complex workflow, job specialisation, and division of labour, which creates complex and diverse patterns of information use. For example, the mode of information use is different in intensive care, on inpatient wards, at outpatient clinics, and in general practice surgeries with regard to variables such as the volume and half-life of data, the need for rapid response, and the value of decision support tools and integration with medical devices.⁷

Many efforts have been made to improve the structure and organisation of patient records, notably Weed's problem oriented medical record (POMR), originally developed nearly 35 years ago for use in hospitals.⁸ In Britain today, few hospitals use POMR, although it is widely used in computerised general practices, having been introduced as an integral part of the Abies-Meditel System 5 in 1987. Users find what they want in a complex patient record (which may have thousands of entries) by displaying information on the screen using multiple views by date, problem, topic, or reminder prompt. This type of dynamic formatting contrasts with paper records, which are formatted at the time that they are written.⁹

Hospital case notes are more voluminous than traditional British general practice paper records, which are normally maintained on small cards, named after the politician who introduced them more than 90 years ago. Lloyd George's system is scarcely fit for its purpose, but the consequent brevity of notes facilitated computerisation with small computers. In contrast, most US doctors dictate verbose records, which are less amenable to structured record keeping.

Slack has suggested that one way forward is to separate the clinical and administrative uses of computers.¹⁰ An alternative approach is to use record architectures that support multiple patterns of use, based on sophisticated indexing and multidimensional terminology structures (such as SNOMED CT, see below). Such an architecture must allow entries in a record to be classified and grouped in many different ways, not all of which can be specified in advance.

Clinical terminology

Medicine is unlike other sciences such as biology or chemistry in lacking a formal, internationally agreed terminology. This is partly due to the enormous breadth of the subject and the eclectic origins of the terms used.¹¹

Classification is a way of grouping and organising categories of things or patients according to some criterion. Each purpose may warrant a different classification. On the other hand, coding schemes provide identifiers for computer use. There is no value in having more than one identifier. Hierarchical coding schemes, such as the international classification of diseases (ICD) and the original Read codes, combine the features of a classification and a coding scheme. They cannot be multipurpose, because they are based around a single hierarchical axis and each code is classified in one way only.

All British general practices now use the Read codes (see box B1), which were designed to facilitate data entry in the consulting room.¹² Attempts to use the original Read codes in hospitals proved impracticable, because the simple hierarchical scheme could reflect only one view, namely the general practice perspective for which the system was designed.

Box 1.

Origins of the Read codes

In 1983 Abies Informatics designed a new computer system for use in general practice. An early decision was to use a development tool that used fixed-length fields, requiring all codes and terms to have a predefined length. The design specified alphanumeric codes of four characters each with 30 character rubrics (code meanings), with the additional requirement that the scheme be comprehensive, covering everything that might be entered in a patient's computerised record.

No existing coding system met these criteria, so the only option was to write one from scratch, using references such as the ICD and British National Formulary. Dr James Read undertook the editing task and developed new sections for patient history, examination findings, investigations, and other subjects for which no suitable model could be found.

The Read codes improved on earlier classification and coding systems in several important respects. They were designed for consulting room use, not for epidemiology. No paper version was ever published, facilitating regular updates. The simple unidimensional hierarchy was easy to implement in software. Each code has a uniform alphanumeric structure with four levels (later extended to five) and 60 possibilities at each node (numerals 0-9 and letters A-Z and a-z, with a couple of exceptions that can be confused with numeric digits). This provides a large potential code space. The first character shows the chapter heading, the second the main subdivision, and so on. The following example shows the 5 byte version (version 2):

G.... Heart and related disorder

G3... Ischaemic heart disease

G31.. Acute myocardial infarction

The scheme was cross mapped to English national requirements (ICD-9, and later ICD-10, and OPCS-4 for surgical procedures). In 1988 an expert committee recommended that the Department of Health should take over the development and support of the Read codes. The codes were purchased, and the NHS Centre for Coding and Classification established in 1990.²⁰

Hospitals have an administrative requirement to classify patients in various ways in order to count the numbers being treated, but simple hierarchical classifications designed for counting cases, such as ICD, have no value in direct patient care. Critics such as Slee, who developed the first hospital discharge abstract system and led the development team for ICD-9 CM (the extended version of ICD used in the United States), claim that the way that existing classification systems are being used, or misused, poses a serious threat to the truthfulness and completeness of medical records.¹³

The NHS Clinical Terms project, which was started in 1992, was a major attempt to address these issues. However, the decision to specify a primary hierarchy defeated the purpose of a multiple hierarchy scheme, and the structure was unnecessarily complex. After an adverse report from the Public Accounts Committee, the Department of Health decided to merge the results with the College of American Pathologist's SNOMED Reference Terminology to develop the SNOMED Clinical Terms, which avoid these problems (see box B2).

Box 2.

SNOMED Clinical Terms

SNOMED Clinical Terms have been developed jointly by the College of American Pathologists and the NHS on the basis of SNOMED Reference Terminology and the NHS Clinical Terms (Read codes). Release 2 (July 2002) includes 330 000 clinical concepts, 1 000 000 relationships between clinical concepts, and 850 000 terms used to describe each concept, including UK and US English dialects and Spanish language terms.²¹ (The original Read codes contained just 16 285 concepts, excluding medication.¹²)

Each SNOMED Clinical Terms concept can be described by more than one term and can be related to any number of other concepts in multiple hierarchies. This allows each concept, such as a condition, to be classified in any number of ways, such as according to anatomical location, body system, appearance, or cause. The identifiers used in the system are meaningless and are invisible to end users.

Interoperability standards

Early general practice computer systems were self contained, and could function without computer interfaces in the surgery as a single computer supplier met all needs. The situation in NHS hospitals is more complex: each hospital has a variety of different systems, which need to interchange data (see fig 1).

Figure 1.

Information flows within a hospital. Each box may represent several different computer systems from different suppliers

Interoperability is a cornerstone of integrated care record services.¹ However, components can interoperate only if they are designed to fit with each other. A national architecture for healthcare interoperability is required. Interoperability falls into two classes—functional and semantic.

Functional interoperability is the ability of components to exchange data, without necessarily understanding what is being exchanged. The USB specification for attaching peripheral components (modem, printer, etc) to computers is an example. Most of the e-Government Interoperability Framework falls into this category.¹⁴

Semantic interoperability is the capability to share data between applications. This depends on both the sender and receiver understanding a common language, in much the same way that English is used as a common language for air traffic control. This does not mean that all systems need to use this language internally, only that it is used for interoperability. The lack of such a language has been an impediment to progress for many years, although special purpose standards have enabled electronic data interchange for a limited range of tasks such as reporting clinical test results.¹⁵ HL7 version 3 (see box B3), is intended to fill this gap, in combination with SNOMED Clinical Terms, although this combination has not yet been proved in practice.

Box 3.

HL7 version 3

HL7 version 3 has been chosen as the future standard for exchanging clinical information by both the United States²² and the NHS in England.¹ It is based on a reference model that ensures consistency in the representation of information in messages and reduces the chance of ambiguity and misunderstanding. This allows the receiving system to use the information safely and effectively.

One of its first applications is the NHS Information Authority's GP2GP project.²³ This project provides a means of transferring complete patient records from one general practice system to another, enabling a patient's new doctor to receive the records much faster than the traditional clerical procedures allow and eliminating the need to re-key patient data.

Major social and economic benefits have been claimed for sharing data between different healthcare staff across different sites and disciplines. One of the few evaluated experiments, which is less well known than it should be, was the Exmouth Care Card project in the late 1980s, which used a smart card as the exchange medium (see box B4).

Box 4.

Exmouth Care Card project

The Exmouth Care Card project (1989) was one of the earliest uses of a patient held electronic medical record. Fifteen general practitioners in three locations shared clinical information with eight pharmacies, a dental practice, the accident and emergency department at a local hospital, and the diabetes unit at another hospital using computer readable patient data cards (smart card). A patient was the networking agent, carrying a medical summary and prescriptions between general practitioners, pharmacists, dentists, and hospital staff.

Evaluation, in a trial that was too small to be conclusive, found significant reductions in the time that general practitioners devoted to information gathering and investigations, reductions in the number of tests performed, improved monitoring of compliance with repeat prescriptions and over the counter drugs, and strong user support for the concept.²⁴

Security

Security was not a major problem for general practice computer systems until the introduction of wide area networking (NHSnet and the internet). Each practice computer was a closed system with no way for an unauthorised user to gain access. A lock on the door was regarded as sufficient. Most general practitioners thought their electronic records were more secure than their paper records. Today, however, all general practitioners are connected to NHSnet and have to comply with a rigorous code of connection.

Security has always been a more serious threat in hospitals, where thousands of staff come and go at all hours. Hospital networks may have thousands of access points, making it impossible to restrict access solely to staff who have been personally vetted by each doctor. The issues of protecting privacy and data sharing are not unique to health care.¹⁶ Other public services, such as the criminal justice system and the tax system, also need scalable methods of protecting privacy, based on user authentication and explicit authorisation of other agents to view personal information. One such tool is the Government Gateway.¹⁷

Developments in computer technology

The power of computers (measured as a function of speed and storage capacity) has increased by a factor of tens of thousands in the past three decades. Early systems were designed around the constraints of what was affordable. The availability of small, inexpensive multiuser computers was a major spur to general practice computerisation. Designers took advantage of the limited size of practices to use microcomputers. The first Abies system in 1980 met the needs of a four doctor practice with 32 kb of RAM and 1 Mb of disk storage (see fig 2). In comparison, the Charing Cross Hospital in 1975 ran patient administration and cumulative ward based clinical test reporting systems with just 450 Kb of RAM and 150 Mb of disk storage. However, this computer occupied a large room.

Figure 2.

A 1981 vintage general practice computing system

Another issue has been the number of computer screens required. Even by 1993, most computerised practices had more than two screens per doctor.¹⁸ Few hospitals have invested in anything like the number of workstations or network band-width they need to provide access anywhere at any time.

The major development of the past decade has been the development of the internet. This has already led to ubiquitous email and browsing and has transformed the way that medical knowledge is created and disseminated.¹⁹

Conclusions

There are several reasons why it was technically easier to computerise general practices than large hospitals, and all are related to scalability. What works for a small practice does not work for a big hospital or across the primary-secondary care divide.

New developments—such as HL7 version 3, SNOMED Clinical Terms, new patient record architectures, security tools, and internet technology—are emerging that may provide the cornerstones on which integrated patient record services can be built. However, each development is as yet unproved individually in the NHS, let alone in combination with the others. On the other hand, we now know that traditional methods do not do the job, so innovation is the only option.