You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/access-request-submission/building-block-view.md
+44-1Lines changed: 44 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,4 +9,47 @@ description: Static decomposition of the system, abstractions of source-code, sh
9
9
10
10
# Building Block View
11
11
12
-
To be added soon.
12
+
This section describes the static decomposition of the system components involved in the Access Request Submission process. It maps the operational steps identified in the SIPOC diagram (dataset selection, collaborator contributions, application completion, signing confirmation, and cost estimation) to the underlying technical building blocks.
13
+
14
+
## Whitebox Overall System
15
+
16
+
This level describes the main components required to support the access request submission workflows, enabling users to create and submit data access applications with dataset selection, collaborator contributions, and signing official confirmation.
17
+
18
+
To support the processes outlined in the runtime view—such as dataset selection, application form completion, collaborator contributions, submission initiation, signing official confirmation, and cost estimation—the system must be decomposed into functional components that handle distinct responsibilities, ensuring data integrity, governance compliance, and auditability.
-**Responsibility:** Serves as the primary web interface for users to interact with the access request submission system. Provides user-facing workflows for main applicants to create, edit, and submit access applications. Enables collaborators to view and contribute to shared draft applications. Provides interfaces for signing officials to review and confirm access request submissions. Routes user actions to backend systems and presents application status and updates.
26
+
27
+
2.**Dataset Catalogue**
28
+
-**Responsibility:** Maintains the inventory of available datasets accessible through the 1+MG network. Enables users to browse, search, and view dataset metadata, availability information, and associated terms of use. Responds to dataset queries from the User Portal and provides dataset information for application completion.
29
+
30
+
3.**Access Request Governance**
31
+
-**Responsibility:** Manages the governance and validation aspects of access request applications. Confirms dataset accessibility for datasets selected in access applications, ensuring data protection compliance. Receives submitted access requests from the User Portal and validates them before forwarding to downstream processes. Maintains the authoritative record of submitted applications and their governance status.
32
+
33
+
4.**Access Request Operator**
34
+
-**Responsibility:** External actor responsible for receiving submitted data access applications and initial cost summaries from the submission system. Informs Central Coordination about initial cost estimates. Acts as the liaison between the submission system and Central Coordination for downstream review processes (conformity checks, ethics review, access decisions).
35
+
36
+
### Important Interfaces
37
+
38
+
-**Main Applicant - User Portal:** Web interface for main applicants to create, edit, correct, and submit access applications.
39
+
-**Collaborator - User Portal:** Web interface enabling collaborators to view and contribute to shared draft applications.
40
+
-**Signing Official - User Portal:** Web interface for signing officials to review and confirm access request submissions.
41
+
-**User Portal - Dataset Catalogue:** API integration for users to query and retrieve available datasets, metadata, and terms of use.
42
+
-**User Portal - Access Request Governance:** API integration for submitting access applications and receiving confirmation of dataset accessibility.
43
+
-**Access Request Governance - Dataset Catalogue:** API integration to confirm dataset accessibility for selected datasets.
44
+
-**Access Request Governance - Access Request Operator:** Interface for transferring submitted applications and communicating initial cost estimates.
45
+
-**Access Request Operator - 1+MG Central Coordination:** External interface for delivering submitted data access applications and initial cost estimate information to Central Coordination.
|**Select Datasets**| Low | List of datasets chosen by users from the Dataset Catalogue for their access request. |
52
+
|**Details from Collaborator**| Medium | Information and documentation provided by collaborators contributing to the application. |
53
+
|**Details from Main Applicant**| Medium | Information and documentation provided by collaborators contributing to the application. |
54
+
|**Data Access Application**| Medium | Structured data entries completing the access application form including research purpose, intended use, investigator details, and data handling plans. |
55
+
|**Initial Cost Summary**| Medium | Preliminary cost assessment report based on datasets requested and project scope. Communicated to Central Coordination via Access Request Operator. |
A user initiates the access request by selecting the desired datasets and creating a draft data access application. This draft serves as the foundational document where all requirements, research goals, and required data variables will be detailed.
24
+
Once the desired datasets are identified, the main applicant initiates a new data access application. The system creates a draft application and associates the selected datasets with it. This step establishes the foundation of the application that will be progressively completed through subsequent collaboration and data entry steps.
25
25
26
-
## Invite collaborator from the same organisation (optional)
26
+
## Invite collaborators from the same organisation (optional)
27
27
28
-
If the research project involves multiple individuals from the same organisation, the primary user can invite them as collaborators. These collaborators can then contribute to filling out and reviewing the data access application.
28
+
The main applicant may invite other individuals from their own organisation to contribute to the access application. These collaborators can view and edit the draft application, providing additional research details, methodological information, or compliance documentation required for the application to be complete.
29
29
30
-
## Invite collaborator from the different organisation (optional)
30
+
## Invite collaborators from different organisations (optional)
31
31
32
-
For cross-organisational research projects, the primary user has the option to invite external collaborators. This facilitates joint research efforts by allowing members from different vetted organisations to collaborate on a single data access application.
32
+
In cases of multi-institutional research projects, the main applicant can invite collaborators from different organisations to participate in the access application. These collaborators can access the shared draft application and contribute their organisational details, roles, and relevant information to support the application submission.
33
33
34
34
## Fill application
35
35
36
-
The user, along with any invited collaborators, provides the necessary details within the application form. This includes specifying the research purpose, methodology, requested datasets, and ensuring all ethical and legal requirements are addressed.
36
+
The main applicant and any invited collaborators complete the structured application form with all necessary information. This includes research purpose, intended data use, investigator qualifications, data security measures, compliance certifications, and other details required by the network. The application evolves through multiple updates as collaborators contribute their sections.
37
37
38
38
## Start application submission
39
39
40
-
Once the application is fully completed, the user initiates the submission process. This action typically forwards the finalized draft to the user organisation's signing official for formal approval before it reaches the data access committee.
40
+
Once the application is fully completed and all required information is provided, the main applicant initiates the formal submission process. This action transitions the application from draft status to pending submission, triggering the workflow for signing official confirmation and downstream processing.
41
41
42
42
## Confirm submission by the signing official
43
43
44
-
The designated signing official from the user organisation reviews the application. By confirming the submission, the official provides organizational endorsement, verifying that the request aligns with the organisation's policies and the terms of service.
44
+
A designated signing official from the user organisation reviews the completed application to verify its accuracy and confirm that the applicant is authorized to submit the request on behalf of their organisation. The signing official provides formal confirmation through a secure authentication mechanism before the application can be officially submitted to Central Coordination.
45
45
46
46
## Inform about initial cost estimates
47
47
48
-
Upon receiving the submitted application, the 1+MG DAC reviews the request and provides the user with an initial estimate of the costs associated with data provisioning, processing, or egress, allowing the user to secure necessary funding or approvals.
48
+
After the signing official confirms the submission, the system calculates and communicates initial cost estimates for the access request to Central Coordination. These preliminary estimates are based on the selected datasets, project scope, and complexity, informing the coordination point about anticipated resource requirements for processing the access request through subsequent review stages.
0 commit comments