Template Versioning Requirements

SDWG page.

Template compatibility requirements

• Ability to indicate forward/backward compatibility
  • Forward compatibility: An instance that conforms to a new version of a template will also continue to conform to a prior version of the template. (Example: Template X, version 1 constrains observation.code to Y. Version 2 constrains observation.code to Y and also constrains observation.effectiveTime to TS)
  • Backward compatibility: An instance that conforms to an old version of a template will also continue to conform to a new version of the template.

From the perspective of the IG constraint

• Template referencing is ALWAYS static (e.g. is ALWAYS to a specific version).
• Ability to constrain to a particular version of a template.
• Different versions retain the same name (suggesting the need for id and setId).
• Ability to distinguish a family of templates in a versioned chain from the particular version within a family.

From the perspective of the instance

• Template referencing is ALWAYS static (e.g. is ALWAYS to a specific version).
• An instance needs to be able to claim conformance with a particular version of a template.

Template metadata requirements

• Version history

Legacy template representation

• Given that these requirements are developed on top of existing IGs...

Template representation bakeoff

• No versioning. Any change results in new templateId.
• Add version number / version date to template (and allow for inclusion in references).

Background sources

• HITSP Template versioning position statement (TN904)
• Value set versioning
• Data types R2 Instance Identifier representation (version identifier)
• eMeasure versioning / clinical document versioning
• Template DSTU