Data entry is the process by which a user submits information containing relevant SNOMED CT Concept identifiers for storage in a record system (e.g. an EHR system).

The way data entry is carried out depends on the setting in which it is performed. In one simple approach a user selects a term from a list of search results, confirms the selection and the Identifier or Description of the selected Concept is added to the relevant field in a database record. This guide considers a range of different modes of data entry which can make it quicker and easier to record different types of information in particular situations.

The focus of this section is on the non-search aspect of data entry but it is also important to recognize that this is usually only one part of the process of recording clinical information. Therefore, the way SNOMED CT data entry is integrated with the overall process of data capture also needs to be considered.

• Benefits of Using SNOMED CT for Data Entry

Here are some of the benefits of using SNOMED CT for data entry.

Specificity and Generalization

SNOMED CT hierarchies are subtype hierarchies (made up of 'is a' relationships) that allow for clinical information to be entered at a level of detail sufficient for the specific clinical situation or possible at the given point in time.

For example, it is possible to specify a clinical finding at very high level of detail, which is relevant and important for clinical treatment. The 'is a' relationships allow for SNOMED CT hierarchies to be automatically traversed, and to enable terminological reasoning of common sub- and supertypes. This means that Concepts can be automatically aggregated into more general types, which is useful for management purposes and for statistics.

Example:

Traversing the supertype hierarchies of the two concepts | actinomycotic pneumonia | and | congenital staphylococcal pneumonia | will show that both Concepts are types of | bacterial pneumonia |.

Clinical Language and Coding

The unique Concept identifiers of SNOMED CT Concepts are numeric identifiers and do not contain information related to the meaning of a Concept or Description. This means it is not possible to infer anything about the meaning of a Concept from the numeric value of the Identifier or from the sequence of digits that form the identifier.

The meaning of a Concept can be determined from relationships to other Concepts and from associated Descriptions that include human readable terms. In the context of data entry, this means that entering SNOMED CT Concepts must be done by using associated Concept Descriptions, and hence by use of the clinical spoken language instead of using the Concept codes for data entry.

Additionally, SNOMED CT allows for coding different Descriptions that belong to the same Concepts. This support flexible data entry, by enabling the possible to use the Descriptions preferred in a specific organization or within a specific user group.

Use of SNOMED CT for data entry has implications for how clinical data can be used and retrieved. The SNOMED CT relationships support meaning-based retrieval of clinical data, which can be useful for creating specific clinical overviews or for aggregating data with specific characteristics (meaning).

The figure below shows some of the defined relationships that are included in SNOMED CT to define the two Concepts | actinomycotic pneumonia | and | congenital staphylococcal pneumonia |. The Concepts have different causative agents; however the associated morphology and the finding site of the findings are equivalent. This means, that both Concepts would be part of a result of queries that retrieve clinical findings with the finding site | lung parenchyma | and the associated morphology | inflammation and consolidation |.

Such types of meaning-based queries are possible to develop because of the integrated clinical meaning which is made explicit by the defined relationships. Terminological reasoning therefore makes it possible to develop queries that retrieve all Concepts with a specific meaning. In many cases this approach is much more effective and efficient than manually specifying which Concepts to retrieve based on the unique Concept Id's.

SNOMED CT can support consistent data entry. The unique Concept Identifiers support unambiguous representation of the clinical content applied in Clinical Information Systems.

However, the flexibility of SNOMED CT allows entering expressions in various ways which may hamper consistency and retrieval. Structured data entry mechanisms such as, having a pre-defined set of Concepts for a specific clinical data entry field in a form can constrain the number of Concepts visible to documenting clinicians and enhance consistent use of SNOMED CT Concepts. [see ]

Therefore it is important that each SNOMED CT-implementation includes strategies for how to balance the flexibility of SNOMED CT when entering data into the clinical record.

Constraining searches refers to disabling Concepts or Descriptions in searches and navigation or allowing these search and navigation results to be filtered. [See Constrained Searches] However, some Concepts and Descriptions that are suitable to be displayed as search results or navigation results, may not be suitable for recording in a patient record once search constraints have been applied. Constraining data entry refers to applying constraints so that only Concepts and Descriptions suitable for recording are selectable.

