The purpose of annotations is to provide a formal means to represent additional information about a SNOMED CT component (concept, description, relationship) or as a member of a reference set.

Annotations are:

• a form of metadata

• optional and non-defining

• constructed by following the Object-Attribute-Value pattern and stored either in annotation refsets or relationship files.

Each annotation uses a subtype of 1295447006 | Annotation attribute (attribute)| to represent the type of annotation with an annotation attribute value.

Attribution - Attributing credit to the source of information

For example,

• Inserm Orphanet attribution annotation at 1332326002 |Isolated cleft lip (disorder)|

Annotations can be:

• added to both new and legacy concepts.

  • For legacy concepts, attribution may only be added if there is a change to the modeling of the concept to support the collaborating organization's definition.

• added in the international edition or extensions.

• inactivated if incorrect or no longer relevant. An inactivation reason is not required. Each annotation attribute has its own requirements and rules on maintenance documented in separate guidance.

Annotations in annotation refsets can be found by using ECL queries for refset members. Currently, there is only data in the refset called Component annotation refset with string value, so the following ECL query yields all SNOMED CT concepts currently with an annotation:

The ECL query can filter the members via ^1292992004 {{ M value="enter annotation string" }}

• For example,

Annotation length is restricted up to 4000 characters and are represented by the String data type which allows URL, number, and text for annotation values. Each annotation attribute should state the allowed values.

For example,

• If an attribute is only allowed for taking numbers, then URL or text should not be used for its values, because numbers are saved in different formats; numbers are saved with a prefix # and text is quoted.

The following are documented in the respective annotation guidance, if applicable.

• Maintenance process

• Validation for annotations, such as spell check

• Annotation cardinality - Most attributes will be 0..1 but some may allow multiple values.

See also for more information.

In addition to the guidance found here in the Editorial Guide, please see information on the use of templates at .

Templates are created by authors in an attempt to standardize the modeling, naming, case significance, etc. of certain subhierarchies of the terminology, though it is recognized that not every concept may conform to a prescribed pattern. The modeling approach may be difficult to apply in all cases, but domain-specific templates are being developed to ensure modeling consistency and accuracy.

No template is necessary if less than 50 concepts are affected. In cases of small numbers, check if existing templates can be generalized and/or look to add elements as optional rather than mandatory.

Disjunctives

Disjunctives are unacceptable with limited exceptions below. Instead of disjunctives, there should be separate concepts when possible.

Concepts with disjunctives (or, and/or) in disorders and procedures often involve one or more body structures.

• For example,

  • 65966004 | Fracture of forearm (disorder)|

    • The concept does not specify which bone of forearm is fractured. It is a break in one or both of the radius and/or ulna per the ICD definition. It would subsume fracture of radius, fracture of ulna, and fracture of both radius and ulna.

Exclusive disjunction ("or" only) is used when either operands is true but both cannot be true.

• For example,

  • 417163006 | Traumatic or non-traumatic injury (disorder)|

Concepts representing a clinical finding caused by more than one distinct substance logically represent disjunction, i.e., a clinical finding caused by substance X and/or substance Y. These concepts should be modeled as primitive using GCI. The causative agent for the main axiom should be the most specific shared parent of the substances involved. The causative agent for each GCI should be its own specific substance.

• For example,

  • 870746005 |Allergy to ergometrine and/or oxytocin (finding)|

  • 1149371006 |Sulfamethoxazole and/or trimethoprim overdose (disorder)|

Conjunction and disjunction are commonly used in the anatomical structure hierarchy. Following the anatomy SEP (Structure/Entire/Part) model, the word structure means all or any part of an anatomic entity, which is an inclusive disjunction.

• For example,

  • 419605007 | Structure of ankle and/or foot (body structure)|represents adjacent regions of ankle and foot by a single concept. It is an inclusive disjunction, because any structures of ankle, foot, or both are true subconcepts. However, "Entire ankle and foot" as a conjunction means the ankle and foot as a whole. The concept represents the entirety of this single region, though there is no dedicated name.

  • "Structure of ankle and foot" has the same meaning as "structure of ankle and/or foot" because of the inclusive disjunction meaning of "structure". "Structure of ankle and foot" was previously used. These descriptions were changed to and/or to explicitly indicate the inclusive disjunction

The and represents conjunction in disorders and procedures that can be interpreted as co-occurrent. It can be read as both in common usage. It would be all if it refers to more than two disorders or procedures.

