This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Template:SAIF Generic IM Content Guidelines

From HL7Wiki
Revision as of 23:10, 11 April 2011 by Gwbeeler (talk | contribs) (Created page with "<noinclude><span style="color:#0000FF">Generic Content Guidelines content for SAIF Domain Information models.<br/>          <b>Only t...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Generic Content Guidelines content for SAIF Domain 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 Guidelines

  1. The DIM should have a level of abstraction somewhere between that of the RIM (the base model for this DIM), and that of the SIMs that will be derived from this model.
    1. Rationale: Abstraction makes a model smaller, and thus easier to comprehend.
  2. The DIM should reflect all of the major "design patterns" that will be used in the SIMs derived from this DIM, and each design patterns should be grouped graphically so as to make it easy to visualize.
    1. Rationale: Displaying and replicating design patterns makes the domain content (derived SIMs) more coherent and understandable.
  3. Vocabulary constraints for attributes that do not have a data type of CS in the RIM, should be constrained, if at all, by constraints (specializations) of the Concept Domain assigned to that attribute in the RIM.
    1. Rationale: Universal designs, as defined in HL7 International domain Work Groups must afford flexibility in selecting code systems to the realms that will refine these models further.
  4. Class names used within this model should reflect "universal" usage and not be targeted to usage in a particular realm, or sub-set of the domain.
    1. Rationale: Universal designs must be understandable to all who need to use them.
  5. Attribute and association cardinality and attribute data types constraints should be limited to those constraints that are appropriate for every use of that attribute anticipated within the domain.
    1. Rationale: Constraints adopted at the DIM level cannot be relaxed when constructing SIMs for the domain, and therefore must be adopted with caution.
  6. Designating an association traversal or an attribute as "Mandatory" or "Required" should only be done when the domain Work Group is certain that all derived models will also need these elements to be "Mandatory" or "Required".
    1. Rationale: Constraints adopted at the DIM level cannot be relaxed when constructing SIMs for the domain, and therefore must be adopted with caution.