Templates SpecificationPrimary Contributor Grahame Greive

Jiva Medical Templates, Co-Chair Russ Hamm

Mayo Clinic Templates, Co-Chair Brett Esler

Pen Computer Systems Templates, Co-Chair Galen Mulrooney

Patriot Tech J P Systems, Inc.Templates, Co-Chair Mark Shafarman

Shafarman Consulting Modeling & Methodology Co-Chair

Woody BeelerBeeler Consulting LLC

Modeling & Methodology Co-Chair

Ioana SingureanuEversolve / Patriot Tech

Modeling & Methodology Co-Chair

Lloyd McKenzieLloyd McKenzie & Associates Consulting Ltd.

Modeling & Methodology Co-Chair

Dale NelsonZed-Logic Informatics, Inc.

Modeling & Methodology Co-Chair

Craig ParkerIntermountain Healthcare

Last Published: 11/15/2006 11:32 AM

HL7® Version 3 Standard, © 2006 Health Level Seven®, Inc. All Rights Reserved.

HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off

Table of ContentsPrefacei  Introduction1  Definition1.1  Formal Template Definition1.2  Discussion1.3  Template Identification1.4  Interoperability Contract Interoperability Paradigms 2  Template Example3  Conformance3.1  Template Authoring3.2  Registry Submission3.3  Instance Construction Applications

3.4  Validation Tools3.5  Instance Processing Applications3.6  Instance Processing Applications4  Requirements & Use Cases4.1  Definition of Clinical Concepts4.2  Construction of Instances4.3  Instance Validation4.4  Processing Support4.5  Incompleteness4.6  Composition of Templates4.7  Registration4.8  Data Type Templates4.9  Constraint Requirements4.9.1  Static Assertions4.9.2  Co-occurrence assertions4.9.3  Containment assertions4.9.4  Logic assertions4.9.5  Composition assertions5  Template Concepts & Issues5.1  Templates are Optional5.2  Relationship between Profiles and Templates5.3  Templates and Local Information Models5.4  When to Use templateId5.5  Expressed, Implied and Applied Models5.6  Indeterminism5.7  External Meaning5.8  Entry Points 5.9  Context Conduction5.10  Incompleteness5.11  Realms and Templates5.12  Derivation Hierarchy Considerations5.13  Shallow and Deep Templates6  Metadata7  Registries8  Best Practice for Template Design9  Implementation Considerations9.1  MIF9.2  Schematron10  Open Issues10.1  Methodology Enhancements10.2  Future Work11  Appendix A: Template Development Framework11.1  Template Analysis11.2  Template Design11.3  Template Validation11.4  Template Registration11.5  Finding a Registered Template11.6  Create an Instance that Conforms to a Template11.7  Validate an Instance Against a Template11.8  Advance a Template to Normative Status12  Glossary

Preface

 i Introduction i - a Statement of scope & intent

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.

 i - b Document Background

This document arises from joint work of the HL7 Templates SIG and the Template Specifications project of the MnM TC. Templates have had a long genesis from the first identification of their need, and a series of draft documents have already been published, all incomplete in some fashion or other.

This document builds on the existing template drafts, and other new work in the general HL7 V3 methodology space to provide a complete specification for templates.

 i - c Contributors

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, Patriot Tech J P Systems, Inc. ← George W. Beeler, Jr., Beeler Consulting LLC ← Grahame Grieve, Jiva Medical ← Gunther Schadow, Regenstrief Institute for Health Care ← Harold Solbrig, Mayo Clinic ← Harry Solomon, GE Medical Systems ← Ioana Singureanu, Eversolve / Patriot Tech ← Jane Curry, HL7 Canada ← Jennifer Puyenbroek, McKesson Information Solutions

← John Silva, Philips Medical Systems ← 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 ← 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

 i - d Ballot Status of the Document

This document is advanced for DSTU ballot. There is reference to several outstanding issues in this document, but it is believed that this document should be published as a DSTU without waiting for these issues to be resolved. It is planned to resolve these issues before the templates specification becomes fully normative.

 1 Definition 1.1 Formal Template Definition

