HealthData consists of data that are sent as an answer to a specific question. This combination of scientific
question and answer from the participants in the health sector is called a register.
Every register is setup as an independent project with a project responsible (‘business’).
The goal of DWH HealthData is to streamline the different projects (standardise) by using the same approach,
programming language, database and methodology. In the case of registers that are managed by WIV the register
manager has to be able to define the complete cycle from question to reporting on the website.
Respect for Privacy is a conditio sine qua non for HealthData.
We are handling medical data of patients, but also for the participating hospitals and other organisations/people
it is very important that the data is stored in a very secure way.
We want to be as transparent as we possibly can. That is why we also want to give data providers the possibility
to see who has seen data that belong to them.
HealthData does not have access to any patient identifying information. We receive a patient identifier managed by eHealth services.
Data from different registers cannot be linked by people outside of the HealthData team. The same patient will
have different identifiers in different registers eHealth is used for authentication of users on the website.
To reduce the risk of exposing detailed data when the website would be hacked, the database that is linked with
the website will only contain the aggregated data needed for the web page and not the detailed data.
Because the respect for privacy is that important to this project we try to be a bit more explicit about the way(s)
we handle this:
- Which data should (not) be stored in a database accessible by researchers is decided per data collection outside
of HealthData. Even if this information is given by the Data Providers, we have to store this in a table that is not
accessible for users.
- Every identification key we receive and create is linked per patient and stored in a table that is not accessible
to the users. This way we will be able to link everything behind the screens (if required)
- The encryption of the NISS of the patient (Rijksregisternummer) is done by eHealth. eHealth uses an encryption key
for Healthdata to do this. This encrypted identification code is the same for all the data collections (if a patient
appears in different data collections, we are able toe see this). Because access to different data collections does not
imply access to a combination of them, this identification key has to be hidden from all the users of the data collections.
- Therefore, we create an extra identification key PER patient PER data collection. So, within the data collection
the users can follow a patient, but it is impossible to link data of the same patient from different data collections.
- If somebody gets the mandate to link data from different data collections, we create a new table with data from
the different data collections and a NEW patient identifier.
- The data that existed prior to HealthData have to be linked with the new data: the patient has to be identified
within the data collection. The existing patient identifier is of course not the same as the encrypted identifier based
on the HealthData key. We have to send the patient information to HealthData and ask HealthData to ‘decrypt’ the old
encrypted NISS code and encrypt it based on the HealthData key. We call this process ‘recoding’
- This is of course auditable: we can tell for each patient where his data is stored and who had the authorization
to access his data during which period in time.
It is not yet clear what has to be done if a patient decides that his data should not be used in a data collection.
Should the patient be excluded from future questionnaires, or should his records be deleted from the past also.
Should this be done logically or physically. If physically, should this also be done in all backups?
A problem within a DWH is the fact that if this occurs we will not be able to recreate the graphs and reports of the past.
Also the data that were used in studies are no longer reproducible.
Data Validation, access and storage
Incoming data has to be validated. Since Healthdata is only responsible for technical facilitation, the validation
cannot be done by HealthData.
managers or somebody mandated to do this.
External users of the website will not be known individually in our database. Therefor we cannot manage their
access to the data using the database features. The access to the data is done in the program and logged using Guardium.
Nothing derived from data is stored outside of the database to be able to guarantee that we monitor all who has seen
something from a data provider.