Scribd
Upload
8 views

Change Management Sop

The document outlines a standard operating procedure for managing changes to software in a data management environment. It describes identifying issues, developing changes, testing, and deploying updates. Responsibilities are assigned to various roles in overseeing the process at both individual sites and centrally.

Uploaded by

jjyoti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
8 views

Change Management Sop

The document outlines a standard operating procedure for managing changes to software in a data management environment. It describes identifying issues, developing changes, testing, and deploying updates. Responsibilities are assigned to various roles in overseeing the process at both individual sites and centrally.

Uploaded by

jjyoti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

CHAIN Change Management SOP v1.

Standard Operating Procedure

SOP title CHAIN Change Management SOP

Version 1.0

Date issued 20-08-2018

Next Review 20-08-2018

1. Purpose
The purpose of this standard operating procedure (SOP) is to ensure that changes in the data
management environment are well documented and communicated effectively.

2. Scope
This SOP describes the process for managing changes from the point the need for change (feature
request, bug or issue) is identified to development, testing and rolling out of the desired change.
This SOP is only intended for managing changes on the software involved in the CHAIN Data
Management Environment. Data changes are out of scope.

3. Abbreviations/Definitions
 Change – Any desired outcome expected to happen to an existing status quo item.
 Issue – Anything causing undesired consequences. Issues can be categorized as: -
o Bug – An anomaly on a computer system causing it to malfunction on the affected
functionality.
o Feature request – A desired addition/enhancement that would improve the
functionality of the part of the system.
 Data Management Environment - Redcap, KIDMS, & Reports Dashboard systems.
 UAT – User Acceptance Testing – A form of software feature testing that is geared to fit for
purpose of the feature under testing.
 Production or production environment – The version of the system being used for real
work/data entry.

4. Responsibility
The following is the responsibility matrix for change management in the study.
Role Responsibility Scope
Site Staff (field, data entry, lab Identify and raise issues (bugs, Site
or clinical) feature enhancements) to site
data manager.
Site Data Manager Compile list of issues from site Site
staff and send to Network Data
Management coordinators.
Informs site co-ordinator and
or site PI on status of issues.
Network Data Manager Receives and updates sites data Network
managers on status of issues
CHAIN Change Management SOP v1.0

Solves issues.
Advance issues to other
network coordinators
Network Co-ordinators Provide subject matter expert Network
(Clinical, Lab, advice and direction on change
Communication, e.t.c) management.

5. Procedure
5.1 Change Management at Site
1. Site staff identify the need for a change on a part of a system/software on the data
management environment. They raise this request to their site data manager.
2. Site data manager discusses the issue with the staff to see if the matter can be resolved
locally. If not, he/she takes note and forwards it to the Network Data Management Co-
ordinators.
3. Site data manager updates site co-ordinator and or site PI of the status of issues raised from
the site.
4. Site data manager follows up with network data co-ordinators for resolution of issues.
Conducts User Acceptance Testing (UAT) and participates in approving changes (especially
those raised by them).
5. Site data manager receives updates (on completion of changes at production) from central
coordination team and communicates to site staff.
6. Site data manager and site coordinator co-ordinates any training required to effectively
implement the change.

5.2 Change Management at Central Co-ordination


1. Data coordination team receives issues from site data managers and channels them to
appropriate central co-ordination team members.
2. Proposed changes from sites are discussed by subject matter Network Coordinator and an
evaluation made as to whether or not these affect all sites. In this case the subject matter
coordinator (clinical, lab, communication e.t.c.) should discuss these with site PI/cordinator
but also evaluating if updates are needed in the main system for all sites.
3. If changes target all sites. Network coordinator responsible makes changes to paper CRFs
and circulates a draft version. E.g. if production Enrolment CRF is v1.63, then he/she releases
v1.63.1 or 1.63.2 (second decimal version). The paper CRF is circulated among Co-ordination
and Leadership members through specific calls/meetings to discuss where necessary. In the
event of minor changes, an email vote can be provided.
This step may be omitted if the requested change does not need a paper crf change.
4. Once, voted, the sub-version is implemented (by co-ordination data management team) on
our UAT server http://uat.chainnetwork.org. A link is shared again to the same group that
approved the paper change. If okay, it is advanced for testing at the site that raised the
issue. If the issue came from the coordination team, then a candidate testing site is selected.
5. Once UAT is successful, success criteria being the expected documented changes according
to the paper CRF sub-version released (which ideally will include any skip patterns and
plausible ranges), a communication is sent to the people that voted for the change (could be
coordination or leadership teams). Final approval will be given by the subject matter
coordinator. E.g. if Lab issue then Caroline or Clinical then Priya e.t.c.
6. If changes are production ready and necessary blessings (approvals) have been provided,
then data team will update CRF versioning document, depending on the change, this could
CHAIN Change Management SOP v1.0

be a major release or minor release. In the event of a major release, then a full version count
is increment. Otherwise the sub-version number is implement. i.e. if enrolment is at v1.63,
and we have changes on UAT at v1.63.2, then a minor release will be v1.64 and a major
release will be v2.00.
Note: Production versions run on one decimal system, UAT versions run on second decimal
system.
7. Data team or subject matter coordination team sends communication out to the network.
Training sessions are held for the changes to be introduced and once ready the change is
deployed.
8. The process repeats.

6. References

7. Document history

Version 1 Author Approved by Dated SOP No:

1.0 Narshion Ngao

8. Site training record


All sites are required to maintain a master copy of this SOP that documents the site staff that have
been trained on this SOP.
Document History
Version No. Trained staff Signature of trained staff Date Trainer’s Initials
initials
1.01 KDT Example row 1st Jan 2016 DM

You might also like