Constraining Data Entry Based on Context

All fields (data elements) used for data entry must be analyzed to understand what underlying context is implied. The appropriate Concepts should then be selected for the value set of each field. Concepts from the Clinical Findings, Procedures, and Observable entities hierarchies can be used directly if the default assumptions are true. Otherwise, Concepts from the Context Dependent hierarchy should be selected to explicitly code the underlying context of the clinical idea.

Particular care must be taken with systems that enable real time post-coordinated constructs to ensure that the appropriate context attributes are included.

To pre-coordinate Concepts that do not already exist in SNOMED CT, care must also be taken to determine if any axis modification is shifting the meaning of a Concept. If so, it should be moved to the Situation with explicit context hierarchy.

Constrain Data Entry by Concept Description Status

Constraining data entry by Concept Status and Description Status should be done in order to avoid recording Concepts and Descriptions which for some reason have been inactivated. Inactive Concepts or Descriptions have been assessed to be unsuitable for recording. Therefore they should not be included as a possible result of a search, which would make them candidates for clinical recording.

Constraining data entry according to supertype relevance is a technique that can support data entry, in which only particular sub-hierarchies that include Concepts relevant for the specific data entry point can be browsed or displayed.

If a pick list in a data entry template should allow the selection, a specific "cardiopulmonary bypass operation", the SNOMED CT subtype hierarchy to specify what Concepts are to be included in the list, namely the descendants of the Concept "63697000 | cardiopulmonary bypass operation | ". Constraining data entry according to subtype relevance can be done using the transitive closure table, as shown in the figure below. The transitive closure table contains relationships to all supertypes ancestors of each defined Concept. A query for the set of Concepts, where the Concept "63697000 | cardiopulmonary bypass operation | "(shown as Concept B in the image below) is a supertype, will produce the constrained set of Concepts relevant for creating specific pick lists.

Identifying selected portions of the SNOMED CT hierarchy may not be a sufficient constraint for entering data into a record. Constraining data entry through the use of Reference Sets may be more sufficient for producing the required set of Concepts relevant for data entry. [see ].

In some cases, identifying selected portions of the SNOMED CT hierarchy may be a sufficient constraint for entering data into a record. However, it is not always sufficient if Concepts from multiple hierarchies are required, or if there is a need to hone the entry options from the full hierarchy. To meet these requirements applications should allow data entry to be constrained by Reference Sets.

Applications should be able to:

• Permit or prevent the entry of Concepts or Descriptions that are members of a specified Simple Reference Set.

• Permit entry of Concepts or Descriptions that are ordered in priority using the Ordered Reference Set.

A UK GP practice implemented a clinical application with a data entry mechanism that:

• Prevents the entry of Concepts in a Simple Reference Set that contains all Concepts that are in the Non-Human Simple Reference Set so human Concepts can only be entered and stored in the clinical record;

• Enables the entry of Concepts in the "UK Administrative Reference Set" only when entering information in an administrative context.

• Enables the entry of Concepts in search results that is prioritized according to the order of disease prevalence using an Ordered Reference Set. Descriptions of Concepts associated with high disease prevalence are displayed before those with lower priority.

A specialty system might prompt for confirmation when the user records a procedure not in a specified specialty Simple Reference Set.

Structured data entry can be applied to support effective data entry and ensure consistent use of Concepts. When using structured data entry methods, SNOMED CT encoded data can be selected in a variety of ways. Some of these involve direct selection of terms while other ways involve encoding which may result from responses to simple choices or entry of particular data values. The sub-section below shows requirements for structured data entry and examples of mechanisms for data entry.

Requirements for Structured Data Entry

Data entry needs to be easy in terms both of the time and effort required to record the information needed, but also easy in the way it fits in with working practices.

User interfaces should make it easy to enter data that includes SNOMED CT where this is required to enable effective retrieval and reuse. Hence, data capture is only worthwhile if the data captured can be usefully reused, and therefore data capture needs to be designed to meet requirements for subsequent retrieval.

