Skip to content

Ch 6 dq

Chapter 6 - High Quality Patient Records

6.1 Introduction

Information quality sits at the very heart of these guidelines. Patient care depends on having good patient information at the time that clinical decisions are made. Healthcare cannot be commissioned or planned without good patient information.

The representation of health data in patient records is in itself a complex and time consuming process and the tools we use to create the records, from Read codes to the computer systems themselves, are sophisticated but sometimes difficult to use. Nor is not a simple matter to define high quality patient records but a good place to start is to consider the factors that help determine data, information[^1] and record quality. In the process it is worthwhile reminding ourselves of the various purposes of health records (Chapter 2). These can be briefly summarised as;

  • *Clinical -- *

    • Facilitate the clinical care of individual patients

    • Assist in the clinical care of the practice population

  • *Non-clinical -- *

    • To meet administrative, legal, and contractual obligations

  • *Additional -- *

    • Clinical governance, professional development, education and training, commissioning and healthcare planning[^2], etc

  • *Emerging -- *

    • Health records created in one health environment are increasingly likely to be accessed for viewing and/or editing in other health environments

    • Patients to have increasing control over their health records

Information quality is not an abstract concept but must be considered in relation to the fitness of information for a particular purpose. Careful recording and well designed systems can help ensure that information is fit for the range of purposes for which it might be used, but it may not possible to support all purposes equally and where compromise is necessary GPs should remember that the usual main purpose of their records is to support the care of individual patients.

Clearly stating and understanding these purposes has important implications for clinical record keeping in terms of data and record quality, meaning, clinical coding, education and training. It is also at the heart of the conundrum facing those who seek to define and achieve high quality records: how is it possible to create patient records that adequately support many purposes?

The context of modern Primary Care where patient records are created is also complex. An increasingly wide range of people from different professional groups and organisations contribute to each record. The record must not only function as a record of events but also as an effective means of communication between members of the team providing care to the patient.

Finally it is possible to define the underlying characteristics of good quality patient records that identifies a practical set of goals that enables data quality to be taught and achieved[^3].

6.2 Information quality and modern general practice

Modern primary care has an increasingly multi-disciplinary team approach to its work, which is not contained by the boundaries between the various organisations involved. Practices will increasingly work together in federations and commissioning groups[^4] [^5]. General Practice will have new responsibilities for commissioning services from the rest of the NHS[^6]. The traditional divide between "primary" and "secondary" care is also becoming blurred. Effective and reliable use of information from patient records and efficient and informative communications are therefore vital at many levels and in a variety of different contexts. This applies not just to clinical data, but also to demographic, appointments, administrative and other data held for a variety of purposes that are necessary to the various processes that contribute to the running of general practice (See Chapter 8a.3).

6.2.1 Data Quality vs Record Quality

Creating high quality records requires not only high quality data, but also that data is arranged in the record to support the various purposes to which the record might be put. As with data quality, record quality depends on the quality of the data recorded, the capability of the GP EPR system and the users' input in the form of using the system to its maximum capabilities and ensuring that the systems and practice for capturing and recording data and supporting text are sound and observed..

To create a good quality record requires a detailed understanding of the capabilities of the system used (at least by those responsible for configuring a system and setting record keeping policies and procedures) so that the particular features provided for structuring the record are used to best effect. GPs should seek system-specific advice, education and training to ensure they adopt best practice for record making and keeping for their particular system (See also Chapters 7, 9 & 12).

\

6.3 Capturing information in the consultation

It is very important to acknowledge that patient information can only be a representation or summary of reality, whether paper based or electronic[^7]. Information quality in an electronic patient record cannot therefore be expected to exceed that of the information available to be recorded.

Medical data has a marked degree of inherent variability, uncertainty and inaccuracy[^8], some of which is due to use of language[^9], some is due to the way that GPs reach diagnoses[^10], or select what to record, some is due to the variability in clinical terms used by different healthcare disciplines. Handling these factors is essential for those seeking to achieve high quality data.

It is important for users to understand that modern electronic patient record systems are designed to be both human-readable and machine-readable. We like to read and write stories, so human-readable records will be (relatively) rich in narrative content which is very important for providing context (see below). However, also having high quality data in computable form is critical to enable patient data to be "processed" (e.g. for QoF, audit and decision-support purposes). It is essential that GPs consider both these dimensions as they build and maintain patient records (see also 6.3.1 below and Chapters 7 & 9).

