Electronic Data Use Certificates (eDUCs)

Today data requesters collect signatures on data use certificates (DUCs) manually, by downloading a .pdf file from Synapse, routing the document and uploading the signed version. This design provides the ability for Synapse to route a document for signature itself, building on DocuSign.

Governance workflow, Part I:

Create document with hooks. (Detail below.)
Export as .pdf
Upload to Docusign as a template
Create an Access Requirement referencing the the template
Send a request with test emails and verify that it looks correct

Requester workflow:

Create data access request (DAR), filling in signers (Synapse users) and signing official (name and email). At this point the signature process has not yet begun.
Kick off the signature process. The document goes out for signatures. (Internally the ID of the routed document in the DocuSign system is saved and linked to the DAR.)
Add or remove signers to the DAR: If the document is in a state which allows signers to change, the changes are applied. Otherwise an error is returned, indicating that changes are locked out. (UI question: Should the update to the routed document be automatic or should the user be required to apply the Request changes to the routed document explicitly? If the latter, do we need to track whether updates are pending?)
Cancel the routed document. (They no longer want to request access.)
Check the status of the signing, including who has signed and which addresses have ‘bounced’.
Submit request (Can only happen if the DUC signing is complete. Signed pdf is attached to the submission.)

Governance workflow, Part II:

Nothing is changed from the current process: The Governance team sees the submitted request/renewal as a signed .pdf document.

Creating the eDUC Template

The document can be created in Google Doc’s and exported as a .pdf. The document should include the following ‘hooks’ for DocuSign to use, with the text color converted to white to make them invisible. Each “nameX” will be filled with username, full name, and email.

TODO: What other fields need to be filled in? Elsewhere Samia listed, “names, dates, PI info, etc.” Which fields are filled in by our system before sending out and which are to be filled in by a signer?

[name1] [signer1]
[name2] [signer2]
[name3] [signer3]
[name4] [signer4]
[name5] [signer5]
[name6] [signer6]
[name7] [signer7]

…

[signing_official_name] [signing_official_signature]

Objects and Services

API	Request	Response	Description

API	Request	Response	Description
GET /duc/template/list	N/A	DucTemplateList	returns a list of IDs and metadata (template name, created on, etc.) for templates created in DocuSign.
POST /accessRequirement (and other services for access requirements)	ManagedACTAccessRequirementEDuc	ManagedACTAccessRequirementEDuc	Like a ManagedACTAccessRequirement but has a DUC template ID field and lacks a ducTemplateFileHandleId field
POST /dataAccessRequest (and other services for DARs)	RequestInterface	RequestInterface	Add name, email, (TODO: What else?) of the signing official.
POST /duc/signature	DucSignature	DucSignature	Initiates the signature process*; for renewals when the template has not changed, then route only to new signers; fails if there is already a routing in process (since there can be only one)
GET /duc/signature/status?dar={id}	N/A	DucSignatureStatus	Returns the status for the current routing and for each signer.
PUT /duc/signature?dar={id}			If signers in DAR differ from signers in eDUC, updates the signers in the eDUC, but if someone who has been removed from the DAR has already signed, just leave them there. In Docusign the envelope goes into 'correct' mode for changing the signers, then sends again. If the update is not possible then an error is returned.
DELETE /duc/signature?dar={id}	N/A	N/A	Voids the routed eDUC
POST /dataAccessRequest/{requestId}/submission	No change	No change	This service is updated to retrieve and attach signed DUC to the submission. Fails if signing is not yet complete. (Details can be retrieved from GET /duc/signature/status?dar={id}.)

DucTemplateList

{
	"description": "A DUC template",
	"properties": {
      "id": {
        "type": "string",
        "description": "The ID of the template"
      },
      "name": {
         "type": "string",
          "description": "The name of the template"     
      },
      "description": {
         "type": "string",
          "description": "The description of the template"     
      },
      "createdOn": {
         "type": "timestamp",
         "format": "date-time",
         "description": "The timestamp when the template was created"     
      },
      "modifiedOn": {
         "type": "timestamp",
         "format": "date-time",
         "description": "The timestamp when the template was last modified"     
      }
	}
}

DucSignature

{
	"description": "A signature task",
	"properties": {
		"dataAccessRequestId": {
            "type": "string",
            "description": "The ID of the data access request who's DUC is to be signed."
        },
        "templateId": {
        	"type": "string",
        	"description": "The ID of the electronic signing template to use."
        }
	}
}

DucSignatureStatus

{
	"description": "A signature task",
	"properties": {
		"dataAccessRequestId": {
            "type": "string",
            "description": "The ID of the data access request who's DUC is to be signed."
        },
        "ducStatus": {
          "type": "string",
          "enum": [
				{
					"name": "sent",
					"description": "email notification with a link has been sent to at least one recipient, and it stays in this state until recipients have at least viewed it"
				},
				{
					"name": "delivered",
					"description": "all recipients have viewed the documents in the signing experience"
				},
				{
					"name": "completed",
					"description": "signing is finished"
				},
				{
					"name": "declined",
					"description": "a recipient has explicitly declined to sign; signing will never be completed"
				},
				{
					"name": "voided",
					"description": "the sender has voided the DUC or it has expired"
				}
            ]
        },
        "signerStatus": {
          "type": "array",
          "$ref" : "org.sagebionetworks.model.duc.DucSignerStatus"
        }
	}
}

DucSignerStatus

{
	"description": "Status of a signature within a DUC",
	"properties": {
        "name": {
          "type": "string",
          "description"; "name of the signer"
        },
        "userid": {
          "type": "string",
          "description"; "Synapse user id of the signer, if any"
        },
        "email": {
          "type": "string",
          "description"; "email of the signer"
        },
        "status": {
          "type": "string",
          "description"; "status of the signer",
          "enum": [
				{
					"name": "pending",
					"description": ""
				},
                
					"name": "done",
					"description": ""
				},
                
					"name": "declined",
					"description": ""
				},
					"name": "bounced",
					"description": ""
				}
          ]
      }
    }
}

Optional: Send an email notification when the envelop reaches a terminal state (completed, declined or voided). Either configure Docusign to do this or add a Synapse worker for this purpose.

Open questions:
When initiating the signature process:
What information is to be populated into the DUC by Synapse (besides full name)?
What information does the signer need to enter, besides their signature?
Can we agree on a max number of signers, e.g. 100?
For renewals :
Does this 'delta' document have to somehow indicate the original signers (who are not signing again?)
Does the signing official, need to sign again?