Enhancing the Quality Control Process for Data Management with Efficient Check Update Requests

Photo by Louis Reed on Unsplash

Abstract: The quality control (QC) process in data management relies on an extensive inventory of checks to ensure data accuracy and consistency. However, the absence of a clear governance process for creating and updating these checks may lead to inefficiencies, incorrect updates, and delays in development. This paper presents a comprehensive governance process to streamline requests for updates and the creation of new checks, with the aim to improve the overall data quality control process.

Introduction

In data management, ensuring the quality of data is crucial for accurate analysis and reporting. The QC process relies on a vast inventory of checks that help identify discrepancies, inconsistencies, and errors in the data. However, the lack of a well-defined process for updating and creating new checks often results in inefficiencies, incorrect updates, and delays in development. This paper presents a comprehensive governance process to address these issues and streamline the handling of requests for updates and the creation of new checks.

Requesting Check Updates or New Checks

When a data manager identifies the need for a new check or an update to an existing check, they must first consult the QC inventory to verify whether a similar check or program already exists. If the check or program is not yet available, the data manager can create a new request in SharePoint with the status ‘Open’. For updates to existing checks, the data manager must first verify whether an update request already exists in SharePoint. If a similar request has been submitted, a new request should not be created. If the request has not been submitted, the data manager can create a new request in SharePoint with the status ‘Open’.

The request must include sufficient documentation and details for the governance team to evaluate the request and either approve or decline it. The documentation should comprise a link to trial datasets, metadata, define.xml, and related exceptions table, along with a clear description of the check’s expectations for the data. The requestor should also consider other potential scenarios that may be present or absent in the trial data for which the check needs to provide exceptions or not.

All this information must be gathered in the “Check Update Request Form,” which should be completed and attached to the request in SharePoint. The request form requires completion of the following fields:

• Check Number or Job Name: For existing checks or jobs, the correct number should be provided.
• Request Type: Indicates the request type (new or update guidance / Update GRP variable). This is ticked for updates to the guidance or group assignment. Update programming: This is ticked if the logic of the check should be updated. New request: This is ticked when a new check or job is requested. Information: Is ticked if more information on the check logic is requested.
• Therapeutic area: Indicates which therapeutic area the reference trial belongs to.
• Request status: Indicates the status in the process flow (see process flow overview).
• Bugfix: This should be checked in case the check should be deactivated while the update is being worked on.
• Request details: A clear description of the requested update or new request is provided. The description should be clear for programmers.
• Test data: A link to the test data is provided.
• Assigned To Governance team member: The governance team member that follows up on the request enters their name here.
• Assigned To Developer: The developer that programs the update enters their name here.
• Assigned For UAT: The UAT-er that plans the UAT enters their name here.
• Date Request Closed: The date the request is closed is entered here.
• Priority: Is completed as Low, Medium, or High. Low is used for updates that improve the check or check output but is not very urgent for implementation. Medium is used for updates that will greatly help interpretation of the check output. High is used for important updates, for example, in cases where the current output is incorrect.

The Governance Process

Once the request has been submitted, the governance team will review the request to ensure it meets the required criteria and includes all necessary information. The governance team is responsible for evaluating the request and deciding whether to approve or decline it. The following steps are taken during the governance team review:

• Assessing the need for the new check or update based on the documentation provided.
• Verifying if the request aligns with existing data standards and guidelines.
• Evaluating the potential impact of the new check or update on existing processes and data quality.

Request Status

Based on the governance team’s evaluation, the request status will be updated in SharePoint. The possible status updates are:

• Approved: The governance team approves the request, and the development process begins.
• Rejected: The request is deemed unnecessary or does not meet the required criteria, and the requestor is informed of the decision.
• Info Needed from Requestor: The governance team requires additional information or clarification from the requestor before making a decision. The requestor must provide the requested information promptly to avoid delays.

Development

Once the request is approved, the development process begins. The development team is responsible for creating or updating the QC check according to the specifications provided in the request. The development team must adhere to the data standards and guidelines applicable to the check.

Dry Run UAT

After the development is completed, a dry run User Acceptance Testing (UAT) is conducted to ensure the new check or updated check functions as intended. The dry run UAT involves applying the check to a test dataset to evaluate its performance and identify any issues or discrepancies.

UAT and Feedback

If the dry run UAT is successful, a full UAT is conducted with the involvement of the requestor or other relevant data managers. This stage allows for thorough testing of the check and provides an opportunity for feedback and any necessary adjustments. If the UAT identifies issues or discrepancies, the check is sent back to the development team for revision.

Final Approval and Closure

Once the UAT is completed and the check is deemed satisfactory, the request is marked as ‘Closed’ in SharePoint. The new check or updated check is then added to the QC inventory, making it available for use by all data managers.

Conclusion

The implementation of a comprehensive governance process for creating and updating QC checks in data management addresses the previous issues of inefficiencies, incorrect updates, and delays in development. By streamlining the request and development process, data managers can maintain a high level of data quality and ensure that all data managers have access to an updated and efficient inventory of QC checks. This governance process is essential for optimizing data management capabilities and overall performance, ultimately leading to more accurate analysis and reporting.