Skip to end of banner
Go to start of banner

Synapse Table Data Change Request Process

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Changes to some Synapse tables may require strict change control procedures in order to meet agreements with data providers, regulators, or for other change control purposes. This process can be used to ensure that changes to a Synapse table are limited to approved by specific authorities.

Scope

This process covers Synapse objects that can be versioned and annotated by the Synapse application; currently this can be done for tables. This process relies on the security model of Synapse, on versioning to capture changes, and on annotations to record signature of the approval authority. 

Out of scope

  • Changes to the configuration of a Synapse project are beyond the scope of the process; auditing of configuration changes can be done by administrators and audited through reports on the Synapse data warehouse.

Process Requirements

Requests for ad-hoc data changes start with a Jira issue ticket that serves as a record of the change and approval process.

Required

When a change effects the elements of a Synapse table related to a project governed by GCP practices, the issue ticket must be generated by the Scientific Project Lead of the relevant project who has the Investigator role. A change request may be documented by any project member, but must be rendered in PDF form, approved and signed by the Investigator, and attached to the Jira issue. As a record of primary data, changes to Synapse tables are always considered "material" in the sense that the change effects the integrity of the project in the long term.

The issue ticket must include the following elements:

  1. In all cases, the change request must be formally documented and tracked as an issue in Jira to create an audit-able trail of the work to be done. 
  2. A description of who is performing the data change and the specifics of what the change entails. This should be detailed enough so that someone looking at the data after the fact can determine how the data was changed.
  3. Approval from the Director of Engineering or Chief Technology Officer must also included in the issue ticket. This is to ensure that no administrative user has unilateral power over participant data, and that we have an audit-able record of following this procedure.
  4. Perform the change:
    1. The Investigator or delegate must issue an API call to create a snapshot of the table version. The snapshot becomes an immutable record of the state of the table before the change.
    2. The appropriate project staff may apply the change with appropriate supervision as defined by the project requirements.
    3. The Investigator, and no other, should review and validate prior and changed versions of the data. Once approved, they must create an annotation on the table entity with a reference to the prior version explaining the reason for the change. This annotation serves as a record of the transaction, including both prior and changed values of all data, and signature of the investigator approving the change. 

Managing Synapse Permissions

Permission control on the Synapse entities should be limited to those with a need to access and modify objects for the duration which requires access. 

Bridge Data Change Request Process



  • No labels