Purpose

1. Explain and provide instruction for initiating, reviewing, approving, and denying change requests for Research Informatics systems.

Responsibilities

1. Personnel that submit a change request are responsible for managing it within the change control logs.
2. System administrators or their designees are responsible for approval or denial of change requests for their system.

Instructions

1. 1. Go to the Sharepoint Change Control page.
   2. Select ‘New’ at the top. 
   3. Below is a list of all fields and a description of what each field should contain. Fields marked with an asterisk (*) are required before the request may be posted. Fields marked with a caret (^) are automatically filled, updated, or appended with the completion of the review/approval via Microsoft Teams.   
      1. Request Date*: The date the request was officially made, or work began on staging the change.
      2. Status*^: Used to determine what the status of the change is. New, In Progress, Approved, Denied, or Deployed are the available statuses.
      3. System*: What system the change applies to. Currently allows for selection of OnCore, eReg, and REDCap.
      4. Request Type: Defines if the log entry is for a change/update to a system or caused by an incident.
      5. Requested by*: Who initially requested the change and is in charge of the details of the change request.
      6. Short Description*: A brief description of the changes being made to the system.
      7. Change Reason and Summary*: The reason for the change to be made, including a summarization of the changes and any details about them.
      8. Risk Analysis^: Denotes the need for a risk analysis, who performed it, and the results of such.
      9. Impact Assessment: An observation of the change being made to identify potential hazards as well as the impact on users or the system itself. 21 CFR Part 11 compliant systems or environments are required to complete a Risk Analysis document that should be attached to the change request.
      10. Testing^: A description of the testing required to ensure the system change is functional and has not adversely affected the system.
      11. Notification Plan: A plan to identify users, support team members, or other personnel that may require a notification of the change.
      12. Approver^: The designated approver for a change request. Typically the approver is a supervisor for that system.
      13. Approval Date^: Date that the approval was given for the change to enter a production environment.
      14. Reviewer^: Name of the person who reviewed the change in a testing environment. This should be performed by a member of the system support team.
      15. Deployment Date: Date that the change was deployed to a production environment.
      16. Deployed by (person): Who deployed the change to a production environment.
      17. Sign-off status^: A designation that the change request was approved or denied.
      18. Emergency Change: A designation of whether the change being made was an emergency change or not.
      19. Review Date^: Date that the change/change request was reviewed.
      20. Approval/Denial Reason: Reason for approving or denying a change request. If the change is approved, comments may be added here. If the change is deemed too risky or unnecessary, it may be denied and the reason for such documented here.
      21. Related References: Lists any additional references necessary for understanding context around the request, including ticket numbers, links, and other text-related methods of accessing information.
      22. Attachments: Any pertinent documents to the change request may be attached, including any Risk Analysis documents that were created.
   4. After filling in the required fields and any supplementary information that may be available, the change request can be saved.
      1. All change requests are given a unique identification number for easy tracking.
      2. Additional information should be added as identified if need be.

Impact Assessment

An analysis of the impact that the change would have upon the system and any related risks.

1. 1. The impact assessment should detail what is affected by the change including fields, consoles or other functionality.
      1. May additionally include, but is not limited to:
         1. Expected down time
         2. Customer or user impact
         3. Security risks
   2. A Risk Analysis is required to be performed for 21 CFR Part 11 validated systems using SOP-RI-002 - Risk Analysis as a guide.
      1. The Risk Analysis Template should be used for this purpose, and attached to the change request upon completion.
      2. A Risk Analysis requires that a QA Specialist or IT Manager is contacted for review and guidance.

Testing and Documentation 

A change to a system should be tested and have the relevant documentation updated to reflect the change.

1. The request should outline what testing is required to verify the integrity of the system after the change.  
   
   1. The environment that the testing is conducted in should be included here.
2. The version of the software being tested should be included in the request if applicable.
3. Results of the testing should be included in the change request before deployment to a production environment.
4. Documentation (e.g. DFDs, User Guides, Work Instructions) should be updated to reflect the change if applicable.
   1. Changes to documentation should be listed in the change request for tracking purposes.

A plan that is made to ensure all that are affected by a change are properly notified.

1. 1. Any personnel or users that should be notified of the change to the system should be listed.
   2. The list of people to be notified may include, but is not limited to: 
      1. The change request reviewer
      2. The change request approver
      3. The support team for the system
      4. Impacted users
   3. The method of notification (e.g., email, Teams, Application UGM, center/institute meeting agendas) may be listed. Note: When using methods like Application UGM and center/institute meeting agendas, ensure the item is added directly on the resource as well.

Change Request Comments

1. If there is further discussion required during review or approval, such may be done with comments.
2. To add a comment, do the following:
   1. Go to the Sharepoint Change Control page.
   2. Select the desired change request.
   3. Select 'Edit'.
   4. On the right side, add the comment or question you have.
   5. Ensure to add an @Name for the person you intend to have answer the question or address the comment.
      1. This step is crucial so that the person is notified via email.