• For example,

  • 75857000 | Fracture of radius AND ulna (disorder)| represents the occurrence of a fracture of radius and a fracture of ulna at the same time or event. In other words, fracture of both radius and ulna. The concept should be modeled using two finding site relationship groups: Bone structure of radius in one and Bone structure of ulna in the other.

See glossary for definition here:

For some, but not all concepts, the proximal primitive parent is a top level concept, e.g., Procedure.

The proximal primitive supertype may also be an intermediate primitive concept located between the top level concept and the concept in question.

There may be more than one proximal primitive supertype for a concept.

The approved modeling approach is to use:

• Proximal primitive supertypes

• Attribute-value pairs sufficient to define the meaning

  • An attribute-value pair is explicitly stated for the concept, even if it is already present for a supertype concept.

  • Attribute-value pairs are grouped as required.

The classifier infers all appropriate proximal supertypes. With sufficiently defined concepts the subtypes are also inferred.

• For example,

  • The proximal primitive supertype for this concept is

    71388002 | Procedure (procedure)|. It has been modeled with one stated supertype and two attribute value pairs in a relationship group.

The inferred view shows the logical definition of the concept. By using the stated relationships (for this concept and other concepts currently in the terminology), the classifier infers three defined proximal supertypes:

• Radiography of humerus (procedure)

• Computed tomography of upper arm (procedure)

• Computed tomography of bone (procedure)

Where more than one potential primitive supertype is identified for a concept, authors should check the primitive supertypes for subsumption of one or more other primitive supertypes. Any subsuming concept is not a proximal primitive supertype.

• For example,

  • There is more than one potential primitive supertype for

    421095001 | Allergic disorder by body site affected (disorder) |. However, 64572001 | Disease (disorder) | is subsumed by 404684003 | Clinical finding (finding)|, therefore 64572001 | Disease (disorder) | is the proximal primitive supertype concept.

For information on the effect of GCIs on modeling primitive supertypes, see (GCIs).

Draft guidance

See the background, use cases, and examples for general concept inclusion axioms as well as explanation of the definition status at General Concept Inclusion 0.01.

Authoring Platform User Guide for GCIs

Reference the Authoring - Description Logic (DL) Support Features for technical information describing how to add an additional axiom and general concept inclusion.

GCI display in the browser

A concept with GCIs will display in the browser in the stated view only.

For example,

Below is 417163006 | Traumatic or non-traumatic injury (disorder)| in the stated view with the GCIs appearing to the right of the concept:

Here is the same concept in the inferred view without the GCIs appearing:

Modeling concepts with a GCI-modeled supertype

General concept inclusions allow multiple definitions of a concept. A group of subtypes may be defined using GCIs and be considered subtypes of the parent concept without fully defining that parent concept. That parent concept could have multiple definitions, each of which is valid but none of which completely describes the parent concept on its own.

When modeling a concept intended to be a subconcept of a GCI concept defined by General Concept Inclusion (GCI) axioms, it is unnecessary to state the GCI concept as a parent if the logic of the concept being modeled is already covered by a GCI axiom. This holds true even if the GCI-modeled concept is primitive, as the GCI axioms ensure that the correct subsumption relationship is inferred regardless.

• For example,

  • 281372009 |Lumbarized first sacral vertebra (disorder)|

The diagram below shows Lumbarized first sacral vertebra (disorder) incorrectly modeled on the right, with a stated primitive GCI-modeled parent of Transitional lumbosacral vertebra (disorder). Transitional lumbosacral vertebra (disorder) is modeled with a GCI, as notified by the salmon pink color. The left side of the diagram shows the inferred view with two parents.

The GCI-modeled primitive concept, Transitional lumbosacral vertebra (disorder), is unnecessary to state as a parent. The diagram below shows correct modeling of Lumbarized first sacral vertebra (disorder) with the absence of Transitional lumbosacral vertebra (disorder) as a parent, and yet the inferred view diagram on the left is still the same as compared to the incorrectly modeled diagram above.

Alternatively, if a GCI-modeled parent will not subsume an appropriate child concept, then the GCI-modeled concept should be stated as a primitive supertype.

Finally, the example below of 82271004 |Injury of head (disorder)| illustrates a concept with a GCI-modeled supertype of 417163006 |Traumatic or non-traumatic injury (disorder)|. In this case, the concept Injury of head (disorder) is sufficiently defined.

