Category:CPs: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Kevino (talk | contribs)
editor
4,951 edits
mNo edit summary
Kevino (talk | contribs)
editor
4,951 edits
Line 31: Line 31:
==CP Management==
==CP Management==


'''Maintenance of existing Technical Framework content  <From Volume 1 Rad>'''
Despite the best efforts of the Technical Committee, documents may contain text that is unclear, incomplete or incorrect.   


Despite the best efforts of the Technical Committee, a published current version of the Technical Framework or Trial Implementation documents may contain text that is incorrect, incomplete or unclear. Such issues are handled as Change Proposals and cover:
'''Change Proposals''' are the way stable, published technical documents (Technical Framework volumes, Final Text Supplements or Trial Implementation Supplements) can be modified.  Change Proposals may be sumbitted by users, vendors or Technical Committee members, and usually result from experiences implementing Profiles, using Profiles or testing them at Connectathons.


:* '''Corrections''': where technical issues causing non-interoperability of implementations are fixed without introducing changes in functionality of a stable Integration Profile.
A '''Submitted Change Proposal''' is documented using the [[Change Proposal Form]] and submitted to a Domain Technical [[Committees|Committee]]. The Change Proposal should include:
:* '''Clarifications''': where text that can be misunderstood or is ambiguous is made easier to understand or disambiguated, without introducing any technical changes.
 
The publication process is the same for both Corrections and Clarifications, and addresses both changes to Trial Implementations and changes to a current version of the Technical Framework.
 
 
A '''Submitted Change Proposal''' results from issues raised by users, vendors or Technical Committee members, e.g. from experiences with Trial Implementation or Final Text Integration Profiles or at a Connect-a-thon. The resulting Change Proposal document should explicitly state:
:* the parts of the Technical Framework requested to be changed,
:* a problem description,  
:* a problem description,  
:* a rationale why the change is considered necessary,
:* a rationale why the change is necessary,
:* and a solution or approach to the problem.  
:* a proposed solution or approach to the problem,
:* and the parts of the Technical Framework requested to be changed.


The Technical Committee regularly considers Change Proposals which are then either accepted or rejected.  
The Technical Committee regularly considers Change Proposals which are then either assigned or rejected.  




A '''Rejected Change Proposal''' is published with a rationale from the Technical Committee explaining why the change is not appropriate.
A '''Rejected Change Proposal''' is published with a rationale from the Technical Committee explaining why the change is not appropriate.


An '''Accepted Change Proposal''' is assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or corrections. The resulting text will again be reviewed by the Technical Committee, and if the text is considered adequate, it is approved.
An '''Assigned Change Proposal''' is assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or corrections. The resulting text is reviewed by the Technical Committee, and if the text is considered adequate, it is approved.


An '''Approved Change Proposal''' is published by the Technical Committee.  Typically a change proposal will stay in the Approved state for at least 30 days.  This period provides a window of opportunity for any public comments on the change proposal which will be considered by the Technical Committee before it is made Final Text.
An '''Approved Change Proposal''' is published by the Technical Committee.  Typically a change proposal will stay in the Approved state for at least 30 days.  This period provides a window of opportunity for any public comments on the change proposal which will be considered by the Technical Committee before it is made Final Text.


A '''Final Text Change Proposal''' is published by the Technical Committee, and is then considered effective. It will be merged into the next version of the Technical Framework, typically done at the end of the annual development cycle. (Submitting a Change Proposal to a Final Text Change Proposal or a Final Text Supplement is not possible?)
A '''Final Text Change Proposal''' is published by the Technical Committee, and is then considered effective. It will be merged into the next version of the Technical Framework, typically done at the end of the annual development cycle.  
 
(Submitting a Change Proposal to a Final Text Change Proposal or a Final Text Supplement is not possible?)


The current version of the Technical Framework is considered the primary reference document. Final Text Supplements and Final Text Change Proposals from the current annual cycle complement this document. Past Final Text documents are retained to provide convenient summaries of differences to prior versions of the Technical Framework or Trial Implementation versions of Supplements.
The current version of a Technical Framework is the primary reference document. Final Text Supplements and Final Text Change Proposals from the current annual cycle supplement this document. Past Final Text documents are retained to provide convenient summaries of differences to prior versions of the Technical Framework or Trial Implementation versions of Supplements.




Revision as of 16:08, 11 January 2007

This page currently describes our requirements for CPs and ideas for using the Wiki. Once we have figured it out and are ready to start drafting a proper CP page we should move this text to Discussion and draft here.

We could organize this page several ways.

1) We could have a manually edited table (probably similar to the Frameworks page, one table for each domain, that lists each CP, maybe indicates the Profile it affects, it's current status and a link to a file with the CP (or a bunch of them).

2) We could have an automatically generated list (similar to the Profile Implementations page. We would then have a page for each CP (based on a template). This might work best if the page was the actual master copy of the CP. The CP pages could have several categories like (XDS CPs) (IT Infra CPs) (Final Text CPs) which give us a bunch of handy autopopulating index pages. ...

Implementor Needs

Q. What CPs do I need to apply (based on what actor/transaction/profile I've implemented and which "version" of the spec I was working from)

Q. What CPs are currently under consideration/development

Q. How do I submit a CP?

Q. What is the current status of a particular CP

Tech Cmte Needs

Q. What CPs are currently under consideration/development

Q. How do I submit a CP?

Q. What is the current status of a particular CP

Q. What CPs are assigned to me?

Q. [TF Editor] What CPs do I need to fold into the next draft of the TF?


CP Management

Despite the best efforts of the Technical Committee, documents may contain text that is unclear, incomplete or incorrect.

Change Proposals are the way stable, published technical documents (Technical Framework volumes, Final Text Supplements or Trial Implementation Supplements) can be modified. Change Proposals may be sumbitted by users, vendors or Technical Committee members, and usually result from experiences implementing Profiles, using Profiles or testing them at Connectathons.

A Submitted Change Proposal is documented using the Change Proposal Form and submitted to a Domain Technical Committee. The Change Proposal should include:

  • a problem description,
  • a rationale why the change is necessary,
  • a proposed solution or approach to the problem,
  • and the parts of the Technical Framework requested to be changed.

The Technical Committee regularly considers Change Proposals which are then either assigned or rejected.


A Rejected Change Proposal is published with a rationale from the Technical Committee explaining why the change is not appropriate.

An Assigned Change Proposal is assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or corrections. The resulting text is reviewed by the Technical Committee, and if the text is considered adequate, it is approved.

An Approved Change Proposal is published by the Technical Committee. Typically a change proposal will stay in the Approved state for at least 30 days. This period provides a window of opportunity for any public comments on the change proposal which will be considered by the Technical Committee before it is made Final Text.

A Final Text Change Proposal is published by the Technical Committee, and is then considered effective. It will be merged into the next version of the Technical Framework, typically done at the end of the annual development cycle.

(Submitting a Change Proposal to a Final Text Change Proposal or a Final Text Supplement is not possible?)

The current version of a Technical Framework is the primary reference document. Final Text Supplements and Final Text Change Proposals from the current annual cycle supplement this document. Past Final Text documents are retained to provide convenient summaries of differences to prior versions of the Technical Framework or Trial Implementation versions of Supplements.


Current Radiology FTP Usage for organizing/ managing CP documents

This category currently contains no pages or media.

Retrieved from "http://wiki.ihe.net/index.php?title=Category:CPs&oldid=2514"