Template:SAIF Generic IM Constraints

Generic Content Constraints for SAIF Information models.
         Only the content appearing below in black font will appear in the inclusion.
These elements are intended to appear under the following section:

Content Constraints

For Information Models that are derived from either the HL7 Reference Information Model (RIM) or from an information model that has the RIM of as one of its derivation ancestors, the Content Constraints are simply stated:

The contents of this model must be either the same as the contents of the model from which it is derived from or a constrained sub-set of the contents of that model.

The key question is what constitutes a "constrained sub-set" of the contents of a model? The answer to these rules is found in HL7 Version 3 Standard: Refinement, Constraint and Localization to Version 3 Messages, Release 2 (ANSI/HL7 V3 RCL, R2-2007), approved in August 2007. (Do not be mis-led by the term "Messages" in the title of this standard. A "message" is simply a Serializable Information Model (SIM).)

The remainder of this section will summarize the constraint rules that are documented in that standard, and modify them to use SAIF terms. It does not replace those rules. The process of constraining, in general, reduces the "breadth" of the semantic content of the model, or limits the scope of the values for a particular element.

Constraints from Refinement, Constraint and Localization Standard

The key elements of the governing standard are in chapter 2 - Constraints and Annotations which begins as follows. Constraints are the central feature of the derivation process, as they reduce the generality of the base model and focus it on a particular requirement. The constraints that may be asserted against a model element, e.g. class, attribute or association, fall into six broad categories:

Appearance constraints determine whether a particular model element in the base model must appear in models or messages derived from the base model, and/or whether the element is precluded from appearing therein.

Cardinality constraints define the number of repetitions that may occur for a given element.

Type constraints limit the structure or "type" of the element in question. These are constraints placed upon the data types for attributes and upon the use of Common Model Element Types (CMETs) at association ends.

Vocabulary constraints limit the set of concepts that can be taken as valid values in an instance of a coded attribute or data type.

Other value constraints provide for the declaration of constraints stated as text and, optionally, as testable expressions to establish "business rules", and for the assertion of default or fixed values.

Appearance Constraints

Appearance constraints apply to attributes and associations. The presence of a model element in a derived model depends upon the appearance constraints that are asserted or implied for that element in the base model, and upon the rules for "cloning" classes from a source model to a target model.

There are two forms of appearance constraints that may be set in a model: the declaration that an element is mandatory; and the assertion of a conformance value.

Mandatory Inclusion Property

The mandatory inclusion property indicates whether or not a particular element must be present in each instance of serialized model. If the mandatory inclusion property of a particular element is set to "M", the element is mandatory. If an element is Mandatory, then all elements that derive from it in derived models SHALL also be Mandatory.

Conformance Property

The conformance property specifies how a model element must be handled by applications. Every attribute and association element in a model has an explicit or implicit conformance property. The property has one of three values: Required, Unspecified or Not Permitted:

• Required (R) - When deriving models, the element must appear in all instances of derived models and must be declared as "Required" in derived models.
• Unspecified (U) - The appearance of this element in derived models is unconstrained. In instances of derived models the element may retain "Unspecified" status, or it may be declared "Required" or "Not Permitted". "Unspecified" is the default value for this property.
• Not Permitted (NP) - This element SHALL not appear in derived models or, it it appears, it MUST also be "Not permitted" in the derived model.

Cloning classes

Whenever an information model is derived by constraining another information model, it is permissible to "clone" the classes of the base model. This is true whether one is deriving a DIM from the RIM, a SIM from a DIM, or an SIM from another SMIM.

Class cloning is the creation of one or more copies of a base class contained in the source model into the new model. Cloning is the only form of model "extension" permitted under the terms of this section. The following rules apply:

• In order to be a source class for more than one clone in the derived model, a class in the base model:
  • Must be reached by an association whose upper cardinality limit is greater than "1", or that is reached by a "recursive" relationship ( typically when a class (type) is declared to have a "component" relationship to its self).
• In order to qualify as a valid clone of a source class, the clone must obey the following rules:
  • If the source class has been cloned more than one in the derivation, the clone classes SHALL have a new name to assure that they have unique names within the derived model.
  • The clone may contain only attributes that are also part of the source class
  • The clone shall only use associations that are valid for the source class and are present in the base model
  • The cardinality and mandatory constraints for elements in the clone class cannot be less constrained than the equivalent elements in the source class
  • The vocabulary domains declared for any coded attributes in the clone must be identical to, or a subset of, the domain asserted in the source class, and if the coded attribute is "CNE" the cloned attribute must also be "CNE"
  • The clone need not include attributes or associations unless they are "Required" or "Mandatory" in the source model, regardless of their cardinality
  • The clone may not include attributes or associations that have a conformance value of "Not Permitted" in the base model

Cardinality constraints

