Requirements for a data request tool

DATE: 17-04-2024 STATUS: Under development

 

Requirements for the data request tool

 The main requirement for a data request tool is that it should be flexible, modular, and easily adaptable to multiple workflows foreseen in the future.

The solution that we seek for the Health-RI request tool should be flexible to fit into the overall architecture of Health-RI. We seek a solution that is built using the principles of Data protection (including Security and Privacy) by Design and by Default, FAIR and a loosely coupled architecture that allows an in and exit strategy per functional component as well as integration with other tools/functional components.

 Functional requirements

 1. Data Access request form

•  The form must display the relevant fields and hide the irrelevant fields based on the data request.

• The form must have fields with fixed options, such as dropdown menus, and questions with multiple choice answer options, such as checkboxes and radio buttons wherever necessary.

• The form must give clear and understandable instructions on how the data user must complete the form (e.g., a mandatory field is not or incorrectly completed). The instructions are given as regular text between the questions as well as a pop-up hover button at each question.

• The form should make it possible for the data holders to add domain and data holder specific fields.

• Filling in the form should also be possible by API (Application Programming Interface) in the future.

2. Data Access request portal

•  Request overview dashboards for all the roles: All the roles have dashboards to see the status of the application process, respectively. The definite specifics are yet to be determined.

  • A status dashboard for Data user
    Example: At every step, the user must be updated with the status of the Data access request application (DAR) (see the steps below). Relevant color coding must be applied at completion of each step (e.g., green for the step when it is done and red for impediments)

  • A status dashboard for Data holder

  • A status dashboard for Data Request facilitatorone and red for impediments)

• Functionality to export the request registration by the local DAC (Data Access Committee) (data holder) to their own system so that they can further send or review the request with related internal committee or responsible persons. In future, we aim to achieve this by Application Programming Interface (API).

• Messaging module to send notifications in the request tool portal but also via email.

• Identification, authorization, and authentication module: The user of the request portal must be able to login with their institutional account using some form of federated authentication.

 3. Identification, Authentication and Authorization (IAAI)

• A user and organization management system

• Role based access control that can be administered by the organization (data user, data holder) for specific parts of the workflow

• Single sign on (SS0) passed on from the catalogue

• Authentication based on OpenID (OIDC)

 Technical and process requirements:

•  Good maintenance and coding practices such as:

  • Follow SOLID principles

  • Clean code

  • Well documented

  • Test cases: unit test and integration tests, having a high branch test coverage (over 80%).

  • A language that is widely supported by the develop community, because of its open-source character

• Multi instance support

• Load balancing

• Adequate logging, at least:

  • Track exceptions

  • Track User, Session, and events

  • Track User flows

• Processes for handling security incidents (e.g., ISO 27000 series certification)

• Proven security through OWASP Vulnerability Scan or ISO 27000 series certifications

• Service level offered for the product