Functional components: tasks and responsibilities
- Health-RI
DATE: 23-08-2024 STATUS: ADOPTED
Â
The national health data infrastructure for research, policy and innovation consists of various components. These components can be applied functionally, technically, organizationally and legally in different places. For example, it can be chosen based on organizational considerations that a component can be applied more cost-effectively through a central shared service principle. For legal reasons, a local/regional application can be chosen, which could technically be implemented centrally/zoned.
The table below was created from sessions with the chief architects of the regional hubs to determine which components can best be applied where. This is a first draft, which does not yet contain all components..
The table below provides an overview of functional components and which Health-RI ecosystem participants could fulfill these functions (and how Health-RI ecosystem participants can use them).
Explanation of columns in the table
The article Nodes describes the Health-RI ecosystem with the nodes. A node represents multiple data holders. Components can be applied at a central level for the nodes.
Name | Data holders (local and for now UMCs) | Node (regional) | Central (national) |
 FAIR Data-point (FDP) of datasets (N>1)  | Every data holderg must be able to offer datasets to an FDP. This may be your own FDP, or FDP from another body (such as national or regional FDP). | Yes, each node must offer FDP to its region  | Required in 2024  |
 | Yes, future based on the principle of data at the source and data visiting | Desirable as an independent party for multicenter studies | Desirable as an independent party for multicenter studies  |
  | Yes, or else node. Each UMC currently has one or usually several points/counters where questions can be asked | Not necessarily One would expect that each institute/region has a counter where all internal processes are secured and handled and which can connect with counters in a federation (collaboration). If you do something locally, you do not necessarily have to go through the central environment, but you go to your own counter (which has its own no wrong door | Yes, but questions are routed to the right experts in the nodes |
  | Yes, or else node | Not necessarily  | Yes |
 | Handling data requests (can use local business functions if requests are allowed, or regional or national business functions if there is no own business function) | Yes | Yes, linked to central catalogue. Can forward requests to the data holders.  |
  | Conditional: request register is needed if the request business function runs here | Conditional: request register is needed if the request business function runs here  | Conditional: request register is needed if the request business function runs here |
 | Yes | No | No |
  | Yes, it is the receiving party | Possibly in orchestration | Yes, in orchestration |
The table below provides an overview of functional components and which Health-RI ecosystem participants could fulfill these functions (and how Health-RI ecosystem participants can use them).
Name | Data holders (local and for now UMCs) | Node (regional) | Central (national) |
  | Access data sets: local | No | Both access to infrastructure and passing on local authorization to access dataset |
  | Not necessarily, unless data holders (currently UMCs) also use SRAM/SURFconext for access to their research services | Not necessarily, unless nodes also use SRAM/SURFconext for access to their regional research services | Yes |
  | Yes, or Node | Yes, or dataholder | Yes |
 | Yes, double (internal use and external use)) | Possibly | If possible: national |