"Shallow" vs. "Deep" LIMs (Templates)

Background

In discussion at the out-of-cycle constraints meeting in Washington on 10/29/2005, M&M discussed the issue of defining and supporting both "shallow" and "deep" LIMs. (This occurred after a discussion that templates are represented as a "Local Information Model" - LIM.)

The discussion arose in the context of determining how to assert the binding to a LIM in a message instance. The issue arises because

• The element names in a LIM do not need to be the same as the name in the CIM (Message Type) that the LIM element constrains.
  • This is asserted in the M&M Template Implementation Specification.
  • This rule allows a single template (LIM) to be asserted as a constraint against multiple, independently defined message types (CIMs)

• If a receiving system seeks to validate a received instance against the templates, it must perform a coordinated "tree walk" on both the message and the LIM simultaneously in order to determine which LIM element should be governing each node.

• If the sending system were to include in the nodes of the instance message an identification of the LIM element used to constrain the instance node, the coordinated tree walk is straightforward.

• Absent such identification in the instance, there are numerous example cases in which the coordinated tree walk that identifies a single node in the LIM which constrains each node in the instance becomes computationally burdensome or even impossible.

As a consequence, discussion arose on the mechanisms by which such references can be made. It included concerns that the current method of inclusion of CMETs in a design may obscure the identification of where a CMET begins. In the XML ITS the element naming is the same whether a CMET is used or the same content is fully expressed in the parent design. This was done to allow common components to be identified and split off into CMETs the designs without resulting in changes in the instances. However if the same approach is taken to referencing LIMs from the instance, then there would need to be explicit references to component models as well as to the LIM that references them. This obscures the way in which a LIM may refer to other LIM's to allow users to build LIMs that reuse the concepts defined in other LIM's in a greater pattern.

This led to the consideration of "shallow" versus "deep" LIMs (templates).

Processing Requirements

We discussed the processing requirements for LIM's in instances.

• LIM's are useful because they can allow the instance reader to associate knowledge of the instance over and above the inherit semantics of the information in the instance
• The instance must be able to identify the LIM(s) that have been applied to the instance.
• Senders may choose not to identify the LIM in the instance, but in this case the receiver may not know to invoke special LIM dependent processing.
• LIM's may further unroll the relationships in the CIM that is being used
• Readers wishing to use the information associated with the further unrolling must be able to associate the parts of the instance with the parts of the LIM

This leads to the more technical requirement stated above:

• If a receiving system seeks to validate or fully understand a received instance against the templates, the receiving system must perform a coordinated "tree walk" on both the message and the LIM simultaneously in order to determine which LIM element should be governing each node.
• If the sending system can (and does) include in the nodes of the instance message an identification of the LIM element used to constrain the instance node, the coordinated tree walk is straightforward.
• Absent such identification in the instance, there are numerous example cases in which the coordinated tree walk becomes computationally burdensome and some in which it is virtually impossible.

"Shallow" and "Deep" LIM references

There are two options for how a LIM that contains CMET references to component models may be referenced from an instance.

1. "Deep" LIM references follow the same rules as the ITS for CIMs, and component models of the LIM are not differentiated in the instance. Thus for every node in the instance that is constrained by a LIM, the identifier for the LIM static model will be included along with the identifier for the node itself.
2. "Shallow" LIM reference rules require that the identity of the static model in which the node constraint is defined be included in the instance with the the identifier for the class.

