Specification and Use of Reusable Constraint Templates

HL7 V3 provides a global framework for exchange of healthcare information as documents or messages by providing a framework for constructing instances of data according to agreed definitions in a standard fashion. The globally agreed definitions are often fairly general in nature due to the intention of their scope or the requirements to be globally suitable, and a framework for making additional rules for more specific knowledge models is required.

Templates are used to provide this framework within the context of HL7 V3 and the Clinical Document Architecture. This document describes how templates are specified, registered and used.

Over the course of the life of this document, many people have contributed in one way or another:

• Alexander Ruggieri, Mayo Clinic
• Amnon Shabo, IBM Research
• Andrew Goodchild, NeHTA Australia
• Angelo Rossi-Morri, CNR
• Bas van Poppel, Hiscom BV
• Brett Esler, Pen Computer Systems
• Calvin Beebe, Mayo Clinic
• Charlie McCay, Ramsey Systems Ltd.
• Charlie Mead, Oracle
• Craig Parker, Intermountain Health
• Dale Nelson, Zed-Logic Informatics, Inc.
• David Markwell, Clinical Information Consultancy
• Dipak Kalra, UCL
• Fred Behlen, LAI Technology
• Galen Mulrooney, J P Systems, Inc
• George W. Beeler, Jr., Beeler Consulting LLC
• Grahame Grieve, Kestral Computing
• Gunther Schadow, Regenstrief Institute for Health Care
• Harold Solbrig, Mayo Clinic
• Harry Solomon, GE Medical Systems
• Ian Townend, NHS
• Ioana Singureanu, Eversolve / Patriot Tech
• Jane Curry, HL7 Canada
• Jennifer Puyenbroek, McKesson Information Solutions
• John Koisch, OCTL Consulting
• John Silva, Philips Medical Systems
• Ken Rubin, EDS
• Liora Alschuler, alschuler.spinosa
• Lloyd McKenzie, Lloyd McKenzie & Associates Consulting Ltd.
• Mark Shafarman, Shafarman Consulting
• Martin Kernberg, MD, UCSF
• Mary Ann Juurlink, Killdara Corporation
• Mike Henderson, Eastern Informatics
• Mike Mair
• Paul Biron, Kaiser Permanente
• Peter L. Elkin, Mayo Clinic
• Richard Harding, Queensland Health
• Rik Smithies, NProgram Ltd
• Robert H. Dolin, Kaiser Permanente
• Russ Hamm, Mayo Clinic
• Sam Heard, MD, Ocean Informatics
• Sandy Boyer, BSP, Consultant
• Ted Klein, Klein Consulting, Inc
• Thomas Beale, Deep Thought Informatics
• Tim Benson, Abies Ltd
• William T.F. Goossen, Acquest Research and Development

A template is an expression of a set of constraints on the RIM or a RIM derived model that is used to apply additional constraints to a portion of an instance of data which is expressed in terms of some other Static Model. Templates are used to further define and refine these existing models to specify a narrower and more focused scope.

A template is represented by:

• a formal definition in one or more human readable languages or notations
• [optionally] a formal definition as a static model
• [optionally] one or more implementation specific representations that can be used to validate instances in a particular context

While the constraints that the template expresses must be based upon a RIM derived static model, and must be expressible as a static model, templates need not actually express the constraints as a static model, though this is encouraged where possible. If a static model is present, it is considered to be a human readable notation.

In addition, there is a set of metadata associated with every template to describe the purpose and use of the template.

In HL7 V3, conformant instances of data will generally conform to many different models at once. Of the full set of models that an instance conforms to, only a subset will be of interest, or even known. Of those that are of interest, the first and most important model is the RIM itself. All conformant instances are proper expressions of the base object model, which is the RIM.

Models may exist at many levels of abstraction. This includes Static Models, which describe a set of constraints on the RIM that clarifies how some real world concept is properly described in the RIM. However these static models are generally rather broad and generic. Other more detailed models may conform to these static models refining the generic concepts to more specific ones such as particular laboratory tests.

Templates are used to constrain and define the structures of these more atomic concepts, and are able to be reused in multiple different contexts wherever the real world concept they describe occurs, such as a laboratory report in a CDA document or quoted within a pharmacy message as supporting evidence.

Instances of data, either documents or messages, will conform to some other model, such as the CDA itself, or a message as specified by an interaction definition.

Portions of the data will also conform to the additional model as specified by one or more templates. At times it will be useful to reference the template in the instance itself, to make use of templates more practical. Whether a template is referenced explicitly or some definitional construct establishes its use in the instance, when it is known that a portion of the instance conforms to a template, a template is said to “be applied” to the instance.

All exchange of data using HL7 V3 is covered by an Interoperability Paradigm (defined in section Interoperability Paradigm) that defines what forms the instances take and how templates are used.

Template concepts and issues are discussed in depth with examples in the section Template Concepts & Issues.

Templates must be uniquely and unambiguously identified. Each template is assigned an identifier. The identifier is used within an instance when applying a template to a portion of the instance, in the templateId attribute that is available on every class, from the base class InfrastructureRoot.

The InfrastructureRoot.templateId has a type of LIST<II>, allowing for more than one template to be applied.

The order of the template identifiers supplied in an instance may be significant. In general, the first stated template should be the most constrained, and subsequent ones increasingly relaxed. However it may be unclear which template is most constrained, and there is no computational algorithm for determining this, so this is not a normative requirement.

It is not required that all templates to which the instance conforms to are actually identified in the instance; this is up to the sender of the instance. It may be possible for a receiver to determine that there are other models to which the instance is also conformant even though they are not identified in the instance.

Each template identified in the list is represented by an II, which has two important attributes, root and extension. The template identifier must clearly specify the root and optionally an extension that unambiguously identify the template. In this document, template identifiers are represented using the format root:extension.

There is no identified normative method to locate a template from its identifier. Templates may be registered in one or more template registries, but the template identifier does not determine where a template may be found.

Any exchange of data in the form of V3 instances requires some common understanding that establishes the ground rules for V3 based information exchange. The common understanding must establish when information is exchanged, in what form it is exchanged, how application implementation details are specified, and, of interest to this specification, how templates are to be used. This common understanding is known as the interoperability paradigm.

HL7 has implicitly defined two interoperability paradigms, Messaging and Documents. Other interoperability paradigms may be defined by HL7 or other bodies, for example, to support services, context integration (i.e. CCOW) or to enable specific large projects. Interoperability paradigms are not specified for specific implementations, though they may themselves specify some or many rules for how specific implementations may specify particular details; these specifications are often known as implementation contracts. For this reason it will generally only be HL7 itself that defines interoperability paradigms.

Note: The concept of Interoperability Paradigm is presently defined here in the templates specification, but it is expected to be introduced to the HL7 Development Framework (HDF). Once it is defined there, this section will be rewritten accordingly.