A template is an expression of a set of constraints on the RIM which 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 within a narrower and more focused scope.

A template is represented as a Static Model, optionally with additional constraints expressed in some computable form. In addition, there is a set of metadata associated with every template.

 1.2 Discussion

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 on many levels of abstraction t.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 as 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 ContractParadigm whichthat is 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

 1.3 Template Identification

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 on InfrastructureRoot.

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

The order of the identifiers supplied in an instance is significant - the first stated template is the most constrained, and subsequent ones are increasingly relaxed. A receiver can walk the list from the beginning and the first template identifier that the receiver recognisesrecognizes will be the tightest fit.

It is not required that all conformant template identifiers are listed in the instance, this is up to the sender of the instance. This means that with knowledge of a template definition that is identified in an instance it may be possible for the receiver to determine other implied models (templates) that the instance is also conformant to.

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 explicit way to locate a template from its identifier. Templates may be registered in one or more template registries, but there is no defined way to determine where a template may be found from the template identifier alone.

 1.4 Interoperability ContractParadigm

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

HL7 has implicitly defined two interoperability contractsparadigms, Messaging and the CDADocuments. Other interoperability contracts 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 these, which 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 specifcation, 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 contract paradigm is not fixed, but it must specify how implementations can be described, when and what information is exchanged, how implementations can be described, and how templates are used within this context. Because the Interoperability Contract is so fundamental, applications must assert conformance to a specific interoperability contract.

Interoperability paradigms are important to the understanding of templates because it is the interoperability paradigm that specifies how templates function.

Interoperability contracts are important to the understanding of templates because it is the interoperability contract that specifies how templates function.

Interoperability contracts paradigms firstly establish which models are used as expressed models and which models are used as applied models, or templates (see Section X for definitions of these terms). The rules of the Interoperability Paradigmcontract also must specify a number of rules about how templates work, including how templates may be defined, whether an application may reject an instance because of the presence or absence of appropriate template definitions, and the relationships between templates, profiles and application conformance.

The implicit messaging interoperability contract paradigm establishes that content is exchanged in association with the V3 dynamic model – interactions, trigger events etc. Each interaction is associated with a fixed static model and two wrapper models. Other models – usually LIMs – are applied as templates on the static model specified

in the instanceinteraction. Profiles constrain both the dynamic and static model, and are associated bound with to the root class of the outer wrapper of the interaction. Templates can be applied by the profiles. Applications cannot reject instances because of templates unless the instance does not conform to the applied templates.

In the implicit document interoperability paradigmthe CDA (Currently CDA and SPL), there is an implicit interoperability contract paradigm which establishes the that there is a single fixed static model. Instances of data conforming to this model may be exchanged whenever and however applications wish – there is no fixed dynamic model. All other models, including potentially CMETs from messaging models, may be used as templates. Profiles are not used in the CDAProfiles are fixed to the entry point of the CDA model. Applications are entitled to reject instances because unrecognized or unacceptable templates are associated with the instance, or if a template is not applied where it is expected.

Services may define their own interoperability paradigm. An example might be where a functional model is associated with specific static models for specific function parameters, and an open or controlled set of templates are available. Profiles are could be associated with the entry points of the selected models, and the service specification may make it’s own determination for how applications process templates, depending on their relevance to the functionality provided by the service.

 2 Template Example

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

Example CIM

In this example, we assume that this model is a normative CIM published by HL7. 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 value="1"/> </continenceOfBowels> </component1> <component2> <controllingBladder> <code codeSystem="2.16.840.1.113883.2.6.15.1.0"

code="BrtlB6202"/> <value value="1"/> </controllingBladder> </component2> <component3> <personalToilet> <code codeSystem="2.16.840.1.113883.2.6.15.1.0"

code="BrtlD520"/> <value value="1"/> </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 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> </component></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 must conform to the constraints described in the template.

 3 Conformance

Conformance to the HL7 template specification is defined for a number of different roles.

Template Authoring Tools Registry Submission Tools

