Difference between revisions of "Maintenance Process"

Revision as of 19:43, 5 October 2021

<<This is a proposal adapted from DICOM. We can decide if it is what we want to do in QIBA.>>

Profiles are published with the belief that they are fully adequate for their task. Despite the best efforts of the authoring Committee, documents may contain text that is unclear, incomplete or incorrect.

Change Proposals (CPs) are the way stable, published technical documents can be modified. Profiles are not placed under change control until they are published as Technically Confirmed (?)

Users, vendors or Committee members submit CPs based on experiences implementing, testing or using Profiles.

Implementers review change proposals to keep up with changes to the Profile.

A Submitted Change Proposal has been documented using the latest change proposal template and emailed to a Cochair of the authoring Committee (or if not known, emailed to RSNA Staff).

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 document requested to be changed.

The authoring Committee periodically reviews submitted Change Proposals which are then either assigned or rejected.

A Rejected Change Proposal has been rejected by the authoring 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 authoring Committee and assigned to a member of the Authoring Committee for further investigation with the goal to produce adequate clarifications or corrections.

A Cancelled Change Proposal has been cancelled by the authoring 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 authoring Committee. <<This is sometimes used as the input to a ballot, and after ballot it becomes final text. Probably more overhead than QIBA needs right now.>>

A Final Text Change Proposal has been approved by the authoring 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 the Profile. <<QIBA might just skip Final Text and go straight to publishing the Incorporated Change. In that case the change is not effective until published Incorporated.>>

Notes:

Change Log at the beginning of the Profile document is helpful during editing.

Need to flowchart how the process goes that results in an update to the Profiles page that provides visibility to the existence and details of changes. Agreement that in later stages, changes should be more judicious and documented.

Could have a history page that tracks prior versions and CP docs with changes. Maybe have the history link beside each new one to make it obvious.

Q. Dates vs Version numbers?

In early stages, documents may change significantly and frequently. Note that "versions" will be cited though even at earlier stages. And maybe incorporate stage into the version as well.

Consider advising BCs to remove "change log" section once the profile gets to Tech Conf (or perhaps even when it goes to Consensus)

CP as a voice or ballot of BC only.

@@ Line 1: / Line 1: @@
-The purpose of this process step is to actively seek and periodically respond to feedback on use of published documents.  It is important to put this into context with other activities that may seem similar at first: Whereas the review and public comment steps that are part of the Drafting phase focus on the document itself, prior to its use, and the Collect Feedback step as part of the Field Test phase collects feedback on the initial use of the document given that it has been placed into trial implementation, this step is where longer-term, extended use of the document allows for actual assessment of its performance in practice.  That is, over the course of time clinical trials may complete that had been designed with this, and/or other results from field usage may become evident either with the user or supplier base.  As such, comments are solicited periodically for a wide range of the public that may connect with it in some way.
+''<<This is a proposal adapted from DICOM.  We can decide if it is what we want to do in QIBA.>>''
-A procedure is outlined below listing what is done (by whom).
+Profiles are published with the belief that they are fully adequate for their task.  Despite the best efforts of the authoring Committee, documents may contain text that is unclear, incomplete or incorrect.
+'''Change Proposals''' (CPs) are the way stable, published technical documents can be modified.  Profiles are not placed under change control until they are published as ''Technically Confirmed'' (?)
-Period: 30 days
+Users, vendors or Committee members submit CPs based on experiences implementing, testing or using Profiles.
-* Periodically, collect list of people that may have used the document and/or professional societies that may have a particular relationship to the document (secretariat)
+Implementers review change proposals to keep up with changes to the Profile.
-* Finalize comment form that will be used in the survey (secretariat with technical committee)
-* Send announcement to mailing lists (secretariat)
-** reminder copy of document that has been placed into field test
+A '''Submitted Change Proposal''' has been documented using the latest change proposal template and emailed to a Cochair of the authoring Committee (or if not known, emailed to RSNA Staff).
-** provide a link to the [[:Media:QIBA_Maintenance_Phase_Feedback_Template-2011.01.doc | QIBA Maintenance Phase Feedback Template]]
-* Email comments to secretariat (Commenters)
+The Change Proposal '''should include''':
-** commenters include full range of users of the document, e.g., vendors/suppliers, clinical oncologists, imaging scientists, pharma, CRO’s, etc.  However, only people who have used document are included.
+:* a problem description,
-** please use the provided comment form
+:* a rationale why the change is necessary,
-* Collate all comments into a spreadsheet (secretariat)
+:* a proposed solution or approach to the problem,
-** Summarize range of feedback to the questions into a report for review by the technical committee provided by the secretariat.
+:* and the parts of the document requested to be changed.
-** Technical Committee decides what changes to make (if any) to the document and whether to refer it to the Modality Committee for re-publication of an updated version, whether to branch the document leaving the current version in place but spawning a derivative, or to retire the document
-* Record resolution in spreadsheet
+The authoring Committee periodically reviews submitted Change Proposals which are then either assigned or rejected.
-** Regardless of recommended status for this document, ensure that the results are made available to related activities
+A '''Rejected Change Proposal''' has been rejected by the authoring 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 authoring Committee and assigned to a member of the Authoring Committee for further investigation with the goal to produce adequate clarifications or corrections.
+A '''Cancelled Change Proposal''' has been cancelled by the authoring 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 authoring Committee.  ''<<This is sometimes used as the input to a ballot, and after ballot it becomes final text.  Probably more overhead than QIBA needs right now.>>''
+A '''Final Text Change Proposal''' has been approved by the authoring 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 the Profile. ''<<QIBA might just skip Final Text and go straight to publishing the Incorporated Change.  In that case the change is not effective until published Incorporated.>>''
+Notes:
+Change Log at the beginning of the Profile document is helpful during editing.
+Need to flowchart how the process goes that results in an update to the Profiles page that provides visibility to the existence and details of changes.  Agreement that in later stages, changes should be more judicious and documented.
+Could have a history page that tracks prior versions and CP docs with changes.  Maybe have the history link beside each new one to make it obvious.
+Q. Dates vs Version numbers?
+In early stages, documents may change significantly and frequently. Note that "versions" will be cited though even at earlier stages.  And maybe incorporate stage into the version as well.
+Consider advising BCs to remove "change log" section once the profile gets to Tech Conf (or perhaps even when it goes to Consensus)
+CP as a voice or ballot of BC only.

Difference between revisions of "Maintenance Process"

Revision as of 19:43, 5 October 2021

Navigation menu

Search