With regards to templates, the form of expression of the interoperability paradigm is not fixed, but it must specify how implementations can be described, when and what information is exchanged and how templates are used within this context.

Interoperability paradigms are important to the understanding of templates because they specify how templates function. Interoperability paradigms firstly establish which models are used as expressed models and which models are used as applied models, or templates (see Section Expressed, Implied And Applied Models for definitions of these terms). The rules of the Interoperability Paradigm must also specify a number of rules about how templates are to be used, including how templates may be defined, whether an application may reject an instance because of the presence or absence of appropriate template definitions in the instance, and the relationships between templates, profiles and application conformance. Interoperability paradigms may make recommendations concerning implementation specific representations that should be included within the template.

This Constrained Information Model (CIM) is based on the clinical statement pattern. It is a very generic statement that an instance may include an observation, which may have multiple components that are also observations.

Example CIM

In this example, we assume that this model is a normative CIM published by HL7, used as the basis for a message design, and that the Messaging Interoperability Paradigm applies. As a CIM, this model would generally be used as the basis for a message type in some interaction definition. If this model was used a template, the template identifier would be 2.16.840.1.113883.1.3: COCT_CM999999, derived from the HL7 oid for normative CIMS and the model identifier.

In order to be specific about how this very generic model is used, more specific models are developed. This is a model of part of the Barthel index, used as part of a diabetes annual review:

Barthel Index

For the purposes of this example, we shall assume that HL7 published this model as a template, so the template Identifier would be 2.16.840.1.113883.10: REPC_RM000103, derived from the HL7 OID for normative models, and the model identifier. If the template was not published by HL7, some other identifier would be assigned.

This instance is an XML ITS rendering of a sample set of data based on the Barthel_Index model:

    <barthelIndex>
      <code codeSystem="2.16.840.1.113883.2.6.15.1" code="Barthel-index"/>
      <derivationExpr>Sumscore</derivationExpr>
      <effectiveTime value="200601191211"/>
      <value value="3" />
      <component1>
        <continenceOfBowels>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB525"/>
          <value code="1" codeSystem="2.16.840.1.113883.2.6.15.1.1"/>
        </continenceOfBowels>
      </component1>
      <component2>
        <controllingBladder>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB6202"/>
          <value code="1" codeSystem="2.16.840.1.113883.2.6.15.1.2"/>
        </controllingBladder>
      </component2>
      <component3>
        <personalToilet>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlD520"/>
          <value code="1" codeSystem="2.16.840.1.113883.2.6.15.1.3"/>
        </personalToilet>
      </component3>
    </barthelIndex>

The Barthel index can be applied as a template to an instance of data based on the Example CIM. This instance is an XML ITS rendering of a sample set of data based on the Example CIM, with an explicit declaration of the template:

    <observation>
      <templateId root="2.16.840.1.113883.10" extension=" REPC_RM000103"/>
      <code codeSystem="2.16.840.1.113883.2.6.15.1" code="Barthel-index"/>
      <derivationExpr>Sumscore</derivationExpr>
      <effectiveTime value="200601191211"/>
      <value value="3" />
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB525"/>
          <value xsi:type="CO" code="1" codeSystem="2.16.840.1.113883.2.6.15.1.1"/>
        </observation>
      </component>
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB6202"/>
          <value xsi:type="CO" code="1" codeSystem="2.16.840.1.113883.2.6.15.1.2"/>
        </observation>
      </component>
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlD520"/>
          <value xsi:type="CO" code="1" codeSystem="2.16.840.1.113883.2.6.15.1.3"/>
        </observation>
      </componen>
    </observation>
            

This example shows how the template is applied using the templateId attribute, which identifies and asserts that the data contained in the root observation conforms to the constraints described in the template.

Each template is represented as a single XML document. The document contains the XML metadata, the human language description of the template, and optionally a representation of the model that the template expresses in a form ready for computational processing, along with a number of attachments that provide implementation specific representations of the template or contain additional supporting information.

Note: Template models are usually designed using composition so that the templates can be reused.

This is an example:

<?xml version="1.0" encoding="UTF-8"?>
<!-- 
This example was originally defined by William Goosen, and generously
offered for use in the template specification. The example has been liberally
adapted; it should not be inferred that the details in here, particularly the
metadata, have any relationship to William's original work.
 -->