Instance Construction Applications

Validation Tools

Instance Processing Applications

Registry Applications

For each of these roles, a set of requirements is detailed below. If an application wishes to claim conformance to this specification, it must claim conformance to one or more of these roles. In order to claim conformance to a role, it must meet the requirements detailed for the role. HL7 does not require that applications meet these requirements, nor does it provide support for testing that any applications meet the requirements.

Applications that assert conformance to the templates specification must clarify which role(s) they conform to. In order to conform to a role, all the conformance statements for the role must be satisfied.

 3.1 Template Authoring

Conf-001: A template authoring tool must allow users to create and modify templates.

Conf-002: A template authoring tool must enforce that template is a valid Static Model.

Conf-003: A template authoring tool shall warn users when the template is not consistent with the Static Model from which it is derived in regards to cardinality, domain value set, or, within the scope of the HL7 defined terminologies, terminology value set.

Conf-004: A template authoring tool shall endeavor to provide warnings to authors when a template is indeterminate or meaning appears to come from the clone names.

 3.2 Registry Submission

Conf-011: A registry submission tool must allow for templates to be submitted to registries as valid templates in HL7 MIF format that passes MIF schema validation.

Conf-012: A registry submission tool must enforce that the Static Model semantics are correct is valid before the template is submitted to a registry.

 3.3 Instance Construction Applications

Conf-021: An instance construction application must construct instances that are valid according to any templates that are applied, either by reference in the instance or by definition from a profile or the applicable interoperability contractparadigm.

Conf-022: 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-023: When an HL7 authored HIM that is not a CIM is used as a template, it shall be identified using the model Id as described in the HDFHDF in templateId.extension and the OID value 2.16.840.1.113883.10 in templateId.root

Conf-024: Instance construction applications shall not use the OID values 2.16.840.1.113883.1.3 and 2.16.840.1.113883.10 in templateId.root to refer to Static Models that are not published by HL7

 3.4 Validation Tools

Conf-031: A validation tool must be able to determine all templates that apply to an instance, by consulting the templateId references and the definitions that apply to the instance as defined by the applicable interoperability contractparadigm.

Conf-032: A validation tool must be able to validate against all the applicable templates.

Conf-033: If an instance fails validation, a validation tool must be able to indicate at least one template that has caused validation to fail, along with a message that allows the user to determine which feature contains the problem.

Conf-034: A validation tool must be able to validate all the static and domain value constraints defined in the templates.

Conf-035: A validation tool must be able to validate co-occurrence constraints and other logical predicates in the templates when they are expressed in the fashion defined in the static model methodology.

 3.5 Instance Processing Applications

Conf-041: An instance processing application MAY reject an instance if it is not valid in respect of any templates applied within the instance.

Note: This means that an instance processing application MAY accept an instance even if it is not valid against all the applied templates.

Conf-042: An instance processing application MAY notSHALL NOT reject an instance because of the presence of any applied template that is valid.

Conf-043: An instance processing application MAY reject an instance because of the absence of a particular template, as defined by the interoperability paradigmcontract.

Conf-044: An instance processing application is not required to validate against any of the applied templates.

 3.6 Instance Registry Processing Applications

Conf-051: A registry must enforce that the user populate all mandatory metadata fields before submission to a registry.

Conf-052: A registry must enforce that before a template is submitted all the IM’s in the derivation path are posted to a publicly available registry or part of a published HL7 standard.

 4 Requirements & Use Cases 4.1 Definition of Clinical Concepts

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, mostly in clinical domains.

Since all templates are also HL7 Static Models, all templates are a formal definition of a particular concept. Templates are most often used to define a clinical concept, though they may also be used to further refine other models, such as administrative information. However for various historical and industry reasons, HL7 models are generally rather more specific and proscriptive in these domains, and so the focus for templates is on clinical content.

 4.2 Construction of Instances

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 a CBC. Applications using templates in this manner may also choose to reference the template in the instance to support validation and processing.