It is generally accepted that data derives an important part of its meaning from the context in which it is recorded[^11][^12] and thus to be meaningful information needs to capture sufficient context to ensure the meaning will be clear to others.. Context is complex and includes unrecorded background and assumptions held by the creator of the record, patient and organisational circumstances, electronic patient record structures and record content alongside the data item

It follows that when information is recorded that is likely to be shared with others working in a different setting, particular care needs to be taken to ensure that important context is made as explicit and unambiguous as possible (see Chapter 4.5).

6.3.1 Coding, structuring and free text

Computer systems are designed to encourage the structured and coded recording of information and provide tools to facilitate this. These tools are designed to speed data entry and ensure consistent structure and coding which will help ensure that information is easy to retrieve and available in a computable form (see specifically Chapters 9.6.2 & 9.6.3) usable by automated facilities in the system.

However, it is not always possible to express clinical information adequately simply as a list of structured codes and in these circumstance it may be preferable to express information as a clinical narrative recorded in free-text, particular where the primary requirement is that it should convey meaning to another human reader rather than support automated processes.

Where information can be adequately recorded using codes and structured data entry it is generally better to do so, but where this is not possible free-text clinical narrative can be used instead of or to clarify structured data entry.

For detail about coding schemes and how they are structured see Chapter 7.

All systems allow users to append text entries to Read-coded entries. Text appended in this way has the advantage that it is likely to retain its contextual relationship to the original Read coded entry even after record transfers to different systems. But it may also become truncated or even lost by some systems in unpredictable ways, an example of where 'system quality' may impact on 'data quality'.

Text appended to Read coded entries should never change the meaning of the original coded concept.

For example the entry;

G30.. Acute myocardial infarction excluded

would be strongly discouraged while the following is quite acceptable

G30.. Acute myocardial infarction developed chest pain at work

6.3.1.1 Use of local codes

Local codes are codes that are not part of the standard national code set (Read, CVT3, SNOMED) but which are generated at a more local level by a particular supplier, health community or practice. Local codes are usually generated to fill a perceived gap in the national set or meet some peculiarly intrinsically local requirement

  • Local codes managed by the supplier

Some local codes are created by suppliers and are essential to support normal system functions but others have been developed to augment Read v2 and CTV3. Such codes cannot be rendered fully interoperable (i.e. cannot be understood if transferred to other supplier systems - see GP2GP chapter -- section 8b.3.4 for further details). Wherever they exist, Read v2 or CTV3 codes should be used in preference to non-Read v2 or non-CTV3 codes and the use of non-Read/CTV3 codes should be deprecated. Some suppliers have embarked on programmes that automatically find their own local codes and replace them with appropriate Read v2 or CTV3 equivalents. Practices are encouraged to avail themselves of these services.

  • Practice generated local codes

Some systems still allow users to create their own codes at practice level. The creation and use of such codes is strongly deprecated. Where such codes have been used in the past it has often been found difficult for users even in the same practice to be certain of their original meaning. It is deemed clinically unsafe to attempt to transfer such coded information to any site away from the originating practice (see GP2GP chapter -- section 8b.3.4 for further details). Practices should seek to replace local codes with standard Read codes wherever possible, using appropriate tools from their system supplier.

6.3.2 Problem and Episode Recording

Most primary care record systems are based on a problem-orientated approach although the detailed implementation varies between systems. In all systems problem titles are Read coded concepts that describe the separate problems that the clinician has identified. Problems may be diagnoses, main symptoms where a pathological diagnosis cannot be made (e.g. headache or abdominal pain), other health issue, life event (e.g. marital breakdown) or major operations.

Problem lists can be built as encounter or consultation records are made, or as information is summarised from paper records, letters or reports. The goal is to build complete and accurate problem lists. Each entry in the patient's problem list should represent a single episode of a problem with an accurate date of onset.

Each system has a method of ensuring that the same Read code can be used for all consultations about the same problem without adding new episodes to the problem list. The principle is to record the episode type of each consultation record.