<Template 
  name="Barthel Index" 
  intention="Expresses the commonly accepted definition of the Barthel Index"  
  description="This template expresses the concept of the Barthel Index using the commonly accepted definition. The Barthel Index is used for assessing a patients ability to deal with daily living"  
  version="2.01" 
  repositoryURL="http://hcxw2k1.nist.gov:8080/hlxregdoc/HCXW2K1Main.html" 
  format="HL7.Template.V1" 
  descriptionLanguage="English"  
  evidenceSource="htt//www.dundee.ac.uk/medther/Stroke/Scales/barthel.htm"  
  cautionPoints="Example Template defined for the purposes of providung an example in the template specification"  
  publicationStatus="PRODUCTION"  
  publicationStatusChangeDate="2007-07-14T10:23:00+10:00" 
  xmlns="uri:hl7.org::template" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="uri:hl7.org::template template.xsd ">
  <!-- 
    Comments on attributes:
    * version is assigned in a form suitable to the author. 
    * repositoryURL on the hypothetical basis that this template is published in the HL7 registry
    * a hypothetical evidence source is provided. 
    * publicationStatusChangeDate should be updated to be when the template specification itself is published
  -->
  <id root="2.16.840.1.113883.10" extension="REPC_RM000103"/>
  <derivationModel root="2.16.840.1.113883.10" extension="COCS_DM000000UV"/> <!--  Derived from the clinical statement pattern -->
  <referenceModelId root="2.16.840.1.113883.1.8"/> <!-- May 2007 release of the ballot. no OID is yet assigned to the RIM itself, this fictional oid used instead -->
  <publisher name="HL7, Inc" email="hq@hl7.org">
    <address>
       3300 Washtenaw Avenue,
       Suite 227 Ann Arbor,
       MI 48104 USA
    </address>
    <id root="2.16.840.1.113883"/> <!-- Is it valid to use this oid to identify HL7 in a corporate sense? -->
  </publisher>

  <revision comment="First Defined" date="2005-07-25T00:00:00">
    <author name="William Goosen" email="Williamtfgoossen@cs.com"/> 
  </revision>
  <revision comment="Revised for Template Specification" date="2007-07-14T10:23:00+10:00">
    <author name="Grahame Grieve" email="grahame@jivamedical.com"/> 
  </revision>


  <!-- 
    model: The actual template model
  -->
  
  <model abstract="false" name="BarthelIndex" sourceModel="REPC_RM000103" >
    <!-- 
       features can be either attributes or associations. 
       They must appear in the correct sort order.
    --> 
    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="classCode" datatype="CS">
    	<vocabulary extensions="false" domain="ActClass" code="OBS"/>
    </feature>
    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="moodCode" datatype="CS">
    	<vocabulary extensions="false" domain="ActMood" code="EVN"/>
    </feature>
    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="code" datatype="CD">
    	<vocabulary extensions="true" domain="ActCode" code="Barthel-index"/>
    </feature>
    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="derivationExpr" datatype="ST">
       <possibleValue>Sumscore</possibleValue>
    </feature>
    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="effectiveTime" datatype="TS"/>
    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="value" datatype="CO"/>
    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="1" name="interpretationCode" datatype="CO">
    	<vocabulary extensions="true" domain="ObservationInterpretation"/>
    </feature>
    <feature xsi:type="Association" conformance="A" mandatory="false" max="1" min="1" name="component1" rimName="outboundRelationship">
    	<target abstract="false" sourceModel="REPC_RM000103" name="Component1">
		    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="typeCode" datatype="CS">
		    	<vocabulary extensions="false" domain="ActRelationshipType" code="COMP"/>
		    </feature>
		    <feature xsi:type="Association" conformance="A" mandatory="false" max="1" min="1" name="continenceOfBowels" rimName="target">
		    	<target abstract="false" sourceModel="REPC_RM000103" name="ContinenceOfBowels">
				    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="classCode" datatype="CS">
				    	<vocabulary extensions="false" domain="ActClass" code="OBS"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="moodCode" datatype="CS">
				    	<vocabulary extensions="false" domain="ActMood" code="EVN"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="code" datatype="CD">
		    			<vocabulary extensions="true" domain="ActCode" code="BrtIB525"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="effectiveTime" datatype="TS"/>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="value" datatype="CO"/>
 		    		<derives xref="observation"/> 
		    	</target>
		    </feature>
		    <derives xref="actrelationship"/> 
    	</target>
    </feature>
    <feature xsi:type="Association" conformance="A" mandatory="false" max="1" min="1" name="component2" rimName="outboundRelationship">
    	<target sourceModel="REPC_RM000103" name="Component2" abstract="false">
		    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="typeCode" datatype="CS">
		    	<vocabulary extensions="false" domain="ActRelationshipType" code="COMP"/>
		    </feature>
		    <feature xsi:type="Association" conformance="A" mandatory="false" max="1" min="1" name="controllingBladder" rimName="target">
		    	<target sourceModel="REPC_RM000103" name="ControllingBladder" abstract="false">
				    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="classCode" datatype="CS">
				    	<vocabulary extensions="false" domain="ActClass" code="OBS"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="moodCode" datatype="CS">
				    	<vocabulary extensions="false" domain="ActMood" code="EVN"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="code" datatype="CD">
		    			<vocabulary extensions="true" domain="ActCode" code="BrtIB6202"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="effectiveTime" datatype="TS"/>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="value" datatype="CO"/>
 		    		<derives xref="observation"/> 
		    	</target>
		    </feature>
		    <derives xref="actrelationship"/> 
    	</target>
    </feature>
    <feature xsi:type="Association" conformance="A" mandatory="false" max="1" min="1" name="component3" rimName="outboundRelationship">
    	<target sourceModel="REPC_RM000103" name="Component3" abstract="false">
		    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="typeCode" datatype="CS">
		    	<vocabulary extensions="false" domain="ActRelationshipType" code="COMP"/>
		    </feature>
		    <feature xsi:type="Association" conformance="A" mandatory="false" max="1" min="1" name="personalToilet" rimName="target">
		    	<target sourceModel="REPC_RM000103" name="PersonalToilet" abstract="false">
				    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="classCode" datatype="CS">
				    	<vocabulary extensions="false" domain="ActClass" code="OBS"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="moodCode" datatype="CS">
				    	<vocabulary extensions="false" domain="ActMood" code="EVN"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="code" datatype="CD">
		    			<vocabulary extensions="true" domain="ActCode" code="BrtIB520"/>
				    </feature>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="effectiveTime" datatype="TS"/>
				    <feature xsi:type="Attribute" conformance="A" mandatory="false" max="1" min="0" name="value" datatype="CO"/>
 		    		<derives xref="observation"/> 
		    	</target>
		    </feature>
		    <derives xref="actrelationship"/> 
    	</target>
    </feature>
    <derives xref="observation"/>
  </model>
  
  <!-- 
    Rim classes. The RIM class definitions used in this model.
    Of course, these must be identical to the RIM against which
    the template is based, but storing them in the template 
    saves implementers work.  
   -->

  <rim version="1.22"> 
    <!-- 
      all the classes that the template depends on.
      For the purposes of this example, the classes
      are not enumerated, but would include directly:
        * Observation
        * ActRelationship
      and therefore the following classes would be 
      dragged in: 
        * Act
      By convention, it is not necessary to define the 
      all the attributes and associations in the RIM
      in this abbreviated rendition, only those which
      the model depends on. But it is not wrong to 
      include all the classes, attributes and associations
      defined in the RIM.
      
      stubs of 3 example classes are provided
    -->
    <class id="act" sourceModel="RIM" name="Act" category="ACT">
	    <feature xsi:type="Attribute" conformance="R" mandatory="true" max="1" min="1" name="classCode" datatype="CS">
    		<vocabulary extensions="false" domain="ActClass"/>
	    </feature>
    </class>
    <class id="observation" sourceModel="RIM" name="Observation" category="ACT">
      <super xref="act"/>
    </class>
    <class id="actrelationship" sourceModel="RIM" name="ActRelationship" category="ACT_RELATIONSHIP">
    </class>
  </rim>

  <!-- 
    Attachments.
    
    Typically a template will have some or all of the following attachments:
     - MIF Static Model - a full MIF of the original template
     - Image - a .gif or .png (or similar, a graphical representation of the static model)
     - ADL - a ADL rendition of the template
     - schematron - an rendition of the template as schematron rules    
  -->
  <attachment type="STATIC_MODEL" mediatype="application/mif+xml">
    <content><!-- MIF Content --></content>
  </attachment>
  <attachment type="STATIC_MODEL_IMAGE" mediatype="image/png">
    <content><!-- PNG of image --></content>
  </attachment>
  <attachment type="COMPUTABLE" mediatype="application/adl">
    <content><!-- ADL equivalent of the template (fully stitched, like the model above) --></content>
  </attachment>
  <attachment type="DOCUMENTATION" mediatype="application/pdf">
    <content><!-- PDF Document with Author's Design comments --></content>
  </attachment>  
</Template>

Typically, a template such as this example will be authored by a small group of experts in the domain of the template, along with assistance from one or more modelers familiar with the HL7 Development Framework. The authoring group will prototype the template, sharing it amongst themselves while they are preparing it for production use.