However the focus of this templates specification is on defining the information constraints in the context of V3 RIM based instances, and 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.

 4.3 Instance Validation

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 paradigmcontract.

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 required mandatory contextControlCode, but the Barthel model prohibits it:

Barthel Index

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

 4.4 Processing Support

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 (i.e. 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).

 4.5 Incompleteness

Templates are very often represent incomplete 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 2 several parts, a set of particular details and a summary, and while not makingke 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.

Such a template is said to be incomplete. It must specifically identify that content that is not described in the template may exist. By contrast, aA complete template is where every element that may exist is described, and any elements that are not described may must not exist.

NOTE: Templates are defined by static models, and static Models are inherently “complete”. If a static model does not describe a concept, then the concept is prohibited. The issue of how to represent incomplete templates is not resolved at this time, and is a matter for future development (see Section 10).

 4.6 Composition of Templates

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.

 4.7 Registration

It is possible to register templates in a central registry in order to facilitate sharing of knowledge. Templates do not need to be registered in any particular registry or even at all, but 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 X) must be defined to support useful searching of the registry.

 4.8 Data Type Templates

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 apply templates as reusable constraints to V3 data types themselves. The use of templates

with datatypes needs a different pattern for re-use because of the breadth of application of data type templates, and for various technical reasons related to how HL7 Static Models are represented.

When templates are applied to data types, they are described as data type specializations, and the use of these is described in the refinement and localization topic refinement and localization topic

 4.9 Constraint Requirements

This section enumerates the requirements that have identified for lists 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 Since templates are defined as static models, the list of features for templates has to match those of static models. However there is no clearly defined list of requirements for static models, and the template requirements include some requirements are not yet supported by static models . This is a matter of ongoing development.

 4.9.1 Static Assertions← A template can choose not to constrain all or some of the attributes for a

class. ← A template can choose not to constrain all or some of the associations for a

class. ← A template can constrain the cardinality of an association. ← A template can constrain the cardinality of an attribute. ← A template can constrain any attribute value to be a subset of the values

allowed in the reference model. A template can constrain the range of allowable date/time values for

attributes valued by date/time data types. A template can constrain the range of allowable code values for

attributes valued by terminology concepts. A template can constrain the range of allowable numbers for attributes

values by numbers. ← A template can constrain the markup within an ED data type.

Example: If the Media Type of an ED data type is “text/html”, a template can preclude the use of the <table> element.

Example: If the Media Type of an ED data type is “text/html”, a template can constrain the markup to only allow for a list or a table, depending on the context.

← A template can constrain any data type component, including recursively-nested components following the rules laid out in the data type abstract specification and the datatype refinement rules described in refinement and localization topic

← All additional constraints that can be expressed in a normative specification can be further constrained in a template.

← A template can constrain recursively nested classes, and can apply different constraints on each nested class.

Example: A Observation with Observation.code = “CBC” has a required nested Observation with Observation.code = “HGB” and an optional nested Observation with Observation.code = “HCT”.

← A template can “unroll” a recursive relationship specified in some other static model.

 4.9.2 Co-occurrence assertions

These assertions range from fairly easy to complex. The final requirement stated here is the most general and expressive and also the most complex to implement in a standard way.

The value of one attribute can be constrained based on the value of another attribute.

o Example: If attributeOne is “X”, then attributeTwo’s value must be “A”. Chronological assertions can constrain the date/time value of one attribute

based on the date/time of another field. o Example: The start time for attributeOne is (earlier | later | equal to)

the start time of attributeTwo. Numeric comparison assertions can constrain the numeric value of one

attribute based on the value of another attribute. o Example: The value of attributeOne is (equal to | less than | greater

than) the value of attributeTwo. Numeric operation assertions can constrain the numeric value of one

attribute based on a numeric operator applied to the value of another attribute or constant.

o Example: The value of attributeOne is (equal to | less than | greater than) the value of attributeTwo (plus 7 | divided by 27).

String comparison assertions can constrain the string value of one attribute based on the value of another field.

o Example: The string value of attributeOne is contained in the value of attributeTwo.