Requesting a Risk Analysis

1. Select the change request.
2. At the top select Automate > Risk Analysis Request.
3. Add a message for them in the Request field. This messaging should clearly state they are analyzing risk, not reviewing or approving the change.
4. Add them to the Approvers list.
   1. If listing more than one person, only one needs to sign off. The first to respond will be listed as the reviewer.
5. Set reminder specifications if desired.
6. Select Run Flow to send an email and Microsoft Teams request to the designated individual.

Risk Analysis Request

A Risk Analysis of the requested change may be required before a change to the system is approved for production deployment. This is not an impact assessment and is required for Part 11 compliant systems. Only request this for Part 11 compliant systems, and assign the request to an IT QA Specialist or IT Manager.

Microsoft Teams Review

1. Within Microsoft Teams, move to the Approvals tab
   1. If the Approvals tab is not visible, you can select it from the triple dots menu at the bottom of the sidebar.
2. Select the request (it will appear as an approval).
3. Select the attachment link and observe the change being made.
4. After analysis of the change is complete, enter a comment in teams explaining the extent and result of the risk analysis.
   1. The comment is automatically added to the change request in the Risk Analysis field when submitted.
5. Select Approve or Reject.
   1. Selecting Approve will automatically update the Risk Analysis field.
      1. The Risk Analysis field is appended with the comment provided.
   2. Selecting Reject will automatically update the Risk Analysis field.
      1. The Risk Analysis field is appended with the comment provided.
      2. If a change is determined to not need a risk analysis, the request may be rejected with a comment stating such. Comments will still be appended to the Risk Analysis field.
6. After completion of the risk analysis, the review and approval processes may proceed.

Requesting Review

1. Select the change request.
2. At the top select Automate > Change Request Review.
3. Add a message for the reviewer in the Request field. This messaging should clearly state they are reviewing/testing the change, not approving it.
4. Add the reviewer to the Approvers list.
   1. If listing more than one reviewer, only one needs to sign off. The first to review the change will be listed as the reviewer.
5. Set reminder specifications if desired.
6. Select Run Flow to send an email and Microsoft Teams approval request to the reviewer.

Review of a Change Request

A review of the requested change is required before a change to the system is approved for production deployment.

1. 1. All changes should be reviewed by a member of the support team for the system being changed.
   2. The reviewer is responsible for ensuring all changes to the system have been made correctly and did not cause extraneous variances. 
   3. The extent of the review should include, but is not limited to:
      1. Testing and verifying test results in a non-production environment.
      2. Ensuring the impact assessment (and risk analysis, if applicable) encompasses the hazards that the change may cause. 
      3. Verifying that any changes to documentation have been listed.
      4. Inspecting the notification plan for all who need to be informed.
   4. The following information should be added to the change request:
      1. Who reviewed the change request.
      2. Date the request was reviewed.
      3. The extent of testing and any issues encountered during such.
   5. The reviewer is responsible for providing feedback to the original requester if all requirements are not met.
      1. After alterations are made to the system the review process should be repeated until all requirements are satisfied.
      2. Problems encountered during testing should be documented with the change request.

There are two methods of documenting review of a change request. However, if you received a Microsoft Teams Review Request, you must use Microsoft Teams:

• Microsoft Teams Review (preferred method)

1. Within Microsoft Teams, move to the Approvals tab
   1. If the Approvals tab is not visible, you can select it from the triple dots menu at the bottom of the sidebar.
2. Select the review request (it will appear as an approval, but the action is still a review).
3. Select the attachment link and observe the change being made.
4. After testing of the change is complete, enter a comment in teams explaining the extent and result of testing.
   1. The comment is automatically added to the change request in the Testing field when submitted.
5. Select Approve or Reject.
   1. Selecting Approve will automatically update the Reviewer, Review Date, and Testing fields.
      1. The Testing field is appended with the comment provided by the reviewer when approved.
   2. Selecting Reject will automatically update the Reviewer field.
      1. No other fields are recorded in this instance as the testing is deemed incomplete.
      2. Rejected reviews are typically caused by selection of the wrong reviewer, an inability to test, or cancellation of the change request.

• Sharepoint Review (only as a backup)

1. Go to the Sharepoint Change Control page.
2. Select the desired change request.
3. Select 'Edit'.
4. Enter the name of the reviewer in the 'Reviewer' field.
5. Enter the date the request was reviewed in the 'Review Date' field.
6. Enter details of the extent and results of testing in the 'Testing' field if applicable.
   1. This should begin on a new line and preceded with 'Reviewer comments:'
7. Save the change request.

Requesting Approval

1. Select the change request.
2. At the top select Automate > Change Request Approval.
3. Add a message for the approver in the Request field. This messaging should clearly state they are approving the change request.
4. Add the approver to the Approvers list.
   1. If listing more than one Approver, only one needs to sign off. The first to sign off will be recorded as the Approver.
5. Set reminder specifications if desired.
6. Select Run Flow to send an email and Microsoft Teams approval request to the Approver.

