# 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](https://app.gitbook.com/o/h8Z6qGxuQrzM9vbx5bPT/s/CEAcChvWjWEu16YmwNrz/ "mention")

* [Optimizing Searches](https://app.gitbook.com/s/CEAcChvWjWEu16YmwNrz/4-optimizing-searches "mention") - describes effective ways to optimize SNOMED CT searches.
* [Optimize Display of Search Results](https://app.gitbook.com/s/CEAcChvWjWEu16YmwNrz/5-optimize-display-of-search-results "mention")- provides guidance on ordering and structuring lists of search results.
* [#ehr-data-entry-overview](#ehr-data-entry-overview "mention") - 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|](http://snomed.info/id/53041004) 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)|](http://snomed.info/id/53041004) . 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)|](http://snomed.info/id/64572001) avoids this error and results a shorter, more appropriate list including concepts such as [25702006 | Alcohol intoxication|](http://snomed.info/id/25702006) .

<table><thead><tr><th width="296.07421875">Field</th><th>Content</th></tr></thead><tbody><tr><td><strong>Constraints on Values</strong></td><td>A concept recorded in this data entry context should be a subtype of `64572001</td></tr><tr><td><strong>Interpretation of Recorded Data</strong></td><td>The fact that this is an <strong>"Initial diagnosis"</strong> context must be captured to ensure accurate interpretation.</td></tr></tbody></table>

{% hint style="info" %}
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
{% endhint %}

> #### 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|](http://snomed.info/id/428251008) ; or
> * Using the concept [80146002 | appendectomy|](http://snomed.info/id/80146002) with an indication that this was reported by the patient as having been done in the past.

<table><thead><tr><th width="271.04296875">Field</th><th>Content</th></tr></thead><tbody><tr><td><strong>Constraints on Values</strong></td><td><p>A concept recorded in this data entry context could either be:</p><ul><li>A subtype of <a href="http://snomed.info/id/161615003">161615003 | History of surgery (situation)|</a> ; or,</li><li>A subtype of <a href="http://snomed.info/id/387713003">387713003 | Surgical procedure (procedure)|</a> with an indication that this is past history.</li></ul></td></tr><tr><td><strong>Interpretation of Recorded Data</strong></td><td>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.</td></tr></tbody></table>

{% hint style="info" %}
The definitions of concepts that are subtypes of [161615003 | History of surgery (situation)|](http://snomed.info/id/161615003) formally represent the past history context by including the attribute [408731000 | Temporal context|](http://snomed.info/id/408731000) = [410513005 | In the past|](http://snomed.info/id/410513005) . If subtypes of [387713003 | Surgical procedure (procedure)|](http://snomed.info/id/387713003) 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.
{% endhint %}

> #### 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|](http://snomed.info/id/162397003) .
>
> * If the patient answers "yes" then [162397003 | sore throat|](http://snomed.info/id/162397003) 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).

<table><thead><tr><th width="201.6171875">Field</th><th>Content</th></tr></thead><tbody><tr><td><strong>Constraints on Values</strong></td><td><p>Each question should be bound to a concept that represents the relevant symptom. These concepts should be subtypes of <a href="http://snomed.info/id/404684003">404684003 | Clinical finding|</a> .</p><p>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.</p></td></tr><tr><td><strong>Interpretation of Recorded Data</strong></td><td><p>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.</p><ul><li>For example, knowing that the patient responded "no" to the question "have you had any pain in the chest?".</li></ul><p>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.</p></td></tr></tbody></table>

{% hint style="info" %}
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[<sup>1</sup>](https://confluence.ihtsdotools.org/display/DOCTSG/3.2.1+EHR+Data+Entry+Overview#footnotes) with the symptom represented as the [246090004 | Associated finding|](http://snomed.info/id/246090004) and the answers represented as values of the [408729009 | finding context|](http://snomed.info/id/408729009) attribute (e.g "yes" = [410515003 known present](https://confluence.ihtsdotools.org/display/DOCGLOSS/410515003+known+present), "no" = [410516002 known absent](https://confluence.ihtsdotools.org/display/DOCGLOSS/410516002+known+absent), and "don't know" = [261665006 unknown](https://confluence.ihtsdotools.org/display/DOCGLOSS/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](https://confluence.ihtsdotools.org/display/DOCGLOSS/410515003+known+present), "no" = [410516002 known absent](https://confluence.ihtsdotools.org/display/DOCGLOSS/410516002+known+absent), and "don't know" = [261665006 unknown](https://confluence.ihtsdotools.org/display/DOCGLOSS/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|](http://snomed.info/id/162397003) , "no" = [410516002 known absent](https://confluence.ihtsdotools.org/display/DOCGLOSS/410516002+known+absent) and "don't know" = [261665006 unknown](https://confluence.ihtsdotools.org/display/DOCGLOSS/261665006+unknown).
{% endhint %}

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

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

**Services Required for EHR User Interface Template Editing**

<table data-full-width="true"><thead><tr><th width="391.30078125">Practical Requirement</th><th width="127.796875">Status</th><th width="286.7890625">Required Terminology Services</th><th>Dependencies</th></tr></thead><tbody><tr><td>Select the SNOMED CT edition and version to be used.</td><td>REQUIRED</td><td><a href="https://github.com/SNOMED-Documents/snomed-terminology-services-guide/blob/main/3-terminology-service-use-cases/4%20terminology-service-types/4.1-select-edition-and-version.md">Select Edition and Version</a></td><td>N/A</td></tr><tr><td>Create or edit a user interface template or control that records specific concepts in EHR depending on user selections</td><td>REQUIRED</td><td><a href="https://github.com/SNOMED-Documents/snomed-terminology-services-guide/blob/main/3-terminology-service-use-cases/4%20terminology-service-types/4.8-find-concepts.md">Find Concepts</a></td><td>N/A</td></tr><tr><td>Create or edit a user interface template including expression constraints that limit permitted values that can be entered through a specific data entry control</td><td>REQUIRED</td><td><a href="https://github.com/SNOMED-Documents/snomed-terminology-services-guide/blob/main/3-terminology-service-use-cases/4%20terminology-service-types/4.7-validate-and-apply-expression-constraints.md">Validate and Apply Expression Constraints</a></td><td>N/A</td></tr><tr><td>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)</td><td>OPTIONAL</td><td><a href="https://github.com/SNOMED-Documents/snomed-terminology-services-guide/blob/main/3-terminology-service-use-cases/4%20terminology-service-types/4.14-validate-concept-definitions-and-expressions.md">Validate Concept Definitions and Expressions</a></td><td>N/A</td></tr><tr><td>Get attributes that can be applied to an identified concept</td><td>OPTIONAL</td><td><a href="https://github.com/SNOMED-Documents/snomed-terminology-services-guide/blob/main/3-terminology-service-use-cases/4%20terminology-service-types/4.13-get-concept-model-rules.md">Get Concept Model Rules</a></td><td>N/A</td></tr><tr><td>Get the range of values that can be applied to an identified attribute</td><td>OPTIONAL</td><td><a href="https://github.com/SNOMED-Documents/snomed-terminology-services-guide/blob/main/3-terminology-service-use-cases/4%20terminology-service-types/4.13-get-concept-model-rules.md">Get Concept Model Rules</a></td><td>N/A</td></tr></tbody></table>

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

<table data-full-width="true"><thead><tr><th width="388.08203125">Practical Requirement</th><th width="122.74609375">Status</th><th width="264.65234375">Required Services</th><th>Dependencies</th></tr></thead><tbody><tr><td>Select the SNOMED CT edition and version to be used for data entry.</td><td>REQUIRED</td><td><a href="../4-terminology-service-types/4.1-select-edition-and-version">Select Edition and Version</a></td><td>N/A</td></tr><tr><td>Enable a concept, and where appropriate an associated term, to be recorded in response to the selection of a particular user interface option.</td><td>REQUIRED</td><td><p><a href="../4-terminology-service-types/4.2-get-a-concept-description-or-relationship">Get a Concept, Description or Relationship</a></p><p><a href="../4-terminology-service-types/4.3-get-terms-for-a-concept">Get Terms for a Concept</a></p></td><td>N/A</td></tr><tr><td>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.</td><td>REQUIRED</td><td><a href="../4-terminology-service-types/4.3-get-terms-for-a-concept">Get Terms for a Concept</a></td><td>N/A</td></tr><tr><td>Enable term searches to be constrained by value set bindings specified for each data entry field.</td><td>REQUIRED</td><td><a href="../4-terminology-service-types/4.8-find-concepts">Find Concepts</a></td><td><a data-footnote-ref href="#user-content-fn-1">Details*</a></td></tr><tr><td>Enable term searches to be constrained by simple constraints specified by the user to narrow a search.</td><td>OPTIONAL</td><td><a href="../4-terminology-service-types/4.8-find-concepts">Find Concepts</a></td><td><a data-footnote-ref href="#user-content-fn-1">Details*</a></td></tr><tr><td>Enable searches for attribute refinements to be automatically constrained by the appropriate concept model range constraint.</td><td>OPTIONAL</td><td><p><a href="../4-terminology-service-types/4.4-get-definition-of-a-concept">Get Definition of a Concept<br></a><a href="https://confluence.ihtsdotools.org/display/DOCTSG/4.8+Find+Concepts">Find Concepts<br></a><a href="../4-terminology-service-types/4.13-get-concept-model-rules">Get Concept Model Rules</a></p><ul><li>Get the range of values applicable to a specified attribute</li></ul></td><td><a data-footnote-ref href="#user-content-fn-1">Details*</a></td></tr><tr><td>Enable the display of the definition of a selected concept.</td><td>OPTIONAL</td><td><a href="../4-terminology-service-types/4.4-get-definition-of-a-concept">Get Definition of a Concept</a></td><td>N/A</td></tr><tr><td>Enable the display of supertype parents and subtype children of selected items in a search result list.</td><td>OPTIONAL</td><td><p><a href="../4-terminology-service-types/4.5-get-and-test-concept-subtypes-and-supertypes">Get and Test Concept Subtypes and Supertypes</a></p><ul><li>Get supertype parents of a concept</li><li>Get subtype children of a concept</li></ul></td><td>N/A</td></tr><tr><td>Enable the validation of a generated postcoordinated expression prior to adding it to a record entry.</td><td>OPTIONAL</td><td><p><a href="broken-reference">Validate Concept Definitions and Expressions</a></p><ul><li>Validate expression</li></ul></td><td>N/A</td></tr></tbody></table>

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 text[^2].&#x20;

Additional terminology service requirements for these techniques are summarized in the following table, and documented in the [postcoordination guide](https://app.gitbook.com/o/h8Z6qGxuQrzM9vbx5bPT/s/usjN9isxKh4cLDTFopLg/).

#### **Additional Terminology Services Required for Ad hoc Postcoordinated Data Entry**

<table data-full-width="true"><thead><tr><th width="295.57421875">Practical Requirement</th><th width="222.21875">Status (for adhoc postcoordination)</th><th width="313.79296875">Required Services</th><th>Dependencies</th></tr></thead><tbody><tr><td>Enable access to the definition of a selected concept.</td><td>REQUIRED</td><td><a href="../4-terminology-service-types/4.4-get-definition-of-a-concept">Get Definition of a Concept</a></td><td>N/A</td></tr><tr><td>Enable the identification of attributes that can be applied to a selected concept.</td><td>REQUIRED</td><td><p><a href="../4-terminology-service-types/4.13-get-concept-model-rules">Get Concept Model Rules</a></p><ul><li>Get the set of attribute rules applicable to an identified concept</li></ul></td><td>N/A</td></tr><tr><td>Enable the identification of the range of values that can be applied to a selected attribute.</td><td>REQUIRED</td><td><p><a href="../4-terminology-service-types/4.4-get-definition-of-a-concept">Get Definition of a Concept</a></p><p><a href="../4-terminology-service-types/4.13-get-concept-model-rules">Get Concept Model Rules</a></p><ul><li>Get the range of values applicable to a specified attribute</li></ul></td><td>N/A</td></tr><tr><td>Enable the validation of a generated postcoordinated expression prior to adding it to a record entry.</td><td>OPTIONAL</td><td><p><a href="broken-reference">Validate Concept Definitions and Expressions</a></p><ul><li>Validate expression</li></ul></td><td>N/A</td></tr></tbody></table>

[^1]: One or more of the following services may be required depending on the range of search constraint types supported

    [Get and Test Concept Subtypes and Supertypes](../4-terminology-service-types/4.5-get-and-test-concept-subtypes-and-supertypes)

    * Test subsumption between two concepts; and/or
    * Test a set of concepts for subsumption

    [Test Reference Set Membership\
    ](../4-terminology-service-types/4.6-get-and-test-reference-set-membership)[Apply Expression Constraints](../4-terminology-service-types/4.7-validate-and-apply-expression-constraints)

[^2]: [Natural language processing](https://confluence.ihtsdotools.org/display/DOCGLOSS/Natural+language+processing) services are distinct from terminology services are not documented in this guide.
