D1.3 Business requirements for G1

This document provides a detailed description of the business requirements – functional and non-functional requirements - of the AI-powered data curation and publishing assistant, aimed at supporting patients (and expert curators) in managing and cleaning their personal health data – in compliance with ethical and regulatory requirements.

The first objective of the AIDAVA project is to demonstrate that the prototype works in a realistic - though strictly controlled through an assessment protocol approved by the local ethical committees as described in Deliverable D1.4 - environment, considering data privacy and regulatory constraints. The second objective is to develop a solution that can be transformed into a full-fledged product, including MDR certification; to meet this second objective we decided to keep all requirements that were captured, and to indicate if they were in scope of the prototype or only in scope of the future product. While the product related requirements will not be developed during the AIDAVA project, it is expected that the technology architects will take these into account when defining the architecture of the system and ensure the prototype can smoothly evolve toward a marketable product.

The requirements were gathered through a structured approach. 

• First, the user journey was defined. It includes the following steps:  registration and logging, upload and ingestion of patient personal data from different sources, integration & curation of data from these sources, use of the resulting curated data, deletion of account (and data).
• Second, the requirements were gathered along the steps of this user journey for the different users - and potential customers - identified for the prototype: patient, expert curator, data users but also administrator and third-party app developers. Capture of requirements took place mainly through structured workshops and on-line meetings across the different sites.
• The requirements across the users were then consolidated and clustered in epics, defined in Deliverable D2.3 Solution Design; duplicate requirements across user groups were deleted.
• Each consolidated requirement was then provided with a level of severity (blocking/crucial, major, minor, out of scope) indicating the importance of having the requirement successfully developed. While assessing the severity, specific attention was given on data privacy, security, and regulatory process as well as on patient needs and acceptability. 
• Finally, the team identified the need to have the requirement in the prototype or only in the future product. 

A total of 596 requirements were gathered with the different users; after consolidation across users and prioritisation, 277 requirements were considered as needed for the prototype (46 blocking, 178 major, 53 minor) and 99 additional ones were considered in scope for a product. As the need for information and documentation came regularly while gathering requirements, the content of four different documents was drafted. 

The content of the business requirements will be consolidated with the automation requirements from Task 2.1 and from quality management requirements from Task 4.2 and transformed by the development team into features-centric user stories to be further used as the basis of the development. 

The content of the deliverable will be re-assessed – and potentially adapted – after the evaluation of Generation 1 of the prototype to deliver Generation 2.