Though most are primitive, it is possible to define concepts modeled with GCIs. A concept must continue to meet the necessary conditions in order to be considered defined. GCIs can be added to extend the subtypes a defined concept will infer when appropriate.

• GCIs are not restricted to particular hierarchies; they can be used as applicable in any hierarchy that has a concept model.

• The Authoring Platform does not currently have the ability to create templates that include GCIs.

• A concept which has a stated "is a" relationship to a concept with GCIs will need to have GCIs added to it directly if GCIs are required to appropriately represent the concept. GCI axioms are not inherited from supertype to a subtype concept.

Considerations for current concepts when creating new concepts

Concepts that are used as target values in an attribute relationship impact the placement of the source concept of the relationship. Some concepts, for example, those in the Qualifier value hierarchy, are created to support the definition of other concepts. Creation of a new concept that will be used as the target value in an attribute relationship requires an author to determine if there are active concepts in the domain hierarchy that should also use the new concept as a target value.

For example,

The creation of 713295009 | Surgical replacement - action (qualifier value)| would require a review of active concepts that represent surgical replacement procedures that were previously modeled with the Method (attribute) of Replacement - action (qualifier value).

A concept that represents a surgical replacement procedure that currently has a Method (attribute) of 282089006 | Replacement - action (qualifier value)| would require inactivation of that relationship and the creation of a new attribute-value relationship of Method (attribute) of 713295009 | Surgical replacement - action (qualifier value)|.

Description Inactivation

Description inactivation values

Depending upon the combination of the type of component and the reason for inactivation, a specific inactivation reason must be selected.

When there is more than one reason to inactivate a description, the order of preference for the inactivation value is as follows:

1. 723278000 | Not semantically equivalent component (foundation metadata concept)|

2. 900000000000483008 | Outdated component (foundation metadata concept)|

3. 1217318005 | Grammatical description error (foundation metadata concept)|

4. 723277005 | Nonconformance to editorial policy component (foundation metadata concept)|

Only the description inactivation value of Not semantically equivalent component requires an association type; the association type is Refers to and necessitates the reference to at least one active SNOMED CT concept. It is possible that the description is ambiguous and may relate to more than one concept.

The other three description inactivation values (outdated, grammatical error, nonconformance) do not require an associated concept.

A value from the choices below must be chosen as a reason for inactivating a concept. Inactivation replacement associations are ultimately at the author's discretion. Especially in the instance of an infinite number of possible replacements, clinical relevance and subset inclusion should be considered. Non-synonymous synonyms should also be inactivated and reassigned.

All possible meanings should be represented in the replacement targets when feasible, creating new concepts as replacements when appropriate.

Ambiguous concepts with a single replacement target may be used if one of the two possible meanings of the ambiguous concept is not clinically useful.

Many, but not all, concepts precoordinated with "with" and "and" are derived from classifications; regardless, this is the acceptable inactivation reason.

For concepts with exclusions, such as NEC, NOS, etc., use the Replaced by association with the immediate parent concept as the value, which is the clinical condition without any context. If a parent concept without the exclusion does not exist, it should be created as a new concept.

For concepts with conjunctions such as 'and' and 'with', use the Partially equivalent to association with the two separate values as targets. For the purposes of patient care, it is recommended that each disorder is recorded individually.

The Partially equivalent to association signifies that all applied targets must be implemented within the clinical notes to ensure the original clinical idea is represented.

• Note that the meaning of the concept is based on the FSN but does not imply that the FSNs are identical. Keep the concept with the more specific FSN. FSN is the source of a concept's meaning; hence, there should be more weight in the meaning of the FSN rather than the underlying modeling. Implementers do not see modeling.

• If appropriate, add the descriptions from the inactivated concept to the remaining active concept while ensuring they are semantically equivalent, clinically useful, and follow current naming conventions.

• Inactivating the newer concept

• Inactivating the concept with fewer subtypes. This will simplify the process and minimize the amount of rework required.

• Inactivating the concept with least modeling

• Updating the retained concept's FSN and modeling to align with current policy.

The Duplicate component is the inactivation for duplicated concepts:

1. Within the following hierarchies:

   1. Clinical finding and Disorder

   2. Procedure and Regime/Therapy

2. Between the following top-level hierarchies:

Any possible duplicates between concepts among other paired hierarchies not listed above should be reconsidered as duplicates and directed to another inactivation reason, likely Erroneous.

Where the error gives rise to potential ambiguity, use the inactivation reason of Ambiguous component. Otherwise, the Erroneous component requires a single Replaced by value.

Meaning of the concept is unknown, and an association type is not given. It will normally be necessary to search the clinical literature to establish that this is truly an unknown concept rather than an outdated clinical concept. This inactivation reason may be used where the meaning of the FSN is considered to be vague.

Concept which do not adhere to editorial guidance can be inactivated without an association type. Else Replaced by and Alternative are Association type options.

Policies will often delineate how these two Association type options will be used. Changes of this type often include bulk updates and may relate to medicinal products, substances, and devices.

When an outdated concept simply falls into disuse without any appropriate replacement, no historical association is applied.

Replaced by is used for a single replacement concept that is semantically similar to or more general than the inactivated concept.

Possibly replaced by is used for multiple replacement concepts.

For example,

A substance or organism originally believed to be a single entity has been reclassified as two or more substances or organisms.

A concept is sufficiently defined if its defining characteristics are adequate to define it relative to its immediate supertypes. A sufficiently defined concept is defined in the context of its hierarchy. See main glossary entry for sufficient definition.

A concept which is not sufficiently defined is primitive. A primitive concept is a formal logic definition that is inadequate to distinguish it from similar concepts. A primitive concept does not have enough defining relationships to computably distinguish it from more general concepts (supertypes).

SNOMED CT is arranged as a polyhierarchy. A hierarchy is defined as an ordered organization of concept codes linked together through IS A relationships. Concept codes are linked to their more general parent concept codes directly above them in a hierarchy. Concepts with more general meanings are usually located at the top of the hierarchy and then at each level down the hierarchy the meanings become increasingly more specialized.

For general modeling information, use the following links to jump to the following pages:

• Annotations

• Changes to Components

For hierarchies with a concept model, the usefulness of fully-defined groupers is limited to convenience groupings based on particular use cases. They may be added if they provide demonstrable benefit to organizing and navigating the terminology.

Grouper concepts provide a definition for subtypes that are always and necessarily true. The grouper concept must be sufficiently defined and clinically useful for the purpose of organizing content for an intensional reference set (e.g. disease of colon and all of its descendants) or in Expression Constraint Language (ECL), << 128524007 | Disorder of colon (disorder)|.

Navigational concepts

Grouper concepts should not be confused with navigational concepts. Navigational concepts were created to group other concepts without explicit regard for defining attributes (since there were none). Their purpose was to provide top level groupers for subsets and reference sets used in implementations. Because the Reference Set mechanism is now available, there is no longer a need for navigational concepts in the International Release; however, they can be added at the national or lower level.

In the past, there was an indiscriminate move of concepts in and out of the navigational concept hierarchy based arbitrarily on use cases by those users organizing concepts based on a particular classification that was wanted. The navigational concept hierarchy was useful to group things into a particular domain. The problem is that many of these are domain-specific and cannot be generalized. For example, mosquito-borne diseases will vary depending on the location of the user. It is difficult to classify the complete instance of these as well. Potential children would have to be manually assigned.

Because this is a primitive hierarchy and subtypes will not auto classify, much work would be required to reorganize hierarchies and maintain the use of navigational concepts. Inactivating concepts may be met with requests to create intermediate primitives. The Content Managers Advisory Group [CMAG] at 2020 Use of navigational concepts is being consulted regarding current use of navigational concepts.

As 363743006 | Navigational concept (navigational concept)| is within the 370115009 | Special concept (special concept)| subhierarchy, please see that section of the Editorial Guide at Special Concept.

Intermediate primitive groupers add a substantial management burden, thus, are discouraged. They may however be added on a case-by-case basis with approval from the Head of Terminology when, for example:

• The concept model is not robust enough to support the full definition of a subset of terms, e.g., genomics (i.e., genetic diseases for which we cannot state, the majority of cases of this disease present with X).

• There are variances in the clinical manifestations.

If an existing intermediate primitive concept cannot be sufficiently defined and has only one subtype, is not used to model another concept nor demonstrably clinically useful, it should be inactivated.

A grouper concept that is added to SNOMED CT must adhere to the following rules:

• The concept must not be created with the hierarchical tag (navigational concept).