A template can constrain the presence or absence of an attribute based on the presence or absence of another attribute.

o Example: If attributeOne is present (regardless of its value), attributeTwo must also be present.

Any constraint a template can make can be made dependent on the value expressed in one or more other attributes. For instance, in addition to constraining the cardinality of an association, a template can constrain the cardinality based on the value in a particular attribute.

o Example: If ((attributeOne is “X” or “Y”) OR (attributeTwo is “ABC”)) then ((a nested act relationship under Observation is required) AND (attributeThree in the nested act has a value of “A” or “B” or “C”) AND (attributeThree in the nested act cannot be NULL)).

 4.9.3 Containment assertions← Data descendant assertions can constrain allowable depth at which one

component is nested within another component. Example: The vital-signs section must be (a direct child of | some

descendant of | less than a depth of X from) the physical-exam section. ← Items in a template can be “ordered” or “unordered”. In an ordered template,

the order of the stated assertions is important. In an unordered template, the order is not important.

Example: Assertion One: There is a nested act under observationOne that has an observation.code for “hemoglobin”. Assertion Two: There is a nested act under observationOne that has an observation.code for “hematocrit. If the template is “ordered”, the “hemoglobin” must come before the “hematocrit”. If the template is “unordered” the “hemoglobin” can come before or after the “hematocrit”.

 4.9.4 Logic assertions← Logical operators can be applied to a set of assertions to indicate which

assertions in the set must be true or false. Example: (All | at least X | at most X | exactly X) of the assertions

contained in this set must be (true | false).

 4.9.5 Composition assertions← A template can designate that the constraints for a class and it’s attributes

and associations are specified by some other template. Example: The template for this observation is a particular CBC

template. ← A template can designate that the constraints for a class and it’s attributes

and associations are specified by some group of templates. Example: The template for this observation is any laboratory Template.

 5 Template Concepts & Issues

This section discusses a number of important background concepts that are required to understand how to use templates.

 5.1 Templates are Optional

Templates are provided as to support application design and functionality. However individual templates may not be available to all applications, and HL7 V3 does not require that they are made available.

For this reason, templates are secondary constructs which may can never be used to provide meaning in their own right. They may constrain the instances of data consistently with the model from which they are derived, but the data must be able to be understood without access or consultation with any applied templates. Although this specification describes several ways in which the application may process data, sometimes in terms of a template specification, it must always be possible to interpret the data correctly even when the template is unknown, and application designers should be careful to ensure that data is processed correctly even in the absence of applied templates if the interoperability contract requires this.

The implications of this are further discussed in the section External Meaning.

 5.2 Relationship between Profiles and Templates

The definition of interoperability paradigmcontracts establishes the relationship between templates and profiles – both are specify static models, and used as applied models, but profiles are controlled by the interoperability paradigmcontract, and may make rules about the presence or absence of templates according to the rules specified in the interoperability paradigmcontract. In addition, profiles must be complete static models (see Incompleteness).

Profiles and Templates are closely related. Profiles are documented in (external reference). A profile may be considered as a template that documents implementation specific knowledge starting from the entry point of the instance.

 5.3 Templates and Local Information Models

HL7 defines the following kinds of models in the HDF:

RIM Reference Information Model

The common source for the information content of specifications

DIM Domain Information Model

Provides a solution to the information requirements of a particular problem domain. May have multiple entry points

CIM Constrained Information Model

A constraint on a DIM which has a single entry point and can therefore be serialized, and used in information systems.

In addition, there is a 4th type called Local Information Model (LIM). LIMs are a particular form of HL7 static model that are introduced to provide explicit support for templates and LIMS are a little different from other static models in this regard. In particular, LIMs will be able to be incomplete models, and have different entry points.

However LIMs are not the same as templates. Note that CIMs may also be used as templates, but CIMs must always be complete models.

The terms “template” and “LIM” are often used synonymously, but this may not be true in all contexts, and the terms should be used carefully throughout HL7 V3 standards development and implementation.

 5.4 When to Use templateId

