Constraints on infrastructureRoot attributes

Issue

There are four attributes listed in InfrastructureRoot: nullFlavor, realmCode, typeId and TemplateId.

Their use follows rules outside the mandates of the committees when performing their design work. A very conscious decision was made to not allow these attributes to be constrained by committees because it was felt that they should not be constrained (at least not in the usual manner - you can constrain nullFlavor with the mandatory indicator, and in MIF 2.0 you can require conformance with certain templates).

If things are supported by tooling or by the MIF, then that does not mean anything in terms of methodology. One can't conclude anything from something being supported by the MIF. Methodology leads, tools follow. Rene spronk 23:13, 21 Jun 2006 (CDT)

Discussion

However some people think this decision needs to be revisited (i.e. committees should be able to constrain these attributes when designing models).

Which is fine, and as usual puts the burden on those that don't agree with the current status quo to bring forward use-cases which may lead to the methodology being changed. I haven't seen that use-case yet. Rene spronk 23:13, 21 Jun 2006 (CDT)

The aim is to answer these questions, for each of them:

1. Why it is there? ( document rules/decision )
2. Could it be constrained in the cloned classes ( Is it allowed?)
3. Should it be constrained in the cloned classes, if allowed ( should it be?)
4. How it should be contrained in the cloned classed, if allowed (How do we do it?)

MnM Conference call 20060630

• Question here should such constraints be applied? (RIM, D-MIMs, Templates?)
• What are the use-cases for constraining InfrastructureRoot elements these?
• Belief that additional constraints on null flavors at the RIM attribute or datatype level may make sense (e.g PINF, NINF)

Note that it's wrong to constrain templateId in any sense - it has no meaning, it is only provided to support instance validation, and no meaning may be associated with it. (From TemplateId)

The NHS would like to use CDA and insist that instances can be validated against certain templates. Hence it would like to make the templateId mandatory in certain places. Is this unreasonable ? Also, since message size is a concern, we want to prevent a long list of templateIds being sent when it is known that the recipient will ignore them. So we would like to make it mandatory 1..1 as a local constraint. Rik Smithies 19 Sep 2006

This is a strongly localised form of conformance, with the virtue of being easier to test and identify the source of errors - since sending applications will have to be configured to add the required template references. This prevents a supplier from ensuring that they conform with the constraints by simply restricting the options for content creation within the application. In practice this GUI-only tailoring is probably not an approach that many suppliers would take, and they are likely to be able to populate the template identifiers as part of the data extract process Charliemccay 09:58, 15 May 2007 (CDT)

Proposed Resolution

From MnM conference call 2006-08-04 (Minute quotes in brackets)

1. ITS should enforce that null flavor only be permitted on associations (and attributes) which are non-mandatory [nullFlavor can be constrained by setting Mandatory]

2. RealmCode should be an element which remains within the control of committees. InM should include it for message types rooted in Transmission classes and CDA should include it in the root Document class. Other committees should only expose it if they have an explicit use-case [realmCode must be specifically asserted by the committee. We recommend that INM include this for transmission.]

3. typeId should only be exposed in the schemas for the root class of a message type [templateId should never be prohibited by a committee]