This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Template Versioning Requirements"
Jump to navigation
Jump to search
| Line 24: | Line 24: | ||
=Template representation bakeoff= | =Template representation bakeoff= | ||
| − | *No versioning. Any change results in new templateId. | + | *CURRENT WORKING ASSUMPTION IS THAT THIS IS THE PREFERRED APPROACH (subject to some refinement): No versioning. Any change results in new templateId. (Assumes the ability to assert various semantic relationships, such as "supercedes", along with "implies" and "contains"). |
*Add version number / version date to template (and allow for inclusion in references). | *Add version number / version date to template (and allow for inclusion in references). | ||
| + | *Assume that in the absence of a version in a reference, the reference is to version 1. | ||
=Background sources= | =Background sources= | ||
| Line 33: | Line 34: | ||
* eMeasure versioning / clinical document versioning | * eMeasure versioning / clinical document versioning | ||
* Template DSTU | * Template DSTU | ||
| + | * HL7 Template Registry requirements | ||
Revision as of 17:01, 10 December 2009
SDWG page.
Contents
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
- CURRENT WORKING ASSUMPTION IS THAT THIS IS THE PREFERRED APPROACH (subject to some refinement): No versioning. Any change results in new templateId. (Assumes the ability to assert various semantic relationships, such as "supercedes", along with "implies" and "contains").
- Add version number / version date to template (and allow for inclusion in references).
- Assume that in the absence of a version in a reference, the reference is to version 1.
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
- HL7 Template Registry requirements
