FAQ Processes

date: 23-08-2024 Status: ADOPTED

Processes

Nr	CR	Question	Answer
1	V1	Most organizations that join HRI do not have a local review committee. Is that an obstacle?	We recognize this. For this reason, it is important to set up an application process with a national review committee. . We expect that data requests will qualify as an administrative decision, which you can object to in the event of a refusal. The question must be answered, where objections and appeals can be lodged. We are thinking about this. It may not make sense for a national review committee to review all applications, but perhaps a national review committee can make all appeals on data refusals. For example. We have to think this out together. Incidentally, according to our information, certainly all UMCs and top clinical and sometimes also general hospitals have a committee that assesses whether a request for health data can be granted.
2	V1	I think we need to be much more specific about how a data producer should do this. A thought: making data available and persisting in bulk is step 1 (in any scenario). OpenEHR is further along in this than FHIR (Bulk FHIR API was only created last year). So we could say in a project, for example: we are going to make an OpenEHR persistence layer (at a hub). From there we immediately have 2 standards, because OpenEHR already has a FHIR API. I think that if we do not do this together with the very scarce knowledge that is available for this at all, we will not make enough progress.	Once. It is important to make this negotiable, both through the architecture and the open consultation process and through the OVT. UMCs already work with FHIR to unlock source data or with OpenEHR for data storage. In collaboration with Cumuluz, two separate POCs will be set up to unlock data for the Health-RI infrastructure.
3	V1	When making the MLDi register FAIR, an ontology was set up based on OBI. If you make the data FAIR from your own data model (EDC in that case Castor), then you do not yet have the coherence and you may not be generic enough in your data field somewhere and you need an intermediate step to give the field meaning. Here we are talking about making data FAIR, so that another register with the same intention can also do so so that you can do analyses on both registers (storyline federated analysis).	Ontologies are an important part of FAIR data. The details and choices for making data FAIR will have to be determined by the domain experts per domain/area, whereby we as Health-RI now mainly focus on harmonizing the process for this and making it available to others via prescriptions. In more domain-oriented joint Health-RI projects in which data is made FAIR (such as MLDi), we will add the necessary depth to the field of ontologies and jointly write down the lessons learned and convert them into a joint work process. This is a work in progress via this page
4	V1	Have you already adopted 'lessons learned' from the Data Utility company of Digitaal Vlaanderen (just launched under the name 'athumi')?	We are also looking at developments in similar initiatives in Europe. If we do not have this on the radar, we will contact you.
5	V2	Are the local conditions also copied when research data is made available? Because the original consent still applies.	Further information about the conditions for making research data available can be found at the ELSI Service Desk.
6	V2	When contracts are sent, are we talking about generic contracts or rather about customization per data holder?	That is not yet known, but generic is preferred.
7	V2	Who is responsible for making data models/ontologies of generated data available?	Ideally, there should be a standard description of a data model/ontology that is followed when making it available. If there are any deviations, the data holder must indicate this. See also The data holder is responsible for making data suitable for multiple use .
8	V2	In the case of a federated analysis: by whom is the analysis question tested?	The analysis question will be assessed when applying for access to the data by a (yet to be determined) Data Access Committee (DAC).
9	V3	I have a question about the assessment at the data holder. Has the metc systematics been looked at? Are there parallels with the assessments of research?	Yes, there are parallels. Within the project in which Health-RI is working on the implementation of the Assessment Framework nWMO research, we hope to learn a lot about the practice of assessment. We can then apply this knowledge within the Health-RI ecosystem.
10	V3	I would like to ask some questions regarding the analysis infrastructure. How federated is this? Follow-up question: What will federated analysis look like?	The analysis architecture should be federated in principle: you cannot centralize the entire world. But it is hybrid. Federated is our preference, but not all issues can be solved federated. How federated analysis will be technically set up has not yet been decided. Various solutions are possible here. We strive for a solution that is as scalable and interoperable as possible.
11	V3	How do the activities in the analysis working group regarding the secure processing environment relate to the HDAB-NL project in which this is also a topic (which I believe is being led by CBS)?	The EHDS legislative text is now available in draft form. It contains four technical components: catalogue, application tool, secure processing environment, data quality(s label). CBS is indeed leading the secure processing environment. The Health-RI architecture team is closely involved in the HDAB work package in which SPEs are being worked on. The analysis working group is informed about this and steps taken by the working group are included in HDAB-NL.
12	V3	In the storyline making data available there is a block 'Determine coding and modeling' at the Data Governance Committee. Is this committee responsible for this? Or does such a task lie with the data owner/generator?	Data definitions lie with the Data Governance Committee. We will come back to this in the next version of the wiki.