Change+Proposal+Process

The Spec Factory Change Proposal Process was adopted from IHE. IHE's process can be found [|here].

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 submitted by users, vendors or Technical Committee members, and usually result from experiences implementing Profiles, using Profiles or testing them at Connectathons.

=Change Proposal Process= toc The status of a Change Proposal proceeds in the following sequence:

A **Submitted Change Proposal** has been documented using the latest and submitted to the Domain. Change Proposals should be emailed to a Cochair of the [|Domain Technical Committee] that published the document (or if not known, emailed to secretary@ihe.net).

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 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 public comment, and
 * for letter ballot by Domain Technical Committee 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.

An **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 Proposal File Names
When **submitting** a change proposal, the file name should be where: For example: CP-ITI-KW-ReplaceOptionalAttributes.doc
 * CP- - -<2|3WordSummary>.doc**
 * is the domain the CP will be submitted to - one of ITI, RAD, CARD, LAB, EYE, PCC, PCD, RO, QRPH
 * are the initials of the person submitting the CP
 * <2|3WordSummary> are 2 or 3 words describing the CP

Once **assigned**, the change proposal file will become where:
 * CP- - - .doc**
 * is the domain of the CP - one of ITI, RAD, CARD, LAB, EYE, PCC, PCD, RO, QRPH
 * is the id number assigned by the Domain Technical Committee
 * is the version of the file
 * starting at 00 and incrementing for each revision of the CP including when it is sent back to Assigned due to comments in ballot (e.g CP-ITI-031-05.doc)
 * FT when a CP becomes final text (e.g. CP-RAD-123-FT.doc)
 * IN when a CP has been incorporated (e.g. CP-CARD-023-IN.doc)

Change Proposal Publication
//// ////

Change Proposal Tracking
Each domain technical committee manages CPs on the ihe [|ftp] site. A common directory structure for this management is desirable, but not yet accomplished. As a common directory structure is agreed to this page will be updated.

Each domain technical committee also maintains a CP-specific wiki page containing:
 * A description of the ftp directory structure used by the domain
 * A table of Final Text CPs for the domain
 * A table of CPs in other statuses (optional)
 * A link to the Excel spreadsheet used to track the status of all CPs. A common format for the Excel spreadsheet is desirable, but not yet agreed to.

Examples:
 * The [| ITI CP Tracking] Wiki page
 * The [|RAD CP Tracking Folder] (details on who does what-when can be found on the Process tab of the tracking document in the folder.)

Editing Change Proposals
A change proposal must specify exactly how the Technical Framework/Supplement will be changed.

When **modifying existing text**, paste the original text into the Change Proposal and DO NOT use MS Word change tracking. Manually format all changed text to bold and either underline the new text or cross out the text to be removed.

When **pasting other text** from documents other than an IHE Technical Framework or Supplement, use “Paste Special…”, select “Unformatted text”, and apply the appropriate styles to the text inserted. This avoids importing spurious paragraph formats (which are the cause of significant headaches for editors).

Proposed changes should be introduced with “editors instructions” in a “box” such as:


 * Replace Section X.X by the following: ||

or

//This category currently contains no pages or media.//
 * Add the following section after Section X.X: ||