AIDAVA Exploitation & Business Model

Exploitation plans, Key Exploitable Results, and business model analysis derived from AIDAVA project deliverables (WP6 Innovation Management).

For the AIDAVA project overview, see AIDAVA. For commercial application of these findings, see Stamen Health and Stamen Health Executive Summary.

Source Deliverables

Deliverable	Status	Date	Description
D6.2 PDEC	Sensitive	Feb 2023	Plan for Dissemination & Exploitation of results incl. Communication — strategic exploitation framework
D6.3 IP Manual	Sensitive	Feb 2023	IP management strategies for collaborative innovation, ownership, sharing, protection
D6.8 SAB Recommendations	Sensitive	Jan 2025	Sustainability Advisory Board recommendations, Go To Market approaches, KERs
D6.9 PDEC Update 2	Sensitive	Sep 2025	Updated exploitation plan, second official report
D1.3 Business Requirements	Public	Jun 2023	596 requirements for G1, 99 for future product. Explicitly targets "full-fledged product, including MDR certification"
D1.7 G1 Performance	Sensitive	Jan 2025	Evaluation results: 45% automation, 83 patients, suboptimal but confirms PHKG potential

Full deliverable list: aidava.eu/results/deliverables

Key Exploitable Results (KERs)

D6.8 presented the project's KERs, value proposition, and exploitation plans to the Sustainability Advisory Board across three meetings (M01-M22). The SAB provided recommendations on sustainability of KERs and potential product combining multiple KERs.

Two "Go To Market" Approaches

The Sustainability Advisory Board suggested two potential avenues for an "AIDAVA product":

1. Interoperability enablement of healthcare authorities and healthcare organisations — as part of implementation of the EHDS
2. Citizens empowerment in managing their health data

These align directly with two of the five business opportunities explored on PHKG Business Opportunities: EHDS compliance infrastructure (approach 1) and patient data consolidation apps (approach 2).

Business Requirements (D1.3)

596 requirements gathered across five user groups: patients, expert curators, data users, administrators, third-party app developers.

After consolidation and prioritisation:

• 277 requirements for prototype (46 blocking, 178 major, 53 minor)
• 99 additional requirements for future product

Key quote from D1.3: "The second objective is to develop a solution that can be transformed into a full-fledged product, including MDR certification. 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."

Source: Zenodo — D1.3

Patient Requirements (D1.2, D1.8)

From patient workshops (Feb 2023) with European Cancer Patient Coalition (ECPC) and European Heart Network (EHN):

• Main incentive: ensure treating physician has smooth access to complete medical record
• Happy to share data "in a controlled way"
• Want to know who will access data and optionally obscure some information
• Want easy consent mechanism for all parties
• Want to know who uses data and for what purpose
• Reward should be envisioned for commercial use of shared data
• Concern about data donation — do they lose control?

G1 Evaluation Reality (D1.7)

83 patients recruited, 70 completed (July–December 2024, Estonia/Austria/Netherlands).

What worked:

• HDI integration was "smooth with regular improvements"
• Usability on computer and phone was acceptable
• Patient acceptance "slightly above medium"

What didn't work:

• Only existing OCR and German NLP tools were usable — team forced to include "suboptimal open source tools and very early prototypes"
• Data Transfer Specification setup was "time consuming — information not readily available"
• Explanations were suboptimal
• Benefits unclear to patients — "lack of direct benefits"
• Data users concerned: "lack of usable high-quality data to support any decision"
• Clinician recruitment slowed down during holidays

The verdict from D1.7: "While Generation 1 is suboptimal, it demonstrates that there is true potential for automation in data curation of health data into a harmonised semantic standard, under the form of a Personal Health Knowledge Graph."

What This Means for Commercialization

1. Exploitation plans exist but are strategic, not product-level. D6.2 and D6.8 identify directions (EHDS, citizen empowerment) but don't specify pricing, go-to-market, or product architecture.
2. MDR certification is planned but not scoped. D1.3 mentions "including MDR certification" as a future product objective but no deliverable addresses the regulatory pathway.
3. The two Go To Market approaches validate the Stamen Health thesis.' EHDS compliance infrastructure (approach 1) and patient data apps (approach 2) are the same opportunities Stamen is pursuing.
4. The gap is reliability: 45% automation with suboptimal tools. Commercial viability needs 80%+. This is an engineering problem, not a research problem — the architecture is right, the execution needs hardening.
5. Patient-perceived value is weak. G1 showed "lack of direct benefits" as a concern. The product needs to demonstrate immediate, tangible value to patients — not just future research benefits.

See also: AIDAVA, AIDAVA Documents, Stamen Health, PHKG Business Opportunities, Stamen Health Executive Summary