Users and Accounts

From DWH
Jump to: navigation, search


We need to identify the user by authentication and give a user access to the reports and data by authorization.

Authentication for the DWH of Health Data is done by eHealth and through the eID.

We can distinguish different types of users who need to be able to see reports and data. Based on the type

of user the register manager decides which type of account is granted to the user and for which register

and which data.

Based on this decision a user can get access to the internal or the external infrastructure.

Types of Users

Data is stored per register and the access is also managed by register. A user can be granted access to all

data or a part of data from a register based on the mandate he received from the privacy commission.

This way we can distinguish 6 different types of users:

  • Healthdata team members
    • Access to all registers
    • Only for development and maintenance reasons, no analysis are performed
  • Register Managers and researchers
    • Access to ‘their’ register
    • According to the mandate they received (normally all data of the register)
    • Have to validate the data
    • If they have access to different registers, the data of the registers cannot be linked based on a patient
identification. If they want to link data from different registers, they have to obtain a mandate for the combination
and then a ‘new’, derived register will be created
  • Data Providers
    • Can have access to their own data combined with an non identifiable aggregation of other data providers (benchmarking)
    • We have setup a website for this reason
    • Authorisation has to be provided by the data provider (who has access to their data)
    • They are the owners of the data
  • Federal and federated health stakeholders (FOD Volksgezondheid, RIZIV…)
    • For registers managed by them they have access to all detailed data of these registers
  • Third parties that have received a mandate to obtain data from HealthData
    • Have access to the data as stipulated in the mandate
    • But we have to make sure that data delivered to the same third party coming from the same register but for a
different scientific question (and therefor different mandate) cannot be linked with the earlier sent data based
on a patient identifier
  • Validators of data quality
    • Most of the time the same person as the register manager or somebody mandated by the register manager
    • Has to have access to all detailed data
    • Not needed in all registers because in some cases the data is already validated before sending them to HealthData

User Accounts

We need to identify the user by authentication and give a user access to the reports and data by authorization.

The user accounts we provide can be split up into 2 different types bases on the type of data they need to access:

  • users that have access to detailed data
  • users that have access to aggregated data

This diffence is a consequence of the requirements with respect to data storage and access that

ask for a distinction between internal accessible data and external accessible data.

Internal vs External.png

The data warehouse and the reporting on the data are made possible for authorized people by the register manager on


eHealth is used for authentication of users on the website for the acceptance and the production environment.

To be able to authenticate the user has to be known at eHealth as a user for HealthData and the organization(s)

he should be able to access data for have to be known also. A user tries to access the website as a part

of an organization. So during the authentication process a part of the authorization is also done.

If one person has access to data for the same data collection, from different organizations, he will have

different accounts at eHealth.


The data providers are owners of the data. Therefore HealthData can never decide who should have access to

which data and in what capacity. Whether a person has access to information of a certain data collection for

a certain data provider is decided by the security officer of the data provider.

To do this, we have created some web pages within the website. When the data providers do not have a security

officer they can delegate this to for instance the manager of the data collection.

Example: Sentinel General Practitioners, where the data provider is a General Practitioner or a group practice.

From the beginning we foresaw the possibility to look at data from a data provider at 3 levels:

  1. data provider
  2. department of data provider
  3. data from the user (MD) within the data provider

It is up to the security officer to decide for each person which type of access this person has to the data of

the data provider.

<--Security Officer = Register manager? Altijd? staat niet in het lijstje hierboven. Eén term?-->

The authorization is used in 3 parts of the framework to be absolutely sure the person has the right to receive

the report.

  • To create the menu for the users: to determin for to which data collections for the chosen organization a user has access
  • At the time of constructing the page for the chosen report this check is done again
  • When executing at the SAS server the program that queries the database the same check is done by the SAS program.

Internal Infrastructure

The internal infrastructure is used to analyze or validate detailed data. This infrastructure can be reached at

Everybody who wants to access the data has to have the following in place:

  1. Registration at eHealth
  2. Mandate to do this
  3. User account
  4. Access to the RDS Server
  5. Account on the SAS and database server

A user account only analyses or validation. If a user needs to analyze and validate data, he needs to have two separate user accounts.

External Infrastructure

This infrastructure can be reached at and only requires a registration at eHealth.

The external infrastructure provides the user with an inventory, which is the descriptional part, and a reporting part. The inventory

can be viewed without a user login. The part where a user can actually consume the reports uses a technical and not a personal user account

in the DWH infrastructure.