GP systems generally support a set of episode types defined by the RCGP which allow episodes of care to be defined as First, New or Ongoing (FNO)[^13]:

  • First means it is the first time the patient has presented with this diagnoses ever in their life. There should only be one episode of type "F" for a given diagnosis in a patient record.

  • New applies to a new episode of illness relating to diagnoses with which the patient has previously suffered but since recovered. There can be many episodes of type "N" in relation to acute illness; in the case of chronic conditions, there may be a need to encode N for acute exacerbations -- e.g. in asthma attacks.

  • Ongoing/Other is used when a patient attends and a health issue is discussed as part of the encounter but not it a relationship to "F" or "N". So for example, it may be recorded when a patient attends for a repeat prescription for a long-term condition (e.g. inflammatory bowel disease). Many practices do not record a Read code in such circumstances. (This option was implemented for the RCGP weekly returns service & other morbidity surveys)

Some examples should help to clarify this complex area;

  • Diabetes mellitus does not generally resolve once correctly diagnosed. The first encounter at which diabetes was diagnosed should have episode type "F". All other encounters related to diabetes should have episode type "O". Failure to do this may result in massive overstatement of the prevalence of diabetes in the practice.

  • An individual might have more that one myocardial infarction (MI). The first should have an episode type "F" while further new MI should have an episode type of "N". However, any encounters relating to an MI that has already been recorded should have an episode type of "O" Failure to do this can result in a record showing an patient has had many more MIs than they actually have.

Some systems possess other functions that allow the user to maintain the quality of the problem lists, and preserve the clarity of the consultation narrative, where the view of encounter records can be filtered by problem title:

  • Evolving problems: linking problem titles with different Read codes to merge them into one episode. If a diagnosis has evolved (e.g. an initial problem title may be chest pain but need to be changed to angina for the same episode when the diagnosis is confirmed) or synonymous Read codes have been used for different consultations about the same episode. This will avoid multiple entries in the problem list for one episode and link the narrative of the consultations on the same problem.

  • Deleting errors: correcting diagnositic or coding errors by deleting problem Read codes and replacing the deleted problem titles with correct Read codes without changing the meaning of previously recorded consultation records (e.g. chest pain initially diagnosed incorrectly and recorded as angina, later found to be caused by something else).

  • Grouping related problems: makes long problem lists clearer and enables a more helpful view of the consultation narrative (angina, myocardial infarction and ischaemic heart disease; or appendicectomy and appendicitis) with the underlying pathology being the "group header".

Systems do vary in the way and extent that they implement episode management. This paper can only describe the principles of problem management. We advise that you check your supplier's documentation or seek system-specific training.

6.3.3 Patient Access and Review

The review of records by patients can be a very effective way of identifying incorrect or missing information in that patient's record. Occasionally patients and healthcare professionals may disagree about what should be recorded in the record and the correctness of individual items. Practices should have polices to deal with such disputes and provide a mechanism to record this dissonance in the record when a common view cannot be agreed [^14] (see also Chapter 5)

Bearing in mind that patients increasingly have access to records, practices should take care to ensure that as far as is consistent with their own requirements records are as meaningful to patients as possible[^15];

  • Avoid abbreviations and acronyms (these may be confusing and have different meanings to patients and other health professionals)

  • Avoid medical jargon in free text when plain English can be just as effective. This does not mean that specialist terms should be avoided when they are necessary to support professional use of the record

  • Take care that third party information that should not be disclosed to the patient is appropriately protected. This particularly applies to free text entries and attached documents

6.3.4 Common sources of error

  • Recording information against the wrong patient. Be particularly aware of common names but remember even uncommon names can be duplicated and these are less likely to be checked. It is good practice to confirm first line of address and date of birth with the patient at the start of the consultation. It is less easy, but no less important, to check that information coming from a source other than directly from the patient really does relate to that patient (e.g. pathology results, hospital letters, record received from previous practice). Parents and children with the same name and living together can be a common cause of confusion. Also beware of twins sharing the same initial, date of birth and address. Ensure you are aware of any naming conventions amongst ethnic minority groups in your practice.

  • Use of the NHS Number (CHI Number in Scotland) can help healthcare staff and service providers match patients to their health records (see also Chapter 8a.4)

  • Confusing codes for procedures and diagnoses (e.g. breast neoplasm screen, with malignant neoplasm of female breast or influenza vaccination with influenza).

  • Changing the meaning of coded data by appending text, worst of all using text to negate a code e.g. Code = Breast Cancer Text = Excluded.

  • False certainty e.g. coding a severe central chest pain as myocardial infarct before the diagnosis has been established

  • Confusing family history codes with history of (H/O) codes and actual diagnoses. In general it is best to date diagnostic codes on the date the history is taken that refers to a past event. So "22/11/2010 chickenpox (1975)" means that the history of chickenpox was taken today, but relates to the past date when the patient had the condition (1975). Basically, H/O codes offer no particular value unless it is otherwise impossible to indicate the date the patient had the condition rather than the date of recording. unknown

  • Entering historic information with today's date instead of the actual date of the event / test result