SNOMED CT encoded data should be rendered in ways that are easily read and understood as part of the clinical record. Approaches to data entry therefore need to be tailored to the way different groups of clinicians work and think. On the one hand, the application of SNOMED CT must be done by a common approach across the various user interfaces to support consistency. On the other hand, the system should not be designed as one size fits all, as this will decrease the applicability of the system. SNOMED CT supports flexible and user-oriented data entry mechanisms, allowing for detailed and very specific data entry as well as bridging different levels of granularities applicable for retrieval of common patterns.

Applying SNOMED CT in EHR has implications for how data can be utilized for effective clinical documentation, enhanced retrieval and decision support functionalities. To support effective display and analysis of SNOMED CT coded data, questions about an individual patient or a selected population must have answers that are:

• Accurate – no false negatives

• Precise – no false positives

• Timely – available when needed

• Efficient – without disproportionate cost, time and effort

To meet the above requirements, collected data must be stored in a consistent form that enables reliable retrieval.

The way information is captured in the clinical record can differ between systems. The choice of Concepts and their representation in the record has implication for interpretation and retrieval.

Requirements for data retrieval are an important determinant of requirements for data content and representation, and the following two overall guidelines can be used to govern the Concept selection and representation:

• To support effective reuse a health record must make it possible to answer relevant questions accurately and efficiently;

• To answer relevant questions information must be selectively retrieved so it can be displayed or analysed.

As the following examples illustrate, the same information (clinical meaning) may be captured in different ways. If information is represented according to the way it is captured it may be difficult to answer simple questions.

A question such as 'does the patient have a family history of diabetes mellitus?' can expand to:

1. Do they have a family history form in which 'diabetes mellitus' is checked as present?

2. Do they have a family history record in which the code for 'FH diabetes mellitus' is present?

3. Do they have text that is tagged with the code for 'diabetes mellitus' in the context of a section of text tagged as 'family history'?

4. … n. There are also many other possible data capture representations to consider

Concepts in SNOMED CT carry a "soft-default" context, which means that, unless stated otherwise within the Description or the definition of the Concept, the term should be interpreted as follows:

For a clinical finding that:

• The finding has actually occurred (vs. being absent or not found).

• It is occurring to the subject of the record (the patient).

• It is occurring currently or at a stated past time.

For a procedure that:

• The procedure was completed.

• It was performed on the subject of the record (the patient).

• It was done in the present time or at a stated past time.

The only exceptions are Concepts whose Description actually contains a specific context (e.g. father smokes), and these are all grouped in a special hierarchy (situation with explicit context).

When recording in the patient record, post-coordinated expressions or free text should only be used to add additional detail to the coded item. They should never negate or modify the meaning of the coded item as this would fundamentally changes its meaning.

For example, free text phrases such as 'family history of', 'absent', 'not found' should not be applied to SNOMED CT coded data.

The illustrations below shows a template designed for the purpose of documenting diseases that occur in the patients familiy history.

The first template below shows a heading that specifies the context of the template, namely documentation of 'family history', whereas the checkboxes allow for specifying the family history of the disease. The direct (lexical) map between the interface term "Diabetes Mellitus" without considering the actual context will be the clinical finding Concept | Diabetes Mellitus (Disorder) |.

However, the appropriate Concept for data entry is the situation Concept | family history : Diabetes mellitus (situation) | based on the meaning of the interface term.

The form below shows a patient note with check boxes to enter diseases that occur in the patient's family history. Here, there is a direct (lexical) map between the interface term "family history : Diabetes mellitus" and the meaning of the interface term, | family history : Diabetes mellitus (situation) |.

It is therefore a requirement that careful thought be given about the actual meaning of each entry when selecting Concepts to represent a data entry, regardless of the specificity (or correctness) of the interface term.