• The concept must use the semantic tag for the relevant hierarchy, e.g., (finding), (procedure).

• The concept must not have stated subtypes. All subtypes must be inferred by the classifier.

• The grouper concept will ONLY be added if it can be sufficiently defined.

Where grouper concepts already exist, the following criteria apply:

• If it can be sufficiently defined, remodel it, and reassign existing stated subtypes to a new proximal primitive parent.

• Identify primitive concepts that cannot be sufficiently defined for additional review.

This page describes the grouping of attributes.

A relationship group combines an attribute-value pair with none, one, or multiple attribute-value pairs in order to refine the meaning of a concept.

For example,

An attribute must be populated with a target value to model a concept.

Relationship groups are needed when modeling:

• Clinical finding concepts that require multiple Associated morphology attributes and multiple Finding site attributes

• Procedure concepts that require multiple Method attributes and multiple Procedure site attributes.

• A single relationship group containing only one attribute can exist.

  • When an attribute is restricted to a single group with no other attributes, the attribute is described as being "self-grouped".

• Multiple attributes may be grouped together in relationship groups, and multiple relationship groups may be created to sufficiently define concepts.

• When creating new concepts or revising existing ones, each attribute type included in a relationship group may only be present once, e.g. two Associated morphology attributes cannot be in the same relationship group.

• Relationship groups are not limited to Clinical finding and Procedure concepts.

• There is no limit to the number of relationship groups that may be added to a concept.

An attribute that is not in a relationship group is considered to be in a group on its own. When attributes are not grouped, their meanings are interpreted separately. For example, in the following diagram, the Associated morphology is Hemorrhage, and the Finding site is Uterine structure. However, it cannot be interpreted that the site of the Hemorrhage is the Uterine structure because the two attributes are not grouped.

When the attributes are grouped, the relationships imply meaning towards each other. To continue the example above for 44991000119100 | Abnormal uterine bleeding (disorder) |, the following diagram shows the Associated morphology of Hemorrhage and the Finding site of Uterine structure in a relationship group together. The grouping can be interpreted that the finding site of the hemorrhage is the uterine structure.

Note the difference in the inferred parents between the self-grouped versus grouped attributes. This is explained in more detail below.

Relationship groups refine inheritance, i.e., a grouped set of attributes is more specific than the same attributes that are not grouped. This is important when considering subsumption. The following diagrams demonstrate the impact of grouping or failing to group consistently using the concepts 50434004 | Excision of lesion of aorta (procedure) | and one of its supertypes, 63296004 | Excision of aorta (procedure) |.

The meaning of the supertype concept, 63296004 | Excision of aorta (procedure) | (where the relationships are grouped) is interpreted as a procedure with an excision on the aortic structure. This is because 405813007 | Procedure site - Direct (attribute) | and 260686004 | Method (attribute) | are grouped.

In the following diagram, the more general supertype concepts, 65801008 | Excision (procedure) | and 118809006 | Procedure on aorta (procedure) | are the proximal supertype concepts.

50434004 | Excision of lesion of aorta (procedure) | is a logical subtype of 63296004 | Excision of aorta (procedure) | . However, the attributes of the concept 50434004 | Excision of lesion of aorta (procedure)| are not grouped. Thus, the classifier interprets the definitions as non-related and 50434004 | Excision of lesion of aorta (procedure) | is not inferred as a subtype of 63296004 | Excision of aorta (procedure) | . This is because the attributes in the subtype concept are not grouped, i.e are not explicitly stated. From a machine-processing perspective, each attribute is considered a group on its own; i.e., there is an excision, but nothing else is known about the excision. This results in the concept, 63296004 | Excision of aorta (procedure) | , being interpreted more broadly.

In the following diagram the attributes of the concept 50434004 | Excision of lesion of aorta (procedure) | are grouped. An author that explicitly states that the excision is of a lesion found in the aortic structure, by grouping the attribute-value pairs, provides the necessary information for the classifier. This enables 50434004 | Excision of lesion of aorta (procedure) | to be inferred as a subtype of 63296004 | Excision of aorta (procedure) |.

Each relationship group should only contain one instance of an attribute. This is because two of the same attributes in a relationship group is not the same as one attribute with one target value that captures the combined meaning of the target values, as illustrated in the following diagram.

