Principles

From DWH
Jump to: navigation, search



Registers

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.


Privacy

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.


Patient Identification

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.


Opt Out

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.


It can be automated based on definitions we received and/or can be done manually by register

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.