Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

A variety of contextual factors may affect the interpretation of statements. Contextual factors typically fall into the gray area between record structure and the semantic model. Some of these may have a profound impact on the meaning or interpretation of a statement.

This section divides this issue into four distinct categories:

  • Contextual information that is not represented by SNOMED CT
  • Structures that may be labeled using SNOMED CT
  • Status  term that have a profound effect on SNOMED CT encoded statements;
  • Context that can safely be represented using qualifiers

Contextual information that is not represented by SNOMED CT

Clinical statements that contain SNOMED CT Concept representations will be associated with some information which is not intended to be represented using SNOMED CT :

  • Dates, times of an activity of recording and activity;
  • Quantitative information including ranges and durations;
  • Identifiers or names of authors, providers of information or other parties involved in a recorded activity.

SNOMED CT is not intended to represent this information. Appropriate constructs in a standardized or proprietary record architecture should be used to relate this information to SNOMED CT encoded clinical statements.

Structures that may be labeled using SNOMED CT

Clinical statements may be contained within structures that represent collections of related information. According to the nature of these structures, SNOMED CT may be used to label them. However, care should be taken to ensure that any semantic implication from such a label is clearly specified.

Many labels (such as headings within a document) may be used only to organize information for a human reader. The existence of a label such as "plan" or "family history" (even if encoded using SNOMED CT ) may not necessarily affect the computer interpretation of the data within it.

Implementers should take extreme care to ensure that any semantic implication that a human reader may assume from such labels is stored on the system in a manner that allows safe interpretation. It is recommended that any apparent inherited semantic context should be represented explicitly at the individual statement level.

Examples

  1. If a data element "Family history" is used and the concept 73211009 |diabetes mellitus| is encoded under that heading, the statement stored in the record should encapsulate the full semantics (i.e. Family history+(Associated finding=Diabetes mellitus) using the SNOMED CT Concept Model.
  2. Links between statements such as a presumed causal association could be labelled with a  concept .
  3. Indication of types (rather than identities) of people of organizations as the source of recorded information (e.g. the patient themselves or a specified family member or carer).

Context and Axis Modifiers

Table 3.5-1: Examples of "axis modifiers" which may fundamentally alter the interpretation of information encoded using SNOMED CT

Modifier Examples Issue

Subject of information

Stating that a relative of the patient has a particular disease. This may be recorded to state either "family history" or a  48176007 |social context|.

If the family history condition is represented using a  SNOMED CT Concept representing the a disease then it must be distinguishable from a statement that patient has that disease.

Planning stages

Stating that a patient should have, has been referred for, or has declined to undergo a particular procedure.

Ensuring these are distinguishable from statements that a patient has had the stated procedure.

Negation and uncertainty

Stating that a diagnosis has been excluded or is unlikely.

Stating a possible diagnosis or a differential diagnosis list.

Ensuring these are distinguishable from statements that a patient has been diagnosed as having that condition.

Contraindications

For example, using a  SNOMED CT Concept to refer to a condition that contraindicates as particular treatment.

Ensuring these are distinguishable from statements that a patient has been diagnosed as having that condition.

There is a temptation to treat modifications such as those shown in Table 3.5-1 as though they were qualifiers. This is not a safe practice because the assumption is that a qualifier refines the meaning of the qualified Concept. A refined Concept should always be a subtype of the original concept . This is not the case for these major modifications as illustrated by the following:

  • Records of a 57177007 |family history of| + 73211009 |Diabetes mellitus| would not be expected in a response to a query for patients with a record of diabetes mellitus (and its subtypes );
  • Records of "planned" + "hip replacement" should not be counted when analyzing the records of patients who have had any type of "joint replacement.";
  • Records that state "meningitis" + "excluded" should not be counted as cases of meningitis;
  • Records that state the patient is |allergic to| + "penicillin" are not records of treatment with an antibiotic.

This issue is discussed in more detail in the section on data entry.

The recommended approaches are:

Context that can safely be represented using qualifiers

Where a contextual modification can be logically regarded as a refinement of the original Concept it is reasonable to use a qualifier . Examples of this include "severity," "episodicity" and "laterality."

Concepts with built-in context

Some Concepts derived from earlier terminologies (i.e. SNOMED International and the Read Codes) contain built-in context. An example is the concept "FH: Diabetes mellitus" (FH being an abbreviation for family history). These concepts are in the Situation with explicit context hierarchy .

To the extent possible with released context attributes, these Concepts are defined (and will continue to be reviewed) so that they are computably equivalent to appropriate postcoordinated representations.

Example

The concept "FH: Diabetes mellitus" is defined to be equivalent to the postcoordinated representation


Feedback