Category:CPs: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Witting (talk | contribs)
editor
1,865 edits
Kevino (talk | contribs)
editor
4,951 edits
Update CP States
Line 13: Line 13:
The Technical Committee regularly considers Change Proposals which are then either assigned or rejected.  
The Technical Committee regularly considers Change Proposals which are then either assigned or rejected.  


A '''Rejected Change Proposal''' has been rejected by the Technical Committee as inappropriate.  It is published with a rationale explaining why.
A '''Rejected Change Proposal''' has been rejected by the Technical Committee and will not be assigned.  It is archived with an explanation of the reason for rejection (it is an inappropriate change, it duplicates another CP, it is out of scope, etc.).


An '''Assigned Change Proposal''' has been accepted by the Technical Committee and assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or corrections.  
An '''Assigned Change Proposal''' has been accepted by the Technical Committee and assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or corrections.  


A '''Cancelled Change Proposal''' has been cancelled by the Technical Committee and no further work on it is planned.  It is published with an explanation of the reason for cancellation (later analysis showed it to be inappropriate, it is a duplicate or has been merged with an existing CP, it has been withdrawn, etc.)   
A '''Cancelled Change Proposal''' has been cancelled by the Technical Committee after being assigned and will not be completed.  It is archived with an explanation of the reason for cancellation (investigation/development showed it to be inappropriate, it has been combined with another CP, it has been withdrawn, etc.)   


''<Question: can you go directly from submitted to canceled?  Answer: No, from submitted, it would be rejected and not given a tracking number.  This avoids cluttering the CP tracking process by filtering out simple misunderstandings at the beginning.>''
A '''Completed Change Proposal''' has been reviewed and the editing judged complete by the Technical Committee. To allow broader feedback, Completed Change Proposals are published:
 
:* for letter ballot by all Domain Technical Committee members, and
''<Q: What about a CP that was a duplicate when submitted? A: It would be rejected as a duplicate and not tracked>''
:* for public comment by non-voting members
 
Negative votes or issues raised may result in the Change Proposal going back to Assigned or Cancelled.
''<Q: Do we really need both canceled and rejected?  Lets just call it canceled and in the explanation say if its inappropriate. A: Rejected CPs are culled at the beginning and not tracked internally.  Ideally there would be no cancellations since we would catch reject as necessary at the beginning, but we're human so somethings may cancelled after work has begun.>''


An '''Approved/Done/??? Change Proposal''' has been reviewed by the Technical Committee and approved as adequate.  To allow the text to be considered by a wider group than those attending the given TC meeting, generally an Approved/Done Change Proposal is either:
:* distributed for letter ballot to all Domain Technical Committee members, or
:* published for a 30-day public comment
Negative votes or issues raised may result in the Change Proposal going back to Assigned or Cancelled.


A '''Final Text Change Proposal''' has passed letter ballot and the comments resolved to the satisfaction of the Technical Committee.  It is published and considered effective.  Implementors are expected to implement Final Text Change Proposals as described below.


A '''Final Text Change Proposal''' has passed the development and approval process steps.  It 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.  
A '''Incorporated Change Proposal''' has been folded into an updated version of a Technical Framework or Supplement, typically at the end of each annual development cycle.  Implementors using the newest published version of a Technical Framework or Supplement are advised to disregard Incorporated Change Proposals since they are already reflected in the new Framework and are not separately maintained.




'''Implementors''' should base their work on:
'''Implementors''' should base their work on:
: the current version of a Technical Framework
: the current version of a Technical Framework
: + all Final Text Supplements not yet merged into the Technical Framework
: + all Final Text Supplements
: + all Final Text Change Proposals not yet merged into the Technical Framework or Supplements
: + all Final Text Change Proposals to the Technical Framework or Supplements


''<Can we introduce the state of Merged for supplements and CPs?  Statements like the above would be simplified to "all Final Text Supplements" if a Final Text Supplement becomes a Merged Supplement after it has been merged into the Technical Framework.  We could then tell people to avoid Merged Supplements since they are not maintained.>''




Revision as of 14:38, 13 February 2007

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

Change Proposals (CPs) 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 has been documented using the latest change proposal template 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 or Supplement requested to be changed.

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

A Rejected Change Proposal has been rejected by the Technical Committee and will not be assigned. It is archived with an explanation of the reason for rejection (it is an inappropriate change, it duplicates another CP, it is out of scope, etc.).

An Assigned Change Proposal has been accepted by the Technical Committee and assigned to a member of the Technical Committee as a work item for further investigation with the goal to produce adequate clarifications or corrections.

A Cancelled Change Proposal has been cancelled by the Technical Committee after being assigned and will not be completed. It is archived with an explanation of the reason for cancellation (investigation/development showed it to be inappropriate, it has been combined with another CP, it has been withdrawn, etc.)

A Completed Change Proposal has been reviewed and the editing judged complete by the Technical Committee. To allow broader feedback, Completed Change Proposals are published:

  • for letter ballot by all Domain Technical Committee members, and
  • for public comment by non-voting members

Negative votes or issues raised may result in the Change Proposal going back to Assigned or Cancelled.


A Final Text Change Proposal has passed letter ballot and the comments resolved to the satisfaction of the Technical Committee. It is published and considered effective. Implementors are expected to implement Final Text Change Proposals as described below.

A Incorporated Change Proposal has been folded into an updated version of a Technical Framework or Supplement, typically at the end of each annual development cycle. Implementors using the newest published version of a Technical Framework or Supplement are advised to disregard Incorporated Change Proposals since they are already reflected in the new Framework and are not separately maintained.


Implementors should base their work on:

the current version of a Technical Framework
+ all Final Text Supplements
+ all Final Text Change Proposals to the Technical Framework or Supplements


Change Proposals

<Imagine a list of change proposals (likely one list/table per domain) here linking to Word documents on ftp.ihe.net. The lists could be generated automatically using scripts like those used for DICOM. Failing that, the Tech Cmte could manually update the status.>

CP Title Profiles Affected Status
RAD-085 Language about CDs with multiple patients information PDI IRWF Final Text
RAD-086 Add use case to TCE profile for Publication Submission TCE Assigned
RAD-087 ... ... ...


<Consider the requirements on the Discussion tab above. It might be useful to group/sort the CPs by Domain and possibly by Profile Affected.>

<Consider links to zipped bundles of CPs instead/in addition. Getting them all one by one is painful>

Change Proposal File names

Change proposals (CP) are kept in a file on the ftp site. The file name will be: CP-<domain>-<number>-<version>.doc where:

  • domain is the domain of the CP - one of ITI, RAD, <fill in list>
  • number is the nubmer assigned by the domain committee
  • version is the version of the draft, starting at 00 and incrementing for each change the the CP. When a CP becomes final text the version is changed to FT, as in CP-RAD-123-FT.doc. When a CP is incorporated the version is changed to IN.

Example: CP-RAD-123-02.doc, CP-ITI-031-05.doc

All characters are upper case.

This category currently contains no pages or media.

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