Guidance documentation

Guidance for recording problems and diagnoses in electronic health records

Drafted by Anoop Shah, Royal College of Physicians Health Informatics Unit
Date: September 2018

Contents

1. Introduction

2. Scope

3. Definitions

4. Principles and recommendations

5. Example

1. Introduction

Accurate recording of problems and diagnoses is essential for safe, effective clinical care. This guidance aims to provide a common standard for the recording of medical diagnoses and problems in electronic health records, for all healthcare professionals.

2. Scope

This guidance covers general recommendations for recording problems and diagnoses in all patient groups, care settings and specialties, and maintaining accurate records over time. It does not cover nursing or therapy diagnoses, or detailed specialty requirements for recording diagnoses in particular disease areas, although the intention is that the general principles will be applicable in many cases.

3. Definitions

Different electronic health record systems currently use different terminology to refer to problems, diagnoses, comorbidities, past medical history etc. To make this guidance clear, a brief description of the structure of electronic health records and a standard set of definitions is provided here.

3.1 Description of terms

Problem: any condition experienced by a patient (such as a symptom or diagnosis) that the clinician feels is important enough to be recorded in the healthcare record. Problems may be active or inactive.

Disease: A disorder of structure or function of the body.

Symptom: An abnormal experience perceived by a patient that is due to disease.

Sign: An abnormal finding on physical examination that is due to disease.

Abnormal investigation result: An abnormal radiographic or laboratory finding, for example an opacity on a chest X-ray or hyponatraemia. This may have no associated symptoms or signs but is further investigated as for a symptom or sign, pending a diagnosis.

Diagnosis: A label assigned to a patient by a clinician stating that the patient is experiencing a particular disease, based on clinical evidence and reasoning. The diagnosis may describe the underlying pathophysiological process if known. Provisional, working and confirmed diagnoses are problems.

Provisional diagnosis: An initial diagnosis, usually associated with a low level of clinical certainty. It may change as test results or advice become available, but is included in the problem list.

Working diagnosis: A diagnosis which is based on a reasonable amount of clinical certainty but is not confirmed. The patient is being treated as though the diagnosis is true and it is included in the problem list.

Confirmed diagnosis: Medical diagnoses can rarely be certain, but ‘confirmed’ means that clinicians have sufficient confidence that the diagnosis is correct that there is no current plan of further investigation to confirm or refute it.

Differential diagnosis: A list of suspected, unconfirmed diagnoses that the clinician is considering as possible causes of a patient’s signs or symptoms. If a patient has multiple signs or symptoms, each may have its own set of differential diagnoses. Suspected or differential diagnoses should not be included in the problem list.

3.2 Structure of medical records

Medical records can be structured in different ways:

  • Encounter-based: one record per healthcare visit (such as emergency department records)
  • Problem-oriented: one record per medical problem
  • Some combination of the two (hospital inpatient records are encounter-based, but may be problem-orientated within each encounter)

General practice records have one record per consultation, but there is also a problem list which persists between consultations, and the ability to link patient data to problems. Hospitals have different levels of maturity of electronic health records, and some systems have problem list functionality, with the ability to persist problems between admissions.

3.2.1 Encounter-based records

Records of healthcare encounters typically contain the following items of information:

Presenting complaint: The reason that a patient seeks a healthcare consultation, such as a symptom that is concerning them (commonly recorded in emergency care, but may not be recorded for routine appointments).
Encounter problems: The final problems or diagnoses for which the patient received care during this encounter.
Other problems: Problems that were not the particular focus of this encounter. Sometimes referred to as ‘comorbidities’.

3.2.2 Problem-oriented records

Clinical information is organised around ‘problems’.

Problem title: A word or phrase identifying or summarising the problem.
Active problems: Patient problems that currently require healthcare input, and a clinician considers that they should be prominent in the record.
Inactive problems: Problems that no longer require ongoing healthcare input, and are less prominent in the record.
Problem list: A list of a patient’s problems, categorised as active or inactive.

3.3 Clinical coding

Symptoms, signs and diagnoses in encounter records and problem lists may be encoded using a clinical terminology such as SNOMED-CT or statistical classification such as ICD-10. This makes it easier to use this information for purposes such as identifying groups of patients with specific diagnoses, clinical decision support, audit and research.

3.4 Capability of clinical systems

These recommendations assume that the electronic health record system allows the creation of a persistent longitudinal record of problems and diagnoses with dates, active / inactive status and additional information. The College is working with the Professional Records Standards Body and other agencies to promote improvements in the capability of electronic health record systems.

4. Principles and recommendations