When the template is ready for production use, a recognised authority will approve and/or endorse the template. The details of this process are subject to the policies and governance models of the authoring organization, or in the case of publishing extant models, the registering organization. The recognised authority may be a legally constituted standards organisation, or it may be a professional association, or a project management team, or even the authoring group itself. In each case, the implications of the endorsement will depend on the nature of the authority.

Once the template is approved for production use, it must be published. If the anticipated use is only within the authoring group, or with a particular project, the publication process may be rather informal. When a template is expected to be used in a more widespread manner, the template will be published into some registry that provides a set of common services allowing users and applications to find and use the templates. There are additional requirements for templates when they are published using public template registries.

When a template is ready for use, it will be used in three different ways by applications. Applications that write instances (either as a message sender, a document author, or a client or server in a service context) will use the template to constrain the contents of the instance that they are writing. They may choose to note in the instance that the appropriate portion conforms to the template, either to meet a implementation requirement as allowed by the paradigm, or to allow a validation application to validate the instance with regard to the template

Appplications that wish to validate an instance with regard to the template must know that a particular template applies at a particular point within the instance. Sometimes this can be done implicitly in profiles and contracts, but there are times when the only way this can be known is if conformance to the template is explicitly noted in the instance. Validation applications must compare the instance against the constraints noted in the applicable templates.

Applications that consume the instances may use the template definitions to assist the processing of the instance. Applications should avoid making processing dependent on the instance explicitly noting conformance to a template in the instance, as the instance may conform to the template without this explicit note.

While the template is being used, design issues with the template may arise, and the authority that endorsed the template may ask for the design to be reexamined, either by the original authoring group, or some other group. If the issues can be resolved by making backwards compatible changes to the design, a new version of the template is published, ideally through all the channels that it was first published to avoid confusion. If the changes are not backwards compatible (defined in Conformance Statement Conf-003), a new template must be issued. The original template may be withdrawn in this case if appropriate.

The list of metadata in a template has been prepared in collaboration with CEN to enable CEN archetypes and HL7 templates to share common registries.

The name column defines the name of the property. The type column is mostly defined using V3 datatypes. This does not mean that the actual V3 datatype or its XML representation must be used, but may be taken as a guide to the kind of information that may be expected for the property

The conformance column specifies whether the metadata items are mandatory or optional. A few properties are conditional; in these cases, the conditionality is specified in the documentation column. The properties marked mandatory are required for a template to be a conformant template at any point in the life cycle. Registries may impose additional requirements on the metadata in order to support some of the interoperability uses of templates.

The final column documents where this metadata item is persisted in the template format documented below.

A template is a single XML document. The XML format is based on the following UML diagram:

Template Format in UML

One important feature of this model for templates is that this working model for a template does not preserve CMET boundaries. While the HL7 static model for the template may create an assocation to a CMET, when the template package is prepared, the model that the CMET represents is "stitched" into place. This process is recursive, so that a template as defined by this model has no dependencies on other models.

In the interests of consistency, this is also true of the RIM classes. A template includes the definitions of the RIM Classes as well.

The XML format that represents this model is described in a schema found in appendix C

Note that this specification does not use the HL7 V3 types; where possible, simple types are used that map directly to UML kernel and W3C Schema types are used rather than the more complex V3 types, since this format is intended to support V3 implementations.

Conf-001: Templates must be valid according to this specification.

Conf-002: Templates must conform to the schema published as part of this specification. Note that not all templates that conform to the schema are actually valid templates.

Conf-003: All versions of a template must be backwards compatible with prior versions. Any change to the semantic meaning of the template that is not backwards compatible will require a new template with a different identifier to be created. A change is not backwards compatible if it may result in an instance processor that is not aware of the more recent definition of the template interpreting conformant data incorrectly. Generally, removing or changing the meaning of existing data elements or their associated vocabularies is not backwards compatible. Further discussion concerning backwards compatibility may be found in the ARB document Substantive Change.

Conf-021: Instances must must be valid according to any templates that are applied, either by reference in the instance or by definition from a profile or the applicable interoperability paradigm.

Conf-022: The use of templateIds in the instance must be consistent with any rules made by the applicable interoperability paradigm and any other interoperability contracts that apply to the context of use of the instance.

Conf-023: When an HL7 published normative CIM is used as a template, it shall be identified using the model Id as described in the HDF in templateId.extension and the OID value 2.16.840.1.113883.1.3 in templateId.root

Conf-024: When an HL7 authored static model that is not a CIM is used as a template, it shall be identified using the model Id as described in the HDF in templateId.extension and the OID value 2.16.840.1.113883.10 in templateId.root

Conf-025: The OID values 2.16.840.1.113883.1.3 and 2.16.840.1.113883.10 shall not be used to refer to Static Models that are not published by HL7 or created by affiliates or organizational members following HL7 naming conventions. Instead, an OID based on the organizational OID of the organization authoring the template should be used.

Conf-031: Instance processing applications may reject an instance if it is not valid with respect of any of the applied templates, but are not required to do so unless specified by the interoperability paradigm.

Conf-032: An instance processing application SHALL NOT reject an instance because of the presence of any applied template for which the instance meets the constraints specified in the template.

Conf-033: An instance processing application may reject an instance because of the absence of a particular template, only as specified by the interoperability paradigm.

The abstract datatypes defines the nullFlavor attribute, and links this to conformance. If an attribute is labeled mandatory, it must not have a nullFlavor in the instance. The datatypes define this behavior in terms of a "constraining model". In the context of this specification, the constraining model is the expressed model.

Templates - applied models - do not work in quite the same fashion, because templates exist to apply additional conformance constaints on the data elements. This means that there may be multiple constraints in a data element, and it may meet some of them and not others. However there is only one nullFlavor.

As an example, take a coded element such as Act.code. The expressed model marks this as optional and assigns it a valueset representing SNOMED. The act has a template applied which requires a mandatory Act.code from LOINC. The sending system does not have a SNOMED code, but does have a LOINC code.

In this case, the attribute itself must have a nullFlavor of OTH, with a codeSystem of 2.16.840.1.113883.19.6.96, since there is no SNOMED code. This is conformant to the expressed model, since the act.code element is optional. In order to meet the template requirements, the attribute has a translation which has no null flavor, a code, and the LOINC codeSystem of 2.16.840.1.113883.6.1.

In order to check template constraints conformance, a nullFlavor is still required, but it need not be the nullFlavor of the data element itself.

Conf-041: Where the type has translations (CD/CE, PQ, ED, ST, and SC) the template constraints may be satisfied by the data element itself, or by one of the translations.

Where the datatype does not have translations, there is only one nullFlavor, and the data element may only be non-Null when all the constraints upon it are satisfied.

In addition, the template may describe a constrained datatype where a collection (BAG, LIST, DSET, HIST) has been constrained to a single item, and rules made upon the item. In this case, the instance may not need to contain just a single item.

