HIT Stakeholders at all levels benefit from understanding the template lifecycle. System engineers and clinical analysts who design templates, implementers who use templates, and participants who govern templates need this knowledge to do their jobs.

Understanding the lifecycle of a template requires you have the following:

1. Appreciation the relationship between a template and its versions.
2. Familiarity with the state model which defines the managed life of a template version.
3. Awareness of the different types of relationships that may exist between templates and their versions.

A Template and Its Versions

The HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 defines the characteristics and functional properties of templates. The illustration below shows two templates in a Template Repository. One is named Template X and the other is named Template Y. Other metadata identifies the templates at the version level, including an id, effectiveTime, version, and purpose description. The metadata also includes computable relationships between one template version and another.

The figure also shows a Template Registry which has indexed template versions for “intention A”. Based on the description in the template version metadata, both versions of Template X and the single version Template Y have been determined to belong to the “intention A” category in the Template Registry.

Relationships between Template Versions

The design of one template version may depend on, build upon, or further constrain the design of another.

One template version may be defined by asserting conformance to another template version. In this case, the newer template version implies the constraints defined previously in the other template version. Template designs using this type of “constraint inheritance” eliminate the need to repeat constraints in the definition of the new template version.

One template version may include a component which has been defined separately in a different template version. In this case, the newer template version “contains” the separately defined template version.

When design interdependencies exist between template versions the set of all related template versions defines the set of “inferred templates”.

The HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 defines relationships that can be identified between two template versions. The following list describes some of the most commonly occurring relationships between template versions.

Replaces	A template that should be used in place of another template version
Specializes	Narrower, more explicit or more tightly constrained than another template version
Generalizes	Broader, less restrictive than another template version
Design Copy	A copy of another template version where nothing changes but for the id and perhaps the governance group responsible for the other template may be different.
Equivalent Copy	A copy of another template version which is a design copy of another template and includes use of different code systems to express the terms identified in the value set bindings of the other template version
Adaptation	Template based on another template version and includes similarities, but is not a specialization, a generalization, a design copy, or an equivalent copy of the other template version.

Now that you have a firm knowledge base about templates and their key characteristics, I’ll show you the states a template version passes through over the course of its lifetime and we’ll see how the template lifecycle address the need for templates to be both stable and mobile information management artifacts.

 Lifecycle of a Template

A template comes into existence through a governed process that sees it through, from creation to retirement.

When a template is created, its first version comes into existence. Over the course of its governed life, the design is drafted. The draft may be cancelled, or it may spend time in a pending state while it is considered. It may get approved and become active, or it could be rejected as an unsuitable design. An active template version may undergo review over time to determine if it is still useful or appropriate, given its purpose and considering the present or predicted future. Eventually, it may be deprecated and retired from use. Until a template version is terminated, new versions can continue to be created, drafted, activated, etc. When a template version is retired, a new version can be created to replace the retired design. The new version can be established to meet the template’s described purpose.

Important to note, a prior version of the template doesn’t need to retire before another version can be created. Multiple versions of the same template can exist at the same time. The versions can be in different states or there can be more than one version in any given state.

The HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 includes a state model describing the phases a template version may pass through. A description of each phase is in the table below the figure.

State code	Description
Draft	Design is under development (nascent).
Pending	Design is completed and is being reviewed.
Active	Design has been deemed fit for the intended purpose and is published by the governance group.
Review	Design is active, but is under review. The review may result in a change to the design. The change may necessitate a new version to be created. This in turn may result in the prior version of the template to be retired. Alternatively, the review may result in a change to the design that does not require a new version to be created, or it may result in no change to the design at all.
Cancelled	A drafted design is determined to be erroneous or not fit for intended purpose and is discontinued before ever being published in an active state.
Rejected	A previously drafted design is determined to be erroneous or not fit for intended purpose and is discontinued before ever being published for consideration in a pending state.
Retired	A previously active design is discontinued from use. It should no longer be used for future designs, but for historical purposes may be used to process data previously recorded using this design. A newer design may or may not exist. The design is published in the retired state.
Terminated	A design is determined to be erroneous or not fit for the intended purpose and should no longer be used, even for historical purposes. No new designs can be developed for this template. The associated template no longer needs to be published, but if published, is shown in the terminated state.

Conclusion

Versioning makes it possible for a template to be both stable yet flexible over time. The template’s purpose persists while the design for achieving that purpose progresses. The iterative nature of a template’s lifecycle permits it to achieve longevity and permanence while permitting flexibility and nimbleness to improve at the same time.

Information artifacts like templates, value sets, and profiles form the foundation for standards like Consolidated CDA (C-CDA) and Fast Healthcare Interoperability Resources (FHIR). These standards transform the way health data is exchanged. Their development and maturation is an iterative process.

Improving our ability to manage and evolve these artifacts over time will create an information sharing environment that includes both stability and innovation. Understanding the lifecycles for these artifacts will help us leverage the power of a versioned environment. Versioning offers the stability and flexibility we need to support smooth scalable transformation of our health information communication systems over time.