This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Read Codes and Its Challenges
The Read Codes are a hierarchically-arranged controlled clinical vocabulary introduced in the early 1980s and now consisting of three maintained versions of differing complexity. The code sets are dynamic, and are updated quarterly in response to requests from users including clinicians in both primary and secondary care, software suppliers, and advice from a network of specialist healthcare professionals. The codes' continual evolution of content, both across and within versions, highlights tensions between different users and uses of coded clinical data. Internal processes, external interactions and new structural features implemented by the NHS Centre for Coding and Classification (NHSCCC) for user interactive maintenance of the Read Codes are described .
The Read Codes are a dynamic clinical vocabulary; they are updated and released on a quarterly basis for clinical terms, and monthly for drugs and appliances. The release intervals provide a balance between the need for a rapid response to feedback, and to minimize disruption to the user. The update process is complicated by the need to simultaneously maintain three separate versions that remain in active use: the early four byte set, Version 2, and Version 3. Although they encourage migration to Version 3, the necessary upgrades to hardware and software are costly, and there is an interim responsibility to ensure that older versions are supported. There is therefore a requirement to respond to user feedback for each version and also to maintain mappings between the different versions of Read and between Read and other systems. These include the International Classification of Diseases, Ninth and Tenth Revisions (ICD9 and ICD10) and the United Kingdom Office of Population Censuses and Surveys Classification of Surgical Operations and Procedures, Fourth Revision (OPCS4) .
Although these formal classifications require stability over a period of time to allow continuity in data aggregation, a controlled vocabulary for the collection of clinical data needs to be dynamic. The frequency and mechanisms of update will vary in response to a number of factors: in particular, size, design purpose, ownership, and available resources. For example, the annual ICD-9-CM revisions are in printed and electronic formats, but the Unified Medical Language System Meta thesaurus is issued annually on CD-ROM, and SNOMED International has increased its frequency of electronic updates .
The following are the three version which are explain in detailed 
Version 1: The Four Byte set
Version 2: Five Byte Set
5.1 The Four Byte Set
The Read Codes were first introduced in the early 1980s to record summary clinical and administrative data for General Practice (GP). Four-character alpha-numeric codes determine the position of a term in a hierarchy, so this version is known as the Four Byte Set.
The Four Byte set is released as two delimited text files, the first containing fields for the Read Codes and the 30-character preferred term, (e.g., F682.| Sensorineural deafness) and the second containing four-character search keywords and synonyms (e.g. F682.| Sensorineural deafness| SENS and F682.| Nerve deafness| NERV). Although the simple code-dependant structure is attractive to users and developers, there are a number of resulting problems. The limitation to four levels constrains the addition of new concepts, and terms often have to be added as impure synonyms or in suboptimal hierarchy positions. Furthermore, multiple parentages are not supported, leading to either incomplete classification or to duplication .
5.2 Version 2
The restrictions imposed by only four levels of hierarchy led to the development of a Five Byte Set, which expanded to support secondary and tertiary care. This set is released in two structurally different versions and has increased content and a more structured mechanism for representing synonyms. Version 1 has shorter terms and keys than Version 2. Both versions have cross-mappings to other classifications, including OPCS4, ICD9, ICD10, the British National Formulary (BNF), and the Anatomic and Therapeutic Chemical Classification Index (ATC).Version 2 is the most widely used format of the Five Byte Set, and subsequent discussions will refer to this .
Version 2 also consists of two files. The first contains the five-character code for the concept and the preferred term of up to 198 characters (with 30- and 60-character abbreviations as necessary) and additional fields for mappings to formal classifications (Table 4.1). The second file contains all the terms that can describe a concept, including, again, the preferred term and synonyms. A separate field holds a two-digit term code that flags a term as preferred (00) or synonymous (11, 12, 13, etc.). Each record has a field that may hold a term key of up to 10 characters to facilitate searching .
Concept 4 Byte Version 2 Version 3
Hierarchy representation Code-dependent Code-dependent Link-based
Multiple parents No No Yes
Hierarchy depth 4 levels 5 levels Unlimited
Hierarchy relationships Mixed Mixed Subtype
Meaningless identifiers No No Yes
Compositionality No No Constrained
Cross maps BNF & ATC OPCS4, ICD9, ICD10, BNF & ATC OPCS4, ICD9, ICD10, BNF & ATC
Flexibility No No Yes
Simplicity Yes Yes No
Term identifiers No Yes Yes
Semantic definitions No No Yes
Number of concepts*
40,927 88,995 187,598
Number of terms*
57,128 125,914 220,840
5.3 Version 3
Version 3 of the Read Codes (the Read Thesaurus) was developed during the Terms Projects (1992-1995), a series of major collaborations between the National Health Service (NHS) Executive and the Conference Information Group of the Conference of Medical Royal Colleges and their faculties in the UK (CIG); the Nursing, Midwifery and Health Visiting Professions; and the Professions Allied to Medicine (PAMS). These projects aimed to provide greater specialist detail and to encompass the wider domain of health care.
Widespread representation of specialist interest was achieved by the establishment of over 50 Speciality Working Groups (SWGs). On completion of the Terms Projects, over 2,000 health care professionals had been involved in the development and quality assurance of the Thesaurus. The requirement to support different clinical perspectives and varying levels of detail led to the development of a more expressive, flexible structure than previous versions.
The more complex Version 3 structure, introduced in 1994, includes meaningless concept identifiers, a flexible link-based directed acyclic graph hierarchy (see figure 5.1), a template table to support semantic definition and attachment of qualifying detail, and a more sophisticated cross-mapping scheme. Additionally, each Version 3 concept is flagged with a status, enabling extraction of different sets of codes for specific purposes and additional functions as discussed below.
Current codes form the core of usable clinical concepts within Version 3, whereas codes flagged as optional are not deemed clinically useful by the SWGs and can be filtered out if desired. This commonly applies to concepts integrated into Version 3 from an earlier version, particularly residual categories derived from formal classifications with suffixes such as NOS (not otherwise specified), and also awkward organizational terms, such as Enthesopathy of the ankle and tarsus.
The extinct status identifies codes, again usually from earlier versions that have more than one potential meaning. This arises from attachments of inappropriate synonyms or hierarchically implied meaning not captured within the terms. They are included only to support users with historical records containing these codes.
The redundant status enables management of duplications that are inevitably introduced into a large thesaurus. For each redundant code a twin persistent code is provided in a separate persistent-redundant table. Thus, the Version 3 database released to system developers is composed of all the current, optional and redundant codes extracted from the editing database. The redundant and optional statuses allow obsolescence of concepts to be managed without deletions from the hierarchy; an alternative strategy is to delete and issue change reports.
Two additional status flags allow preliminary new development of the Thesaurus to be tested without affecting existing users. The developmental status allows new hierarchies to be integrated into the Thesaurus for distribution to SWGs in browsing software, but not for use in live clinical systems. This enables preliminary assessment and incorporation of feedback prior to release for clinical use. Finally, there are experimental concepts, accessible only to in-house authors at the NHSCCC, and allowing preliminary exploration of different options. The features of the three versions are compared in Table 5.1.
In order to facilitate inter-version compatibility, current work aims to incorporate all Four Byte and Version 2 codes into Version 3, thus making Version 3 a superset of all versions (see figure 5.2). Any concept or term added to an earlier version must, therefore, now be added Version 3, and a record must be entered in appropriate inter-version mapping tables.
5.3.1 Read/SNOMED Codes
Read/SNOMED codes are an attempt to classify medical activity and offer to be the means by which medical records will in future be transferred from one practice to another .
Not dissimilar in principal to the Linnaean classification of species in the Nineteenth Century, James Read produced an international classification of medical activity to include disease names, operations and procedures. The aim was to allow easy transfer of information between primary, secondary and tertiary care and be easy to use by clinical staff, researchers, administrators and planners .
The doctor selects the Read/SNOMED Code and so coding is only as good as the knowledge of coding by that doctor. Every computer system in use allows, encourages, or insists on coding every consultation.
Where coding is obligatory it tends to force the doctor into entering a diagnosis and in this sense the code can prejudice the record and a doctor uncertain of the diagnosis can be pressed into entering a code for which there is no firm evidence but which may later be judged as supporting that diagnosis.
Coding is easy for conditions such as "sore throat" or "ear pain." Such entries are likely to be accurate but the more complex codes are less reliable and many are entered wrongly.
Busy doctors have learnt short cuts to avoid coding by entering codes such as "Unwell Generally" or "Chat to Patient". Some codes are well known as being ridiculous, for example "Doctor walked out" or "Accident caused by soap stew or curries" and "Late effect of foreign body entering orifice."
To the best of my knowledge the significance of the selecting of the code has yet to be tested in a case in court but if a doctor has entered a code and not acted upon it, he or she is likely to be open to criticism.
5.4 Read Codes Maintenance
Although Read Version 3 is eventually to become the standard clinical coding system within the NHS, earlier versions remain in widespread use and need ongoing maintenance. Their fixed code-dependent hierarchies, however, limit maintenance to a relatively small number of additions and corrections. In contrast, the flexible data structure of Version 3 allows improvement and evolution involving larger scale ongoing authoring. Read codes are maintained by two processes, internal process and external interaction. They are explained below .
5.4.1 Internal Processes
Maintenance of the Read Codes is funded by the NHS and is undertaken at the NHSCCC by teams of clinical authors supported by technical personnel. The authoring environment is itself a key component of terminology development and considerable investment has been made in support software. The master copy of the Read Codes, along with cross-mapping tables, is stored in a multi-user relational database. The master is edited with a purpose-built editing tool, or more directly with commercial desk-top database products (figure 5.3). At present, additions or modifications to the Read Codes require the use of a different editing tool for each version, a time-consuming approach with the potential for inter-version inconsistency. An extended, integrated tool that can handle feedback from multiple sources and simultaneously update all versions and inter-version mapping tables is planned.
Additionally, many tasks are performed through a Structured Query Language (SQL) interpreter, either in scheduled processes (e.g., removing trailing spaces from terms) or as batch updates (e.g., changing the status flags of concepts in a newly created hierarchy from developmental to current, prior to release).
At the time of each quarterly release, tables are exported to intermediary databases, from which release files or demonstrator products are generated for distribution on floppy or compact disks. A separate database stores details of requests and feedback from SWGs and users and handles the tracking and auditing of this feedback. Finally, a quality assurance module performs complex data integrity checks on a daily basis and manages several hundred rules: e.g., all Version 3 Read Codes must be five characters long and there can be no duplicated terms.
Close teamwork, good communication, and clearly defined boundaries of responsibility, rather than standard record locking, allow effective concurrent editing.
5.4.2 External Interactions
To enable Version 3 to fulfil its intended role as a multidisciplinary thesaurus, the NHSCCC maintains an extensive support network of specialist clinicians, clinical users, and system developers. Each group offers a different but crucial perspective.
An attenuated SWG structure has been retained from the Terms Projects for several reasons. First, the readily accessible specialist knowledge is an invaluable resource for the NHSCCC authors who, although predominantly from clinical backgrounds, often lack detailed knowledge in specialist areas and therefore benefit from the insight into current clinical practice such contact provides (see figure 5.5). Second, their involvement engenders a sense of professional ownership and control and so facilitates adoption of Read at a local level. The members of the specialty working groups are among the NHSCCC's most vociferous champions. Third, the specialist representatives have the endorsement of their professional associations at a national level. Read Code browsing software is regularly released to SWGs as part of their involvement.
The need to mediate when different groups hold conflicting opinions sometimes arises. Resolution often requires significant time and negotiation, with the involvement of a multidisciplinary Clinical Review Panel. Additionally, Product Review Panels bring specialists, users, and system developers together; a Coding Review Panel resolves difficult cross-mapping issues; and a Release Standards Group monitors and approves any changes to the format of release files.
Site-specific additions to a terminology may be necessary either to cater to regional needs (local codes) or to resolve omissions (temporary codes). The latter can be used as a resource to enable maintenance of a terminology. Such additions are permitted as long as they are not communicated to other systems. This mechanism allows users to store data between releases before a request is made for the appropriate concept to be added. If a new concept is subsequently endorsed, and added to the national set, data held against the temporary code will then be transferred to the permanent code. This mechanism will also support the addition of codes specific to a site or system and intended to remain local. A specific initial character is reserved for these codes; in Version 3, a parent code Temporary and local additions, is provided.
The concepts within the Read Codes are located in a branching display hierarchy in which levels of increasingly detailed concepts are placed. This structure facilitates browsing and eventual selection of a concept for data entry .
In the 4-byte and Version 2 file structures, the hierarchical position (or ancestry) was implicit in the alphanumeric code (path-form hierarchy representation). In Version 3 the hierarchy is stored as a table of parent-child linkages (link-form hierarchy representation). This migration from path- to link-form representation has allowed the adoption of a directed acyclic graph "hierarchy" structure which permits multiple parentage (see Figure 2), unlimited depth (the maximum in Version 3 at present is fifteen levels in parts of the anatomy chapter) and readily supports refinement and expansion .
Thyroid disorder Thyroid disorder
Toxic goitre Toxic goitre
It also overcomes a major limitation of the earlier versions in which, when the final level of the fixed-depth hierarchy is reached, new concepts can only be added as "siblings", even when they might be "children" (see Figure 5.6), or as synonyms, even when they are detailed variants that might warrant their own code.
Version 2 7130. Mastectomy
71304 Subcutaneous mastectomy
71307 Subcutaneous mastectomy - gynaecomastia
Version 3 7130. Mastectomy
71304 Subcutaneous mastectomy
71307 Subcutaneous mastectomy - gynaecomastia
(Ideally 71307 should be a child of 71304 but this is not supported by the fixed
Version 2 hierarchy in which it has had to be added as a sibling)
If hierarchies are to be coherent, some redundancy seems inevitable in the absence of multiple parentage as shown in the two Version 2 examples in Figure 5.7 where the same concepts have been duplicated to allow inclusion in both the Infections (A) and Nervous system (F) chapters and the Female genital (K) and Congenital (P) chapters respectively.
Read Code Term Read Code Term
A130. Tuberculous meningitis F004. Meningitis -
K5623 Atresia of vagina PC4yB Atresia of vagina
5.6 Comprehensive coverage
At the time of its introduction, the 4-byte set allowed far greater coverage than any existing clinical coding system, including history, signs and symptoms, prevention and administration. Version 2 offered similar domain coverage with an emphasis on supporting the acute sector's requirements for generating central statistical data for diagnoses and operations. Version 3 aims to support the requirements of health care workers in all sectors and specialties for recording clinical data and thus contains significantly increased detail. A recent phase of refinement has ensured that concepts from earlier versions are also included, so that the new Thesaurus can fully support the needs of both specialists and generalists .
The Read Codes are re-issued quarterly (monthly for drugs) allowing timely incorporation of corrections and enhancements. Additions to the 4-byte set usually originate in the primary care sector; those for Version 2 from both primary and acute sectors. Version 3 is undergoing refinement in response to feedback from initial hospital partnership sites.
Version 2 and Version 3 are cross-referenced to the Tabular List of the Classification of Surgical Operations and Procedures produced by the Office of Population Censuses and Surveys (OPCS-4), the International Classification of Diseases 9th revision (ICD-9), and the International Classification of Diseases and Health Related Problems 10th revision (ICD-10) .
In each version, a preferred term is assigned to a code but synonymous terms can also be included and the overall ratio of terms to codes for the full sets is illustrated in Figure 5. This suggests that the richness of the terminology in Version 3 (ratio 1.2) is lower than the 4-byte set (ratio 1.5). However, Version 3 contains extensive sections of anatomy, organisms and other qualifying detail which have a low synonymy rate. A comparison of clinical subsets, as reported below, suggests that Version 3 is indeed a richer clinical vocabulary (see Figure 5.8).
All versions support synonymy and Versions 2 and 3 include separate term identifiers. In Version 2, the terms are fixed to concepts with 2 character additional term codes, whereas in Version 3, the labelling of terms with unique 5 character codes enables them to be relocated to different concepts. In Version 3, a dynamic descriptions table links the term identifiers to Read codes (figure 5.9).
Read Code Term identifier Term
Version 2 G3... 00 Ischaemic heart disease
11 Arteriosclerotic heart
Version 3 G3... Y201T Ischaemic heart disease
Y201V Arteriosclerotic heart disease
In Version 3, a non-preferred term can be linked to more than one concept, allowing terms with a more general meaning to point to more specific concepts. This is important to support the functionality of a natural language terminology. In order to avoid ambiguity, it is important to ensure that terms do not depend on hierarchical or contextual clues for accurate assignment of meaning. In the 4-byte set and Version 2, the term IgG (Read code 43J3.) is in the laboratory procedures hierarchy though in isolation it may appear to be a substance.
Attempts to avoid confusion may require unnatural defining terminology, for example, Aspiration - action (a procedure as opposed to a cause of pneumonitis), though it may be possible to preferentially use a natural synonym in a live system.
A final point in relation to terms is the released term lengths: the 4-byte set only includes 30 character terms; Versions 2 and 3 include 60- and 198-character term lengths. The use of unabbreviated terms avoids ambiguity in systems which can support them.
The Read Thesaurus enumerates common clinical concepts but also supports the composition of concepts through the attachment of specified attribute-value pairs as qualifiers to objects. This was an essential factor in enabling Version 3 to represent a wealth of clinical detail in a manageable way. The template table contains allowable object-attribute-value triples to support qualification of concepts and also enables semantic definition as described below. The long-term plans for the development of Read Version 3 include widespread semantic characterisation of concepts throughout the thesaurus, a process referred to as atomic mapping .
5.9 Problems with Read codes
Example 1: Case study
The case study has been explained from . In 1998 about 1.2 million people were receiving treatment for diabetes in England and Wales. This number is predicted to increase substantially in the next few decades because of factors such as better case ascertainment, raising levels of obesity, and the ageing of the population. Hence, because diabetes is associated with considerably increased morbidity and mortality, improving its management is a national priority.
To help achieve this objective, the government envisages a much greater role for primary care in the management of diabetes and has launched several initiatives. Firstly, the NHS Plan is leading to an expansion of services for patients with diabetes through greater investment in primary care and through initiatives such as the creation of specialist general practitioners. Secondly, the national service framework for diabetes requires primary care trusts to undertake a baseline assessment of current services to help plan the long term development of services for diabetes. Thirdly, the NHS Information Authority has developed a draft national specification for diabetes registers. Fourthly, the NHS National Strategic Programme for Information Technology plans to improve patient care through a large investment in information and communication technology.
The construction of accurate disease registers will be essential if these initiatives are to be successful in improving the care of people with diabetes. These registers are needed so that people with diabetes can be identified and key aspects of their care monitored.
Read codes were developed in the 1980s and are currently used to code clinical data in primary care in the United Kingdom. New codes are released regularly by the NHS Information Authority. In addition, producers of general practice clinical computer systems can add their own codes, as can individual practices. Few countries use Read codes; many more use the international classification of primary care (ICPC).
The box gives an example of a Read code hierarchy. The Read coding system is complex, and a disease can be coded in many different waysfor example, through a specific disease code, history and symptoms, or investigations and procedures.
This can lead to wide variations in the way in which general practitioners code clinical problems. We examined the Read codes used in recording information on the management of diabetes in one primary care group. The objective was to identify the range and frequency of use of these codes as the first step in developing a local disease register and examining the quality of care for people with diabetes.
We used a two stage process to identify Read codes currently being used to record the management of diabetes in primary care in 17 general practices in the Battersea Primary Care Group in southwest London. Firstly, we tried to identify all patients with diabetes and all the Read codes associated with their management. We then calculated the proportion of patients for whom each code was used. All 17 practices used the EMIS computer system.
An example of the Read code hierarchy
C Endocrine or metabolic disease
C1 Other endocrine disease
C10 Diabetes mellitus
C100 Diabetes mellitus with no complications
C108-1 Insulin dependent diabetes mellitus
C109-1 Non-insulin dependent diabetes mellitus
C108-2 Type 1 diabetes mellitus
C109-2 Type 2 diabetes mellitus
C108-3 Type I diabetes mellitus
C109-3 Type II diabetes mellitus
C1000 Diabetes mellitus of juvenile onset with no complications
C1001 Diabetes mellitus of adult onset with no complications
In the first practice searched, we identified patients with diabetes by using the C10 code for diabetes (and all its lower level codes) and drugs used to treat diabetes (British National Formulary, section 6.1). We identified additional Read codes used in managing diabetes by viewing all the codes used in patients with diabetes and selecting those that were relevant to diabetes. This included codes for the complications and management of diabetes. In the second practice, we repeated this search using all the codes for diabetes identified in the first practice in addition to drugs used in treating diabetes. We repeated this process in the remaining practices and continued to add codes for diabetes. We also checked patients' computerised records to confirm that they had diabetes.
After the computerised records in all 17 practices had been searched once, we searched each practice again using all the codes for diabetes that we had identified, as well as drugs used in the treatment of diabetes. We then calculated the proportion of practices that had used each Read code for diabetes and the proportion of patients with diabetes who had the code in their electronic medical record. We also examined how often other relevant Read codessuch as those for blood pressure recording and measurement of serum cholesterol concentrationwere used in patients with diabetes. These non-diabetes codes, however, were not used to identify patients with diabetes.
We identified 2512 patients with diabetes in the 17 practices (total list size 98 705), an overall prevalence of diabetes of 2.54%. By the time we reached the final few practices, no further Read codes for diabetes were found.
In addition to Read code C10 and its sub codes, we identified several others related to diabetes. Only one code (C10, the generic code for diabetes) and one EMIS specific code (EGTOND1, denoting that dietary advice was given) were in use in all of the 17 practices. Fourteen codes were used by more than 60% of the practices, and two practices used codes that were found only in their own practice (table 5.2). Although a code may be found in a practice, it will only be used to code a proportion of patients with diabetesfor example, the percentage of patients coded with the C10 code in each of the 17 practices ranged from 14% to 98%. We found similarly large variations in the use of other codes related to diabetes.
Table 5.2: Use of selected Read codes in 17 general practices and proportion of patients with diabetes for which each code was used
Group (Read code) % (No) of 17 practices using code % (No) of 2512 patients with code
Diabetes mellitus (C10): 100 (17) 63 (1593)
Diabetes subtypes (C10 subcodes) 82 (14) 45 (721)
Diabetes treatment method
Diet only (66A3) 65 (11) 12 (302)
Oral treatment (66A4) 59 (10) 17 (422)
Insulin treated (66A5) 65 (11) 10 (239)
Place of care
Outpatients (66AF) 6 (1) <1 (1)
Primary care (66AP) 18 (3) 3 (76)
Shared care (66AQ) 18 (3) 5 (120)
Attends diabetes clinic (9NMO) 12 (2) <1 (2)
Care is taking place
Diabetes monitoring (66A) 94 (16) 38 (959)
Diabetes monitor (9OLA) 35 (6) 6 (142)
Process of care
Ankle reflex (2A4) 71 (12) 11 (277)
Retinal inspection (2BB) 82 (14) 21 (538)
Feet examination (66AE) 12 (2) <1 (9)
Footcare advice given (EGTONF01) 94 (16) 33 (830)
Dietary advice given (EGTOND1) 100 (17) 30 (762)
Organ related diabetes
Diabetic retinopathy (F420) 53 (9) 4 (111)
Diabetic neuropathy (F372-2) 18 (3) <1 (9)
Disease management codes
Framingham cardiac risk score (EMISFR4) 6 (1) 4 (111)
Serum cholesterol (44P) 100 (17) 51 (1269)
Serum triglycerides (44Q) 71 (12) 14 (364)
HBA1c (42W) 88 (15) 62 (1555)
Blood pressure (2469) 100 (17) 86 (2172)
Urine protein (467) 100 (17) 64 (1604)
Other diabetes codes
Diabetic diet (13B1) 6 (1) <1 (1)
History of diabetes (1434) 12 (2) <1 (8)
Good diabetes control (66A1) 12 (2) 4 (96)
Practice created codes
Attends eye clinic (QUENSAT1) 6 (1) 3 (75)
Non-insulin dependent diabetes (ZAFARN1) 6 (1) 2 (55)
Of the patients with diabetes, 1593 (63%) had been given the C10 code for diabetes or one of its subcodes. Among patients with a C10 code, 872 (55%) had no subcode identifying their type of diabetesfor example, type 1 or type 2. Eleven (65%) of the 17 practices used Read codes identifying the type of treatment given66A3 (diet only), 66A4 (oral hypoglycaemic agents), 66A5 (insulin). In total, 963 (38%) patients had a treatment code recorded. Place of care codes66AF (hospital clinic), 66AP (primary care), 66AQ (shared care) were used in only three (< 20%) practices and in only 197 (8%) patients.
The process of care code 66A (diabetes monitoring), which indicates that a consultation about diabetes has taken place, was used in 94% of practices. More specific monitoring codes that record aspects of care for people with diabetes were used much less commonly. Examination of the ankle reflex, for example, was used in 71% of practices but in just 11% of patients and examination of the retina was used in 82% of practices and 21% of patients. Codes for measurement of blood pressure, HbA1c, and cholesterol were used in 86%, 62%, and 51% of diabetic patients respectively. Only 4% of patients had a record of being assessed for their risk of an acute coronary event on the basis of the Framingham risk score.
Producing disease registers in inner city areas is difficult. Study has shown that a wide range of Read codes needs to be used, with information from prescribing records, to ensure that the register is as complete as possible. It found that only about two thirds of patients with diabetes were coded using the Read code for diabetes (C10) or one of its sub codes. Because of this, many patients were identified from other codes related to diabetes or from prescribing records. Practices also varied widely in the codes they used and in the proportion of patients in each practice in which each code was used.
5.9.4 Strengths and limitations
It was found that the overall prevalence of diabetes was 2.54%similar to the prevalences of 2.4% in males and 2.0% in females in a recent large study covering England and Wales1. This suggests that the search process was comprehensive.
All 17 practices in one locality participated, so the findings are for an entire population and not from a selected group of practices that have volunteered to take part in a study. The findings therefore are likely to give a true representation of everyday practice. Furthermore, the Battersea area of London varies widely in its socioeconomic characteristics and has a high proportion of patients from ethnic minority groups.
The study will have identified only the diabetic patients who had a Read code for diabetes or another diabetes related code or who had been prescribed medication for diabetes. Some patients, particularly those with diet controlled diabetes, may have been missed by this strategy, as would people whose diabetes had not been diagnosed. Furthermore, the process of care in actual practice is likely to be better than suggested by the coding data. This is because many general practices may be providing care but not coding this information on practice computers. Some patients will also be receiving treatment in hospital clinics, and because of the current low level of integration between hospital and general practice clinical information systems, information on care in hospital clinics may not be recorded in primary care.
5.9.5 Comparison with previous research
The most common method of developing diabetes registers in primary care has been through identifying patients with a diagnostic code for diabetes. Our study suggests that this method may underestimate the prevalence of diabetes because many patients do not have the C10 Read code or one of its sub codes recorded in their computerised medical record. This conclusion is supported by the substantially higher prevalence of diabetes in our study than the 1.2-1.5% reported in previous studies. However, some of these differences may be because the populations in which these previous studies were conducted had different ethnic and socioeconomic characteristics from those in Battersea.
An alternative method of producing disease registers is to use record linkage to combine information from different databases, but this is currently difficult to do in many parts of the United Kingdom. A study using record linkage in Tayside found a prevalence of diabetes of 1.9%lower than the prevalence reported in our own study, but this may have been because of the smaller proportion of people from ethnic minorities in the Tayside population.
Implications for practice
The findings of this study have some important implications. Firstly, with the introduction of the new contract, a substantial component of general practitioners' income will come in the form of quality payments for providing care that meets specified standards. Much of the information used to measure care against these standards is likely to come from computerised medical records. Hence, as well as providing high quality care, general practitioners will also need to ensure that the process of care is recorded and adequately coded on their practice computers. Furthermore, if general practices do not record key information on their computers, then the systems being put in place to monitor the national service framework for diabetes will assume that the process of care being measured has not been carried out.
Secondly, the findings illustrate how much work needs to be done to improve coding levels in primary care and standardise the use of Read codes to allow electronic health records to be used for purposes such as measuring the quality of care. Such improvements will require substantial investment in hardware, software, and training, as well as developing methods of providing more structured chronic disease management. Thirdly, much better integration is needed between hospital and primary care information systems to prevent the unnecessary duplication of entry of data and to ensure that general practice information systems provide a complete and accurate record of the management of patients with diabetes.
This chapter focuses on Read codes and its structures. In this chapter 3 versions of read codes are explain with examples. Maintenance of read codes i.e. internal process and external interaction and hierarchy has been explained with figures. The example case study represents the limitations associated with 3 versions, its results and solutions.
Evaluation: Though version 3 comes with its flexible directed acyclic graph hierarchy, greater synonym purity, and more flexible cross-mapping scheme, incorporating default and alternative maps, avoids these limitations. This flexibility, however, allows other potential problems