Conf-042: Where a template specifies a single data item, and the instance contains a collection of items of type BAG, LIST, DSET or HIST, the instance conforms to the template if any one of the of items in the collection conforms to the template.

Both these conformance statements have implications for how a template is designed. In particular, if a template wishes to constrain a RIM item that is a SET<II> so that there can only be one item, then it should leave the type as SET<II> and set the cardinality to 1..1, whereas if the template wishes to assert that the identifiers must include a particular identifier, it should set the type to II, and make the appropriate constraints. In regard to these aspects, templates work differently to other models, and designers should keep these in mind.

HL7 Static Models serve as a structured formalism through which human beings can unambiguously exchange agreed knowledge models that describe concepts they share. In this wider context, templates are often used to define knowledge models at a finer level of granularity than the HL7 interoperability definitions.

Since all templates are also HL7 Static Models, all templates are a formal definition of a particular concept. Templates may be used to further refine any models in any domain of interest to HL7, including messaging infrastucture, healthcare administration and clinical concepts. Since, for various historical and industry reasons, HL7 models are generally more specific and proscriptive in messaging and administrative domains, templates are most often used to define clinical concepts.

HL7 Static Models are used to guide and direct information input for a message or document. This may take the form of a specification for a user input interface, or where the Static Model is used to guide an application in constructing a proper instance. Templates can be used to provide extra support for this by providing knowledge models that are applied on a context sensitive basis to a consistently applied more general model, and provide a coherent framework for customizing application behavior.

A common example of this use is a consistent laboratory report model provided by HL7, where specific templates are used to specify the form of particular laboratory reports such as CBC. Applications using templates in this manner may also choose to reference the template in the instance to support validation and processing.

The focus of this template specification is on defining templates as information constraints in the context of V3 RIM based instances. Applications may need to use other resources to define how the information model described in the template is properly presented or applied in other contexts, such as input screens; these things are out of scope of this template specification.

Templates are also used to support validation of instances. When a template is applied, either by definition or by reference, the instance can be validated against the constraints expressed in the template in addition to the base static model identified in the interoperability paradigm.

Template definitions may overlap as they apply to an instance. More than one template may be applied to a given class, or a template defined elsewhere in the instance may still apply when a new template is applied. Where more than one model (templates and the underlying model) apply to a feature, the possible valid set of instances for the feature is the set intersection of the set of instances described by each applicable model. Note that it may be that there is no instance which can satisfy all the applied templates if the models contain incompatible constraints (the set of valid instances is the empty set).

A practical example would be in the case where the Example CIM had this model:

Example CIM

In this case, the component has a mandatory contextControlCode, but the Barthel model prohibits it:

Barthel Index

So in this case there are no valid instances that can be both an Observation valid to the Example CIM model and the Barthel_Index at the same time.

When an application is aware that a template has been applied to a portion of an instance, it can choose to process the instance in terms of the template definition.

Processing in terms of the template definition may mean either using different code optimized to the terms and valuesets defined in the templates, or it may mean processing linked to the class names in the templates. Implementers choosing to process based on a template in this second fashion are cautioned to be aware of the issues that are documented in sections Template Concepts & Issues and Conformance.

The application may choose to use the template definition as a basis for understanding the instance, or it may choose to the use the template as the basis for applying rules in support of it’s processing, such as “is this an instance of a normal CBC”?

Finally, templates can be used as definitions to describe the structure and relationships of data. An exanple is the use of a template made accessible via automated query: "Where would I have to look to find all instances of a WBC?", where the template is used to define the rules used to decide whether an instance represents a WBC. In this case, the template is not used to determine whether an instance represents a WBC based on the presence of a matching templateId in the instance, but based on the presence of data in the instance that meets the criteria defined in the template.

Templates are often composed to form a more complete definition of a concept, in order to facilitate the reuse of templates in many contexts. A template may designate that some other template or group of templates apply at some point in the template. This can even be useful at the root of the template, where an otherwise empty template would provide a grouping construct. CMET bindings are used to represent this composition, and templates may use new CMET binding constructs as they are developed in the base HL7 methodology to manage composition.

It must be possible to register templates in a central registry in order to facilitate sharing of knowledge. Although templates do not need to be registered in any particular registry or even at all, registration of templates will facilitate common sharing. In order to support template registration and sharing, all templates must be uniquely identified and appropriate metadata (see section Metadata) must be defined to support useful searching of the registry.

Templates are able to make various forms of constraints on the datatypes of the attributes within the scope of the template. However, it is also possible to constrain V3 data types themselves in a re-usable fashion. These resusable datatype constraints bear many similarities with templates, but since the use of these constrained datatypes needs a different pattern for re-use due to the breadth of application of the constrained data types, and for various technical reasons related to how HL7 Static Models are represented, they are described as data type specializations, and the use of these is described in the refinement and localization topic refinement and localization topic.

This section lists the requirements that have been identified for the kind of constraints that a template may make on the instance to which it is applied.

Note: This list is defined here to define the desired features for templates. Where templates are represented using HL7 static models, it is not yet clear how some of these features are correctly implemented. This is matter of active development between the MnM and template committees, and new static model methodology features may be adopted for use in templates as they are defined.

Templates are provided to support application design and functionality by documenting exactly how particular concepts are to be represented in a V3 instance. Layers of templates can be used to tightly constrain messages, amongst all the possible ways those messages could have been populated. It is not necessary to invoke a template in an instance in order to conform to the representation described in the template. Templates may be invoked in an instance by specifying the template id as a reference, in order to support machine based validation, and to assist applications when processing the instance.

However individual templates may not be available to all applications, and HL7 V3 does not require that they are made available. For this reason, the invocation of a template in an instance can never be used to imply meaning that is not otherwise carried in the instance. A template may constrain the instance but the resulting instance must be able to be understood without access or consultation with any applied templates, and should not look any different if the templates were not referenced in the instance. It must always be possible to interpret the data correctly even when a template is unknown. Some implications of this are further discussed in the section External Meaning.

For this reason, application designers should be wary of processing data based on the presence or absence of template references. Generally, it is safe for applications to perform template reference dependent processing, but application designers should be careful to ensure that data is processed correctly when templates are not present. By agreement, applications may agree that some templates are mandatory under some set of clearly defined circumstances. In these cases, applications may rely on the presence of particular templates to assist with processing the instances, for instance to improve the overall speed of processing. Such agreements may be made by site or realm-specific agreement, or HL7 may publish specific profiles requiring the use of specific templates. In all cases, these profiles must be consistent with the rules established in the applicable interoperability paradigm. Where applications depend on templates to be present, this requirement must be made clear in any conformance statements.

The definition of interoperability paradigms establishes the relationship between templates and profiles – both specify static models, and used as applied models, but profiles are controlled by the interoperability paradigm, and may make rules about the presence or absence of templates according to the rules specified in the interoperability paradigm.

