Profile Integrity and Revision

From IHE Wiki
Revision as of 16:34, 3 April 2007 by Chrisdcarr (talk | contribs) (Process for Creating, Maintaining and Revising IHE Profiles)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

What Is an IHE Profile?

What Are Profile Options and What Are the Rules for Their Creation?

What Types of Profiles Are There?

What Is the Life Cycle of an IHE Profile?

What are the Rules for Revising Profiles?

What Are the Criteria for Moving a Profile to Final Text?

How Do You Modify a Profile after it is Published as Final Text?

Co-Chair Perspective

With regard to the evolution of the XDS specification, we have two conflicting requirements: stability and evolution. Vendors and national programs need a stable specification. But, we must offer, through profiles, new technology as it becomes stable and available. As profile writers we are near the beginning of the process. While we follow the work of standards development bodies, we must keep in mind all the industrial and community decisions that must be made after we do our work.

It is from this perspective we propose that the XDS specification be frozen from the perspective of adoption of new technologies with Revision 3 dated 2006-12-09. The XDS specification will still be allowed to be changed from the perspective of applying necessary editorial and technical fixes. We should embark, this season, on the creation of a new XDS2 specification which will incorporate the new Web Service extensions and the new Web Services Retrieve transaction. The evolution of XDR, and XDM should follow this same pattern.

This approach is consistent with other movements within ITI. The sub-group working on PIX/PDQ V3 are close to deciding that PIX/PDQ V3 should live apart from the original V2 version of PIX/PDQ allowing developers and installations the choice of which generation of specification to support/use. A recent decision by the committee has moved the Change Proposal work on Patient Identity Merge/Link into a suppliment. This important work will therefore not burden the above approach. It also allows the solution to the Patient Identity Merge/Link issue move into the Technical Framework or stay in Supplement form (Trial Implementation) as long as is necessary given the concensus process.

If this approach is accepted then a major issue to resolve is what is the scope of XDS2. Should it only include the new Web Services etc. issues that are on the table this season. Should we wait another season to get a better version 2? These are important considerations.

We believe that this approach will allow vendors, communities, and national programs to adopt the technology as it makes sense for them.