This is a supplement to the IHE PCC Technical Framework . Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.
This supplement is published on for Public Comment. Comments are invited and may be submitted at http://www.ihe.net/PCC/PCCcomments.cfm. In order to be considered in development of the Trial Implementation version of the supplement, comments must be received by .
This supplement describes changes to the existing technical framework documents.
“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.
General information about IHE can be found at: www.ihe.net.
Information about the IHE PCC domain can be found at: http://www.ihe.net/Domains/index.cfm.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at: http://www.ihe.net/About/process.cfm and http://www.ihe.net/profiles/index.cfm.
The current version of the IHE PCCTechnical Framework can be found at: http://www.ihe.net/Technical_Framework/index.cfm.
http://ihe.net/ihetemplates.cfm. Please enter comments/issues as soon as they are found. Do not wait until a future review cycle is announced. CONTENTS
The purpose of this supplement is to update IHE PCC Templates to be consistent with the most recent version of HL7 templates published in the IHE Health Story Consolidation Implementation Guide. This supplement addresses how IHE templates are to be versioned, and how new versions of templates can be created to replace existing templates.
Open Issues and Questions
What text should be used to identify a template version? Should versions be sequentially numbered? If so, should we start with version 1 or version 2, given that existing templates did not have a version number. Should we use the date of publication of the template? If dates are used, how do we deal with changes between publication for public comment and final text? If numbers are used, would we also indicate state (e.g., PC, TI, FT).
We will use version numbers in the form Major.minor. Existing templates will be defined as being version 1.0, but will not have an extension denoting that.
With the introduction of template versions, how can a consumer of content determine whether they support the versions of the templates present in a document? Can this be structured/declared in a way that does not require inspection of all templates in the document being consumed?
We will create a template for each revision of the PCC Technical Framework which can be used within a document to indicate the minimum version of the PCC TF that must be understood in order to be able to understand the PCC TF Content.
When templates are versioned, some new versions will be backwards compatible with previous versions, and others may not be. Is there a way to mark these version changes (e.g., major/minor)?
A backwards compatible change is one where the receiver of a CDA document can still correctly understand a template without having to be modified (even though it may not understand additional content). A change that is not backwards compatible is considered a change to the major revision of a template.