Approval of a Change Request 

A request is required to be approved before a change to the system is allowed to be made.

1. All change requests must be approved by an application manager for the system or an appropriate designee before the change may proceed.
   1. Following approval of the request, work on the change in production may proceed.
2. The approver is responsible for ensuring all applicable fields in the change request have been filled.

There are two methods of approving a change request. However, if you received a Microsoft Teams Approval Request, you must use Microsoft Teams:

• Microsoft Teams Approval (preferred method)

1. Within Microsoft Teams, move to the Approvals tab.
   1. If the Approvals tab is not visible, you can select it from the triple dots menu at the bottom of the sidebar.
2. Select the pending approval.
3. Select the attachment link.
4. After viewing the Sharepoint change request, enter a comment in teams explaining the approval of the request (if needed).
   1. The comment is automatically added to the change request in the Approval/Denial Reason field when submitted.
5. Select Approve.
   1. Selecting Approve will automatically update the Status, Sign-off Status, Approver, and Approval Date fields.

• Sharepoint Approval (only as a backup)

1. Go to the Sharepoint Change Control page.
2. Select the desired change request.
3. Select 'Edit'.
4. Change the 'Status' field to 'Approved'.
5. Change the 'Sign-off Status' field to 'Approved'.
6. Enter the name of the approver in the 'Approved by' field.
7. Enter the date the request was approved in the 'Approval Date' field.
8. Save the change request.

Denial of a Change Request 

A request that has been denied should prevent the change from occurring in production environments.

1. 1. The approver is responsible for denying the change request if problems are found.
      1. The reason for denial should be documented
   2. If the approver denies the change request the change should be prevented from applying to the system in a production environment.
   3. If the change is deemed unwanted or unable to be applied and is subsequently denied, the change request is considered resolved. 
      1. All work on the change should cease.
      2. Any existing work should be reverted to a version prior to the change.
   4. If the change is still requested to be implemented after denial by the approver, steps to remedy the identified issues should be taken.
      1. After the issues have been addressed, the change request should proceed through the review and approval process, repeating this flow until the change is approved or cancelled.
      2. If the change is found to be unable to be approved, the request should be denied and considered cancelled.

There are two methods of denying a change request. However, if you received a Microsoft Teams Request, you must use Microsoft Teams:

• Microsoft Teams Denial (preferred method)

1. Within Microsoft Teams, move to the Approvals tab.
   1. If the Approvals tab is not visible, you can select it from the triple dots menu at the bottom of the sidebar.
2. Select the pending approval.
3. Select the attachment link.
4. After viewing the Sharepoint change request, enter a comment in teams explaining the denial of the request (required).
   1. The comment is automatically added to the change request in the Approval/Denial Reason field when submitted.
5. Select Reject.
   1. Selecting Reject will automatically update the Status, Sign-off Status, Approver, and Approval/Denial Reason fields.

• Sharepoint Denial (only as a backup)

1. Go to the Sharepoint Change Control page.
2. Select the desired change request.
3. Select 'Edit'.
4. Change the 'Sign-off Status' field to 'Denied'.
5. Change the 'Status' field to 'Denied'.
6. Enter the reason the request was denied in the 'Approval/Denial Reason' field.
7. Save the change request.

Change Deployment

Approved requests may be deployed to a production environment.

1. Approved requests may move forward with their deployment procedures.
   1. This process will vary based on system, and their specific procedures should be followed.
2. After deployment the following fields need to be updated in the change request:
   1. Status should be set to Deployed.
   2. Deployed by (person) should be set to whoever lead the deployment of the change to production (if applicable, this not required for vendor lead updates).
   3. Deployment Date should be set to the date the change was made in production.
3. An email reminder to set the deployment date and the status field one day after approval of the change control.
   1. Additional email reminders will be sent on a weekly basis until the deployment date field is filled.
4. After a change is successfully deployed to production and the related fields are complete, the change request is considered complete.

Emergency Change Requests 

An emergency change is defined as any update, disaster, or other immediate and/or unforeseen occurrence within a system that happens prior to the ability to create a change control entry (this includes vendor provided changes or updates that were applied without timely notification given to UW). Emergency changes to a system are required to be authorized and should be documented during or after the change has been made.

1. 1. An emergency change is required to be documented as a change request.
      1. The request should be filled in the same way as a normal change request, but it should be designated as an emergency change.
   2. Emergency changes are required to be authorized by the system manager or designee.
      1. The system manager or designee that authorizes the emergency change should also be the approver for the change request when it is added to the system.
   3. If there is adequate time before an emergency change is made the request may be added.
      1. In this scenario minimal information may be entered, but after deployment of the change any missing information should be placed in the change request.
   4. Emergency changes should be reviewed or tested before release to a production environment.
      1. Initial testing for an emergency change may be minimal to ensure a timely response to the emergency.
      2. Following the release of the change to a production environment, further testing may be done and documented in the change request.

Document History

Related Documents

• SOP-RI-010 - Change Management