Static Model 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.
1.3 Working Terms
1.3.1 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)
1.3.2 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
1.3.3 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 *
1.3.4 Implementation Profile - A fully constrained conformance profile.
NOTE: need profile ID, plus packageID (e.g. the message implimentation manul) need RIM harmonization proposal.
1.3.5 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)