One or more templates may be applied using of 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 contracts 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

 5.5 Expressed, Implied and Applied Models

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.

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. Since all CIMS are ultimately derived from the RIM, The final implied model in the sequence will be the RIM itselfthe RIM is always an implied model.

Implementation Note:

A processor can correlate the instance data against an implied model by reading the full MIF definition 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> </component>

</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 MIF or the schema for the CIM. (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 MIF definition of the Example CIM, as these derivations are defined in the MIF but not found in the schema).

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.

 5.6 Indeterminism

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> </component></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, it’s reasonably straight forward 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.

This could happen if the following ICFXXX codes where 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 interdeterminate 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 disctinction 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.

 5.7 External Meaning

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> </component></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 therefore an application might infer meaning to the 3 different values which would not be available to an application which did not have access to the template.

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 areis no grounds for interpreting the data correctly without access to the template.

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 codes in the class ← Template parsers should never use sequence to do tree matching

This theme is taken up in template best practices and conformance.

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 correct 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 back-bone classes. In particular, it’s not possible to define templates for the query classes.

 5.8 Entry Points

A template definition is not required to have the same entry point as the model from which it is derived. A template may choose to have an entry point derived from any class in the CIM from which it is derived. If a template is referenced in the instance, the point at which it is referenced must be the entry point of the template, and the reference point it must match the clone class have the same RIM Class type from which the entry point is derived in the instanceas the class at entry point of the template.

This rule is transitive – if a template is derived from an inner class in a template derived from the HIM for the instance, the template reference for the derived template must occur in the correct class for the derived template. The template from which it is derived does not need to be referenced.

The fact that a template does not need to have the same entry point as the model it is based on is related to the idea of incompleteness – a template with a different entry point to the model from it is derived is simply a template that is incomplete with regard to the portion of the model between the entry point of the derivation model and the template.

Note: The methodological implications of these entry point rules, particularly with regard to the need to conform to the hierarchy of the derived model, will need to be resolved by MnM and Tooling.

 5.9 Context Conduction

Context Conduction is an important structural behavior of the RIM – and is why only CIMs, not DIMs, can be used as the basis for interoperability. 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.

 5.10 Incompleteness

As noted in the requirements, templates may need to be incomplete. A template designer may wish to describe the concepts that are of interest to the template, but not make rules about other concepts.

As an example, 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.

This specification accepts the requirement that templates may be incomplete, but Static Models are inherently “complete”. If a static model does not describe a concept, then the concept is prohibited. This is also true when static models are used as templates.

This issue is being taken up with MnM and Tooling.

 5.11 Realms and Templates

V3 instances are able to make reference to a realm. A realm may be considered as a reference to a set of templates that are implicitly applied to the instance as defined by the realm owner (usually an HL7 Affiliate).

As with multiple and overlapping templates, all the constraints applied must be satisfied for the instance to be valid.

Realms are also able to define their own versions of templates, but these need separate identifiers for use in templateId, so the 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.

 5.12 Derivation Hierarchy Considerations

A template may be applied to an instance 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. This problem is particularly acute when working with incomplete models with different hierarchies of complete models

 5.13 Shallow and Deep Templates

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.

 6 Metadata

In addition to a HIMStatic Model, templates have metadata associated with them that enables templates to be shared through template registries and used in applications.

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.

For reference, the MIF implementation of the concept is provided.

Property Name Type Conf Documentation

Identification      

TemplateId II M

A globally unique, non-semantic, identifier for the Template. This is the primary identifier for all Templates. MIF: OID as defined by HL7. extension is the model id as defined in the HDF

templateName String M

A free text natural language name identifying the Template. It is anticipated that there will be far too many templates to be able to assign a unique mnemonic or meaningful name to all of them. This is the secondary identifier for all Templates MIF: business name of the model

originatingAuthorEntityID II M

A globally unique non-semantic identifier for the original author of the Template. MIF: header.responsibleGroup.groupId

templateIntention Text M

