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.
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.
Readers of this section of the guide are advised to read the following sections of the SNOMED CT Search and Data Entry Guide
- describes effective ways to optimize SNOMED CT searches.
- provides guidance on ordering and structuring lists of search results.
- describes a range of techniques that facilitate the effective recording of SNOMED CT concepts or expressions in health records.
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.
The range of concepts that can rationally be entered is determined by the data entry context.
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.
The interpretation of concepts or other data entered may be affected by the data entry context.
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 and may show that at the top of a search list. The problem is that this term is a synonym for the . 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 avoids this error and results a shorter, more appropriate list including concepts such as .
Surgical History as Part of Past Medical History
A past history of an appendectomy could be recorded in different ways including:
Using the concept ; or
Using the concept with an indication that this was reported by the patient as having been done in the past.
Symptom Checklist with Yes or No Options
A question about whether a patient has a sore throat would be linked to the concept .
If the patient answers "yes" then 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).
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.
Services Required for EHR User Interface Template Editing
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.
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.
Additional terminology service requirements for these techniques are summarized in the following table, and documented in the .
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 .
REQUIRED
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
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
N/A
Get attributes that can be applied to an identified concept
OPTIONAL
N/A
Get the range of values that can be applied to an identified attribute
OPTIONAL
N/A
REQUIRED
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
N/A
Enable term searches to be constrained by value set bindings specified for each data entry field.
REQUIRED
Details*
Enable term searches to be constrained by simple constraints specified by the user to narrow a search.
OPTIONAL
Details*
Enable searches for attribute refinements to be automatically constrained by the appropriate concept model range constraint.
OPTIONAL
Get the range of values applicable to a specified attribute
Details*
Enable the display of the definition of a selected concept.
OPTIONAL
N/A
Enable the display of supertype parents and subtype children of selected items in a search result list.
OPTIONAL
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 expression
N/A
REQUIRED
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 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 expression
N/A
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.
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.
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.
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
Select the SNOMED CT edition and version to be used.
REQUIRED
N/A
Select the SNOMED CT edition and version to be used for data entry.
REQUIRED
N/A
Enable access to the definition of a selected concept.
REQUIRED
N/A
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: location: } ; or
Create or edit a user interface template or control that records specific concepts in EHR depending on user selections
Enable a concept, and where appropriate an associated term, to be recorded in response to the selection of a particular user interface option.
Enable the identification of attributes that can be applied to a selected concept.
An such as: :{ = }