A template’s inaugural design often doesn’t seem like a “version”. It is difficult for designers while working closely to solve a problem, to envision that someday, perhaps even in the not too distant future, the solution they are in the midst of creating will need to change.
And so it is with templates. We build a template with an intension for its design to be stable. This stability allows an industry to rely upon templates and invest in innovations that utilize templates adopted as standards.
However, as progress pushes forward, the nature of a problem may change or a new opportunity for improvement is revealed. Templates need to change.
The true nature of a template is revealed as it works its way through a natural lifecycle. While a template is a singularly defined permanent thing with a unique purpose to fulfill, through its lifecyle it also is a set of designs managed as distinct and changing versions of the template they represent. Like Clouds and Mountains, a template is both stable and flexible at the same time.
A greater appreciation of the template lifecycle gives the knowledge needed to develop operational processes and governance policies to support the use of templates and other information artifacts with a similar nature, like value sets, FHIR resources, and common data elements.
As the number and kind of standard “templates” expands and our reliance on them increases, the ability to manage templates over time is becoming a critical need for HIT Stakeholders at all levels.
- To understand the lifecycle of a template you must first appreciate the relationship between a template and its versions.
- You need to know about the model describing the states a template version goes through.
- You also need to understand the types of relationships that may exist between different template versions.
The next blog post will discuss this background material in greater detail to provide the foundation you need to understand the template lifecycle.