Profiles and Templates are closely related. Profiles are documented in the Refinement, Constraint and Localization Specification. A profile may be considered as a template that documents implementation specific knowledge starting from the entry point of the instance.

One or more templates may be applied using the templateId property on any RIM class. In many circumstances it is optional for the instance to reference a template when it has been used in the construction of the instance, or the application constructing the instance somehow otherwise knows that the template applies. When the application is allowed to choose, the following considerations are relevant to assist in this choice:

• The relevant definitions (profiles, interoperability paradigms etc) may not clearly establish that a particular template applies at a particular point.
• When it is not known that a template applies, validation and template specific processing cannot be performed.
• Referencing the templateId will make the instance larger

HL7 V3 instances generally conform to many models simultaneously. The models fall into one of three categories:

Expressed Models are represented directly in the XML. The names of this model’s classes and associations are found in the instance, and it is explicitly obvious which model artifacts are being invoked. Typically the expressed model is a message type in the XML ITS, but it could also be the CDA RMIM. If the instance was serialized at the RIM level - the RIM class and association names are in the instance - the RIM would be the expressed model. At this time, in the XML ITS, an instance has one and only one expressed model.

Implied Models are implied by the derivations contained in the definition of the expressed model. CIMs do not derive directly from the RIM, so there will be a series of implied models for any instance where the expressed model is a CIM. The final implied model in the sequence will be the RIM itself. Since all CIMS are ultimately derived from the RIM, the RIM is always an implied model.

Implementation Note:

A processor can correlate the instance data against an implied model by reading the full static model for the expressed model and tracing the derivations from the expressed model to the implied model of choice. This can also be done by the developer by hard coding the derivations in the application. HL7 XML ITS schemas also provide a partial link to the RIM level definition. The implied RIM model is of such consequence that a separate pattern for identifying the RIM classes in the instance exists, using structural codes.

Applied Models are LIMs to which the instance conforms but which are neither expressed or implied. There is a number of ways to apply a model:

• by invoking it explicitly in templateId
• by a profile, template or other external model
• by some conditional rule that associates the application of a model to some feature of the instance (usually a coded value)

Templates are applied models. For example:

    <observation>
      <templateId root="2.16.840.1.113883.10" extension=" REPC_RM000103"/>
      <code codeSystem="2.16.840.1.113883.2.6.15.1" code="Barthel-index"/>
      <derivationExpr>Sumscore</derivationExpr>
      <effectiveTime value="200601191211"/>
      <value value="3" />
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB525"/>
          <value value="1"/>
        </observation>
      </component>
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB6202"/>
          <value value="1"/>
        </observation>
      </component>
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlD520"/>
          <value value="1"/>
        </observation>
      </componen>
    </observation>
                    

In this model, the Example CIM is the expressed model. The clone classes Observation and Component are found directly in the instance.

The RIM is an implied model. In order to know that “component” is an Act-Relationship with typeCode=”COMP”, a processing application must consult the derivations in the static model definition. (This is a relatively trivial instance and human users are able to make this connection instantly. In bigger models, it becomes harder for humans. The Example CIM is presumably derived from the clinical statement pattern itself, so the clinical statement DIM is also an implied model, and the only way to link from the instance to the clinical statement pattern would be to consult the full static model definition for the Example CIM which includes these derivations).

The Barthel Index is an applied model and hence a template. It is explicitly referenced in the instance using the templateId, and the instance conforms to its constraints. But the identification of the elements in the wire format is not carried directly, so it’s not made explicit which Observation matches to which component in the template (ContinenceOfBowels, ControllingBladder, or PersonalToilet). If this identification is important, it may be inferred by a variety of methods, and this is discussed further below.

Templates very often represent partial constraints – they express a set of rules about content that only consider some aspects of the content, perhaps from a particular perspective. For instance, a template may require that a particular observation has at least several parts, a set of particular details and a summary, while not making any other rules about what other elements may or may not exist, such as authors, and other components of the observation, since it is concerned with the inherent structure of the content only, and not with the concepts of how the observation is reported. Another example is that a laboratory may want to define templates that describe the structures it uses for the various clinical reports it publishes. These templates will describe what observation components may be found on the reports, and what structures they have. However the templates do not make any comment on what forms of attestation are included with the reports.

When these constraints are described in an HL7 Static Model, the static model is said to be incomplete. It must specifically identify that content that is not described in the static model may exist. By contrast, a complete static model is where every element that may exist is described, and any elements that are not described must not exist.

In general, templates should be as incomplete as possible. The idea is to say as little as possible to convey the intent of the template. The more extra things that are constrained in the template, the less re-use for the template.

As applied models, templates are not represented explicitly in the instances. In some of the uses of templates, the tree of nodes in the instance must be matched to the features defined in the template. Since the names of the instance come from the expressed model, not the template, they cannot be used to assist in the determination of which nodes in the instance match the nodes in the templates, and some other strategy is needed to match the instance to the template definition.

As the basis for an algorithm to perform the tree matching the constraints expressed in the template must be matched to the actual data values found in the instance. Constraints defined in a template such as fixed Act.code values or value sets of allowed codes can be used to match nodes of the tree in a given instance.

The sequence of the associations may appear to be useful too but due to unrolling and other considerations, great care must be taken when using the sequence. At best it can only be used to increase the performance of the algorithm.

As an example of this, consider the instance fragment from above:

    <observation>
      <templateId root="2.16.840.1.113883.10" extension=" REPC_RM000103"/>
      <code codeSystem="2.16.840.1.113883.2.6.15.1" code="Barthel-index"/>
      <derivationExpr>Sumscore</derivationExpr>
      <effectiveTime value="200601191211"/>
      <value value="3" />
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB525"/>
          <value value="1"/>
        </observation>
      </component>
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlB6202"/>
          <value value="1"/>
        </observation>
      </component>
      <component>
        <observation>
          <code codeSystem="2.16.840.1.113883.2.6.15.1.0" code="BrtlD520"/>
          <value value="1"/>
        </observation>
      </componen>
    </observation>
                    

The problem of the tree match algorithm is to match the three component observations to the three definitions of the component observations in the template. In this case, its a reasonably straightforward process, since the different component observations have different fixed code values.

However this not guaranteed to be the case. The extensive use of terminologies in HL7 models may make this process a little more difficult. In this template, the fixed codes have been replaced by value sets:

Example Code Set Use

In order to perform the tree matching, the processor must check whether the codes in the instance are part of the value sets, and the processing becomes more time consuming, though the process is still relatively simple, if the value sets do not overlap.

If however, the value sets overlap, it is no longer possible to tell which observation is which in the template, and the template is indeterminate: it is not computationally definite which model data element a given instance data element conforms to.

This could happen if the following codes were in the relevant value sets:

x_Barthel_1	BrtlB525 BrtlB6202
x_Barthel_2	BrtlB6202 BrtlD520
x_Barthel_3	BrtlD520 BrtlB525

