This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "TemplateId"

From HL7Wiki
Jump to navigation Jump to search
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
A globally unique, non-semantic, identifier for the Template. This is the primary identifier for all [[Template]]s.  
+
<div class="messagebox cleanup metadata">
 +
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 +
<div style="background:#F0F0F0">
 +
This page documents an [[:category:MnM Open Hot Topic|Open]] [[:category:MnM Hot Topic|MnM Hot Topic]], i.e. a methodology issue requiring a resolution from Modeling and Methodology.
 +
</div>
 +
</div>
 +
[[Category:MnM Resolved 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 knowledge artefact to which it conforms.
+
'''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.
  
 
Notes:
 
Notes:
*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 can be ignored by receivers.  
+
*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.
*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. Prohibiting custom templates would be similar to prohibiting local extensions, which you're also not allowed to do.  
+
*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.  
 
*If an application rejects a message because that message contains a template the application doesn't recognize, that application would be considered non-conformant.  
*(discussion)The use of specific templateId may be constrained, see [[Constraints on infrastructureRoot attributes]]
+
*The use of specific templateId may not be constrained, see [[Constraints on infrastructureRoot attributes]]
 +
 
 +
===Example===
 +
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.113883.2.1.3.2.4.12" extension="REPC_MT000103.Barthel_Index">
 +
  <code codeSystem="2.16.840.1.113883.2.6.15.1" code="Barthel-index"/>
 +
  <id codeSystem="2.16.840.1.113883.3.19.4" extension="373645"/>
 +
  <effectiveTime value="200601191211"/>
 +
  <value value="3"/>
 +
  &lt;!-- various bits omitted from this example --&gt;
 +
<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. 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 [[Template]]s. TemplateId is an attribute of the [[InfrastructureRoot]] class.
 +
 
 +
==Resolution==
 +
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

Latest revision as of 16:23, 6 July 2007

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.

Notes:

  • 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

Example

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.113883.2.1.3.2.4.12" 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 -->
<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. 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.

Resolution

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