Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

Some Concepts or Descriptions displayed by searches, hierarchical navigation or other methods of data entry may not be suitable for recording in a patient record. Various reasons for this are discussed in the following sections. They include:

Excluding inactive concept and descriptions

In Release Format 2 the value of the active field determines whether a concept or description is intended for active use. Inactive Concepts should not be added to a record. Similarly, terms associated with Inactive Descriptions or any descriptions applied to an Inactive Concepts not be added to a record.

Excluding Special Concepts and Model Components

Concepts that are subtypes of the top-level Concept 370115009 |Special concept| ( RF1) or 900000000000441003 |SNOMED CT Model Component| ( RF2) are rarely if ever required in clinical end-user searches. Therefore, they should be excluded from text searches except where explicitly needed to meet a particular requirement (e.g. to display a 370136006 |Namespace concept|, a 106237007 |Linkage concept| or a 363743006 |Navigational concept| ).

Constraining data entry according to subtype relevance

It may be necessary to prevent entry of a Concept in a subtype hierarchy that is inappropriate to a particular data entry field or to a particular part of a patient record. For example:

  • An application should not allow a disorder Concept to be recorded in a field intended for recording a procedure (or vice-versa);
  • An application should not allow a Concept that is a subtype descendant of the top-level Concept "attribute" to be recorded, except to associate another Concept with an appropriate qualifying value;
  • An application should not allow a Concept that is a subtype descendant of the top-level Concept " qualifier value" to be recorded, except where it qualifies an appropriate attribute Concept .

Constraining data entry using Reference Sets

In some cases, identifying selected portions of the SNOMED CT hierarchy may be a sufficient constraint for entering data into a record. However, that is not always sufficient if Concepts from multiple hierarchies are required, or if there is a need to hone down 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:

Example:

A UK GP system might:

Example:

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

Constraining data entry based on mappability

One of the requirements for some applications may be that the data recorded in particular fields has to be mapped to a particular classification or grouping scheme.

One way to simplify this process is for the application to check mappability at the time of data entry. If a selected Concept has no unambiguous map, the application may encourage or compel the user to refine their selection until a mappable Concept has been selected.

This type of facility should not be applied in situations where it may inappropriately affect the perceived accuracy or detail of a clinical record.

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 Concept -Dependent hierarchy should be selected.

Particular care must be taken with systems that enable postcoordinated constructs to ensure that the appropriate context attributes are included.

To precoordinate 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 so it should move to the Situation with explicit context hierarchy .

Absolute and configurable constraints

Some of the constraints on data entry discussed in the preceding sections are absolute while others should be configurable.

Constraints based on subtype hierarchies, Subsets and other Reference Sets including maps to other terminologies or code systems should usually be configurable to particular institutions, users and/or data entry fields.


Feedback