A free text natural language description of the intent and scope of the Template. The purpose is to provide the author’s initial intent for the Template. In the language specified below Example: The intention may include the Realm or sub-realm within which the Template was designed to be used for. NOTE: A change to the semantic meaning or intent of a Template will constitute a new Template, not a new version of the Template. MIF: UsageNotes on the model

templateVersion ? M The version identifier for the Template. The ability to determine the correct version of a Template is essential to its identification. NOTE: Changes to the Template that do not change the semantics or intention of

the Template will constitute a new version of the Template being created. Any change to the semantic meaning of the Template will constitute the creation of a new Template. MIF: part of the model identifier

templateDerivedModelID II MThe globally unique identifier of the CIM from which the Template is derived MIF: derivation reference

templateReferenceModelID II M

The globally unique identifier of the reference model from which the Template is derived.

NOTE: For HL7 use only, we could assume that this was the RIM, and only provide a version number. But providing a full reference to the RIM enables HL7 templates to be shared with templates on other reference models in a single registry MIF: derivation reference

templateRepositoryIdentifier URL M

Identifier of the primary registry where the Template is located. This is a required metadata item since the core functional purpose of a Template is reuse, and things in general are much harder to reuse when they cannot be easily located. MIF: header.primaryRepository

Description      

descriptionLanguage SET<CS> M

The natural language in which the Template is represented MIF: description.text.language

templateDescription Text M A free text natural language description of the Template. Generally, this field should be used for things such as goals, variable lists, instructions for clinical use and interpretation, literature, examples from paper world, mapping from natural language to HL7 and

the model itself, etc. MIF: description annotation on the model

templateFormat CS M

The format of the template definition itself. HL7 Templates are always defined in MIF form, so this value is fixed to “MIF”. This field is documented to allow for registry interoperability with templates in other specifications, such as CEN 13606 templates. MIF: no equivalent

evidenceSource URL O

A description, reference or link to the published medical knowledge that was used in the definition of this Template.

MIF: requirements annotation on model

detailedDescription Text O

A detailed explanation of the purpose of this Template, including features of interest. This may include an indication of the intended user group for which this definition is intended. MIF: use model annotations as appropriate

cautionPoints Text O

A formal statement regarding when this Template should not be used, or may be used erroneously. To define roles where the Template should not be used, or should be used with care. This field is used to expand in detail on the templateIntention. MIF: usage Notes on model

Publication      

publicationStatus CS M ← Draft ← Not For Use (i.e.

teaching) ← For Production Use ← Withdrawn

MIF: maps to approvalInfo.approvalStatus

publicationStatusChangeDate TS M

The date that the current value for publicationStatus was applied of the Template MIF: approvalInfo.approvalDate

publisher ? M

The name of the author(s) institutional affiliations and contact infomation for the creators of the Template MIF: header.responsibleGroup

publishingAuthority II? M

The authoritative body who has reviewed the Template for clinical accuracy and relevance, and authorized it for publication MIF: header.reviewingAuthority

revisionHistory Text M

The free text description describing the changes in this version of the Template as compared to the previous version. Since Template versions are built off of previous versions, the net effect of this field is to function as a comprehensive historical reference of the Template MIF: everything has a revision history; this would have to built on the fly

effectiveDate TS O

The date after which the Template can be considered for use. Use of the Template prior to this date would be considered an invalid use of the Template MIF: approvalInfo.approvalDate

supercedingTemplate II O

A template that has superceded this template and should be used instead. This field can only be populated if the publicationStatus is withdrawn MIF: TBD

 7 Registries

This specification does not provide normative implementable specifications for template registries. Instead this section may be taken as a general functional specification for the kind of operations that a template registry should provide.

Note that H7 provides a template registry at http://hcxw2k1.nist.gov:8080/hlxregdoc/HCXW2K1Main.html

Operation In Parameters Out Parameters Comments

AllocateTemplateId

User Identification to allow audit

TemplateIdThe registry assigns the templateId. Allocated Id’s are never reused.

CreateTemplate Template Package Error or Ok

Error if ← metadata is

malformed or incomplete

← or template fails validation

← templateId already exists

← etc

