FAQ Architecture
- Health-RI
date: 23-08-2024 Status: ADOPTED
Architecture
Nr | CR | Question | Answer |
1 |
| What exactly is meant by 'multiple use'?
| Use both within healthcare (so-called primary use) and outside it, such as research and innovation (so-called secondary use) |
2 |
| What is the scope of the Health-RI ecosystem and which parts within the Health-RI ecosystem are filled in by whom?
| The scope of the Health-RI ecosystem is research and innovation. This includes applying health data for research and innovation and making research and innovation data available for multiple use. For the application of healthcare data, research and innovation benefit from making care data suitable for multiple use. It is not the responsibility of the Health-RI ecosystem to make healthcare data suitable for multiple use. The Health-RI ecosystem consists of participants who make data available to and/or use data from the Health-RI ecosystem. These parties are responsible for filling in the necessary parts themselves, using generic services provided by third parties. Health-RI foundation orchestrates
Who exactly will fill in which parts has not yet been determined. |
3 |
| There is also an eye for other areas, such as elderly care and the social domain. | Yes. The scope of Health-RI focuses on health data. This can also concern data from long-term, or elderly care, mental health care, Health data trackers (e.g. FITBIT), or other health data. Health data will also occur in the social domain. The socio-economic data – which can often be interesting for prevention cases – do not fall within the scope of Health-RI. However, we do maintain close contact with other domains, such as ODISSEI, when it comes to socio-economic data. In particular, we try to coordinate the finding and application procedures, so that researchers can carry out cross-domain research. |
4 |
| There is a culture in which datasets are made available under the condition that the data holder becomes co-author of the research. That is quite an obstacle to the free operation of the system.
| This is addressed in the OVT; namely in obstacle 9: fear of missing out on recognition from the organizations that generate the data. This can also be, for example, research groups that necessarily want recognition by means of author attribution and touches on the ongoing initiatives recognition and appreciation and open science. Co-authors are listed below. This is in cluster 1 and will be further elaborated from the stakeholder analysis with inventory needs and interests with options to develop alternative ways to meet the wishes and needs. |
5 |
| How are the data holders motivated to do the necessary work? What is the incentive? | This is a well-known challenge, which will be addressed in the OVT and will be explicitly addressed in a subsequent version |
6 |
| Reading the architectural design, Health-RI seems to be portrayed as a solution provider and data holder, which takes on the entire process of standardization, data cleansing, processing and dissemination from extracted medical records. Is that correct ? | It is not the intention to present Health-RI as a solution provider and holder of data, which takes on the entire process of standardization, data cleansing, processing and dissemination from extracted medical records. Health-RI wants to orchestrate the process to create a national health data infrastructure for research and innovation. The data-holding parties themselves must ensure that the data can be applied multiple times in a standard way, using generic services, usually offered by third parties. As a central hub, Health-RI will create an environment for researchers in which they can safely find, request and in turn deliver research results that are suitable for multiple use. The architecture ensures that Health-RI does not have the exclusive right to do such a thing. Other organizations can provision similar environments. |
7 | V1 | I assume that your mission is 'interoperable' but not 'one size fits all' and 'modular with room for scientific innovation' and not 'central' and 'federated' | Indeed, we try to serve the different target groups. The architecture must support the interests of multiple target groups. |
8 | V1 | Can the PBL serve as a source? | Yes, the PBL can serve as a source. But there is still a lot of thought and work to be done for this. For example, about how the quality of the data can be monitored and duplication can be prevented. The disclosure of PBL as a source is included in the target architecture around the CumuluZ concept versus PBL. |
9 | V1 | How is version control of data and data models supported? | The version control of datasets and the operations performed on them will have to be supported in the infrastructure, but will probably be handled at the source. |
10 | V1 | How does the generation and use of (primary) research data fit into the architecture? It is important to make the link with the preclinical data, e.g. the sequencing of human material. | This point is addressed in the storylines of generating data and analyzing data centrally. The intention is that the infrastructure will also offer tools to generate data (FAIR), to make it findable via the catalogue and possibly to combine it with existing data for analysis. In the architecture plate, we also talk about research data. |
11 | V1 | Do you want to avoid duplicating 'what'? Because I always see tension between 'innovation' and 'standardisation/centralisation'. So my dream is also to stimulate a bit of competitive innovation, but at the same time get a number of modular standards that ensure that data can flow between solutions. | We want to avoid unnecessary copying for which registrations (housekeeping books) are needed as well as copying errors as much as possible. In short: leave data at the source and consult it, unless there is no other option to make a copy. |
12 | V1 | How does a region platform compare to not duplicating? | A regional platform is a place where things can be found, exchanged and requested. This is not to say that there will be duplication. Leave data at the source as much as possible and visit/consult it via such a platform. If there is a good reason or there is no other option than to duplicate it. Q1 2024, there will be a letter to parliament from the Ministry of Health, Welfare and Sport with advice on how to achieve national data availability |
13 | V1 | How do the solutions for primary use compare to CumuluZ? | Health-RI works closely with CumuluZ, where CumuluZ is responsible for making healthcare data suitable for multiple use. For healthcare institutions that are not connected to CumuluZ, another solution must be found. |
14 | V1 | To set up a metadata catalogue, I think it is important to work together with FAIR Biobanks Architecture and ELSI: is there already a joint cross-domain working group? | There is no separate cross-domain working group, but there are many cross-connections, for example by working together on implementation examples and use cases. Architecture and ELSI have jointly determined that consultation is needed to identify what is needed for the desired compliance by design. Based on this, it will have to be further determined whether it is sufficient to do this through implementation examples / use cases or whether more is needed. |
15 | V1 | I would like to see 'APIs' (i.e., plural), multiple smaller scooped APIs that are easy to implement instead of 1 large API that require a high investment. | We strive for standardization, preferably also an unambiguous technical standard. Parties often have difficulty implementing a full API, a modular API would be a solution here. |
16 | V1 | So you want to encourage presets for APIs for specific domains and/or specific use cases. | No. We strive for standardization, preferably also an unambiguous technical standard. |
17 | V1 | There is a strong focus on regional hubs, usually with the UMC as the director. Is there room in this architecture for a non-regional hub, in which a group of scattered institutions can organize themselves? | There are several options on the table. Such as categorical connection point for oncology. However, it will still be necessary to look carefully at what is and remains workable. Doubling or more is lurking. So are governance issues. |
18 | V1 | It is often about nodes: can such a node also be located at an institution that is not a healthcare institution? Is that included under 'research domain'?. | A node can be set up at different levels.
|
19 | V1 | Is metadata available in Dutch or English or in both languages? | A good metadata language is agnostic for English and Dutch. By standardizing metadata, it will be possible to make it available in multiple languages. |
20 | V1 | If research requires data at the individual level from multiple sources, then the only source is the data from healthcare providers (unless the researcher can get by with the data from one other source that has already done the collection process). The requirement for quality registrations is to work with pseudonymised data. So only pseudonymised data can be passed on. In order not to let healthcare providers go crazy by all the data requests from different angles, it can be worthwhile to investigate how to prepare the data from the operational process for multiple users with a legitimate information need based on an (inter)nationally shared knowledge model. | The aim of Health-RI is indeed to allow data holders to make data suitable for multiple use once, based on a (inter)nationally shared information model |
21 | V1 | What are the plans for primary care (research) data? | Health-RI will conduct research into scenarios to make primary care data available for multiple use. For example, access via Cumuluz and first-line research databases is being examined. |
22 | V1 | The idea is that we set up a working group on semantic standards. | This is the subject of the clinical data architecture working group, which works closely with the FAIR working group. |
23 | V1 | The architecture document is now mainly based on healthcare data as the primary source. Are there already parties in the picture in the "health context"? | Yes, quality registrations (in the broadest sense) and research databases |
24 | V1 | To what extent should data models be generic? | The way in which a node captures data in a persistent data platform is not imposed, as long as it can be retrieved via an open API. Joint choices do speed up the process of achieving data availability. To make choices for preferred standards, we work together with the nodes in working groups. |
25 | V1 | Is this approval process supported by the architecture? | Yes, there are several moments in the architectural design when an assessment is carried out. |
26 | V1 | It seems to me that researcher is very much focused on medical research, and less on (general) innovation of, for example, healthcare processes where, in my opinion, secondary use of data is essential. For example, if we are going to develop a prediction algorithm to predict length of stay, does it also have to go through a medical ethics committee? | All research that falls under the Medical Research Involving Human Subjects Act (WMO) must be reviewed by a medical ethics committee. For this, the study participants must be directly involved in the study. Since this is not the case when training an algorithm on existing data, I do not expect that this research will have to go through an MREC. On the other hand, the EHDS provides for a system of permits. In the long term, data requests (in particular data refusals) will probably also be regarded as an administrative decision against which objections and appeals can be lodged? This is not yet clear, but it is necessary for us in the Netherlands to determine together how this can be incorporated into the General Administrative Law Act, in a way that is least burdensome (the most cost- and time-efficient), that contributes to unity (decisions are taken according to the same rules everywhere) and in which the independence of science is guaranteed. These are quite complicated questions, and anyone who thinks about them is welcome. |
27 | V1 | What is the expected/planned turnaround time from 'start of application' to 'I have data'? | The ambition is to use the infrastructure to significantly reduce the current lead times for the benefit of the learning care system. There is no exact lead time yet, but the ambition is as soon as possible. FYI: the new (proposed) EHDS prescribes a term of 14 days. We are now trying to achieve a term of 4 weeks, but if a number of manual steps in the process are optimized or automated, we expect that the lead time can be reduced to the required term. |
28 | V1 | Although it is said that data stays at the source, we see large data flows to the Health-RI platform, where it is processed | We distinguish 2 places where data is 'processed'
|
29 | V1 | Is HL7 NL involved? | People involved in HL&NL participated in the consultation. Health-RI is also affiliated with SDO NL, of which HL& NL is also affiliated. |
30 | V1 | Is there an open common data model in place? | Maybe in the longer term. For the short term, we aim to make data FAIR. |
31 | V1 | What exactly is meant by making FAIR? | In order to clarify what the joint Health-RI approach in FAIR data is, we have inventoried various FAIR models, with the aim of agreeing on a concrete and practical work process around FAIR. This work process will provide more clarity. This is a work in progress via this page. |
32 | V1 | What is meant by a persistent data platform?
| A persistent data platform is a central and durable data storage environment that must remain available and kept consistent over a long period of time. |
33 | V1 | Who defines the API, who develops the API? Can it then be deployed by all region nodes and used to access the regional data? | These are good questions that we are going to work out together. The idea is to define them together with the nodes. Perhaps we can make a standard SAAS solution out of this, which can be applied by the nodes
|
34 | V1 | Where does the role of data scientist fit into the HRI ecosystem? | The data scientist is reflected in various places in the Health-RI ecosystem; Examples include:
|
35 | V1 | The MREC assesses applications for WMO investigations. Who assesses research/applications that do not fall under the WMO, e.g. an application from a data scientist | For this purpose, non-WMO committees and data boards are set up in various houses. |
36 | V1 | Is anything being done to support AI in analytics? Or are we expected to design it locally? | Yes. This will be further elaborated in future versions. For example, offering an environment where AI algorithms can be trained and repositories of proven algorithms, on which others can continue to develop. |
37 | V1 | Can a researcher make direct adjustments to the source data, e.g. an EPD?
| No, there is a feedback loop that allows the researcher to provide feedback to the healthcare provider. This storyline will be further developed in a future version. |
38 | V1 | When making a dataset available via a data store, this can be done via a central datastore, a regional one, or both. | The data should be made available at the source as much as possible. If the source holder does not have the means to do this himself, this can be carried out centrally/regionally on behalf of the source holder from a shared service center point of view. |
39 | V1 | Can you also pseudonymize data be done live during issuance, or preferably when preparing the data for issuance (perhaps to also store the pseudonymized data for e.g. traceability and archiving) | That depends on the use case. It is preferable to perform the pseudonymization step as late as possible in the process. For traceability, it is advisable to have the pseudonymized data available somewhere. |
40 | V1 | How do distributed and federated data processing differ from each other? | This is a difficult question that we will come back to in a future version. For now, we've conceived federated processing as a form of distributed processing without going deep into the differences. |
41 | V1 | Is the idea that the generic functions are realized centrally, or separately per node? | The nodes are supported by generic functions. This can be technically implemented by a central solution or several interchangeable solutions. |
42 | V1 | Is it the case that the generic services are NOT operated by Health-RI itself, but that they are offered to the nodes and that nodes offer these services in the region? | Yes |
43 | V1 | Which of these application (functions) will Health-RI develop nationwide and offer as a service?
| Within the Health-RI ecosystem, it will be determined in the near future who will develop and offer which applications for the Health-RI ecosystem. The Ministry of Health, Welfare and Sport instructs NEN to describe standards for generic functions and takes the lead in designating generic facilities to implement these |
44 | V1 | In the generic functions, I see topics/capabilities that are specifically applied. What is the consideration behind this. Isn't that at the expense of decentrality/scalability? | Scalability and/or broad applicability are of great importance for generic functions. We would like to be informed about the aspects that specific capabilities prevent this. |
45 | V1 | Regarding the generic Data Converter (Mapping) function, generic translation seems very naïve to me. All information only makes sense in context. So you always have to interpret (translate) information from your own context. | Ideally, you should let the source handle it, yes. But sometimes translating a terminology into a classification is indeed possible. And if terminologies are linealized, it is also possible. |
46 | V1 | The citizen/patient must give permission for the use of the data. How is this arranged? | Health-RI stands for a central consent register for multiple uses (including research and innovation), where conditions of use are centrally maintained and what has happened to the data can be viewed. A PoC with MITZ will start soon. Here we are also looking at how this can be set up in a federated way. This will continue to be worked on in cluster 2. On behalf of the Ministry of Health, Welfare and Sport, NIVEL is conducting an investigation into control and trust. In 2024, NIVEL completed a study on behalf of VWS into trust and data availability. |
47 | V1 | Where does the patient's consent come into the picture? | There are two requirements: a legal basis and an exception to the prohibition on processing special categories of personal data. The legal basis is "the good reason" for which you want to process personal data. In our case, this is mostly science, a recognized basis. This must be weighed against the privacy risk: the greater the scientific interest, the greater the privacy risk that may be taken. In addition, there must be an exception to the processing ban. This is stated in Article 24 of the UAVG Implementation Act. If the data holder is a healthcare provider, he must also comply with Article 7:458 of the Dutch Civil Code , the exception to medical confidentiality. These articles of law summarized; Patient consent is not necessary if it requires disproportionate effort, and the question of whether it is disproportionate must be considered in the light of the privacy risk. The better the data is secured, the less privacy risk there is, the less you need to ask for your consent. However, if the data holder is a healthcare provider and the patient has explicitly indicated that the data about him may not be used, then it is not allowed. The system does not assume the patient's consent (the EU is even against this because it is bad for data availability), but individual patients can refuse to use data about them. However, as long as there are no national control registers, it is difficult to exercise this possibility of refusal properly. In the future, the legislator may determine that certain categories of data or applications may only be carried out with an opt-in. |
48 | V1 | And how does this work in other countries? | There's a lot of variety. Click here for a comparison between some European countries. |
49 | V1 | Careful consideration must be given to a future-proof control solution that can support all forms of control. The architecture must be in line with this and support the possibilities. | The control solution falls under solution 4 of the Obstacle Removal Trajectory. The importance of a control register was processed into a plea in collaboration with the parties in the field. The functional specifications are currently being explored. This concerns themes such as information and communication, the environment of the register, and connecting to forms of participation from the EHDS proposal. |
50 | V1 | How do you see that central control register across domains? E.g. towards the social domain? | There are multiple sources for registering control information, including local ones at source holders, or local ones in a citizen-controlled environment. When the statements are digitally signed by these sources, it is easy to verify the integrity and authenticity of these statements. |
51 | V1 | Does it also support scenarios for consent for new (commercial) services that want to plug into the Health-RI API? | This will also have to be included in the register of control, if necessary. with a connected solution for payment |
52 | V1 | I do wonder, or am concerned, about the consequences of such a central register. In any case, we notice that personal contact and explanation of consent is very important to inform people well and increase participation. That's where individual (local) contact is crucial. Is a central control register purely for the purpose of registration or is there more to it, such as communication? Locally, it is important to provide (age-appropriate) information in the event of consent | This remark will be included in OVT cluster 1 (Principles, support and communication) and 2 (Ethical, legal, privacy, social and knowledge security) that deal with this and is part of NIVEL's research into control and trust, which is being carried out on behalf of the Ministry of Health, Welfare and Sport. Centrally designed communication can be disseminated in a decentralized manner. We also think about communication packages for specific groups/situations. This is valuable input for the control register (solution 4 of the OVT). Additional information on what can go wrong is welcome. |
53 | V1 | How do you see the central register of control with regard to More sensitive applications such as genetic research, collaboration with industry, etc., matters that fall under informed consent. | The starting point is that the register of control is layered: different levels for different applications. The EHDS lays the foundation for this differentiation. |
54 | V1 | How do you see the central register of control across national borders? | At the moment, the solution for a national register of control is being worked out in more detail. This will be in line with the EHDS proposal. It is not yet known exactly how this will be organised at the European level.
|
55 | V1 | How is authorization (the right to access data) regulated? | The aim is to achieve role-based authorization. At the moment, we are working on authorization for researchers affiliated with knowledge institutions, and in the future authorization for more user groups will have to be realized. |
56 | V1 | How is purpose limitation regulated? | Purpose limitation can be linked to control when it comes to the use of patient data for a specific purpose. |
57 | V1 | Consent via MITZ: Is that going to be different from permission for LSP (VZVZ's other product)? | Yes |
58 | V2 | Regarding Pseudonymization:This is certainly relevant for analysis of network care (following the client about his or her care pathway)Point of attention: how do you recognize that it is the same episode/care trajectory. | Once. In subsequent versions of the Wiki, a supported solution to this problem will be published in collaboration with Cluster 2 of the obstacle removal process. |
59 | V2 | Is it the intention to make data suitable for every possible situation/target group? How far does multiple use go? | We will use the 80/20 rule. At the moment, 80% of the budget is used to prepare data and 20% is left over to conduct research. We want to turn that around. Absolute generic reusability is a dream, this is what we want to strive for. We put some effort into making it as good as possible. And we grow/learn in the future and get better over time. |
60 | V3 | I have a question about consent conditions. You are now looking at Mitz. This is now between healthcare provider and citizen. How are you going to shape the variety of consents for research there.
| There is a concept design to check consent for secondary use via Mitz. This will initially be processed into consent for retrospective research with data and/or body material. |
61 | V3 | If I look outside of healthcare: how does the AP do that (Authentication and Identification)? Or institutions that work with personal data from other sectors? . | We comply with the GDPR and eIDAS2 and what happens from EHDS. Government institutions such as the Tax Authorities use DigiD. For us, that is currently not possible, since Health-RI is not a government institution or healthcare institution and is therefore not allowed to process BSNs. The expectation is that this will change if an HDAB has to fulfill these functions within the framework of the EHDS. This will most likely be a government body |
62 | V3 | Within VWS, Generic Functions are being developed, including Identification and Authentication. This is for the PGO/MGO. It would be great if this were connected. Also consider Mitz/Nuts
| Health-RI connects to the nationally established facilities when possible with regard to generic functions. |
63 | V3 | Will we actually get 1 HDAB or more in the Netherlands?
| No decision has been made about this yet. We expect more clarity about this by the end of this year. |
64 | V3 | If an authentication service is set up - does this give the EHDS the opportunity to ensure that the data underlying a study (e.g. as used and described in a publication) is made available under Terms of Use for e.g. all researchers? So: without going through an IRB/METC and having to wait 6 months (no hyperbole) until the TTO/KT&C route has been completed?
| We share your concern: the lead times are long, Health-RI was set up to reduce this. In the long term, this process should come back to 2 to 4 weeks. We really want to have a well-scalable infrastructure and be able to respond quickly. This is also required by law with the EHDS. |