See below for a section which contains the text of the MnM Hot Topic.
TemplateId is a globally unique reference that can be used by look-up services and registries in an international distributed computing environment, and can be stored within each instance as a permanent record of the constraint artefact to which it conforms.
- The constraint applies from the "point of occurrence" (of the templateId attribute) in the model. A sender can assert any templateID anywhere they like. It must be ignored by receivers for all purposes except validation.
- receivers are not required to validate against the templates
- There's no reason to prohibit the declaration of any templates at all, because the declaration of non-recognized templates has no impact on the receiver.
- If an application rejects a message because that message contains a template the application doesn't recognize, that application would be considered non-conformant.
- The use of specific templateId may not be constrained, see Constraints on infrastructureRoot attributes
The example shows an instance (with ID 373645) of an observation (of type Barthel-index). The observation uses the REPC_MT000103.Barthel_Index template.
<Observation> <templateId root="2.16.840.1.113818.104.22.168.2.4.12" extension="REPC_MT000103.Barthel_Index">
<id codeSystem="2.16.840.1.113822.214.171.124" extension="373645"/> <effectiveTime value="200601191211"/> <value value="3"/> <!-- various bits omitted from this example --> <Observation/>
Hot Topic: Definition of TemplateId
The existing definition of InfrastructureRoot.templateId is:
When valued in an instance, this attribute signals the imposition of a set of template-defined constraints. The value of this attribute provides a unique identifier for the templates in question.
The problem with this is that it doesn't clarify exactly what the implications of asserting this conformance to a set of constraints are.
A number of possible implications have emerged from consideration of this subject. This is some of the things people think you can use templateId for:
- supporting validation by tools
- finding concepts quickly in the instance
- allow processing based on the contents of the template model
- implying other related information (such as definitions the user saw when entering the data)
All but the first usage violates the intent of semantic interoperability based on the RIM, and are dangerous because they add hidden meaning or are outside the control of the modeling process.
For this reason, this hot topic proposes to add the following text to the definition of templateId, after the existing text:
The templateId attribute may only be used in support of validation of instances. Applications are not allowed to associate any other meaning against the templates, nor are applications allowed to reject instances based on the templateId unless the templateId refers to a template to which the instance does not conform.
Note that this hot topic proposed resolution has caused modifications to Constraints on infrastructureRoot attributes. If the proposed resolution is changed, then that topic may need to be modified