Static Model Working Terms

Working Terms

• SIM: Semantic Information Model

An artifact that defines an information model that specifies constraints on a reference model.

• HSIM: Hierarchial Semantic Information Model

An artifact that defines a hierachial information model that specifies constraints on a reference model. This is suitable to produce an information technology specification that can serialize information as a wire protocol.

• DIM (Domain Info Model) – to represent the concept space (i.e. elements of interest) for a ‘domain’ (HL7 content area)

   * static model
   * need not be serialisable
   * may have multiple entry points (entry point = class where serialisation begins)
   * must be a valid constraint of the RIM and possibly other DIMs
   * may include “stubs” (linkages to CMETs, other packages)
   * (corresponds to ‘old’ DMIM)

• CIM (Constrained Info Model) – to define content for communications ‘over the wire’ or parent of the same (abstract)

   * static model
   * must be serialisable
   * must have one (and only one) entry point
   * must be derived from a DIM or another CIM
   * may include “stubs” (linkages to CMETs, other packages)
   * (corresponds to ‘old’ RMIM, HMD, Message Type, part of a CMET)
   * you must transmit the element names

• Interaction Profile - A fully bound LIM starting at the root of the interaction

   * specific to a single Interaction
   * contains
         o 1 Profile Static Model
         o receiver responsibilities for the Interaction
         o other local vocabulary constraints assertions
 

• Implementation Profile - A fully constrained conformance profile.

NOTE: need profile ID, plus packageID (e.g. the message implimentation manul) need RIM harmonization proposal.

• LIM (Localized Info Model) – allows additional constraints of models without impacting the interoperability of instances with other instances conformant to the (more generic) parent CIM

   * static model
   * must be serialisable
   * must have one (and only one) entry point
   * must be derived from a CIM or another LIM
   * may include “stubs” (linkages to CMETs, other packages) if it’s a Template
   * association names are not reflected as element names in ITSs (e.g. XML)
         o the names of the CIM are transmitted

• LIM types

         o Template – to assert constraints on a static model without requiring changes in element names
               + can be applied to any static model and at any point within that model where the descendent tree from that node is equivalent to (or is a proper subset of) the static model on which the template is based
               + entry point need not be the same as its parent CIM
         o Profile Static Model
               + a fully bound LIM starting at the root of the Interaction
               + start at Message or Batch – goes through all wrappers, CMETs, CMETs inside CMETs, etc. to define constraints
               + specific to an Interaction
               + entry point is the same as the entry point of the CIM it is based on
   *

1.3.6 Stub - to reference content from any static model to a serializable static model

   * defines both a minimum and maximum static model, which represent constraints on what model can be bound to the stub
         o a parameter in a parameterised type (e.g. in a List)
   * you don’t know what message type will be used (bound to the stub)
   * where used today
         o in Transmission wrapper to reference Control Act
         o Control Act wrapper to reference ‘payload’definition
               + today, payloads only have CMET stubs (no other types of stubs)
         o Control Act wrapper to reference a query definition
         o a CMET reference is a special case of a Stub, min.=max. (you know what message type is used)
   * by Interaction time, all stubs will be bound
   * a CMET may reference a stub (CMETs with exit points) –exit points need to be bound by the model that references the CMET, either to a class or a stub inside the referencing model
         o e.g. specimen – allows reference to patient CMETs – bind patient stub with specimen stub
   * stubs = parameterised types = UML generic (but HL7 allows an optional minimum model to be asserted)

1.3.7 Entry point – class where serialization can begin

1.3.8 Conformance Profile

   * Conformance Profile
         o contains
               + 1-to-many Interaction Profiles
               + other conformance info (e.g. Realm, transmission technology)
         o

1.3.9 Conformance Statement – textual language assertion of a fully-defined Conformance Profile

1.3.10 (NOTE: need profileId plus packageId (e.g. the message implementation manual) – need RIM harmonization proposal for new attribute)