The following example may help to clarify the situation. There is a LIM for "Diabetes Annual Review" that includes a LIM for "Body Mass Index" as a CMET, and both are defined as LIMs against the Clinical Statement Model. An instance of a Care Provision message is created for an annual review encounter, an dthe sender wants to assert that the instance conforms to the LIM for "Diabetes Annual Review". If the deep LIM approach is taken then each node in the subtree of the nmessage that contains the annual review data will include a templateId that points to the "Diabetes Annual Review" LIM, and to the name of the appropriate class within that model (or the CMETs that it references). In this case the instance will not include any explicit reference to the "Body Mass Index" CMET, but the receiving system will be able to walk the tree of the instance, and the LIM for "Diabetes Annual Review" and discover that the CMET has been used. If the shallow LIM approach is taken then the Identifier for the "Diabetes Annual Review" LIM will be included for all elements in the subtree that conform to the LIM, until the start of the subtree that conforms to the "Body Mass Index" branch, at which point the Identifier for the "Body Mass Index" model will be included. In all cases alongside the identifier for the model will be the identifier for the class within the model that confrmance is being asserted to. Note that in the Shallow reference a receiver that has rules for processing "Body Mass Index" structures will be able to recognise the structure even if they do not recognise the "Diabetes Annual Review" structure.

Note also that the "Shallow" and "Deep" distinction applies to the way that the reference to the LIM in the instance is provided, and is not a property of the definition of the LIM itself.

"Deep" LIM (template)

A "deep" LIM (template):

1. is simply any valid static model, with the full richness and complexity allowed in any HL7 message type design.
2. establishes constraints for all the elements that it contains.

Although another LIM (LIM-b) might also be asserted against elements that are "internal" to the LIM in question (LIM-a), this assertion is in addition to the assertion of LIM-a, not a part thereof.

All LIM's are bound to the instance at a single point, which must link that node of the instance to the root node of the LIM. There are three different approaches to binding parts of the instance to the parts of the LIM within the context of the root nodes.

1. Readers (receivers) are expected to figure out the linking themselves
2. Writers (senders) are expected to link every node in the instance to the associated name in the LIM (by using the templateId property of InfrastructureRoot)
3. Writers (senders) are expected to link the important nodes to the LIM, and need not link the others to the LIM

The first solution is known to be computationally incomplete, so cannot be adopted. The problem with the third option is that it is not possible for HL7 to define which nodes are "important", and even if it was, it would still introduce unnecessary optionality.

So this leads to a rule:

• If a LIM is associated with the instance, then all sub-parts of the instance which conform to the LIM must identify the name of the LIM element in their templateId property
  • This rule is required to enable deep LIM's to be appropriately processed by readers.

"Shallow" LIMs (templates)

Purpose

A "shallow" LIM is a construct designed to support bottom-up composition of templates. It creates sub-templates that can be included in larger LIMs to build a larger concept. Thus a LIM to represent hemoglobin, and one to represent hematocrit can be defined and then used in the definition of a blood test. This pattern has been used successfully in several health record implmentations.

Requirements In order to fullfill this purpose, a "shallow" LIM should:

• present no ambiguities when doing a coordinated tree walk of an instance and the LIM;
• have the ability to declare, in a message instance being constrained by a LIM (LIM-a, above) that a portion of the message is constrained by another, subsidiary LIM that is a component(??) (LIM-b, above) of the original LIM.

Rules for a proper "shallow" LIM The rules that determine whether a LIM is a valid "shallow" LIM are those rules which assure that the node tree of an instance can be unambiguously walked in coordination with that LIM. Specifically:

1. A "shallow" LIM may "include" a subsidiary LIM at any node (class clone).
2. The "shallow" LIM must 'include' a subsidiary LIM at any point where: the maximum cardinality of an association is greater than one.

(Note - these rules are illustrative, not technically complete)

Mixing Deep and Shallow LIMs

Deep and shallow LIMs are not incompatible. Each are enabled by a different solution. Deep LIMs are enabled by the rule that each element must identify it's LIM name. Shallow LIMs are enabled by providing a mechanism for LIMs to include another LIM. The point of describing them in the terms above is to describw how the templates could work in the absence of each technology

Straw Vote

A straw vote was taken. A few individuals were still unclear on the concepts but most present believed that both solutions should be available. This solution confers maximal flexibility on the template desiger to balance between management and reuse.