Current Version - Under Revision
The simplest form in which any conceptcan be stored is as a single Identifier. This is referred to as a precoordinated expression, because all aspects of a potentially multifaceted conceptare precoordinatedinto a single discreet form. SNOMED CTcontains more than a quarter of a million concepts, and thus allows a wide range of clinical statements to be expressed in precoordinatedform.
The procedure "Laparoscopic emergency appendectomy" has at least three distinct facets: "removal of appendix","using a laparoscope" and "as an emergency procedure". SNOMED CTincludes a conceptthat precoordinates these facets.
The concept 174041007 |laparoscopic emergency appendectomy|has the following defining characteristics: 260870009 |priority|= 25876001 |emergency|, 116680003 |is a|= 80146002 |appendectomy|, [ 2 425391005 |using access device|= 86174004 |laparoscope|.
A multi-faceted conceptcan be stored using a combination of Identifiersfor its individual facets. This is referred to as postcoordination, because the various aspects of the conceptare coordinated during data entry rather than in the preparation of the terminology. Three types of postcoordinationare described in the following sections.
Example: Total replacement of hip using a Sheehan total hip prosthesis -postcoordinatedA postcoordinated expressionbased on the concept 52734007 |total hip replacement|can be used to record an instance of this procedure. The definition of this conceptincludes 363699004 |direct device|= 304120007 |total hip replacement prosthesis|and the value of this attribute can be refined to 314580008 |Sheehan total hip prosthesis|(which is a subtypeof 304120007 |total hip replacement prosthesis|). Therefore, the following postcoordinated expressioncan be created and used to represent this procedure: 52734007 |total hip replacement|: 363699004 |direct device|= 314580008 |Sheehan total hip prosthesis|.
Another common use of refinement is to represent a situation such as a family history, or a planned procedure. In this case, a conceptrepresenting the general type of situation can be refined by applying a clinical finding or procedure.
Example: Family history of temporal arteritis -postcoordinatedA postcoordinated expressionbased on the concept 281666001 |family history of disorder|can be used to record a family history of any disorder. The definition of this conceptincludes 246090004 |associated finding|= 64572001 |disease|and the value of this attribute can be refined to 400130008 |temporal arteritis|(which is a subtypeof 64572001 |disease|). Therefore, the following postcoordinated expressioncan be created and used to represent this family history: 281666001 |family history of disorder|: 246090004 |associated finding|= 400130008 |temporal arteritis|.
Qualification is a type of postcoordinationin which a conceptis made more specific by applying value to attributes that are permitted by the Concept Model. Unlike refinement, the attributes applied need not be present in the definition of the conceptthat is being qualified.
Example: Laparoscopic emergency appendectomy -postcoordinatedA postcoordinated expressionbased on the concept 80146002 |appendectomy|can be used to record an instance of this procedure by separately specifying the access instrument and priority. The concept 80146002 |appendectomy|does not have defined values for the attributes 260870009 |priority|and 425391005 |using access device|but the Concept Modelpermits these to be added to subtypesof 71388002 |procedure|. Therefore, the following postcoordinated expressioncan be created: 80146002 |appendectomy|: 260870009 |priority|= 25876001 |emergency|, 425391005 |using access device|= 86174004 |laparoscope|This postcoordinated expressionis equivalent to the definition of the concept 174041007 |laparoscopic emergency appendectomy|. However, the postcoordinatedapproach can also be applied to procedures for which there is no precoordinated concept.
"Gallstones with cholecystitis" could be represented by combining the conceptsfor the disorders "gallstones" and 76581006 |cholecystitis|as a single postcoordinatedstatement. Neither of these conceptsis really a qualifierof the other since it could equally well be regarded as 25924004 |Calculus of gallbladder with cholecystitis|. SNOMED CTallows Conceptsto be combined in postcoordinatedstatement.
Combinations like this should only be used to represent conceptsthat can be regarded as discreet reusable clinical statements. They should not be used to construct arbitrarily complex representations of multiple statements to a particular record.
Some concepts, such as the first and last examples above, can be represented in either a postcoordinatedor precoordinatedform. However, there are other concepts, like the second example above, for which no precoordinated Conceptexists in SNOMED CT. Although future releases of SNOMED CTwill include new precoordinated Concepts, there will always be some clinical Conceptsthat require postcoordination.
This guide does not specify a single right way to represent postcoordinated expressions. Alternative representations have different profiles of advantages and disadvantages. The choice of representation depends on functional requirements including performance, information model of the software application and the communication standards to be supported.
Some alternative representations are summarized below. These summaries illustrate some of the main options and do not go into extensive technical detail. Detailed design may lead to further alternatives that are not documented here.
Each of the following summaries assumes that SNOMED CT expressionsare stored in (or associated with) one or more fields within particular types of record entry. The expressionis only one part of the data in that record entry.
The schema for representation of clinical statements contains a field (or element) for representation of the SNOMED CT expression;
An unrestricted relational database representation of a postcoordinated expressionrequires that a data item that may be expressed using SNOMED CTis modeled in a way that permits an indeterminate number of attribute-value pairsto be appended to a focus concept. In addition, the value within each attribute-value pairmust be able to be refined by addition of nested attribute-value pairs.
This offers a flexible and extensible approach but adds significantly to database design complexity. Disadvantages arising from this complexity include storage capacity requirements and the impact on writing queries and retrieval performance.
The clinical statements table contains a field for a Concept Identifier.
The clinical statements table also contains fields for a specified number of qualifiers. These fields may be provided in different ways:
Each qualifieris represented by two Concept Identifierfields (one for the attribute and one for the value) and an optional field for relationshipGroup field. With this option the only restriction is the total number of qualifiersor modifiers that can be stored for each Concept.
Each qualifieris represented as a single Concept Identifierand carries the value of a qualifierattribute specific to that field. This restricts the usable qualifiersto those specified in the database schema.
Similar to above, but with different sets of qualifying attributes available according to the semantic type of the primary Conceptin the statement. There are various ways of implementing this approach to ensure that the appropriate interpretation is applied to each row of the table.
Combined Conceptsmay be represented by explicitly combining two rows of the clinical statements table.
Unlike the representations discussed in previous subsections, this approach limits the expressivity of postcoordinatedstatements. The advantage of this restricted approach is that it reduces the number of joins involved in retrieval queries. In some software environments this may significantly improve performance.
The balance between demands for flexibility and performance depends on user requirements. Therefore, limitations in expressivity may be acceptable for some users or user communities but not for others. However, it should be noted that these limitations might cause difficulties when communications are received from systems that support richer forms of expression.
The clinical statements table (or element) contains a field (or element) for representation of the concept.
User input includes also a text label for the expression, and the new conceptis created, usually a team of expert SNOMED CT modelersreview the new conceptfor quality assurance. Other implementations requires that user enter only the text label, and then the modelers team can associate the label to an existing concept, or create a new conceptin a local extension using the label as a Descriptionand adding the new Relationshipsfor the conceptdefinition.
This approach is called Managed Content Additions (MCA). Has some advantages like having all new content available for text searches by users, and allowing the use of a description logicsclassifier for inferring Relationshipsand super-types, avoiding the need of complex real-time expressionscomputations. On the other having a centralized team of experts represents an expensive approach and a possible bottleneck for terminology development, as the experts need to review all content additions in the system.
Transforming an expressionto a normal formmay be necessary to support effective data retrieval. However, even quite small minor corrections to the definition of a conceptin future releases may significantly alter the resulting normal formof the same expression.
Therefore, it is recommended that:
If transformationsto alternative representations are used to enhance the efficiency of retrieval, these should be stored as secondary supporting tables or indices:
This has the advantage that these alternative forms can be regenerated based on the most up to date set of definitions when a new release of SNOMED CTis installed, without affecting the integrity of the original records.