This wiki has undergone a migration to Confluence found Here


From HL7Wiki
Revision as of 16:23, 6 July 2007 by Lmckenzi (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

See below for a section which contains the text of the MnM Hot Topic.

Basic Definition

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.

  <templateId root="2.16.840.1.113883." extension="REPC_MT000103.Barthel_Index">
  <id codeSystem="2.16.840.1.113883.3.19.4" extension="373645"/>
  <effectiveTime value="200601191211"/>
  <value value="3"/>
  <!-- various bits omitted from this example -->

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. Messaging applications are not  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

A globally unique, non-semantic, identifier for the Template. This is the primary identifier for all Templates. TemplateId is an attribute of the InfrastructureRoot class.


Revised wording to reflect that only messaging disallows rejection for non-expected templates. 2007-07-06 Lloyd to submit harmonization proposal with above revised wording. Motion Lee, Second Mead, 4-0-0