6.4 Capturing information from outside the practice

A modern general practice continually receives large volumes of information from a wide range of sources and in a variety of different formats. The 'hub and spoke' diagram below of sources that feed into the EPR, which is taken from PRIMIS+ training materials, is intended to be illustrative rather than exhaustive. Each of the 'spokes' can be further subdivided and the precise details are likely to vary from practice to practice.

{width="3.3402777777777777in" height="3.2527777777777778in"}

It would be both impractical and undesirable to incorporate these large volumes of information into the EPR in their raw state. Much of the incoming information has to be sifted and summarized, capturing the key data in Read codes in the clinical record. The processes that lead to information being entered into the electronic patient record are typically dependent on a range of different members of the practice team each with their own roles and responsibilities (see Chapters 9 and12).

Any practice wishing to enhance the quality of its electronic patient records will therefore wish to review:

  • Sources of information coming into the practice

  • Processes and policies for handling each of these sources

  • Roles and responsibilities of the practice team members involved in these processes including regular training needs assessment, perhaps as part of an annual appraisal (see also chapters 9 and 12).

  • The clinician-patient-computer consultation is also a key point at which it is essential to capture high quality clinical data, to create and update the patient record (See "Consulting with computers" Chapter 9.7.7)

The aim of this review should be to ensure that;

  • All significant information sources have been identified

  • Clearly defined processes and coherent practice-wide policies exist and are followed for handling each of these sources

  • Individual team members:

    • Are clear about their roles in these processes and of relevant practice policies

    • Have appropriate levels of responsibility

    • *Have appropriate knowledge and skills to perform these functions *

  • *Regular reviews or audits are carried out of *

    • Information sources, processes and policies

    • *Staff roles, responsibilities and training needs *

    • The quality of the data extracted from all of these sources

6.4.1 Issues to consider -- an example to illustrate

A case has been made for recognizing the complexity of the process of achieving good quality patient records and the characteristics of such a record. It is beyond the scope of this chapter to attempt to provide a detailed breakdown of all of the information handling processes and policies that a typical practice might need to have in place to achieve quality. However, consideration of the 'handling of incoming letters' is provided as an example to illustrate the kinds of issues that should be considered. Other chapters in these Guidelines should be consulted for specific guidance that relates to data migration (Chapter 8c), GP2GP (Chapter 8b), and other messaging processes (Chapters 8d, 8e and 8f).

6.4.1.1 Handling of letters incoming to the practice