Accurate and precise recording of problems and diagnoses is essential for safe patient care, to support clinical decision support, for audit and research, and to enable accurate reimbursement. Problem lists should be complete, accurate, relevant, accessible, timely, unambiguous and linked to treatments and other information. The indications for all medication and other treatments that a patient is currently receiving should be included in the problem list.

4.1 Creating problem and diagnosis records

4.1.1 What to record as a problem
When creating a problem list based on patient history or historical records, include the following:

  • Any condition for which a patient is currently receiving care or follow-up
  • Major past conditions that may have long term consequences or complications (e.g. myocardial infarction).
  • Chronic medical conditions (e.g. diabetes, hypertension).
  • Operations that may have long term consequences or complications (unless these are recorded separately in a surgical history section).
  • Any issues that may impact on care, that are not recorded in immediately visible structured data areas. An example might be an abnormal test result which needs to be further investigated, and which would be useful to flag as a problem so that the next clinician taking over care is alerted to it.

Allergies, medication, family history, social history and health behaviours should be recorded primarily in other structured parts of the electronic health record. This will ensure that the information is available to clinical decision support, and is aggregated correctly for audit and service planning. However, it may be useful to create problem list entries for information that needs to be brought to a clinician’s attention quickly, such as a history of anaphylaxis or heavy drinking, but absence of a problem list entry should not be interpreted as absence of information.

4.1.2 Acute and chronic problems
If a patient has an acute condition that is a manifestation of a chronic condition (such as an exacerbation of asthma), both the acute and chronic conditions should be recorded as separate problems. They should be linked if the system has this functionality, and the acute condition should be marked as inactive once the acute episode is over. This will enable the creation of an accurate longitudinal record of exacerbations.

4.1.3 Accuracy and precision of problem titles
The problem title should be a correct summary of the problem as it applies to the patient, and if coded using a clinical terminology, the term should be drawn from the correct part of the terminology hierarchy. For example, if a patient has an infection caused by a particular organism, the SNOMED-CT term for the infection, not the organism, should be used as the problem title. If a person has a family history of colon cancer, the problem title ‘Family history of cancer’ is acceptable (accurate but imprecise), but ‘Colon cancer’ is not, because it implies that the person has colon cancer, which is untrue.

Problems should be recorded at the highest level of precision and pathological understanding, but not at the expense of accuracy. When coding problems and diagnoses using a terminology, use the most precise code that is accurate, and add additional details in a text comment.

4.1.4 Suspected and differential diagnoses
It is important to record suspected and differential diagnoses, but they must not be confused with provisional, working or confirmed diagnoses, and should not be included in the problem list.

If a diagnosis is suspected, record the symptom, sign or abnormal investigation result that suggested the diagnosis as the problem title (e.g. ‘shortness of breath’), and the suspected underlying diagnosis or differential (e.g. ‘heart failure or asthma’) as an associated text comment.

Some electronic systems have structured ways of recording suspected or differential diagnoses, which can be used instead.

4.1.5 Refuted diagnoses
When reviewing a problem list, delete any problems or diagnoses that are incorrect because they were entered in error. However, if a diagnosis is part of a differential and is refuted, or if clinical decisions were based on it when it was thought to be true, it is important to record that the diagnosis was actively refuted. This will help to inform further investigations.

If the system does not provide a structured method of recording refuted diagnoses, record as the problem title the symptom, sign or abnormal investigation result which originally suggested the diagnosis, and add a comment stating which diagnosis was refuted and why.

4.1.6 Important attributes to record about problems
Record the following information for each problem or diagnosis, where possible:

  • Date of onset (record an approximate date if the exact date is not known).
  • Which clinician, team or service is responsible for managing the problem, if not the general practitioner or the primary team looking after an inpatient.

For problems that are diagnoses, also record the following information about the diagnostic process, where possible:Evidence for the diagnosis (e.g. history, or tests used to confirm it), if known.

  • Which clinician, team or service made the diagnosis, if known.
  • If it is a provisional or working diagnosis, rather than a confirmed diagnosis.

The exact location where this information can be recorded will vary between electronic health record systems. If no structured field is available, record it in a comment associated with the problem.

4.2 Maintaining problem and diagnosis records

Problem list maintenance is essential in order to ensure that it remains relevant, up-to-date and uncluttered. Problem list maintenance should include the following actions:

  • Add missing problems
  • Delete incorrect problems
  • Convert problems to inactive if they are no longer relevant
  • Combine problems that are duplicates
  • Evolve each problem into the most up-to-date diagnosis
  • Ensure that all problems have correct attributes
  • Group related problems together

4.2.1 Problem list reviews

