Difference between revisions of "Maintenance Process"
(New page: 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 tha...) |
|||
| (13 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ''<<This is a proposal adapted from DICOM. We can decide if it is what we want to do in QIBA. Definitely within a Stage but probably not when moving from one stage to the next (defiinitely not for Stages 1->2->3 since those were not really "stable" to begin with.>>'' | |
| − | + | ''<<Need to sketch up how we're going to communicate what CPs are approved but NOT yet incorporated in the latest Profile Edition. Also what CPs have ALREADY been incorporated in the latest Profile Edition (i.e. what's different). Likely a CP page and link to it from profiles that have NOT yet incorporated the newest. The decision of when to incorporate and publish a new revision will be up to the BC. Maybe a guidance page on factors to consider when the BC decides.>><<Keep it clear to the users. >><<Be VERY CLEAR - no changes without updating the date. So what do you declare when there is no "new" edition but there is an approved CP that you (site) have followed so what do you say you conformed to? Edition <previous> + CP <number> >>'' | |
| + | ''<<Note that approval can be on live meeting or by email>>'' | ||
| − | + | 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 ''Clinically Feasible'', (formerly ''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. | ||
Latest revision as of 21:52, 15 November 2022
<<This is a proposal adapted from DICOM. We can decide if it is what we want to do in QIBA. Definitely within a Stage but probably not when moving from one stage to the next (defiinitely not for Stages 1->2->3 since those were not really "stable" to begin with.>>
<<Need to sketch up how we're going to communicate what CPs are approved but NOT yet incorporated in the latest Profile Edition. Also what CPs have ALREADY been incorporated in the latest Profile Edition (i.e. what's different). Likely a CP page and link to it from profiles that have NOT yet incorporated the newest. The decision of when to incorporate and publish a new revision will be up to the BC. Maybe a guidance page on factors to consider when the BC decides.>><<Keep it clear to the users. >><<Be VERY CLEAR - no changes without updating the date. So what do you declare when there is no "new" edition but there is an approved CP that you (site) have followed so what do you say you conformed to? Edition <previous> + CP <number> >>
<<Note that approval can be on live meeting or by email>>
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 Clinically Feasible, (formerly 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.