FAQ Processen

Nr 

CR

Vraag 

Antwoord 

1

V1

De meeste organisaties die bij HRI aanhaken hebben geen lokale toetsingscommissie. Is dat een obstakel ?

Dit herkennen we. Hierom is het belangrijk om een landelijke toetsingscommissie een aanvraagproces in te richten.

We verwachten dat data-aanvragen zullen gaan kwalificeren als een bestuursrechtelijk besluit, waartegen je bezwaar kunt maken bij een weigering. De vraag moet beantwoord worden, waar dan bezwaar en beroep kan worden aangetekend. Hierover zijn we aan het nadenken. Het is wellicht niet logisch dat een landelijke toetsingscommissie alle aanvragen beoordeelt, maar misschien kan een landelijke toetsingscommissie alle beroepsschriften op data-weigeringen doen. Bijvoorbeeld. Dit moeten we samen goed gaan uitdenken.  

Overigens hebben, naar onze informatie zeker alle UMC’s en topklinische en soms ook algemene ziekenhuis een commissie die toetst of een verzoek om gezondheidsdata gehonoreerd kan worden.  

2

V1

Ik denk dat we veel specifieker moeten aangeven hoe een dataproducent dit moet doen. Een gedachte: het in bulk beschikbaar stellen en persisteren van data is stap 1 (in welk scenario dan ook). OpenEHR is hier verder in dan FHIR (Bulk FHIR API is pas vorig jaar gemaakt). Dus we zouden b.v. in een project kunnen zeggen: we gaan een OpenEHR persistentie laag maken (bij een hub). Vanaf daar hebben we meteen 2 standaarden, want OpenEHR heeft al een FHIR API. Ik denk dat als we dit niet gezamenlijk doen met de hele schaarse kennis die überhaupt hiervoor beschikbaar is, we onvoldoende meters maken. 

Eens. Het is belangrijk dit bespreekbaar te maken, zowel via de architectuur en het open consultatieproces als via het OVT. 

Het is nu al zo dat UMCs met FHIR werken om brondata te ontsluiten of met OpenEHR voor dataopslag. Daar zal in samenwerking met Cumuluz hiervoor twee aparte poc’s ingericht worden om data voor de Health-RI infrastructuur te ontsluiten. 

3

V1

Bij het FAIR maken van het MLDi register is er op basis van OBI een ontologie opgezet. Als je vanuit je eigen datamodel (EDC in dat geval Castor) de data FAIR maakt, dan heb je nog niet de samenhang en mogelijk ben je ergens niet generiek genoeg in je dataveld en heb je een tussenstap nodig om het veld betekenis te geven.  

Hier hebben we het over het FAIR maken van data, zodat een ander register met de dezelfde intentie dat ook kan doen zodat je analyses kan doen over beide registers (verhaallijn federatieve analyse). 

Ontologieën zijn een belangrijk onderdeel van FAIR data. De details en keuzes voor het FAIR maken van data zullen per domein/gebied door de domeinexperts moeten worden bepaald, waarbij we als Health-RI nu vooral inzetten op het harmoniseren van het proces daartoe en deze via recepten beschikbaar te maken aan anderen. In meer domeingerichte gezamenlijke Health-RI projecten waarin data FAIR gemaakt worden (zoals MLDi) zullen we de benodigde verdieping aanbrengen op het gebied van ontologieën en de lessons learned gezamenlijk opschrijven en omzetten naar een gezamenlijk werkproces. Dit is work in progress via deze pagina

4

V1

Hebben jullie al 'lessons learned' overgenomen van het Data Nutsbedrijf van Digitaal Vlaanderen (net gelanceerd onder de naam 'athumi')? 

We kijken ook naar de ontwikkelingen bij vergelijkbare initiatieven in Europa. Mochten we deze niet op de radar hebben, dan zullen we contact opnemen. 

5

V2

Worden bij het beschikbaar maken van onderzoeksdata de lokale voorwaarden ook meegekopieerd? Want het oorspronkelijke consent blijft van toepassing.

Nadere informatie over de voorwaarden bij het beschikbaar stellen van onderzoeksdata is te vinden op de ELSI Servicedesk: Onder welke voorwaarden mag ik onderzoeksdata delen, beschikbaar stellen of toegang geven tot mijn onderzoeksdata? | Elsi Servicedesk (health-ri.nl)

6

V2

Als er contracten worden verstuurd, hebben we het dan over generieke contracten of eerder over maatwerk per datahouder ?

Dat is nog niet bekend, maar generiek is de voorkeur.

7

V2

Wie is verantwoordelijk voor het beschikbaar stellen van datamodellen/ontologien van gegenereerde data

Idealiter is er een standaard beschrijving van een datamodel/ontologie die gevolgd wordt bij het beschikbaar stellen. Als er afwijkingen zijn dat dient de datahouder dat aan te geven. Zie ook De datahouder is zelf verantwoordelijk om data meervoudig bruikbaar te maken. .

8

V2

Bij een federatieve analyse: door wie wordt de analysevraag getoetst ?

De analysevraag wordt getoetst bij de aanvraag van de toegang tot de data door een (nader te bepalen) Data Access Commissie (DAC).

9

V3

Ik heb een vraag over de toetsing bij de datahouder. Is er gekeken naar de metc-systematiek? Zijn er parallellen met de toetsingen van onderzoeken?

Ja die parallellen zijn er. Binnen het project waarin Health-RI werkt aan de implementatie van het Toetsingskader nWMO-onderzoek hopen we veel te leren over de praktijk van toetsing . Deze kennis kunnen we vervolgens toepassen binnen het Health-RI ecosysteem.

10

V3

Ik wil graag wat vragen mbt de analyse infrastructuur. Hoe gefedereerd is dit?

Vervolg vraag: Hoe gaat gefedereerde analyse er uit zien?

De analyse architectuur moet in basis gefedereerd zijn: je kan niet de hele wereld centraliseren. Maar het is hybride. Gefedereerd heeft onze voorkeur maar niet alle vraagstukken kunnen gefedereerd opgelost worden.

Hoe gefedereerde analyse technisch precies ingericht wordt is nog niet besloten. Hier zijn verschillende oplossingen mogelijk. We streven naar een zo schaalbaar en interoperabel mogelijke oplossing

11

V3

Hoe verhouden de werkzaamheden in de analyse werkgroep mbt de beveiligde verwerkingsomgeving zich tot het HDAB-NL project waarin dit ook een onderwerp is (wat daar volgens mij getrokken wordt door CBS)?

De EHDS wetgevingstekst is nu in concept beschikbaar. Daar zitten een viertal technische componenten in: catalogus, aanvraagtool, veilige verwerkingsomgeving, data kwaliteit(s label). CBS trekt inderdaad de veilige verwerkingsomgeving.

Het Health-RI architectuur-team is nauw betrokken bij het HDAB werkpakket waarin aan SPE's gewerkt wordt. De werkgroep analyse wordt hierover geïnformeerd en stappen die de werkgroep zet worden in HDAB-NL ingebracht.

12

V3

Bij de verhaallijn data beschikbaar maken staat een blokje 'Vaststellen codering en modelering' bij de Data Governance Commissie. Gaat deze commissie hier dan over? Of ligt zo'n taak toch bij de data owner/generator?

Data definities liggen bij Data Governance commissie. We komen er op terug in volgende versie van de wiki.