Two Finding site attributes are required to support the location of 53627009 | Closed fracture of radius AND ulna (disorder) |. Each 363698007 | Finding site (attribute) | and its respective target value are placed in a relationship group with the attribute 116676008 | Associated morphology (attribute) | with its target value of 20946005 | Fracture, closed (morphologic abnormality) |.

In the 71388002 | Procedure (procedure) | hierarchy, a relationship group is usually a way of combining attributes about a particular method.

In the concept 302619004 | Cholecystectomy and exploration of bile duct (procedure) | within the following diagram, the relationship groups clarify that there is exploration of the bile duct and excision of the gallbladder. Without the relationship groups, the appropriate relationships between the attributes would be unclear; i.e. the exploration of the bile duct versus gallbladder and the excision of the bile duct versus the gallbladder.

In the Clinical finding/Disorder hierarchy:

• The Finding site (attribute) and Associated morphology (attribute) are always grouped when both are present and related.

  • When there is more than one Finding site (attribute) or Associated morphology (attribute), then more than one relationship group is required.

  • When the attributes Occurrence and/or Causative agent are stated and related to the Finding site and Associated morphology attributes, include them within that relationship group.

For 413350009 | Finding with explicit context (situation) | concepts, the following four attributes are grouped:

• 408729009 | Finding context (attribute)|

• 246090004 | Associated finding (attribute)|

• 408731000 | Temporal context (attribute)|

• 408732007 | Subject relationship context (attribute)|

For example,

• 704008007 | No family history of asthma (situation)| IS A 243796009 | Situation with explicit context (situation)|,

  • 408729009 | Finding context (attribute)|, 410516002 | Known absent (qualifier value)|

  • 246090004 | Associated finding (attribute)|, 195967001 | Asthma (disorder)|

  • 408731000 | Temporal context (attribute)|, 410511007 | Current or past (actual) (qualifier value)|

For 129125009 | Procedure with explicit context (situation) | concepts the following four attributes are grouped:

• 408730004 | Procedure context (attribute)|

• 363589002 | Associated procedure (attribute)|

• 408731000 | Temporal context (attribute)|

• 408732007 | Subject relationship context (attribute)|

For example,

704503005 | Advice given about pelvic floor exercise (situation)| IS A 129125009 | Procedure with explicit context (situation)|

• 408730004 | Procedure context (attribute)|, 385658003 | Done (qualifier value)|

• 363589002 | Associated procedure (attribute)|, 420227002 | Recommendation to (procedure)|

• 408731000 | Temporal context (attribute)|, 410512000 | Current or specified time (qualifier value)|

• 408732007 | Subject relationship context (attribute)|, 125676002 | Person (person)|

When defining 363787002 | Observable entity (observable entity) | concepts, attributes are grouped.

For example, 400975005 | Standing diastolic blood pressure (observable entity) | is represented using multiple attributes within one relationship group.

Concepts that cannot be sufficiently defined by necessary conditions are called primitive concepts. Primitive concepts cannot have subtypes automatically assigned by the classifier, unless a sufficient condition for that concept exists. Relevant concepts that are subtypes of a primitive concept in the taxonomy must be manually assigned an IS A relationship to that concept.

When a primitive concept is a child of one or more concepts and a parent of one or more concepts, it is known as an intermediate primitive.

• For example,

  • 41969006 | Idiopathic disease (disorder)|

    • Without a stated IS_A relationship to the proximal primitive concept Idiopathic disease (disorder), a concept will not classify as a subtype of Idiopathic disease (disorder).

Identifying all subtypes is important when creating a subset or when Identifying relevant content during data retrieval. Therefore, when adding new concepts, potential primitive parents need to be identified and the IS_A relationship stated.

Consistent assignment of subtypes to intermediate primitive concepts is challenging. To find a possible intermediate primitive parent, it may be necessary to view the authoring form of several concepts that should be siblings of the new concept. Authors should also check for a possible intermediate primitive supertype among the descendants of the most proximate defined parent(s) under which the new concept would be expected to classify as an inferred subtype.

Given the manual burden that intermediate primitives impose, the creation of new intermediate primitive concepts in the international edition is prohibited unless:

• There is no other option and the concept is clinically necessary.

• The impact of adding the concept has been fully explored and understood.

• The impact is manageable and there is a management plan, including an extensional definition for the direct sub-concepts.

For the International Release, such requests are assessed case-by-case.