The example below shows another typical way of documenting occurences or negations of specific findings. The interface terms 'yes' and 'no' can be mapped to the qualifier values | yes (qualifier value) | and | no (qualifier value) |. However, these Concepts are meaningsless without knowing the finding or situation to which they relate. The appropiate mapping for these entries would therefore be expressions that specify the presence or absence of the actual finding, situation, etc. In this example the Concepts that represent respectively 'Yes' and 'No' would be the situations | no family history diabetes (situation) | and | family history: Diabetes mellitus (situation) |.

User selects from a small list of possible Descriptions applicable to a particular field in a template or step in a protocol. A Simple Reference Set with corresponding Descriptions from a particular Language Reference Set may specify the set of applicable Descriptions.

See section , for further information about effective search techniques.

When a value is entered in this control it is labeled with the appropriate Concept Identifier and added to the record.

When selections are made using this control the appropriate Concept identifier is added to the record.

When specific values are entered the appropriate (defined) Concept identifier is added to the record. The above examples show how specific numeric values can lead to specific clinical findings, based on pre-defined rules.

The example below, illustrates that the BMI can be automatically calculated by the entered values for body weight and height. Moreover, it is possible to develop rule-based coding (i.e. algorithms that assign BMI values between 20 and 24 to the SNOMED CT Concept 35425004 | normal body mass index |, or to a more specific Concept 412768003 | body mass index 20-24 - normal |.

SNOMED CT contains Concepts that allow many clinical ideas to be represented by a single Concept identifier. However, SNOMED CT also allows more specific ideas to be represented even when they cannot be expressed by a single Concept. This is achieved by adding refinements to a selected Concept creating a post-coordinated expression containing several Concept Identifiers .

Several types of post-coordinated data are outlined in this section from the perspective of data entry. These include refinement, qualification and combination. The requirements for and relevance of each of these will depend on decisions about data representation within patient records.

Entry of Refined Defining Characteristics

The application may allow a user to refine a Concept by selecting a subtype of one of its defining characteristics. A defining characteristic is a relationship to a target Concept that is always necessarily true from any instance of the source Concept.

Refinement options may be entered by selecting from hierarchical lists showing subtype values. Simple lists or option buttons could support selection from limited sets of possible refinements. Wider ranges of possible refinement could be facilitated by text searches constrained to subtypes of one or more of the refineable characteristics.

Example:

One of the defining characteristics the Concept | total replacement of hip | is | using | = | hip prosthesis |. The Concept | total replacement of hip | could be refined by allowing the user to specify one of the subtypes of "hip prosthesis."

The application should also allow a user to refine the meaning of a selected Concept by selecting and applying a value to one of the attributes applicable to that type of concept. The set of permitted attributes is defined by the SNOMED CT concept model. The concept model also defines the range of values that can be applied to sanctioned attributes

For a clinical finding such as | otitis media | it is possible to specify different values, for the following attributes | severities |, | episodicities | and | courses |.

The illustration below show how a user interface can support entry of qualifier values, and how the selection can be represented by a single SNOMED CT expression.

Qualifiers must only be used where the result of applying them results in a true subtype of the original Concept. Therefore, qualifiers should not be used for the purposes listed in the table below. These and similar major modifications need to be handled in ways that are explicit and ensure that queries and decision support protocols are able to accurately retrieve and analyze the available information.

Deprecated Uses of Qualifiers

Combinations of Concepts in a single expression for data entry may be required in cases where a Concept that represents the full scope of an activity is not available. Facilities for combining Concepts in an expression should be implemented and used with care.

It is appropriate to use these facilities when the combined result is conceived as a single statement that could potentially be used in many different patient records. For example, a diagnosis of "gallstones with cholecystitis" could be entered by selecting the 235919008 | gallstone (disorder) | and then selecting 76581006 | cholecystitis (disorder) | and combining these in a single statement.

It is not appropriate to use these constructs to attempt to express an entire encounter, episode or clinical history in a single statement. For example, if a patient is treated for "gallstones with cholecystitis" diagnosed by "ultrasonography of biliary tract" with a course of | amoxycillin | followed after the acute phase has resolved by a | cholecystectomy |, this should not be entered as a single complex post-coordinated statement combining the diagnosis, investigation and treatments