Terminology Services Guide

Search

SNOMED CT Document Library

    Loading...
  

This section provides a general introduction to the terminology service requirements related to EHR data entry. It outlines the rationale for the following sections on data entry design and practical data entry.

Background Reading

Readers of this section of the guide are advised to read the following sections of the SNOMED CT Search and Data Entry Guide.  

Data Entry Context

Entry of data into an Electronic Health Record (EHR) requires access to services that enable the user to rapidly locate and select the concepts and terms that need to recorded. There are a wide range of different EHR data entry scenarios determined by the type of healthcare encounter and the reason for that encounter. A typical data entry scenario involves recording data in different data entry contexts. The data entry contexts are typically distinguished by section headings (e.g. "Surgical History"), individual data item labels (e.g. "Initial Diagnosis") and in some case by specific questions with a limited range of answers (e.g. "Family history of heart disease?"  with values "Yes", "No" or "Unknown").

Data entry design needs to take account of data entry context for two reasons.

  1. The range of concepts that can rationally be entered is determined by the data entry context.
    • Table 3.2.1-1 illustrates this point with examples of three data entry contexts. In each of these contexts, there are constraints on the range of SNOMED CT concepts that it is rational to enter.
  2. The interpretation of concepts or other data entered may be affected by the data entry context.
    • Table 3.2.1-1 provides examples of ways in which the data entry context can affect the interpretation of recorded data. To ensure appropriate interpretation, relevant information about the data entry context must be stored with or linked to the data entered.


Table 3.2.1-1: Data Entry Context Examples

Data Entry ContextConstraints on ValuesInterpretation of Recorded Data
Initial diagnosis on an encounter or admission form

A concept recorded in this data entry context should be a subtype of 64572001 | Disease (disorder)| .

Example

A healthcare professional assesses an unconscious person in the emergency room and concludes that the patient is suffering from effects of alcohol. To enter this initial diagnosis they type "alcohol".

An unconstrained search for "alcohol" will find a concept with the term | Alcohol| and may show that at the top of a search list. The problem is that this term is a synonym for the 53041004 | Alcohol (substance)| . While a substance may be relevant to the patient's condition a substance is not a valid diagnosis.

A search for the term ""alcohol" constrained to subtypes of 64572001 | Disease (disorder)| avoids this error and results a shorter, more appropriate list including concepts such as 25702006 | Alcohol intoxication| .

The fact that this is an "Initial diagnosis" data entry context needs to be captured so that the record can be appropriately interpreted.

Note

Subsequent investigations and assessments may refute the initial diagnosis. In this case, the initial diagnosis should not be presented as a condition the patient has actually had. However, it may remain relevant as the rationale for initial treatment and investigation. Furthermore, a subsequently refuted initial diagnosis may also be of interest from the perspective or service administration, clinical audit and research.

Surgical history as part of past medical history

A concept recorded in this data entry context could either be:

Example

A past history of an appendectomy could be recorded in different ways including:

The "Past History" data entry context needs to be captured so that the record can be appropriately interpreted. It must be possible to distinguish a past history record of a procedure from a contemporaneous record of the same procedure.

Note

The definitions of concepts that are subtypes of 161615003 | History of surgery (situation)| formally represent the past history context by including the attribute 408731000 | Temporal context|  =  410513005 | In the past| . If subtypes of 387713003 | Surgical procedure (procedure)| are to be used to record surgical history, these record entries must include an explicit indication of the past history context.

In either case, it may also be useful to indicate the source of the information (e.g. reported by the patient, derived from the original record) and actual or approximate date of the procedure.

Symptom check list with yes or no options for each symptom

Each question should be bound to a concept that represents the relevant symptom. These concepts should be subtypes of 404684003 | Clinical finding| .

The simplest way to represent the "yes" and "no" answers to a question like this is to record the relevant finding concept if the answer is "yes" and not to create a record if the answer is "no". However, where the answer "no" has clinical significance, alternative approaches discussed in the next column may be preferable.

Example

A question about whether a patient has a sore throat would be linked to the concept 162397003 | sore throat| .

  • If the patient answers "yes" then 162397003 | sore throat| is added to the patient's record.
  • If the patient answers "no" then no entry is added to the record (see notes on alternatives in next column).

The simple approach suggested in the previous column does not explicitly record negative answers. However, in many cases, a negative response has its own significance and does need to be recorded.

  • For example, knowing that the patient responded "no" to the question "have you had any pain in the chest?".

Similarly, there may be questions that have 3 alternative answers (e.g. "yes", "no", "don't know"). In these cases, an approach is needed to distinguish between the available responses.

Note

Options for representing answers such as "yes", "no" and "don't know" include:

  1. A postcoordinated expression using the SNOMED CT situation with explicit context model1 with the symptom represented as the 246090004 | Associated finding| and the answers represented as values of the 408729009 | finding context| attribute (e.g "yes" = 410515003 known present, "no" = 410516002 known absent, and "don't know" = 261665006 unknown.
  2. A simplified representation of the situation model in which only the finding context values are recorded - e.g. "yes" = 410515003 known present, "no" = 410516002 known absent, and "don't know" = 261665006 unknown.
  3. A simplified representation of the situation model in which the associated finding is used for "yes" and the finding context is used for "no" and "don't know". For example, "Yes" = 162397003 | sore throat| , "no" = 410516002 known absent and "don't know" = 261665006 unknown.

Terminology Binding

Table 3.2.1-1 highlights the significance of the relationship between the SNOMED CT terminology and EHR structured data and data entry contexts. Formal representations of these relationships are referred to as terminology bindings. 

  • A terminology binding is a link between a terminology component and an information model artifact.

There are two distinct types of terminology binding:

  • A value set binding is a terminology binding that represents the set of permitted values that can be used to populate a coded data item.

    • This type of binding is used to represent search constraints applicable to a particular data entry context.
  • A meaning binding is a terminology binding that represents the clinical meaning of a data item or collection of data items.

    • This type of binding is used to represent aspects of the meaning of the entered data that are derived from the data entry context.

Footnotes
For further information on the situation with explicit context model please refer to Situation with Explicit Context Modeling.
See 3.2.2 EHR Data Entry Design for notes on terminology service requirements for creating data entry templates with bindings to SNOMED CT.

Feedback
  • No labels