Difference between revisions of "Template:SAIF Generic IM Constraints"
Line 20: | Line 20: | ||
<p><b>Vocabulary constraints</b> limit the set of concepts that can be taken as valid values in an instance of a coded attribute or data type.</p> | <p><b>Vocabulary constraints</b> limit the set of concepts that can be taken as valid values in an instance of a coded attribute or data type.</p> | ||
<p><b>Other value constraints</b> 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.</p> | <p><b>Other value constraints</b> 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.</p> | ||
+ | ====Cloning classes==== | ||
+ | <p>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.</p> | ||
+ | <p>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:</p> | ||
+ | <ul> | ||
+ | <li>In order to be a source class for more than one clone in the derived model, a class in the base model: | ||
+ | <ul> | ||
+ | <li>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).</li></ul></li> | ||
+ | <li>In order to qualify as a valid clone of a source class, the clone must obey the following rules: | ||
+ | <ul> | ||
+ | <li>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.</li> | ||
+ | <li>The clone may contain only attributes that are also part of the source class</li> | ||
+ | <li>The clone shall only use associations that are valid for the source class and are present in the base model</li> | ||
+ | <li>The cardinality and mandatory constraints for elements in the clone class cannot be less constrained than the equivalent elements in the source class</li> | ||
+ | <li>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"</li> | ||
+ | <li>The clone '''need not include attributes or associations unless they are "Required" or "Mandatory" in the source model''', regardless of their cardinality</li> | ||
+ | <li>The clone may not include attributes or associations that have a conformance value of "Not Permitted" in the base model</li> | ||
+ | </ul></li></ul> |
Revision as of 01:17, 11 April 2011
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.
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