Incomplete Static Models

Introduction

In order to use static models for templates, we need to be able to have incomplete static models. An incomplete static model is a model that leaves some content open.

Rationale

Usually a static model is complete - any content not described by the model is disallowed. For normal static models - D-MIMs, R-MIMs, CMETs - this makes complete sense. But when it comes to templates, such completeness is often not appropriate.

A typical case is the use case for a template that says that this observation must have a snomed code associated with it. A simple static model would therefore have a single Act Class, with classCode <= OBS, and a constraint on the code to say that there must be a term from snomed.

(It's not the focus of this page, but assuming that the oid for the snomed code system is [snomed_oid], then the constraint might look something like this in OCL:

 inv: code->hasCodeSystem([snomed_oid])

This fragment depends on some decorations on CD, but that's not what this page is about)

The problem with the simple static model described above is that it says that the observation cannot have anything else on it - only a classCode and a code, and no associations. Not very useful.

An alternative is to add every attribute, and also to add every possible association. This includes all the classes that might be encountered, including at the very least the entire RIM backbone - but this is all getting very difficult. At the least we can say that the conceptual problems this brings up can be ignored since no one would ever bother writing such a template for a simple statement.

The solution to this is to allow a static model to say somethings, and refrain from making rules about some content. This is known as an incomplete static model.

Maximum and Minimum Models

The first option that we (LM,GG) considered was maximum and minimum models. This is a concept that is used with stubs to describe what possible models can be bound to the stub. The model that is bound must be between the two models, minimum and maximum.

This concept works when a model is compared to minimum and maximum models (at least for some usages), but doesn't work with instances. It's relatively easy to figure out how cardinality works with minimum and maximum models, but fixed values is a problem. If you tried to capture the case above using a min/max approach, it turns out the min model is irrelevant, and the max model must make the rule - and it turns out to be the same model as the full model with the backbone etc above.

So this is not useful.

Incomplete Classes

A workable approach is to add a flag to classes in static models. The flag on the class is called "incomplete". If this is flag is set, then any attributes and associations that are not mentioned are not constrained in any fashion. Any attributes or associations that are defined carry the normal meaning.

The default value for the flag is false - classes are always complete by default.

This flag can only be set to true in a LIM. If a model is to be used as a CMET, Message, Document etc, then the flag must be false. (All sorts of problems if you tried to allow incompleteness in these kinds of artifacts).

To prohibit an attribute in an incomplete class, set the cardinality to [0..0]? You cannot prohibit an attribute if it is mandatory in the model from which this is derived, of course.

Like attributes, associations are prohibited by setting the cardinality to [0..0]. Since associations are not distinguished by name, but by their data content (at least not when used as templates), what is prohibited is the existence of any association that meets the criteria specified by the constraints on the class that the association points to.

Methodology consequences

Extension

Definitions:

• Derivation - models are derived from other models. This is a human level statement which asserts that the model was designed with the intent of being consistent with the model from which it is derived.
• Constraint/Extension - models may be constraints or extensions of other models. (models may also be incompatible)

Rules

• Templates may be derived from a particular model, and may be constraints or extensions of other models.

• Incomplete templates are always *derived* from the RIM.

• A model may be applied as a template on another model if it is either a constraint or an extension (or, most usefully, both) but not if it is incompatible.

• Only LIMs are allowed to contain incomplete classes (for now).

• Incomplete templates cannot be used as expressed models

[Note that there is an pending outstanding hot topic that Lloyd will create that will further discuss the relationship between derivation, constraint and extension, but for now these rules are adopted in the interim period)

Diagrams

The flag will be shown on the model as a ? (bright purple border? snazzy picture?)

The flag will be shown as the text "Incomplete" in italics and bold in the table views.

The flag will be stored in the MIF as a boolean attribute with a default value of false on the Class type.

Tooling

In order to fully support this model, the following things are needed in the various tooling

Static Model Designer

• support for a "model is extension" flag - setting, storing and displaying
• support for a "class is incomplete" flag - setting, storing and displaying
• support for entry points on any class
• MIF validation routines that know about these new rules

Validation Engine

• template validation that understands incompleteness.

Ideally the visio tooling could be extended to at the very least have rudimentary support for the two flags. This would allow us to start exploring how these new template features allow us to capture the existing CDA templates as static models.

Examples

Use snomed codes

This example is based on the use case discussed in the introduction to this document. Making this into a template:

• define a static model with a single class.
• Set the incomplete flag to true
• set the classCode <= OBS
• add the snomed constraint from above (inv: code->hasCodeSystem([snomed_oid]))
• leave all the other attributes off.

Further Discussion

This was presented in MnM Wed Q3 May 2007. There was strong pushback to the idea of using models for extension, but there was general agreement on the need for incomplete classes in templates and entry points on any classes. A motion was passed on this point

(Grahame to get this out of MnM minutes once they are posted--GrahameGrieve 11:12, 3 May 2007 (CDT))

There was much discussion concerning the difference between models and delta models, and applying templates as models without considering their derivation heirarchy. This was not conclusive.

This leaves Lloyd and Grahame to work on the methodological approach that supports the desired outcome.

Keith is writing a document on the subject of mathematical operations on models as sets. This may assist in the further development of the subject. Grahame to link here -> <- when Keith posts the document to the wiki.