Difference between revisions of "Template Specification"

From HL7Wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
+
Templates Specification
 +
 +
  1)  Introduction
 +
 +
  2)  Specification
 +
 
 +
  a)  Templates Are Static Models (what they are, where defined)
 +
 
 +
  b)  Taxonomy of static models
 +
 
 +
    i)      RIM (one and only one)
 +
      (1) Need to document entry points (Act, Role, Entity, Transmission,  QueryParameter, …)
 +
      (2)  Bound to Universal realm
 +
 
 +
    ii)    DIM
 +
      (1) Must have one or more Entry Points to be useful for deriving CIMs
 +
      (2)  Can include by reference CIMs derived from another DIM (CMETs)
 +
      (3) Can include stubs (an unbound reference constrained a minimum and maximum CIM)
 +
      (4)  Derived from RIM or another DIM
 +
      (5)  Bound to universal realm
 +
      (6)  Attributes may only be constrained (effectively) to specific codes where the value set binding is in the universal realm.
 +
    iii)  CIM
 +
      (1) Single entry point and serializable
 +
      (2) Familiar examples: rmim, hmd, mt, cmet, wrapper
 +
      (3)  Derived from a DIM or another CIM
 +
      (4)  Primary balloted, normative artifact for domains
 +
      (5)  Must be bound to one or more realms (including universal, in which case this is the only binding)
 +
      (6)  Where the CIM has been bound to a specific realm, attributes may only be constrained to specific codes found in value sets bound to all of the realms to which the CIM is bound or found in a universal value set.
 +
    iv)  LIM
 +
      (1)  Names of elements, as represented over the wire, must be the names of the corresponding elements within the nearest ancestor CIM.
 +
        (a)  Parsing a LIM imposes no rules not contained in the CIM
 +
      (2)  Derived from a CIM or another LIM
 +
      (3) template
 +
        (a)  Intended for:
 +
          (i)    broad re-use and to be applied to different models and interactions
 +
          (ii)  represent constraints for a more restrictive application than the base CIM represents
 +
        (b)  The entry point need not derive from an entry point of the CIM from which it is derived.
 +
      (4) profile is made up of:
 +
        (a)  Intended to have narrow scope and represents detailed constraints on how a particular interaction is (or is intended to be) used in a given context
 +
        (b)  Static profile
 +
          (i)    (a template that starts at the Entry Point of the outermost CIM to which the interaction in the profile was bound)
 +
          (ii)  Cannot contain stubs (must fully define all data elements within all contained models of the parent CIMs)
 +
        (c)  Dynamic profile
 +
    v)    Issues – How can we handle context inheritance in order to allow templates to start at other than the Entry Point of a CIM
 +
      (1)  Recommend – If starting a LIM at a node that inherits context from an ancestor node in the CIM, the LIM will not inherit that context.  Context can only be defined within the scope of the LIM.
 +
      (2)  Also – We need to be able to designate entry points for LIM use that are stereotyped for that purpose.
 +
    vi)  NOTES
 +
      (1) "Business names" are available for clones, association role names, and attributes at the level of DIM and below. (and for data types and data type properties)
 +
    vii)            In MIF allow a static model to define a data type flavor for use in the context of this static model, would allow a template to define a data type flavor for use within the template
 +
    viii)        All constraints should be expressed in one of the HL7-designated, testable constraint languages in order to be fully usable.

Latest revision as of 20:51, 14 July 2005

Templates Specification

 1)   Introduction

 2)   Specification
 
  a)   Templates Are Static Models (what they are, where defined)
 
  b)   Taxonomy of static models 
 
    i)       RIM (one and only one)
      (1) Need to document entry points (Act, Role, Entity, Transmission,  QueryParameter, …) 
      (2)  Bound to Universal realm
 
    ii)    DIM 
      (1) Must have one or more Entry Points to be useful for deriving CIMs
      (2)  Can include by reference CIMs derived from another DIM (CMETs)
      (3) Can include stubs (an unbound reference constrained a minimum and maximum CIM)
      (4)  Derived from RIM or another DIM
      (5)  Bound to universal realm
      (6)  Attributes may only be constrained (effectively) to specific codes where the value set binding is in the universal realm.
    iii)  CIM
      (1) Single entry point and serializable 
      (2) Familiar examples: rmim, hmd, mt, cmet, wrapper 
      (3)  Derived from a DIM or another CIM
      (4)  Primary balloted, normative artifact for domains
      (5)  Must be bound to one or more realms (including universal, in which case this is the only binding)
      (6)  Where the CIM has been bound to a specific realm, attributes may only be constrained to specific codes found in value sets bound to all of the realms to which the CIM is bound or found in a universal value set.
    iv)  LIM 
      (1)  Names of elements, as represented over the wire, must be the names of the corresponding elements within the nearest ancestor CIM. 
        (a)  Parsing a LIM imposes no rules not contained in the CIM
      (2)  Derived from a CIM or another LIM
      (3) template
        (a)  Intended for:
          (i)     broad re-use and to be applied to different models and interactions
          (ii)   represent constraints for a more restrictive application than the base CIM represents
        (b)  The entry point need not derive from an entry point of the CIM from which it is derived. 
      (4) profile is made up of:
        (a)  Intended to have narrow scope and represents detailed constraints on how a particular interaction is (or is intended to be) used in a given context
        (b)  Static profile 
          (i)     (a template that starts at the Entry Point of the outermost CIM to which the interaction in the profile was bound)
          (ii)   Cannot contain stubs (must fully define all data elements within all contained models of the parent CIMs)
        (c)  Dynamic profile
    v)     Issues – How can we handle context inheritance in order to allow templates to start at other than the Entry Point of a CIM
      (1)  Recommend – If starting a LIM at a node that inherits context from an ancestor node in the CIM, the LIM will not inherit that context.  Context can only be defined within the scope of the LIM.
      (2)  Also – We need to be able to designate entry points for LIM use that are stereotyped for that purpose. 
    vi)  NOTES
      (1) "Business names" are available for clones, association role names, and attributes at the level of DIM and below. (and for data types and data type properties)
    vii)            In MIF allow a static model to define a data type flavor for use in the context of this static model, would allow a template to define a data type flavor for use within the template
    viii)         All constraints should be expressed in one of the HL7-designated, testable constraint languages in order to be fully usable.