Support EHR Data Entry

An electronic health record (EHR) that represents clinical information using SNOMED CT must support efficient entry of data accurately coded as SNOMED CT concepts and/or expressions. Data entry approaches need to be tailored to fit the needs of different healthcare professionals in a variety of clinical situations. However, the end results of different data entry techniques must be record entries that are consistent and comparable. The following sections outline the ways in which terminology services can be used to support the design and application of effective data entry techniques.

EHR Data Entry Overview

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

• Optimizing Searches - describes effective ways to optimize SNOMED CT searches.

• Optimize Display of Search Results- provides guidance on ordering and structuring lists of search results.

• EHR Data Entry Overview - describes a range of techniques that facilitate the effective recording of SNOMED CT concepts or expressions in health records.

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.

   1. The table below 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.

   1. The table below 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.

Examples

Initial Diagnosis on an Encounter or Admission Form

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| .

Field	Content
Constraints on Values	A concept recorded in this data entry context should be a subtype of `64572001
Interpretation of Recorded Data	The fact that this is an "Initial diagnosis" context must be captured to ensure accurate interpretation.

Subsequent investigations may refute the initial diagnosis, so it should not be assumed the patient had the condition.

However, it may still be relevant: • As rationale for initial treatment and investigation • For audit, administration, and research purposes

Surgical History as Part of Past Medical History

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

• Using the concept 428251008 | history of appendectomy| ; or

• Using the concept 80146002 | appendectomy| with an indication that this was reported by the patient as having been done in the past.

Field	Content
Constraints on Values	A concept recorded in this data entry context could either be: A subtype of 161615003 | History of surgery (situation)| ; or, A subtype of 387713003 | Surgical procedure (procedure)| with an indication that this is past history.
Interpretation of Recorded Data	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.

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 Checklist with Yes or No Options

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).

Field	Content
Constraints on Values	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.
Interpretation of Recorded Data	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.

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 model¹ 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.

EHR Data Entry Design

This section identifies terminology services required to support the design of data entry forms and templates that incorporate terminology bindings. The objective of these templates is to facilitate the entry of appropriate concepts (or expressions) into electronic health records.

As noted in the previous section, there are a variety of different EHR data entry contexts and each context logically constrains the range of concepts that can be used. This logical constraint can be formally specified using a value set binding represented as an expression constraint. Similarly, the data entry context may affect the meaning of data entered and this can be formally specified using a meaning binding represented by an expression or expression constraint.

A well designed template can simplify data entry and improve data quality by limiting the range of concepts available to those appropriate to a particular data entry context. The table below provides examples of some practical uses of templates with terminology bindings.

Data entry templates can also be used to combine and structure related data items, or to enable addition of refinements a selected concept. Different requirements can be met by a common template structure with different terminology bindings. In other cases, a more complex template may be required containing a collection of data items with different value set bindings. Similarly, a meaning binding may be applied to an individual template or to a collection of templates that share a similar interpretation (e.g. past medical history entries). Terminology bound templates that are designed to meet the needs of different data entry contexts can be combined into a more complex template that supports a complete data entry scenario.

Practical Uses of Terminology Binding in a Data Entry Template

The following table shows a summary of the terminology services required to enable terminology bindings to be created and edited when developing user interface templates for health record data entry.

Practical Use	Examples
To specify a concept or expression to that is added to the record entry when a particular data entry option is selected	To specify that the concept 195967001 | asthma| should be added to record entry when an item in a check list of medical conditions is marked as true.
To constrain the range of concepts that can be entered into a specific data entry field	To limit the range of concepts that can be entered in "surgical procedure" field to: Subtypes of 387713003 | Surgical procedure| ; or Members of a locally defined reference set containing surgical procedures carried out in particular department. To specify the concepts to be displayed in a short drop-down list from which an item may be selected.
To support the structured entry of specific refinements relevant to a selected concept	To specify a template that includes questions about general findings followed by prompts for the site of the finding and/or other features. The template also specifies how the refinement should be represented. Options include: A record containing several named data items { symptom: 10601006 | Pain| location: 85151006 | left hand| } ; or An expression such as: 10601006 | Pain| :{ 363698007 | Finding site| = 85151006 | left hand| }
To support the entry of any refinement permitted by the concept model (or a constrained version of the concept model)	To specify a template that allows a clinical finding to be refined using any attributes that are valid in the clinical finding concept model. The refined concept would be represented as an expression.

Services Required for EHR User Interface Template Editing

Practical Requirement	Status	Required Terminology Services	Dependencies
Select the SNOMED CT edition and version to be used.	REQUIRED	Select Edition and Version	N/A
Create or edit a user interface template or control that records specific concepts in EHR depending on user selections	REQUIRED	Find Concepts	N/A
Create or edit a user interface template including expression constraints that limit permitted values that can be entered through a specific data entry control	REQUIRED	Validate and Apply Expression Constraints	N/A
Create or edit a user interface template or control that records a specific expression in an EHR depending on user selections (in cases where no specific concept matches the required meaning)	OPTIONAL	Validate Concept Definitions and Expressions	N/A
Get attributes that can be applied to an identified concept	OPTIONAL	Get Concept Model Rules	N/A
Get the range of values that can be applied to an identified attribute	OPTIONAL	Get Concept Model Rules	N/A

EHR Data Entry

This section identifies the terminology services required to support practical entry of EHR data containing SNOMED CT concepts and expressions. It assumes that templates with appropriate terminology bindings have been created and applied using data entry design techniques identified in the section on EHR Data Entry Design.

The following table shows a summary of the terminology services required to support the most common types of EHR Data Entry. These service requirements are also sufficient to entry of postcoordinated expressions provided that these expressions are created using a specific predefined template.

Terminology Services Required for EHR Data Entry

Practical Requirement	Status	Required Services	Dependencies
Select the SNOMED CT edition and version to be used for data entry.	REQUIRED	Select Edition and Version	N/A
Enable a concept, and where appropriate an associated term, to be recorded in response to the selection of a particular user interface option.	REQUIRED	Get a Concept, Description or Relationship Get Terms for a Concept	N/A
Display appropriate terms in search results, user interface lists, checkboxes, radio buttons and any other user interface controls in which options are represented by concept identifiers.	REQUIRED	Get Terms for a Concept	N/A
Enable term searches to be constrained by value set bindings specified for each data entry field.	REQUIRED	Find Concepts
Enable term searches to be constrained by simple constraints specified by the user to narrow a search.	OPTIONAL	Find Concepts
Enable searches for attribute refinements to be automatically constrained by the appropriate concept model range constraint.	OPTIONAL	Get Definition of a Concept Find Concepts Get Concept Model Rules Get the range of values applicable to a specified attribute
Enable the display of the definition of a selected concept.	OPTIONAL	Get Definition of a Concept	N/A
Enable the display of supertype parents and subtype children of selected items in a search result list.	OPTIONAL	Get and Test Concept Subtypes and Supertypes Get supertype parents of a concept Get subtype children of a concept	N/A
Enable the validation of a generated postcoordinated expression prior to adding it to a record entry.	OPTIONAL	Validate Concept Definitions and Expressions Validate expression	N/A

Data entry methods that generate adhoc postcoordinated expressions, without a specific predefined template, have additional requirements for access to the concept definitions and the concept model rules. For example, a user interface control could be designed to respond to the selection of a SNOMED CT concept by displaying options that allow a user to select one or more attributes applicable to the concept's domain. The user could then be prompted for values for each selected attribute allowing them to refine the meaning of the selected concept. Another technique involves natural language processing (NLP) identifying the primary focus concept and any relevant refinements stated in a passage of .

Additional terminology service requirements for these techniques are summarized in the following table, and documented in the postcoordination guide.

Additional Terminology Services Required for Ad hoc Postcoordinated Data Entry

Practical Requirement	Status (for adhoc postcoordination)	Required Services	Dependencies
Enable access to the definition of a selected concept.	REQUIRED	Get Definition of a Concept	N/A
Enable the identification of attributes that can be applied to a selected concept.	REQUIRED	Get Concept Model Rules Get the set of attribute rules applicable to an identified concept	N/A
Enable the identification of the range of values that can be applied to a selected attribute.	REQUIRED	Get Definition of a Concept Get Concept Model Rules Get the range of values applicable to a specified attribute	N/A
Enable the validation of a generated postcoordinated expression prior to adding it to a record entry.	OPTIONAL	Validate Concept Definitions and Expressions Validate expression	N/A