Cardinality constraints apply only to attributes and associations. Every attribute or association element in a model has an explicit or implicit cardinality that expresses the number of times an attribute or association may appear in a derived model or model instance. Since associations in HL7 information models are directional, the cardinality constraint of an association is equal to its destination multiplicity, i.e. the minimum and maximum number of times instances of the target class of the association may be referenced.

When deriving a model both the minimum and maximum cardinality for a particular derived element may be constrained in a way that narrows the range of possible occurrences. Thus, either minimum or maximum values of the derived cardinality range may be set to a new value within the closed range defined by the minimum and maximum values in the source range. This is subject to two the further constraint rule that the minimum cardinality of the derived range must be less than or equal to the maximum cardinality of that range.

Type constraints

Type constraints apply to attributes, classes, CMET references, and Choices. Each of these model elements has a type explicitly or implicitly derived from information in the model specification.

• The type of a class can be determined either from the classCode or typeCode attribute of the class.
• The type of a CMET reference is determined by its name and "attribution" level.
• The type of an attribute is the data type declared for that attribute in the model.
• The type of a Choice of classes is determined by the set of classes in the Choice

Type constraints are constraints on the type of a model element. The constraint rules for classes are governed by the constraints on the vocabulary specification of its typeCode or classCode, and are not elaborated further.

Data Type Derivation Constraints

Each attribute classes in the base model is assigned a data type. When a class is cloned, the the attributes of that class in the derived model may keep the same data type that it had in the source class or may be constrained by making a valid type substitution to one of the allowable types specified in the Data Types Model bound to the base model. This document will not attempt to summarize or list the valid substituion patterns.

Common Message Element Types (CMETs)

CMET substitution - When a model is being derived, a CMET may be substituted for a class or a class clone, provided that:

• The CMET in the clone is based on either the same class as the base class being substituted or on a sub-type of that class,
• The values for the structural codes for the CMET fall within the vocabulary constraint specified for those attributes in the base class,
• That the body of the CMET that is substituted uses the constraint rules described here for the model being derived.

CMET constraint hierarchy - When a model is derived, the CMETs within that model may be further constrained along the defined restriction hierarchy for CMETs. The hierarchy is based on a general to specific refinement. The hierarchy is determined by the "attribution levels" of the CMETs, as defined in the CMET Normative Standards. The derived CMET must be at the same or a lower level of attribution than was the source CMET.

Choice element constraints

An HL7 v3 static model may contain a Choice element in the model. The Choice element is treated as if it were a class itself. The Choice element contains a finite number of other classes. If model X contains a Choice element and if model Y is derived from of model X, then model Y may contain a simplification of the Choice according to the following rules.

• Y may eliminate an entire Choice element, and any associations with the Choice as source or target, provided that the result is still a complete model. and that no associations to the choice were "Required".
• Y may eliminate any class from a Choice element, and all associations with only that class as source or target, provided that at least one class remains in the Choice.
• Y may reduce a Choice to a single class, and then may substitute that class for the Choice in the model, retaining the Choice associations as associations for the class.

Vocabulary constraints

Vocabulary constraints limit the values that coded attributes may take on. (If an attribute is derived from a RIM attribute that has a Concept Domain constraint (Property:vocDomain) assigned, then it is a coded attribute.)

A simplified set of Vocabulary constraint rules during model derivation are:

• If an encoded attribute in the base class is constrained to a Concept Domain "A", the derived attribute may be constrained to:
  • Concept Domain "A"

  • A Concept Domain that "specializes" Concept Domain "A"

  • A Value Set that has a universal "context binding" to Concept Domain "A" or to a Concept Domain that "specializes" Concept Domain "A"

  • If Concept Domain "A" has no universal "context binding"
    • A Value Set that includes the concepts defined by Concept Domain "A" (model binding).

    • A single coded concept from a code system (fixed value assertion), where the coded concept is a valid member of the concepts defined by Concept Domain "A"
• If an encoded attribute in the base class is constrained to Value Set "B", the derived attribute may be constrained to:
  • Value Set "B"

  • A Value Set based on the same code system as Value Set "B" and whose content is a sub-set of the content of Value Set "B"

  • A single coded concept that is a member of Value Set "B" (fixed value assertion)
• If an encoded attribute in the base class is constrained to a single coded concept, the derived attribute must be constrained to the same coded concept.

Other value constraints

These constraints are those that limit the value for an attribute in ways not covered above. These are the assertion of a default value and the declaration that an attribute has a fixed value.

Default value may be declared for an attribute. The default is a single value for that attribute that will be asserted for an instance that does not contain the attribute. The default value may be any value that is valid for the data type and, if applicable, for the vocabulary constraint on that attribute. Once a default is assigned to an attribute, a different default cannot be assigned for the same attribute in a derived model.

Fixed value - In an information model an attribute of a class may be assigned a fixed value. The fixed value may be any value that is valid for the data type and, if applicable, for the vocabulary constraint for that attribute. Once a fixed value is assigned to an attribute, a different fixed value cannot be assigned for the same attribute in a derived model.