Category:CPs: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
← Older editNewer edit →
Kevino (talk | contribs)
editor
4,951 edits
Kevino (talk | contribs)
editor
4,951 edits
Updated Draft for review
Line 1: Line 1:
'''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.
Despite the best efforts of the [[Committees|Technical Committees]], documents may contain text that is unclear, incomplete or incorrect.  


We could organize this page several ways.
'''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.


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 [[:Category:Profile Implementations| 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.
A '''Submitted Change Proposal''' has been documented using the [ftp://ftp.ihe.net/Document_templates latest change proposal template] and submitted to a Domain Technical [[Committees|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.


==Implementor Needs==
The Technical Committee regularly considers Change Proposals which are then either assigned or rejected.  
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.  
A '''Rejected Change Proposal''' has been rejected by the Technical Committee as inappropriate.  It is published with a rationale explaining why.


'''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.
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 '''Submitted Change Proposal''' is documented using the [[Change Proposal Form]] and submitted to a Domain Technical [[Committees|Committee]].  The Change Proposal should include:
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 (analysis showed it to be inappropriate, it is a duplicate or has been merged with an existing CP, it has been withdrawn, etc.)
:* 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.  
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 '''Rejected Change Proposal''' is published with a rationale from the Technical Committee explaining why the change is not appropriate.
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.  


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.
'''Implementors''' should base their work on:
: the current version of a Technical Framework
: + all Final Text Supplements not yet merged into the Technical Framework
: + all Final Text Change Proposals not yet merged into the Technical Framework or Supplements


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.  
''<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.>''


(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.
==Change Proposals==


''<Imagine a list of change proposals 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.>''


'''Current Radiology FTP Usage for organizing/ managing CP documents'''
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).


[[Image:Ftp-cp-usage.jpg]]
''<Consider the requirements on the Discussion tab above. It might be useful to group/sort the CPs by Domain and possibly by Profile Affected.''>

Revision as of 16:27, 6 February 2007

Despite the best efforts of the Technical Committees, 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 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 as inappropriate. It is published with a rationale explaining why.

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 (analysis showed it to be inappropriate, it is a duplicate or has been merged with an existing CP, it has been withdrawn, etc.)

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 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.


Implementors should base their work on:

the current version of a Technical Framework
+ all Final Text Supplements not yet merged into the Technical Framework
+ all Final Text Change Proposals not yet merged into 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.>


Change Proposals

<Imagine a list of change proposals 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.>

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).

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

This category currently contains no pages or media.

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