Difference between revisions of "Category:CPs"

Overview

Despite the best efforts of the Technical Committees, published technical documents (Final Text Technical Framework volumes or Trial Implementation Supplements) may contain text that is unclear, incomplete or incorrect.

Change Proposals (CPs) are the way published technical documents 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

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

> > Submitted Change Proposal: The user or implementor documents the CP using the latest change proposal template:

• Change Proposal Template on the IHE Google Drive (as of June-2020)

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

See guidance below on file names for CPs.

The user or implementor submits the CP to the Domain: Change Proposals should be emailed to a Co-chair of the Domain Technical Committee that published the document (or if not known, emailed to secretary@ihe.net).

(Although the above general directions apply, some domains have established supplemental processes for submission. For example, see the ITI domain CP process.)

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

> > Rejected Change Proposal: The Technical Committee reviews the CP and determines and will not be assigned. It is archived with an explanation of the reason for rejection (e.g., it is an inappropriate change, it duplicates another CP, it is out of scope, etc.).

>> Assigned Change Proposal: The Technical Committee reviews the CP and assigns to a member of the Technical Committee for further investigation with the goal to produce adequate clarifications or corrections.

> > Cancelled Change Proposal: The Technical Committee decides, after some investigation, that an assigned CP will not be completed and should be cancelled. The CP 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.)

> > Completed Change Proposal: The Technical Committee reviews the changes in an Assigned CP, and judges the editing to be complete.

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.

> > Final Text Change Proposal: has passed letter ballot and the Technical Committee has resolved any comments to the satisfaction of the committee members. The CP is published and considered effective. Implementors are expected to implement Final Text Change Proposals as described below.

> > Incorporated Change Proposal: The Technical Committee integrates Final Text CPs to produce an updated version of a Technical Framework or Supplement, typically at the end of each annual development cycle.

Implementors should base their work on:

the current version of a Technical Framework

+ all Trial Implementation and 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

CP-<domain>-<initials>-<2|3WordSummary>.doc

where:

• <domain> is the domain the CP will be submitted to - one of ITI, RAD, CARD, LAB, EYE, PCC, PCD, RO, QRPH
• <initials> are the initials of the person submitting the CP
• <2|3WordSummary> are 2 or 3 words describing the CP

For example: CP-ITI-KW-ReplaceOptionalAttributes.doc

Once assigned, the change proposal file will become

CP-<domain>-<number>-<version>.doc

where:

• <domain> is the domain of the CP - one of ITI, RAD, CARD, LAB, EYE, PCC, PCD, RO, QRPH
• <number> is the id number assigned by the Domain Technical Committee
• <version> 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)

Final Text CP Publication

Starting with the 2015 cycle, a new (pilot) process for communicating Final Text CPs has been established. Not all domains will initially be utilizing this process and there may be slight variances per domain. The goal is to make Final Text CPs accessible to implementors by providing links. Questions about Final Test CPs for a specific domain should be directed to the domain's Technical Committee co-chairs (or the domain's designee).

The Process:

1. Each domain’s Technical Committee follows their current process for approving CPs.
2. Each domain should maintain an index (a spreadsheet or similar document) that tracks CPs as they move through the process
3. Once a CP is approved for Final Text, a member of the domain’s Technical Committee:
   1. Updates the index to add one row for each Final Text CP
   2. Makes a PDF of each Final Text CP, and puts it in the domain's Google Drive Folder of Final Text CPs (optional)
      1. If a domain chooses to add this step to their process, a Google Drive Folder has been set up [here]
4. Annually, when Final Text CPs are integrated into Final Text volumes and TI supplements, a member of the domain’s Technical Committee:
   1. Updates the row(s) added to the index to indicate the TF Volume/Supplement into which the CP has been integrated
5. Each domain will identify one person that can be a point-of-contact for CP inquiries. This person does not necessarily need to be the manager of CPs for that domain, but should be able to respond if there are questions about approved CPs in that domain.

Notes:

1. Items (3) and (4) will occur immediately following the approval of a Final Text CP (i.e. this is not a once-a-year process). That is because, as soon as a CP becomes Final Text, it carries the same weight as published FT and TI docs, e.g., it is ‘testable’ at a Connectathon from the time it is approved for Final Text, even if it will not be integrated until several months from now.
2. Both the Google Sheet ‘index’ and the Google Drive folder ‘collector of CPs’ is a cumulative record over time. It is not ‘cleaned out’ every year.

We are asking that each domain begin using the resources (Google Drive Folders and Google Spreadsheet Index) and process starting with CPs that are approved for Final Text and will update documents published in calendar year 2015. A domain may optionally choose to update these resources with CPs that were approved prior to 2015.

Change Proposal Tracking

Each domain technical committee manages CPs in IHE Documents on Google Drive. A common directory structure for this management is desirable, but not yet accomplished. Many domains manage their CPs in Google Drive under <Domain> >> TF_Maintenance >> CPs, with one sub-folder for each CP state (Submitted, Assigned, Completed...).

Each domain technical committee also maintains a CP-specific wiki page containing:

• A description of the 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 or google spreadsheet used to track the status of all CPs. A common format for the Excel spreadsheet is desirable, but not yet agreed to.

Examples:

IHE RAD Domain

• The Radiology CP Tracking spreadsheet
• The RAD CP management folder on the IHE Google Drive

IHE ITI Domain

• The ITI CP Tracking Spreadsheet
• The ITI CP management folder on the IHE Google Drive
• ITI domain CP Management on the IHE wiki, organized by year.

IHE PCC Domain

• The PCC Tracking Folders

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

Add the following section after Section X.X: