A Horizon Europe health project can have a detailed data management plan and still finish with data that nobody outside the original work package can use.
The plan may describe storage, metadata, access, preservation, and sharing correctly. Yet the datasets can remain scattered across partner systems. Identifiers can be inconsistent. Transformations can live in personal scripts. Access decisions can depend on email chains. Six months after the project closes, the only person who understands a critical dataset may no longer be available.
This is the gap between planning for FAIR data and building FAIR data infrastructure.
The current Horizon Europe application template states that selected projects must produce a detailed data management plan by month six and revise it toward the end of the project. That plan is essential. But it is a description of how research outputs should be managed. It does not, by itself, create the metadata, pipelines, interfaces, quality controls, and ownership that make the data findable, accessible, interoperable, and reusable in practice.
For health consortia, FAIR data has to become a system behaviour, not only a reporting commitment.
A data management plan describes the system. It does not implement it
A useful data management plan records decisions across the research data lifecycle. It explains what the project will collect or generate, which formats and standards it will use, how access will be controlled, where outputs will be preserved, and how reuse will be supported.
Those decisions need an implementation layer.
Commitment in the planInfrastructure that makes it real“Datasets will include rich metadata.”A shared metadata schema, automated metadata capture, validation rules, and a searchable catalogue.“Partners will use common standards.”Canonical data models, controlled terminology mappings, unit normalization, schema tests, and versioned transformation logic.“Data will be accessible to authorized researchers.”Identity, role-based access, approval workflows, secure workspaces, access logs, and documented conditions of use.“Research outputs will be reusable.”Persistent identifiers, provenance, quality records, licenses or use conditions, versioned releases, software dependencies, and reproducible workflows.
Without these capabilities, the plan remains dependent on manual behaviour. Every partner must remember to create metadata, follow naming conventions, preserve transformations, update documentation, and communicate schema changes. That may work for a small dataset and one closely connected team. It rarely scales cleanly across a multi-country consortium with several institutions, data types, and work packages.
FAIR data is not the same as open data
The FAIR Guiding Principles were designed to support discovery and reuse by both people and machines. They call for persistent identifiers, rich metadata, standardized retrieval protocols, shared knowledge-representation languages, qualified links between related data, clear usage conditions, provenance, and domain-relevant standards.
None of that means sensitive health data must be published without restriction.
The European Research Executive Agency describes the Horizon Europe approach as “as open as possible, as closed as necessary”. Sensitive data can remain inside a controlled environment while its metadata explains that the dataset exists, what it contains, who may use it, and how authorized access can be requested.
This distinction matters for health projects. Accessibility is not the absence of controls. It is the presence of a clear, durable, and technically enforceable access path. A dataset hidden on a partner server is not accessible. A dataset with searchable metadata, documented conditions, an accountable owner, and a governed request process can be.
Why Horizon Europe health consortia are especially vulnerable
Health research projects often combine sources that were created for different purposes. A consortium may need to connect clinical observations, laboratory outputs, medical images, registry data, patient-reported measures, environmental exposures, or data from connected devices. Each source can have a different owner, structure, collection cadence, vocabulary, and access condition.
The project structure adds another layer. One partner collects the data. Another cleans it. A third develops the model. A fourth evaluates the output. A fifth leads dissemination or exploitation. If the connections between those activities are informal, the consortium accumulates hidden dependencies as the project progresses.
A shared drive or final repository does not solve this problem. Co-location is not interoperability. Two files can sit in the same folder and still disagree on patient identifiers, units, event timing, missing-value conventions, or the meaning of a clinical category.
The Horizon Europe Health Work Programme 2026-2027 explicitly connects impact with data exchange, collaboration across funded projects, reusable research outputs, and privacy-preserving distributed infrastructure. That direction raises the implementation standard. A dataset should not only satisfy the team that produced it. It should remain understandable and usable across institutions, tools, and future research questions.
Six infrastructure layers turn FAIR principles into working research data
1. A source register and data contracts
The consortium needs a living register of every planned source, its owner, structure, update pattern, sensitivity, quality profile, and downstream consumers. Each critical source should have a data contract that defines required fields, accepted formats, identifiers, expected delivery frequency, and what happens when the source changes.
This turns an informal handoff into a testable interface. If a laboratory export changes column names or a registry adds a new coding convention, the pipeline can detect the change before it silently alters an analysis.
2. A shared model for identity and meaning
Partners do not need to replace their local systems. They do need a common way to represent the concepts the project shares.
That usually means a canonical model for core entities such as participant, sample, observation, intervention, site, device, or dataset. It also means explicit mappings from local terms, identifiers, units, and classifications into the shared model.
The goal is not to erase local context. It is to prevent every work package from interpreting that context differently.
3. Repeatable ingestion and transformation pipelines
Reusable data should not depend on a sequence of manual exports and private scripts. The path from source to curated dataset should be version-controlled, tested, observable, and repeatable.
A strong pattern is to preserve an immutable source layer, then apply documented transformations into validated, research-ready data products. Automated quality checks should flag missing deliveries, schema drift, duplicate records, invalid values, unexpected distributions, and broken relationships between datasets.
When a result changes, the team should be able to determine whether the cause was new source data, corrected mapping, updated transformation logic, or a different analysis version.
4. Metadata that is generated during delivery
Metadata created at the end of the project is usually incomplete because the context has already been lost. It should be captured as data enters and moves through the system.
At minimum, a reusable dataset needs a persistent identifier, owner, description, source, collection period, schema, version, quality status, provenance, access condition, and relationship to associated software, models, publications, and other datasets.
The catalogue should support both human discovery and machine processing. A researcher should be able to search it. A workflow should be able to retrieve the same metadata through an interface.
5. Lineage, versioning, and reproducibility
If a project publishes a figure, trains a model, or reports a result, the consortium should be able to reconstruct which data release, transformation code, configuration, and software environment produced it.
This is where FAIR data connects to scientific reproducibility. A repository copy of the final table is useful, but it does not explain how the table was derived. Reuse requires the chain behind the output: source versions, processing steps, parameters, exclusions, quality decisions, and dependencies.
DataDrill's guide to lineage and governance for external AI examines the same operational requirement in a production setting. The principle is equally relevant to research: an output becomes more credible when its path from source to result can be inspected and repeated.
6. Governed access and reuse interfaces
The final layer is how researchers and systems use the data. Depending on the project, this may include a repository, catalogue, secure analysis environment, application programming interface, query service, notebook environment, or federated execution layer.
The interface should match the reuse case. Publishing a downloadable file may be enough for a stable reference dataset. A longitudinal study that continues receiving new observations may need a queryable service and versioned releases. A cross-border project involving sensitive data may need to send approved computation to institutional nodes instead of moving patient-level data into one central platform.
The architecture can be centralized, federated, or hybrid. What matters is that discovery, authorization, execution, and output handling remain consistent and traceable.
FAIR implementation needs an owner inside the technical work package
Assigning a data management deliverable to one researcher or project manager does not create operational ownership.
FAIR implementation usually crosses at least four responsibilities:
Scientific owners define what the data means and which quality decisions are acceptable.
Data stewards define metadata, access, preservation, and reuse expectations.
Technical owners build and operate the pipelines, models, catalogue, interfaces, and controls.
Project leadership aligns the implementation with work packages, resources, risks, exploitation, and post-project ownership.
These responsibilities should be connected from proposal design onward. If the data architecture appears only as a late implementation task, the consortium may discover that the scientific plan assumes access, comparability, or update speeds that the technical design cannot support.
This is especially important when data moves across work packages. Every handoff should have a named producer, consumer, interface, acceptance criteria, and process for change.
Test FAIRness as an engineering acceptance criterion
The Research Data Alliance FAIR Data Maturity Model provides assessment indicators and guidance for evaluating adherence to the principles. A consortium can complement formal assessment with practical delivery tests:
Can a new partner discover a relevant dataset without asking the person who created it?
Can software retrieve the metadata through a documented protocol?
Can two partners interpret the same field, unit, category, and missing value consistently?
Can an analyst reproduce a published result from versioned data and code?
Can an authorized researcher request access through a defined process, and is the decision recorded?
Can the team explain why two versions of a dataset differ?
Can the output still be used when the original developer or data manager leaves the project?
Can another EU-funded project understand which assets are reusable and under what conditions?
If the answer depends on personal memory, manual reconstruction, or an undocumented message thread, the infrastructure is not ready, regardless of how complete the plan looks.
The transferable lesson from multi-country data integration
DataDrill has not published a Horizon Europe FAIR-data case study, so adjacent delivery experience should not be presented as one. The useful comparison is the engineering pattern.
In one anonymized life-sciences data platform engagement, more than 50 national datasets were unified for more than 1,000 users across more than 15 countries, reducing manual data preparation by 60 percent. The lasting value came from common definitions, automated ingestion, governed transformation, and a reusable platform rather than a collection of one-off data deliveries.
A Horizon Europe consortium has different governance, scientific, and access constraints. But the infrastructure lesson transfers: reuse becomes possible when the shared data layer is built as a product with owners, interfaces, tests, documentation, and an operating model.
A practical starting point for a Horizon Europe consortium
Before finalizing the data management plan or technical work package, the consortium should define one concrete reuse path from end to end.
Choose a representative dataset and one future user who did not create it. Map how the data will be collected, identified, transformed, described, quality-checked, accessed, analyzed, versioned, and preserved. Then identify which steps are currently documents, which are manual tasks, and which are enforced by infrastructure.
That exercise often reveals the real work early: missing metadata standards, incompatible identifiers, unclear access ownership, unbudgeted pipeline development, no catalogue, or no organization prepared to operate the platform after the grant.
DataDrill's data engineering and software development practice covers this implementation layer, from source mapping and platform architecture to governed pipelines, metadata, APIs, and technical handover. Related articles on multi-region clinical data integration and data-lake foundations explore adjacent architecture patterns.
A good data management plan tells the consortium what it intends to preserve and share. Good FAIR data infrastructure makes that intention survive partner boundaries, staff changes, new research questions, and the end of the funded project.