This is primarily a 'back office / administration' function but with wider implications. A variety of letters may arrive in the practice by various means (e.g. post, courier, fax, email or other electronic means). The following checklist is intended to be illustrative rather than exhaustive. Practices should develop and maintain clear policies that address the following questions;

  • *Does the letter or report need to be filed or attached to the EPR? *

    • Does the letter need to be scanned?

    • Can the letter be linked to the right patient? (preferably by use of NHS Number)

    • Does the method of filing make the letter easily accessible from the patient record and capable of being retrieved by GP2GP when the patient leaves the practice?

    • What information will be entered describing the kind of letter (e.g. cardiology discharge letter, rheumatology outpatients letter) and how?

  • Reviewing the content of the letter, should there be

    • Follow-up actions that should be entered into the EPR?

    • Changes made to (repeat) medication records?

      • Who does these and when?

    • New adverse drug reactions recorded?

      • Who enters these and do they know how this should be done?

    • Content that should be coded into the EPR?

      • Is there a practice policy for what should be coded?

      • Are there clear guidelines about choice of codes?

      • Are there clear rules for the setting of dates (e.g. for actual date of diagnosis, operations or procedures as opposed to today's date)?

      • Are there clear rules for when the episode type should be set (e.g. to First, New, or Ongoing / Other)?

      • Who does the coding?

      • Is the 'coder' appropriately trained?

      • Does the 'coder' know who to ask when in doubt about what to code or how to code?

      • Are there arrangements for holiday / sick leave?

  • If, at a later stage (e.g. in consultation with patient), entries are found to be inaccurate or erroneous (see also specifically chapter 9.7.6)

    • Is there a clear policy about who should make corrections and how it should be done?

    • Is there a clear policy about who should make deletions and how it should be done

It can be seen that if this task is poorly handled then there may be adverse effects on information quality.

  • Relevant information may not be recorded or irrelevant information may be recorded.

  • The patient's record may be rendered incomplete, inaccurate or out of date, or all three.

  • If information is not coded or structured appropriately then it may be inaccessible, for example:

    • Making it hard to find important information when reviewing the patient's record in the consulting room

    • Making it irretrievable by machine searches / audits. Where an adverse drug reaction is not correctly entered there is a particular danger that prescribing decision support will not be triggered with the potential for serious risks to patient safety; this may be setting an "error trap" for a future unsuspecting user (see chapter 3).

See also specifically chapter 9.7.9 Document Management.

6.5 Recognising high quality patient records

A high quality record is one that supports the purposes for which it was created and will be used. It needs to contain high quality data and be structured so that the data can be viewed and manipulated in ways that support the uses to which it will be put.

"Information quality" may have complex interdependencies but in practical terms there can be no doubt that it is a real entity, which has a real impact on patient care. The largest repository of evidence for inter-practice variability in recording quality in GP computer records is PRIMIS+[^16]. This national project was set up with the specific task of improving "data quality" in General Practice by cascading multi-disciplinary information handling, and change management skills into individual practices. Based on previous work[^17][^18], "data quality" for PRIMIS+ has been pragmatically defined as having five key attributes (represented by the acronym CARAT):

  • *Completeness *

  • *Accuracy *

  • Relevance

  • *Accessibility *

  • *Timeliness *

Notwithstanding all of the complexities described above, this is at the heart of the matter that this chapter is addressing.

  • Completeness

Superficially this seems to be a very simple concept. For data to be "complete" every real world instance of a concept should be recorded. Thus for the diagnosis of diabetes mellitus, every patient known to have diabetes in a given population (e.g. practice registered list) would have that fact recorded. So completeness equates to the rate of recording of true positive cases. For the recording of blood pressure every patient for whom a blood pressure measurement was deemed necessary would have a record.

The problem in the former case is to determine what is meant by "known to have ..." and how to define and code the different types of diabetes and in the latter case to determine who decides which patient's blood pressure measurement is "necessary". The issue of relevance also applies; the actions necessary to detect a diagnosis or to measure a blood pressure are likely only to take place if considered relevant or important to the context or purpose(s) for which the data is recorded.

Areas of the record that may be poorly recorded include; home visits and telephone consultations, information derived from the paper records before the practice went paperless, incoming new patient records, or hospital reports and letters, or data not deemed relevant at the time that it was revealed to or found by the person creating the record. Clearly the thoroughness of the person recording the data, the time available to the record creator and the priority he / she gives to record keeping play a part in the quality of the data. Completeness also has impact on other characteristics of quality of the record and is explored in more detail in Chapter 9 (specifically Chapter 9.6.2).

Completeness may be affected indirectly by actions of the data recorder. Failing to use a smartcard may impair the Completeness (and also the Accuracy and Timeliness of the patient's Summary Care Record).

  • Accuracy

While Completeness carries the idea of capturing all real world instances (i.e. the capture of all True Positives) the linked concept of Accuracy is about ensuring that every record relates to a genuine real world occurrence (i.e. all recorded instances are True Positives and there are no False Positives). In the case of the diagnosis of diabetes, every recorded case would have to be genuine for there to be 100% accuracy. For diagnoses, there is a particular problem with ascertaining what constitutes "True Positive" which is a separate matter from consideration of what affects the action of recording.

Accuracy is distinguished from Precision. A blood pressure recorded to the nearest 1mm of mercury might be more precise than one recorded to the nearest 5mm, but would not necessarily be any more Accurate unless repeatable and reproducible.

Accuracy includes an accurate representation of the true number of episodes of an event or illness. For example, over-representation of the number of episodes of stroke or myocardial infarction in the record are serious inaccuracies. It also includes the correct representation of certainty, especially where a diagnosis is uncertain, yet may evolve, change or become certain. Thus accuracy is not an absolute characteristic of data that is permanent once recorded. It requires a continuing process of maintenance, or housekeeping, to reflect a changing understanding of the patient's health problems (see Chapter 9.7.6).

When patients review their records they will often spot any missing or incorrect data. They may also disagree about what should be recorded in the record. Practices should have policies about patient access to their records that cover these eventualities and provide a method of coming to agreement that follows professional and legal standards (See Chapters 5.3 & 9.7.6).

  • Relevance

GPs and their practice teams, they are most likely to record information if they believe it to be important or relevant to a given context, which they have in mind at the time of recording[^19]. This may include direct patient care, commissioning, sharing, Quality and Outcomes Framework, research, or medico-legal factors. Relevance is therefore likely to be playing a key role in determining recording behaviour, raising the question of how individuals come to decide what is or is not important or relevant in a given context. This might be amenable to education and training (See Chapter 9.6.2)

  • Accessibility

A given piece of information may be recorded in several different ways. It may be coded, written in free text, which may contain acronyms or abbreviations (see section 6.7). Coding may follow local or national guidelines or may be more unpredictable. It may match the record display preferences of the system in which it was recorded and/or other systems that may display this data in future (e.g. after GP2GP transfer -- see Chapter 8b). All these factors will have an influence on the accessibility of the record to future retrieval and use of the information.

In general, structured data (e.g. codified information) will be more rapidly accessible than free text but an exception to this is the aide memoire function of the record, where to the human eye a prose narrative may be far more accessible than a string of codes. Some ways of using Read codes can make the meaning of the record less accessible, particularly the use of practice-based euphemisms or free text that distorts the meaning of an attached Read code (see section 6.7). Accessibility may affect "timeliness" in the first (non Currency) sense outlined below. Consistent coding within a practice, and ideally beyond organisational boundaries is essential to assure high-quality data, so users always use the same code for the same problem. Templates and forms can help ensure consistency of coding (but not necessarily correct coding!)

(See also Chapters 7 & 9.6.3)

  • Timeliness/Currency

Timeliness can be used in a number of senses. Records created contemporaneously with the clinical activity they relate to, e.g. immediately after a consultation, are more likely to be accurate than those created later It may refer to Currency which extends the concept of Completeness by requiring information to be up to date. A field containing last year's blood pressure may appear Complete but might only be rendered Current on being updated with the result of today's measurement. It is easy to overlook that the Currency of a record depends not only on the age of a recorded data items but also on the availability of updates. For example, the information in a record might be current but an updating action overdue. An item of information may be described as Timely if displayed quickly and at a time when it is most relevant to a given context.

Finally, it is important not to view information recorded on GP systems as homogeneous. It is the result of the collective action of teams made up of individuals with different roles. Diagnostic, prescribing, administrative, and clinical management information (e.g. blood pressures, serum cholesterols, eye-checks) may each depend on different groupings of people, working in different contexts, and carrying out different actions.

6.6 System specific issues

Each GP clinical system has it strengths and weaknesses and different systems are designed to support particular styles of record keeping. To make the best use of a system it is important that users understand how best to use the system to exploit its strengths and avoid its weaknesses. This can be a particular problem for users moving between systems (see Chapter 8c)

Every member of the practice team should have had training in the use of the practice system that is commensurate with his or her role and responsibilities and their training needs should be regularly reviewed. Practices should ensure they have clear policies supported by system-specific training for those users whose roles or responsibilities involve entering information relating to;

  • Identifying patients / registration (see Chapter 8a)

  • Consultations: it is beyond the scope of this section to go into detail but different systems structure consultations in different ways and this for example, has implications for code use and for the way that the evolution of a 'problem' should be handled (See Chapter 9). Users must understand the options provided by their system and have a consistent approach in their use.

  • Medications (See Chapter 8f)

  • Problem orientation

  • File attachments

  • Summaries

  • Drug allergies -- these are important and worthy of further discussion (below)

6.6.1 Drug allergies

Transfers of allergy information between same systems generally work well but transfers between different clinical systems do not always result in all allergy information being transferred because allergies can be handled in different ways in different systems. Not all systems use Read codes to record allergy information, some use other code sets to drive their prescribing decision support software. The GP2GP team has developed import mechanisms designed to recognize system specific allergy information that then presents the information to the user for action. However some system specific allergy data may be degraded; where the incoming allergy codes cannot be safely mapped to the receiving system's codes, the allergy data will appear as text rather than as coded data. (See also specifically Chapter 8b.3.2)

  • GPs should continue in all cases to use their system-specific mechanism for recording allergies. It is essential that allergy information is properly recorded on your own system to ensure it can be picked up and dealt with during any subsequent GP2GP transfer. Receiving systems will have any incoming allergy information that has been entered using the sending system's specific mechanism presented to them as part of a receipt workflow (for detailed advice see references below).

  • Transfers of allergy information between same systems generally work well but transfers between different clinical systems do not always result in all allergy information being transferred because allergies can be handled in different ways in different systems. Not all systems use Read codes to record allergy information, some use other code sets and others may use bespoke codes. Translation arrangements are therefore needed. The GP2GP team has developed import mechanisms designed to recognize system specific allergy information that then presents the information to the user for action. However some system specific allergy data may be degraded; where the incoming allergy codes cannot be safely mapped to the receiving system's codes, the allergy data will appear as text rather than as coded data.

  • It is essential that practices understand clearly and > unambiguously that to be transferrable (interoperable) across > different clinical systems, adverse drug reactions MUST be entered > in a way that interacts with the native prescribing decision > support system - and that users MUST enter the information > relating to degraded adverse drug reactions in an imported record > in such a way that it interacts with their clinical system > prescribing decision support software.

The GPC issued its own guidance on the use of Read codes to record allergy information in 2006[^20]. See also Chapters 8b & 12 of this.

6.7 Data quality and shared records

Greenhalgh's UCL team and Wyatt at Dundee have both produced important reviews of the literature in relation to data quality and shared records since 2008. Greenhalgh led the review of data quality in the Summary Care Record[^21] that was published as part of the SCR evaluation programme in 2008. Wyatt's review was published as part of the RCGP's Shared Record Professional Guidance (SRPG) project in 2009[^22] and focused on issues relating to shared detailed care records (See also Chapter 5 of these guidelines).

6.7.1 Data quality in Shared Detailed Care Records

From his literature review, Wyatt concluded that there was little published evidence of health benefits from Shared Electronic Patient Records. However, when they do occur, they are probably improvements in the quality and safety of care, in access to care or in cost effectiveness. Key factors in realizing the benefits are;

  • *Commitment and involvement of all stakeholders *

  • *Strong leadership *

  • Looking at benefits from a range of perspectives

  • *Organisational change. *

Wyatt's review emphasised the importance of proper organisation and labelling of data items in shared records. He also emphasised the importance of understanding the effects of meaning, interpretation and semantics of data as well as, data entry, coding, import and translation when working with shared records across professional and organisational boundaries. He concluded that;

"It is clear that the definitions of clinical data items, and even of the headings under which these items appear in the record, vary considerably from one professional group to another and from primary to secondary care. Such differences can usually be overcome over time by discussion in the context of a well-circumscribed organisation such as a single general practice. However, when records are shared across multiple professions and organisations, it will become increasingly hard to interpret and rely on the data entered by others unless radical steps are taken to develop shared definitions of clinical concepts across all relevant professionals groups".

Wyatt's literature review specifically examined issues of data and record quality in shared record systems and emphasised the importance of the following dependencies in contributing to shared-record quality;

  • Defining an acceptable standard of data quality within and across professions and organisations

  • The role of audit to help ensure the quality of data in shared records

  • The shared responsibility of the different organisations concerned to ensure the quality of data in a shared record

  • Minimizing system level errors in electronic shared record (e.g. prevention of data loss during transmission from one organisation to another)

  • Ensuring that different systems are able to match and maintain the patient's identity

  • The completeness of the data in the record will also depend on the access rights provided to professionals by the system

6.7.2 Data quality in the Summary Care Record (SCR)

The UCL study[^23] was focused primarily on ways of driving up the quality of general practice data over time, in the context of the SCR. Their findings highlight the need to assess data not just in terms of whether it is right or wrong, but also on its capacity to be misleading.

Crucially, the UCL study emphasised the importance of clearly understanding the scope and purpose for which records are to be shared before being able to make any useful statements about appropriate data quality standards. The implications for this include the reputational damage that might occur where shared record data is perceived to be poor, resulting in the possibility that such shared systems might therefore have low uptake. The UCL report emphasised that;

  • Good quality data does not just happen

  • Practices need training and support

This study made an important statement about improving the quality of patient records (in the context of the SCR);

"Audits do provide diagnostic information about data quality in the patient record. The data they provide has indicative value as to the likely source of systematic mistakes in data production. These indicators can then be used to drive a process of organisational change that will lead to the production of good data. A combined process of audit and intervention is the most effective way to improve the clinical usability of data in the SCR"

Their review concluded; "that the best possible standards of data quality will be obtained through the use of ongoing audit and intervention cycles" and also recommended that a national strategy for data quality be established.

6.8 Conclusion

To write high-quality patient records, it is essential to understand the various purposes for which those records will be used and the factors that contribute to make the records fit for purpose. As well as those factors, described in this chapter (and Chapter 5), the care and skill of the record keeper and the capabilities of the particular clinical system being used, contribute to the quality of the record.

Record keeping polices and user training should be designed to make the best of the system being used and it is essential to understand that assuring and maintaining data and record quality is an ongoing process, requiring active audit and intervention, supported by validated tools, expert resources (e.g. PRIMIS+) and an ongoing education and training strategy.

Leadership and teamwork are both essential pre-requisites for building high-quality patient records. Someone in the practice team has to take responsibility for driving forward the data/information/record quality agenda. Practices need to create an environment where they continually strive to improve their data quality.

Finally, the quality of patient information only becomes truly apparent when the information is used. Practices, PCOs (and their successors), should ensure that mechanisms are in place to enable these insights to be applied to the continuous improvement of record quality.

[^1]: In the context of health records, "data" items might be a set clinical codes. The data becomes "information" when there is associated context

[^2]: Liberating the NHS: commissioning for patients, Dept of Health, 2010. http://www.dh.gov.uk/en/Consultations/Liveconsultations/DH_117587

[^3]: PRIMIS+ website http://www.primis.nhs.uk/

[^4]: Primary Care Federations: putting patients, RCGP, August 2008, http://www.rcgp.org.uk/docs/ISS_4_PrimaryCareFederations_FINAL.doc

[^5]: Liberating the NHS: commissioning for patients, Dept of Health, 2010. http://www.dh.gov.uk/en/Consultations/Liveconsultations/DH_117587

[^6]: Equity and Excellence: Liberating the NHS, Dept of Health, 2010

[^7]: RCGP Health Informatics Task Force. Scope EPR Project report 1998.

[^8]: Teasdale S, editor. Doubt and Uncertainty in the electronic health record. Proceedings of the Annual Conference of the Primary Health Care Specialist Group of the British Computer Society; Worcester: PHCSG; 1994.

[^9]: Beyth-Marom R. How Probable is Probable? A Numerical Translation of Verbal Probability Expressions. Journal of Forecasting 1982; 1:257-269.

[^10]: Howie JGR. Diagnosis - The Achilles heel? Journal of the Royal College of General Practitioners 1972; 22:310-315.

[^11]: van der Lei J. Use and abuse of computer-stored medical records [editorial]. Methods Inf Med 1991; 30(2):79-80.

[^12]: McWilliams A, editor. Computer-based patient records in primary care: The substrate of ideals and reality. Proceedings of the Annual Conference of the Primary Health Care Specialist Group of the British Computer Society; 92; 1992.

[^13]: Definition in: Morbidity Statistics from General Practice. Forth National Study 1991-92, OCPS, page 16 "Recording consultation type"

[^14]: SRPG report http://www.rcgp.org.uk/news_and_events/news_room/news_2009/rcgp_shared_record_professiona.aspx

[^15]: NIGB Care Record Guarantee http://www.nigb.nhs.uk/guarantee

[^16]: PRIMIS+ http://www.primis.nhs.uk/

[^17]: Teasdale S, Bainbridge M, Horsfield P, Simpson L, Teasdale K, Williams J. JIGSAW - Jumping the Information Gap Solutions at Work. Foundation and quality of care programmes project team; 1998.

[^18]: Teasdale S. The role of information management training in improving the quantity and quality of data held on GP clinical computer systems [MSc thesis]. University of Nottingham; 1997.

[^19]: RCGP Health Informatics Task Force. Scope EPR Project report 1998.

[^20]: Guidance note from GPC January 2006 - Advice from the GPC -- Allergy recording in GP clinical Systems

[^21]: Data Quality Evaluation for the Summary Care Record: An independent evaluation by University College London. Byrne et al 2008. http://www.ucl.ac.uk/dome/openlearning/dataquality2008

[^22]: SRPG Reference Report (Chapter 5) http://www.rcgp.org.uk/PDF/Get_Involved_SRPG_final_ref_report.pdf

[^23]: Data Quality Evaluation for the Summary Care Record: An independent evaluation by University College London. Byrne et al 2008. http://www.ucl.ac.uk/dome/openlearning/dataquality2008

Back to top