HL7 templates are not guaranteed to be determinate. However, at the clinical level, it’s nonsensical to have overlapping code sets for the Barthel index, and so, while there is no rule meaning that the templates are not indeterminate, the presence of indeterminism would generally indicate a poor representation of content or poor modeling practice.

Poor modeling practice can lead to indeterminate templates by injudicious use of optionality and choices to try and represent co-occurrence constraints. An example would be this model, which is a variation of the example template:

Example Choice Box Constraints

The intent of this model is to express the idea that the Controlling Bladder may include either a method code, or an effective time, but not both. Given the instance above, it’s not possible to determine whether the first component observation is a ControllingBladder or a ControlingBladder2 in this template.

For validation, it mostly doesn’t matter: if the first component is either a ControllingBladder or a ControllingBladder2, it is valid, and as long as the instance conforms to one of the choices, the instance is valid. However it is possible to construct more complicated models where the combinations of indeterminate features lead to indeterminate validation outcomes.

For interpretation of the data, it should not matter whether the instance component observation is either a ControllingBladder or a ControlingBladder2. In this contrived example, it won’t. However in general with templates it can be very subtle whether the distinction matters or not, and it may depend on the nature of the assumptions made when the template is interpreted.

Within the context of the existing HL7 Static Model design process, it’s not possible to prevent indeterminism in HL7 template design, but following the template design best practices below will ensure that templates will never have ambiguous meaning, and that validation will work.

It’s possible to design a template where the names of the clone classes in the template have meaning themselves, and are not supported by appropriate codes and values in the instance. This template falls into this category:

Making the codes optional in this fashion may make the template become indeterminate, but more importantly, it is dangerous. Given this instance:

    <observation>
      <templateId root="2.16.840.1.113883.10" extension=" REPC_RM000103"/>
      <code codeSystem="2.16.840.1.113883.2.6.15.1" code="Barthel-index"/>
      <derivationExpr>Sumscore</derivationExpr>
      <effectiveTime value="200601191211"/>
      <value value="3" />
      <component>
        <observation>
          <value value="1"/>
        </observation>
      </component>
      <component>
        <observation>
          <value value="1"/>
        </observation>
      </component>
      <component>
        <observation>
          <value value="1"/>
        </observation>
      </componen>
    </observation>
    

A template parser may use association sequence information to match the 3 component observations against the 3 components in the template definition without noting the implicit indeterminism, and consequently an application might wrongly infer meaning to the 3 different values. As discussed in section Templates are optional, it must always be possible to interpret the instance correctly even when the template is unknown. In this case, there are no grounds for interpreting the data correctly without access to the template, and since the template is indeterminate, there is no real grounds for interpreting the data correctly.

The exact definition of the meaning of “interpreting the data correctly” is rather difficult to pin down. In this case, it is possible to understand the data to some very minimal degree, and the template provides for further meaning. In the general case, whether a template provides enough extra information in the meaning of the names can be very difficult to determine, as it very much depends on the interpretation by the template by the user.

For this reason, the simplest rules to prevent misinterpretation of the data are:

• the template should not be indeterminate
• the names of the CloneClasses in the template should have no meaning that is not made explicit in the structural codes and other attribute constraints for the class and its contextual associations. (Test this by attempting to interpret your model pretending that all class names have been changed to "Foo" and see if the constraints are sufficient to have the correct interpretation.)
• Template parsers should never use sequence to do tree matching

Templates can be used to provide “adornment” information. This information might be used to assist an application to choose how to display a particular observation, for instance. If the application does not identify a template, it may not display the information in the expected style, and a user might misinterpret the data. While no hard and fast rules can be made in this regard, implementers need to be very cautious that their applications do not violate the intent of the ruling that data should be interpreted correctly without knowledge of the template.

A consequence of these rules is that templates can only be used for the backbone classes. In particular, it’s not possible to define templates for the query by parameter classes, as there is no structural codes to prevent indeterminism.

Context Conduction is an important structural behavior of the RIM. Consult the RIM for further information. Since Templates are applied models, and multiple different templates are applied at different points in the hierarchical model, it can be very difficult to determine in advance what the rules for context conduction will be.

Template designers should design templates with the knowledge that the context conduction rules in the model from which they have been derived may have been overruled. The best practice for templates is to never make any rules about context conduction.

Instance processors should be aware that context conduction can only be fully interpreted in the context of the instance where a template is applied, it is not a property of the template itself.

There is a close relationship between some forms of localization and templates. Templates are generally the most efficient way to implement localization where the localization is a matter of constraining the universal V3 specifications.

Not all requirements for localization can be met by constraining the universal V3 specifications. Circumstances arise where the only way to implement localization requirements is by extending the V3 specification. This is allowed by the rules in Refinement, Constraint and Localization Specification.

Templates can be extended in the same way as static models, and can also constrain extended content. For example, an implementor can extend a class by adding the attribute myBusinessThing : ST. This must be in some other namespace than the HL7 namespace. A template can constrain this attribute by referring to it directly in the template. The template must declare than namespace using the extensibilityNamespace attribute of the Feature class. Other than this, it is a standard template feature constraint.

Note that if a template makes an localised feature like this mandatory, it will not be able to be used outside the localization context.

V3 instances are able to make reference to a binding realm. Binding realms are also able to define their own versions of templates, but these need separate identifiers for use in templateId, so the binding realm reference does not alter or qualify an applied template.

It is possible that an international realm could apply incompatible constraints to those in the template, and then no instance could be valid. This might occur if a template restricted a particular attribute to a particular set of values (such as LOINC codes), and the realm had imposed a restriction to another disjoint subset of values (such as SNOMED codes). This situation is most likely to occur with coded values, but only where translations are not allowed because the attribute type has been restricted to CV.

A template may be applied to an instance that is based upon a CIM from which the template is not derived. The most useful application of this is where templates are derived from some general DIM, such as the Clinical Statement Pattern, and then may be applied against any instance.

Where a template is applied to an instance defined against a model from a different derivation path, the constraints in that template, which reflect all the constraints in its derivation path, are also applied. It may be difficult to understand the implications created by the application of templates in this fashion, and it is very easy to create constraint combinations that cannot be satisfied or to create unexpected constraints, so care is recommended in applying templates against instances where there are derivation paths not shared between the expressed model and the template.

Given that it is possible to compose templates by referencing one template from another, two generally different styles of template use arise. In one use, a single template is used to specify an entire model, and in the other use, a group of templates is used where each template is fairly simple and refers to the templates for the deeper content. These styles are referred to as “deep” and “shallow” templates respectively.

These styles of usage are not incompatible or absolute, they may be mixed as desired. Each use has advantages.

Advantages for deep templates:

• Templates are internally complete, so easier to understand
• Processing is simpler and faster (though this may be implementation dependent)