Clinicians seeing a patient at the following points in a patient’s journey should perform a comprehensive review of all items on the problem list:

In primary care:
– First appointment after registration
– Review of chronic condition or medication review

In secondary care:
– Pre-admission clinic
– Admission to hospital
– Discharge from hospital

In any care setting:
– When writing a medical report based on the patient record, such as a transfer of care document
– When assuring the record for patient access
– When receiving a transfer of care document

4.2.2 Active and inactive problems

Clinicians should be able to rapidly assimilate important information needed to treat patients safely by viewing the active problem list. Chronic conditions and acute conditions requiring ongoing input should be marked as ‘active’.

Problems should be marked as ‘inactive’ when they no longer require special consideration during clinical care. Timely conversion of problems to inactive status is important to avoid cluttering the problem list, and to ensure that important problems are always prominent.

Classification of a problem as active or inactive is separate from the underlying disease activity. For example, cancer in remission that still requires ongoing follow-up should have a problem activity status of ‘active’.

4.2.3 Problem lists in inpatient settings

Problem lists should be updated as part of the clerking process, taking into account the patient’s history, their general practice record (if available) and other previous documentation.

Problem lists should be kept up to date during the hospital admission, so that at any time a doctor called to see the patient can know what the active problems are.

Some systems allow diagnoses on the problem list to be transferred easily to a discharge summary. Before writing the discharge summary, the problem list should be updated, removing any problems specific to the hospital stay that are not relevant for the long term or for the GP to know should be marked as inactive.

4.2.4 Problem lists in secondary care outpatients

Outpatient secondary care episodes may be infrequent and relate to a very specific clinical issue, and patients may be discharged after one or two appointments. Given the time constraints in many outpatient clinics, it is unreasonable to expect clinicians to create and update a comprehensive problem list for all patients. However, it is important that conditions being actively managed in secondary care are included.

When viewing a problem list in secondary care, bear in mind when it was last updated. Seek confirmation by asking the patient or reviewing the general practice record, if available, as it is likely to be more up to date.

4.3 Communicating problems and diagnoses

Encounter problems must be recorded on all discharge letters and clinic letters. Other problems should also be recorded if they impacted on the patient’s care during the episode, as this helps to ensure that coding and billing are accurate. However it is not necessary to include a comprehensive list of inactive problems that have no ongoing impact.

4.4 Using advanced features of problem-oriented records

4.4.1 Linking problems to other documentation
Problem oriented documentation (linking individual items of clinical documentation to problems) can be useful to link problems to:

  • Medication
  • Test results
  • History and examination specific to the problem
  • Clinical decisions

General information should not be forced to relate to a problem if it is inappropriate, and ‘non-problems’ should not be created purely to link to generic healthcare activities. If a consultation or intervention relates to multiple problems, and there is no facility to link it to multiple problems, it should remain unlinked and brief pertinent information can be entered alongside each problem.

4.4.2 Major and minor problems
Some systems provide the ability to categorise problems as ‘major’ or ‘minor’, or assign a priority number. ‘Minor’ problems may automatically become inactive after a period of time. Problems which are essential for all clinicians to know about, such as diabetes, should always be marked as ‘major’. However, when reviewing a patient’s record, do not rely on the major / minor classification to identify all serious condition.

4.4.3 Relationships between problems
Use the merging, nesting and semantic linking functions of the electronic health record system to improve the organisation of the problem list, to make it easier to understand quickly. For example, if a patient has angina and previous myocardial infarctions, they can be nested under ‘ischaemic heart disease’. However, beware that nesting may result in serious conditions being hidden, so always expand the list to ensure that no problems are missed.

5. Example

A patient visits the GP and complains of shortness of breath. The GP examines the patient and suspects that he has heart failure. He also notes that the patient has an irregular pulse, and might have atrial fibrillation. The GP records these symptoms and signs in the problem list and records the suspected diagnosis in text comments:

Shortness of breath suspected heart failure
Irregular pulse suspected atrial fibrillation
It is important to note that ‘heart failure’ and ‘atrial fibrillation’ are not entered as diagnoses or problems in their own right, because they are not yet confirmed.

The patient undergoes relevant investigations (ECG, B-type natriuretic peptide and echocardiogram), which confirm these diagnoses. The GP updates the signs and symptoms to confirmed diagnoses, and links them to supporting evidence (investigation results), or adds a comment if the system does not have functionality for linking:

Heart failure confirmed on echo <date>
Atrial fibrillation confirmed on ECG <date>

The patient visits the cardiologist who refines the diagnoses. After reviewing the outpatient clinic letter, the GP refines the problem list with the more specific diagnoses given by the cardiologist:

Heart failure with preserved ejection fraction confirmed on echo <date>, under Dr X’s heart failure clinic
Paroxysmal atrial fibrillation confirmed on ECG <date>, under Dr X (cardiologist)

Personalised care and support planning for people with severe mental illness

A review of a sample of current care plans, and the way they have been developed, may be helpful in identifying the priorities for this improvement. The PRSB Implementation Guide provides more detailed explanations about each element of the plan, including advice on how the planning process might be best conducted.
These questions might form a checklist for current plans to be compared with. 

1. Does the plan include an About Me section in which the service user, in their own words, can indicate the information they want to be available about their lives, their values, their interests, and priorities, available for all those who may care for them?
2. Is the approach to developing a care plan patient centred and engaging, allowing plans to be based on patient priorities goals, and aspirations, along with the actions they plan to take and the support that they will receive?
3. Is there space for a “formulation” to be recorded in which the person receiving care and the professionals who provide it, share and record the personal meaning and the origins of the person’s difficulties?
4. Are relevant procedures and therapies recorded?
5. Where relevant, are one or more contingency plans included for anticipatable disruptions, exacerbations, or deterioration, and do they include advice on what to do and points of contact for those called upon to respond?
6. Where relevant are additional supporting plans incorporated, (an example being an “educational and health plan” for someone with a neurodevelopment disorder)
7. Is a version of the plan available to a service user (if they wish to have it) in a form and format that they can understand and find to be of value?
8. How is a version of the plan available to the GP and other key parts of the health and care system?

Work conducted by PRSB and partners recently has looked specifically at the suitability of this approach to the development and documentation of care and support plans for people with Severe Mental Illness. This resulted in an updated version of the standard (v1.4), for use by any service and for any group of service users, but with some modifications to ensure that it meets the needs of this community. The approach to a patient centred process of identifying goals, hopes, and values, and the support needed to achieve them, is fully compatible with and can be conducted using, specific tools in use in mental health, such as DIALOG, DIALOG+, and ReQoL, for example. 

Where analysis indicates the need for improvement in the content and process of personalised care and support planning for patients with Severe Mental Illness, specific improvement projects should be instituted to co-design with service users and their representatives, and the relevant staff groups, new approaches, and documentation that would be of value in delivering improvement. The toolkit includes a range of existing resources that could be used to engage in this improvement work, including signposting to relevant existing approaches informed by patient experience-based design.

Moving to a single holistic plan

A review of a sample of current care plans, and the way they have been developed, may be helpful in identifying the priorities for this improvement. The PRSB Implementation Guide provides A key development, consistent with national policy on support for Personalised Care across all health and care sectors, is the move towards an individual with complex needs having a single, integrated, care plan, rather than a series of plans developed by different parts of the health and social care system in isolation of one another. For a patient with severe mental illness, the related concerns and challenges might form a very prominent part of such an integrated plan; many will also have concurrent health challenges and needs. The intention is that the relevant services work together to plan and wrap support around the patient and their family in an integrated way, rather than as a series of sequential or disconnected encounters in which the service user or their friends and family have to adopt the role of the integrator.

A starting point would be to agree priority groups of service users who may already have more than one care plan because they need care from more than one part of the system of health and social care. This could be initiated by looking at service users registered with some sentinel practices or PCNs. Alternatively, the approach might focus initially on people with defined co-morbidity or risk that entails collaborative care with agencies beyond specialist mental health services.

The focus here is on the process of care planning and agreement on what should be shared, rather than solely on the technology used;

1. What is the process to agree which professional will initiate care planning and act as the “lead point of contact” for the service user?
2. Will initial plans be agreed with the service user in joint consultations or sequentially? Where and how will they be conducted?
3. What will be the process to agree the elements of the plans which should be available to professionals and potential authorised users beyond the immediate care teams, (A&E services, Ambulance Services, Social services, etc.) with the service user’s consent?
4. How will elements of the plan be updated following consultations in a way which is proportionate, to allow contact and progress notes to be maintained by the service conducting the consultation, whilst avoiding unnecessary work for partners in care if there is no significant change to the personalised care and support plan?
5. What are the implications for workload, logistics, and administration arising out of these decisions?

The answers to these questions and others will best be elicited through focused joint working, grounded in real, or at least realistic examples. This will entail process mapping, and co-design with a range of professionals, service users, and families. Resources from the toolkit and outputs from the Simulation element of this project will be valuable. Some organisations would adopt an approach such as a Rapid Process Improvement Workshop, planned over several weeks and conducted over a number of sequential days, to develop prototype ways of working that could be tested in the field.