Powered by OpenAIRE graph
Found an issue? Give us feedback
image/svg+xml art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos Open Access logo, converted into svg, designed by PLoS. This version with transparent background. http://commons.wikimedia.org/wiki/File:Open_Access_logo_PLoS_white.svg art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos http://www.plos.org/ ZENODOarrow_drop_down
image/svg+xml art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos Open Access logo, converted into svg, designed by PLoS. This version with transparent background. http://commons.wikimedia.org/wiki/File:Open_Access_logo_PLoS_white.svg art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos http://www.plos.org/
ZENODO
Project deliverable . 2021
License: CC BY
Data sources: Datacite
image/svg+xml art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos Open Access logo, converted into svg, designed by PLoS. This version with transparent background. http://commons.wikimedia.org/wiki/File:Open_Access_logo_PLoS_white.svg art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos http://www.plos.org/
ZENODO
Other literature type . 2021
License: CC BY
Data sources: ZENODO
image/svg+xml art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos Open Access logo, converted into svg, designed by PLoS. This version with transparent background. http://commons.wikimedia.org/wiki/File:Open_Access_logo_PLoS_white.svg art designer at PLoS, modified by Wikipedia users Nina, Beao, JakobVoss, and AnonMoos http://www.plos.org/
ZENODO
Project deliverable . 2021
License: CC BY
Data sources: Datacite
versions View all 2 versions
addClaim

CAPABLE D2.2: Requirements Table and Use Case Description

Authors: Peleg, Mor; Ganicheva, Valentina; Lanzola, Giordano; Panzarasa, Silvia; Parimbelli, Enea; Polce, Francesca; Quaglini, Silvana; +25 Authors

CAPABLE D2.2: Requirements Table and Use Case Description

Abstract

The aim of this deliverable is to define the requirements of the CAPABLE system. These requirements include clinical requirements regarding the clinical scope of decision-support and its content (knowledge base), patient and clinician user needs, and technical system requirements for the different system components. Following our iterative development approach for the CAPABLE system, this document presents the functional and non-functional requirements. This document opens with a literature review (Section 2, corresponding to Task T2.1) that we have performed to identify the state of the art of data-science-based methods and systems for supporting the quality of life of cancer patients, starting with data collection and data integration methods, and continuing to machine-learning-based prediction models and patient coaching systems. The literature review allowed us to identify best practices that we plan to adopt in the CAPABLE system, as well as open challenges, many of which we plan to address. Going from the state of the art to our own CAPABLE system, in Section 3 we present the overall system architecture, along with the different components of the system. In addition to this structural description of the system, we also provide a workflow presenting the process of care supported by the CAPABLE system, from patient enrollment and initial setup of the physician-facing dashboard and patient-facing mobile app, to the ongoing services provided by the systems to these users, including patient monitoring and decision-support. The following chapters present a description of the methods that we used to collect different requirements, as well as the requirements themselves. Section 4 presents patient requirements (Task T2.1) and Section 5 – clinical requirements (Task T2.3), relating to the needs of the clinicians as well as a selection of clinical practice guidelines, monitoring data to be collected by patients at home, and certification/barriers to market. Section 6 (corresponding to Task T2.6) starts with a set of Sequence Diagrams that specify how the system components interact with each other in order to achieve the M12 Demo Scenario. Then we present all functional and non-functional requirements of the different system components (Data integration components [Case Manager, Data Platform, and the Knowledge-Data Ontology Mapper (KDOM)], decision-support [Computer-interpretable Guideline (CIG) Execution Engine and Knowledge Base, Multimorbidity Controller, Coaching System – all three rely on the existing decision model of the PROforma formalism], user interfaces [Patient APP GUI, Doctor APP GUI], sensors) as well as security/privacy). Section 7 presents the Technical requirements for data representation, integration, quality, and exchange (corresponding to Task T2.4). Section 8 presents the Technical requirements for the AI data processing and analysis methods (corresponding to Task T2.5), including predictive model and knowledge discovery (pattern detection). Technical detailed requirements for security and privacy will be formulated in WP4. WP2 continued to meet in Year 2 to complete the formulation of requirements. Issues that were elaborated in Year 2 include defining the structure and content of the pdf summary for the general practitioners [Section 4, Req. 5.3.1], additional requirements related to security by design [Section 6.12], and the final choice of phones and sensors [Section 6.8]. Based on feedback from the M12 Demo from all stakeholders and on the 1st technical review, we added one requirement [Req 4.5] and elaborated the user interface screens and for all requirements related to the clinicians' app and the patients' app [Sections 4.7 and 5.9].

This deliverable is a part of a project receiving funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 875052

Keywords

use case, requirements

  • BIP!
    Impact byBIP!
    selected citations
    These citations are derived from selected sources.
    This is an alternative to the "Influence" indicator, which also reflects the overall/total impact of an article in the research community at large, based on the underlying citation network (diachronically).
    0
    popularity
    This indicator reflects the "current" impact/attention (the "hype") of an article in the research community at large, based on the underlying citation network.
    Average
    influence
    This indicator reflects the overall/total impact of an article in the research community at large, based on the underlying citation network (diachronically).
    Average
    impulse
    This indicator reflects the initial momentum of an article directly after its publication, based on the underlying citation network.
    Average
    OpenAIRE UsageCounts
    Usage byUsageCounts
    visibility views 8
    download downloads 28
  • 8
    views
    28
    downloads
    Powered byOpenAIRE UsageCounts
Powered by OpenAIRE graph
Found an issue? Give us feedback
visibility
download
selected citations
These citations are derived from selected sources.
This is an alternative to the "Influence" indicator, which also reflects the overall/total impact of an article in the research community at large, based on the underlying citation network (diachronically).
BIP!Citations provided by BIP!
popularity
This indicator reflects the "current" impact/attention (the "hype") of an article in the research community at large, based on the underlying citation network.
BIP!Popularity provided by BIP!
influence
This indicator reflects the overall/total impact of an article in the research community at large, based on the underlying citation network (diachronically).
BIP!Influence provided by BIP!
impulse
This indicator reflects the initial momentum of an article directly after its publication, based on the underlying citation network.
BIP!Impulse provided by BIP!
views
OpenAIRE UsageCountsViews provided by UsageCounts
downloads
OpenAIRE UsageCountsDownloads provided by UsageCounts
0
Average
Average
Average
8
28
Green