Advantages for shallow templates:

• Allows for more re-use of modular concepts in the design and the instance.

If every template was shallow – only 1 level, many templates would be required to express any useful concept. If every template is deep, reuse of templates becomes extremely difficult. Most templates will reflect a combination of deep and shallow design patterns.

Example - The template in the common example can be considered to be a deep template:

Example Deep Template

A shallow variation would be to use CMET references to refer to other templates:

Example Shallow Templates

In this somewhat trivial example, the definitions of the component Acts have been moved to other templates, which are invoked using CMET style references, which is a shallow design style.

The concept of shallow and deep templates is a design style; it is not a useful way to classify templates.

This specification defines a static model based representation of a template. HL7 templates need not include a representation in this form, though they are strongly encouraged to do so, as it provides the best support for reuse across all HL7 implementation contexts.

Validation applications may use the static model definition directly as a source when validating templates, if it is provided. Other formats such as XMI, OCL and schematron may be used to perform validation. The validation from any of the formats may sometimes be incomplete, as not all contraints can be porperly represented in any particular representation.

Schematron is a very useful form for an implementation specific representation of the template constraints, and there is support for template validation using off the shelf tools, though additional infrastructure may be required to support terminology validation.

In order to fully represent templates as Static Models, various enhancements to the Static Model methodology are still required. In particular, the following features have been identified:

• Model typing functionality in order to fully support template composition (some categorization mechanism for templates in order to specify that one of a group of templates must be used somewhere)
• What’s the relationship between a template CMET reference and constraint on templateId? (This will only be fully relevant once incomplete templates are allowed

These enhancements a current work items shared between MnM, Tooling, and the Templates SIG.

In general, HL7 recognises the need for tooling that enables the full implementation of the features described in the HDF, as well as the features described in this specification, in the Use of OCL as a constraint language in RIM Derived Models specification, and incomplete templates before HL7 templates will be truly useful.

Issues deferred to a future version of this specification:

• A process for describing certification of templates is required

Any organization or individual can create a template to meet business needs, enhance evidence-based medical practice, encode a clinical practice guideline, support a defined administrative process etc.

The initial template analysis and statement of requirements generally results in a structured expression of the template using the vocabulary and nomenclature of the users who are expressing the need for the particular Template instance. This may be done independently of any standard, though a variety of standards, including HL7 V3 itself, may be used to assist this process by defining shared language and recognised requirements. This structured expression can exist in a variety of representations, though usually it will be some form of general document. Regardless of the specifics of the expression, however, one should note that there is an emphasis on gaining domain expert consensus as to structure and content. Such consensus is obtained through the generation of one or more analysis artifacts including process flow diagrams, data/concept static diagrams, and a carefully written and complete glossary that defines all the terms required by the Template (see the HDF discussion for further details, approaches, and examples). There will typically be several software tools to facilitate template analysis, with a variety of user-interface designs. These user-friendly artifacts enable review by domain experts. Figures 1 and 2 show sample results of the analysis phase used to create a CBC template and a template governing the components of a comprehensive review document. Figure 3 shows a more extensive analysis, based upon the review of a national clinical practice guideline, resulting in an abstract data entry template.

Figure 1. Abstract statement of a CBC template.

When reporting the results of a CBC, the following observations shall be present:

• Hemoglobin (required, cannot repeat)
• Hematocrit (optional, cannot repeat)
• Platelet count (required, cannot repeat)

Figure 2. Abstract statement of a document template that indicates the components in a “comprehensive review” document.

A Comprehensive Review document contains the follow components:

• "objective" section (required, cannot repeat)
  • The "objective" section contains a "physical-exam" section (required, cannot repeat)
    • The "physical-exam" section contains a "vital-signs" section (required, cannot repeat)
  • The "objective" section contains a "lab" section (optional, cannot repeat)
    • The "lab" section contains a CBC observation, where the CBC is based on the template shown in Figure 1.

Figure 3. Data entry template produced upon review of a national clinical practice guideline

Entry Template

The artefacts of template analysis need to be transformed into Static Models. The specifics of the transformation process depend on the rigor by which the initial analysis process was performed. Often times, a technical expert is needed to map the clinical or domain analysis model into the normative form. During the mapping, it may be necessary to further clarify vocabulary, cardinality, and other requirements. There is also the potential that analysis-level templates address semantics not covered by an existing HL7 standard. For instance, it wouldn’t be possible to convert a CBC analysis-level template into a design-level template if there weren’t an HL7 standard for transmission of clinical observations with the required attributes. (See the HDF discussion on ‘Normalization/Harmonization’ for further details of this process).

The end result of template design is a template as defined in the Formal Definition.

A template is a constraint on some portion of a Static Model. Template metadata declares the scope of the constrained fragment. The template should be a valid and consistent constraint on top of the constraints expressed in the Static Model from which it is derived, but this is not strictly necessary (this is discussed in the section Template Concepts & Issues).

While there are some validations that template editing and checking tools can perform, full validation that the template is a valid constraint may not be possible.

What checking can be performed may be performed as part of the template authoring or registration process, or may be performed be a receiver upon receipt of a template.

Templates can be registered in a suitable template registry, such as the NIST HL7 template registry. The submission process will require authentication of the submitter. The registry will have rules governing which existing templates a submitter can revise. Typically, a submitter can add new templates, and can revise templates they (or their organization) have submitted, but cannot edit templates submitted by other entities. Registries maintain persistent copies of revised artifacts, and assign unique identifiers to all artifacts, including new revisions of existing templates.

A template registry can potentially hold tens of thousands of templates and will typically index much of the template metadata.

Users can search a template registry using any of the available metadata fields. Registries may differ in the search sophistication provided and in the metadata exposed to the search engine.

There are a number of mechanisms by which users create valid HL7 instances (messages and/or documents). Mapped data can be pulled from an internal database, a local document can be transformed into a CDA-conformant document, etc. A constraining template can be used to guide data entry. For instance, Figure 2 shows those components that are required for a comprehensive review document. This template can be used to validate that a CDA document conforms to the additional constraints expressed in the template, and can also be used to guide data entry, ensuring that required document sections are included.

An HL7 instance can carry information showing which templates it conforms to.

Using an appropriate tool, an instance can be validated against any templates applied to the instance. (Refer for further discussion to the section Implementation Considerations.)

In a registry of tens of thousands of templates, some of which may overlap, it can be challenging for a user to know which template to select. There may, for instance, be an echocardiography template submitted by LOINC, by the American College of Cardiology, and by DICOM. Ideally, these groups would converge over time and generate either a hierarchy of echocardiography templates that contain progressively more and more constraints and/or they would work together to produce a single echocardiography template.

Templates in the registry may be approved by a number of professional societies. In addition, templates in the registry can themselves go through the HL7 ballot process, yielding templates that have an HL7 Informative or an HL7 Normative status.