UpdateTemplate Template Package Error or Ok

Error if ← metadata is

malformed or incomplete

← or template fails validation

← templateId does not exist already exists

← user doesn’t have permission

← etc

RemoveTemplate templateId Error or Ok

Error if ← templateId← does not exist

already exists ← user doesn’t

have permission

← etc

SearchForTemplate

Template metadata filter

A list of template metadata for metadata that matches

-

RetrieveTemplate templateId Template Package

Error if ← templateId

already exists ← user doesn’t

have permission

← etc

A Template Package consists of the normative MIF for the template, the template metadata in the registry format (will generally be a duplicate of the same metadata in the MIF), and any other formats that the authoring tool created for the template representation.

 8 Best Practice for Template Design

Best practice for template design

Templates should always specify appropriate coded values to indicate meaning rather than using the name of the clone class

Templates should be deterministic – there should always be mandatory attributes with appropriately constrained values to properly differentiate between classes involved in associations and choices

Templates should be as incomplete as possible – say as little as you can say to convey what you want to say. The more extra things you say, the less re-use for the template. Be careful excluding concepts – this is generally not needed. Generally all you need to say is positive things

Templates should not constrain the conduction and separation attributes. It can be done, but again, it’s about re-use. The less you say about this difficult and significant subject, the more re-use of the templates is possible – less likely to create problems with context conduction rules in the expressed models

Templates should use expression languages for co-occurrence constraints rather than creating choice boxes

Template Metadata should be carefully populated Templates should be registered in the global NIST artifacts registry Make consistent constraints

 9 Implementation Considerations 9.1 MIF

MIF (Model Interchange Format) is an XML format maintained by HL7 for the full specification of all of the HL7 data that supports models and the internal publication processes used by HL7. The MIF XML format is documented as part of the HDF.

MIF is the master required format for templates: any HL7 templates must be stored in registries as MIF format. Other formats are allowed but not required; they must always be able to be produced from the MIF using automated tools.

Validation applications may use the MIF directly as a source for validating templates, and as the master format this will always be the most complete source of information to support validation. However other formats such as XMI, OCL and schematron may be used to perform validation.

 9.2 Schematron

It is possible to represent most of the important parts of a template as schematron statements. While it may not be possible to translate the co-occurrence constraints as schematron using automated tools, it is possible to automatically build schematron constraints for the particular XML ITS that meet the requirements of a conformant template validation tool.

 10 Open Issues 10.1 Methodology Enhancements

In order to fully implement the features described in this specification, various enhancements to the Static Model methodology are required. In particular, the follow 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?

← Incomplete templates (attributes, associations) ← Entry Points not having to match the derivation model entry points

These enhancements are a matter of ongoing discussion between MnM, Tooling, and the Templates SIG.

 10.2 Future Work← Determine a process for describing certification of templates is required, and

the templates SIG will work on this. ← Add Description, details, and examples of shell/sandbang use of templates

reference within an instance. ← Related item "templates are deterministic" implication on successful use of

shell method needs discussion. ← Decide on whether Shallow/Deep templates discussion should be moved to

informative appendix. ← Discussion on implementation of co-occurence constraints by structural

definition (choice box) and expression languages where required. ← Discussion on context conduction use in templates, implication and best

practice.

 11 Appendix A: Template Development Framework

This section presents a series of scenarios that walk through the entire process of template inception to template creation to template validation. The various scenarios are presented to help put the HL7 V3 Template standard into perspective.

 11.1 Template Analysis

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 is generally done independently of any standard, and 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 expression can exist in a variety of representations, typically any representation that makes it easy to capture domain expertise. 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 which 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

 11.2 Template Design

The artiefacts 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, a HIM with the template metadata described below.

 11.3 Template Validation

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 template concepts and issues section).

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.

 11.4 Template Registration

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.

 11.5 Finding a Registered Template

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.

 11.6 Create an Instance that Conforms to a Template

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.

 11.7 Validate an Instance Against a Template

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

 11.8 Advance a Template to Normative Status

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.

Hide Revision Marks Return to top of page