- Introduces the terminology service requirements related to EHR data entry by outlining the rationale for the following sections on data entry design and practical data entry.
|
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 
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 
and the reason for that encounter. A typical data entry scenario involves recording data in different data entry contexts.
Data entry design needs to take account of data entry context for two reasons.
- The range of
that can rationally be entered is determined by the data entry context.
illustrates this point with examples of three data entry contexts. In each of these contexts, there are constraints on the range of 
.
- The interpretation of or other data entered may be affected by the data entry context.
- 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 dat.
Data Entry Context Examples |
| Data Entry Context | Constraints on Values | Interpretation of Recorded Data |
| Initial diagnosis on an encounter or admission form | A concept recorded in this data entry context should be a subtype of  . 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  . |
| The fact that this is an "Initial diagnosis" data entry context needs to be captured so that the record can be appropriately interpreted. 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: - A subtype of
 ; or - A subtype of
 with an indication that this is past history.
A past history of an appendectomy could be recorded in different ways including: - Using the concept
 ; or - Using the concept
 witndicaat this was reported by the patient as having been done in the past.
|
| 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 formally represent the past history context by including the attribute  . If subtypes of e 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 | question should be bound to a concept that represents the relevant symptom. These concepts should be subtypes of  . 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. 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).
|
| 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.
|
highlights the significance of the relationship between the SNOMED CT terminology and data and data entry contexts. Formal representations of these relationships are referre 
.
There are two distinct types of terminology binding:
- This type of binding is used to represent search constraints applicable to a particular data entry context.
- This type of binding is used to represent aspects of the meaning of the entered data that are derived from the data entry context.