Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

SNOMED CT contains many precoordinated Concepts that allow fairly complex Concepts to be represented by a single Concept Identifier. It also permits the qualification or refinement of Concepts to represent more detailed Concepts by postcoordinated combinations of several Concept Identifiers .

Several types of postcoordinated 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.

Entering refined defining characteristics

The application may allow a user to refine a Concept by selecting a subtype of one of its defining characteristics .

Example:

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

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

CAUTION:

Some conceptsshould not be refined if the result means the new conceptis not a subtypeof the parent concept.

This situation occurs when context such as "Family history" or 405613005 |Planned Procedure| is attached to a Clinical Finding or Procedure. "Family history" of a Clinical Finding needs to be defined in the situation with explicit context hierarchy. All postcoordinated constructs should consider the impact of context.

Entering concept model refinements

The application should allow a user to refine the meaning of a concept by selecting an attribute permitted by the concept model and applying an appropriate value to that attribute. The attributes permitted for a concept depend on the domain in which that concept falls (i.e. its position in the subtype hierarchy). Similarly, the set of values that can be applied to an attribute range specified for that attribute .

Entry of unsanctioned qualifiers

The application may also permit refinement of a concept by the addition of attributes and values that are not sanctioned by the concept model. However, this is not recommended as it results is inconsistency between representation of meaning in different systems. Any facility to allow qualification of concepts in this way carries a risk of creating nonsensical or contradictory statements. It may also result in incomplete or inappropriate retrieval where the qualifier significantly affects the meaning of the concept .

Constraints on the entry of refinements

Refinements should only be used where the result of applying them results in a true subtype of the original Concept. Therefore, refinement should not be used for the following purposes:

  • Negation.

Example:

66308002 |Fracture of humerus| should not be qualified by "excluded."

It would be inappropriate for data retrieval to treat this as a subtype of the clinical finding 66308002 |Fracture of humerus| .

  • Certainty.

Example:

285432005 |Carcinoma of cervix| should not be qualified by "possible."

It would be inappropriate for data retrieval to treat this as a subtype of the diagnosis of 285432005 |Carcinoma of cervix| .

  • Subject of information.

Example:

73211009 |Diabetes mellitus| should not be qualified by "family history."

It would be inappropriate for data retrieval to treat this as a subtype of the diagnosis of 73211009 |Diabetes mellitus| in the patient.

  • Planning stage.

Example:

"Hip replacement" should not be qualified by "planned" or "requested."

A count of "Hip replacement" operations performed should not include this. Decision support protocols should not assume the patient has had this operation.

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.

Entry of concepts combinations

The application may allow other combinations of Concepts in a single statement where a Concept that represents the full scope of an activity is not available. This approach might for example be applied where a single procedure, which lacks a precoordinated SNOMED CT representation, is a combination of two procedures that can be separately represented in SNOMED CT .

Facilities for entering combined Concepts 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.

Example:

A diagnosis of "gallstones with cholecystitis" could be entered by selecting the "gallstone (disorder)"235919008and then selecting 76581006 |cholecystitis (disorder)| 76581006and combining these in a single statement [1 .

It is not appropriate to use these constructs to attempt to express an entire encounter, episode or clinical history in a single statement.

Example:

If a patient is treated for "gallstones with cholecystitis" diagnosed by "ultrasonography of biliary tract" with a course of 27658006 |amoxycillin| followed after the acute phase has resolved by a 38102005 |cholecystectomy|, this should not be entered as a single complex postcoordinated statement combining the diagnosis, investigation and treatments.


Feedback