Health-RI wiki v4.0 -> consultatie (open tot 03-12-2024)

Vereisten data-aanvraagtool

Owned by Health-RI
Nov 18, 2024
3 min read

datum: 17-04-2024 Status: IN ONTWIKKELINg

GBFlag48x34.png

Dit artikel bevat een aantal vereisten waaraan een data-aanvraagtool moet voldoen

Vereisten voor de data-aanvraagtool

 De belangrijkste vereiste voor een aanvraagtool is dat deze flexibel, modulair en gemakkelijk aanpasbaar moet zijn aan meerdere workflows die in de toekomst worden verwacht.

De oplossing die we zoeken voor de Health-RI aanvraagtool moet flexibel zijn om te passen in de algehele architectuur van Health-RI. We zoeken naar een oplossing die is gebouwd met behulp van de principes van gegevensbescherming (inclusief beveiliging en privacy) by Design en by Default, FAIR en een losjes gekoppelde architectuur die een in- en exit-strategie per functioneel onderdeel mogelijk maakt, evenals integratie met andere tools/functionele componenten.

Functionele eisen:

1. Aanvraagformulier voor toegang tot gegevens:

Zodra de datagebruiker de relevante dataset(s) heeft gevonden, wordt de datagebruiker doorgestuurd naar het portaal met een aanvraagformulier. In de toekomst van het aanvraagportaal kan er meer dan één aanvraagformulier zijn en moet de gegevensgebruiker het relevante formulier selecteren om in te vullen en in te dienen op basis van de gegevensbehoeften (anoniem of pseudoniem). We zijn momenteel bezig met het formuleren van de aanvraag, maar technisch gezien moet het aanvraagformulier aan de volgende vereisten voldoen:

  • Het formulier moet de relevante velden weergeven en de irrelevante velden verbergen op basis van het gegevensverzoek.

  • Het formulier moet velden bevatten met vaste opties, zoals vervolgkeuzemenu's, en vragen met meerkeuze-antwoordopties, zoals selectievakjes en keuzerondjes waar nodig.

  • Het formulier moet duidelijke en begrijpelijke instructies geven over hoe de gegevensgebruiker het formulier moet invullen (bijv. een verplicht veld is niet of onjuist ingevuld). De instructies worden gegeven als gewone tekst tussen de vragen en een pop-up hoover-knop bij elke vraag.

  • Het formulier moet de datahouders in staat stellen domein- en datahouder-specifieke velden toe te voegen.

  • Het invullen van het formulier moet in de toekomst ook mogelijk zijn via API (Application Programming Interface).

2. Portaal voor het aanvragen van gegevenstoegang:

  • Overzichtsdashboards aanvragen voor alle rollen: Alle rollen hebben dashboards om respectievelijk de status van het sollicitatieproces te zien. De definitieve details moeten nog worden bepaald.

    • Een statusdashboard voor de datagebruiker:
      Voorbeeld: Bij elke stap moet de gebruiker op de hoogte worden gehouden van de status van de aanvraag voor gegevenstoegang (DAR) (zie de onderstaande stappen). Relevante kleurcodering moet worden toegepast bij voltooiing van elke stap (bijv. groen voor de stap wanneer deze is voltooid en rood voor belemmeringen)

    • Een statusdashboard voor de datahouder

    • Een statusdashboard voor facilitator van gegevensverzoeken

  • Functionaliteit om de aanvraagregistratie door de lokale DAC (Data Access Committee) (datahouder) te exporteren naar hun eigen systeem, zodat zij het verzoek verder kunnen verzenden of beoordelen met gerelateerde interne commissies of verantwoordelijke personen. In de toekomst willen we dit bereiken door middel van Application Programming Interface (API).

  • Berichtenmodule om meldingen te verzenden in het portaal van de aanvraagtool maar ook via e-mail.

  • Identificatie-, autorisatie- en authenticatiemodule: De gebruiker van het aanvraagportaal moet zich kunnen aanmelden met zijn instellingsaccount met behulp van een vorm van federatieve authenticatie.

 3. Identificatie, authenticatie en autorisatie (IAAI)

  •  Een gebruikers- en organisatiebeheersysteem

  • Rolgebaseerde toegangscontrole die kan worden beheerd door de organisatie (gegevensgebruiker, ouder) voor specifieke delen van de workflow

  • Single sign-on (SS0) doorgegeven uit de catalogus

  • Authenticatie op basis van OpenID (OIDC)

 Technische- en procesvereisten:

  •  Goede onderhouds- en coderingspraktijken zoals:

    • Volg de SOLID-principes

    • Schone code

    • Goed gedocumenteerd

    • Testcases: unit test en integratietests, met een hoge branch testdekking (meer dan 80%).

    • Een taal die breed gedragen wordt door de ontwikkelgemeenschap, vanwege het open-source karakter

  • Ondersteuning voor meerdere instanties

  • Taakverdeling

  • Adequate logging van ten minste:

    • Uitzonderingen

    • Gebruikers, sessies en gebeurtenissen

    • Gebruikersstromen

  • Processen voor het afhandelen van beveiligingsincidenten (bijv. ISO 27000-seriecertificering)

  • Bewezen beveiliging door OWASP Vulnerability Scan of ISO 27000-serie certificeringen

  • Serviceniveau aangeboden voor het product

 

Â