The submitted data from healthcare organizations are after pseudonymisation by the TTP (Trusted Third Party), and approval, correction and annotation steps by the dedicated teams, collected and stored in the data warehouse of healthdata.be.

Data analysis and reporting of the aggregated data from the data warehouse is made possible for authorized people.

The Secure Processing Environment export request of aggregated data process enables data analysts to request data exports from the Secure Processing Environment (SPE), which are made available as secure download links.

This process is applicable for the export of aggregated data only. It is prohibited to export non-aggregated data from the SPE. In cases where the use of non-aggregated data is authorised, a specific process must be followed (see Exceptions to the SPE export requirements).

1. SPE export request roles

- Data validator (aka data manager): individual who is granted access to the HD DWH (healthdata.be Data Warehouse) validation environment in order to validate the data received at DWH.

- Data analyst (aka researcher): individual who is granted access to the HD DWH analysis environment in order to perform analysis on the validated data. The data analyst is also responsible for requesting data exports from the SPE. Each SPE export must fulfill the automated checks (see SPE export request of aggregated data process). After that there are 2 types of provisioning SPE exports:

- Single Point Of Contact (SPOC) data governance: Each department has 1-2 SPOCs that can be contacted regarding general data governance topics. Contact details are provided/updated by the head of department to healthdata.be (HD) via a Jira Service Management ticket (JSM - https://healthdatabe.atlassian.net/servicedesk/customer/portals).

Responsibilities of the SPOC related to HD SPE:

- Data governance officer: the data governance officer is a team member of the HD data governance team.

- Data publisher: This role is specific to export requests made from the bunker environment. Since the data analyst is not known within the bunker environment, a data publisher (max. 2 per bunker) should be appointed by the client or the SPOC. The data publisher is responsible to verify the content of the export request made by the data analyst and is the recipient of the export request e-mail.

2. Disclaimer on Responsibilities, Monitoring and Data Exports

- Prohibition of data exports from the validation environment

Exporting data from the validation environment is strictly prohibited. Under no circumstances may data validators initiate, perform, simulate, or facilitate data exports from this environment. No exported data, files, screenshots, or derivative content may originate from the validation environment.

- Authorised export requests

Only authorised data analysts operating within the analysis environment are permitted to submit data export requests. All exports must be requested exclusively through the official and approved export request procedure. Any alternative method of data extraction or transfer is strictly forbidden.

- Data analyst responsibility and compliance obligations

The guidelines described herein outline key expectations governing data exports from the SPE. However, they do not constitute an exhaustive description of all technical, organizational, or procedural controls in place. Data analysts retain full responsibility for ensuring that all requested exports comply with applicable data protection legislation, ethical approvals, contractual obligations, and healthdata.be data governance policies.

- Monitoring, auditing and traceability

All export requests initiated by data analysts are subject to the following controls:

- Enforcement and accountability

In the event of a violation of export rules or applicable policies, the responsible data analyst can be identified through the audit trail. Sciensano/HD reserves the right to take appropriate corrective and enforcement measures, which may include suspension of access rights, reporting to relevant authorities in case of data breaches, or other actions as permitted by law and governance frameworks.

- No limitation of oversight

Nothing in this disclaimer limits the right of HD to implement additional monitoring, controls, or reviews, nor does it waive any legal, regulatory, or contractual obligations applicable to users of the SPE.

3. SPE export request of aggregated data process

Two configurations are offered within the SPE:

3.1. SAS environment

- Data analysts having access to the analysis environment prepare aggregated data in the SPE  and save the file in the SAS work directory, e.g. my_file.csv. Different types of files can be exported: PDF, xls workbook, htlm pages, csv, SAS table,…

- Data analysts execute the %request_file_export() macro with the name of the file to be exported as an argument (e.g., %request_file_export(my_file.csv);). The argument can also refer to a table available in the data analyst’s environment (e.g., %request_file_export(mydb2lib.my_table)).

- The export macro requires an accompanying valid metadata file (e.g. my_file.csv.meta) (see Metadata file requirements).

- The macro performs a serie of checks before the request is submitted (automated checks):

- Export request is either

- Batch scheduled exports run every day at 10:00, 12:00, 14:00, 16:00, 18:00 and 20:00. It checks the status of the export request (accepted vs rejected):

- Once the request has been submitted, the data analyst can view its status in the CONTROL.V_FILE_EXPORT view available in his/her environment.

3.2. Bunker environment

The process is identical to that described for the SAS environment except that:

4. Requirements for SPE export requests

Any data export request from the HD SPE must fulfill the below described mandatory requirements:

4.1. Data file requirements

4.1.1. Aggregated data

The SPE export process described in this document is only applicable for the export of aggregated data from the analysis environment. Export of non-aggregated data if allowed, follows a specific procedure (see Exceptions to the SPE export requirements).

4.1.2. Minimum cell count rule (“rule of 5”)

Values calculated on small populations (n < 5) carry a higher risk of unintentionally revealing identifiable information. To protect patient privacy and minimize the risk of re-identification, all aggregated data exports must comply with the “rule of 5”:

It is therefore mandatory to always include a "count" or "n" field to indicate the number of observations used in the calculation, in addition to the total count (N) applicable for the calculated variable.

Examples:

Attention points

The “rule of 5” applies as well to values not necessarily lower than 5: as soon as it is possible to conclude that there are less than 5 patients involved, the values should be replaced in line with the “rule of 5”.

Examples:

- If absolute numbers are replaced by “< 5” in your dataset, ensure that all other deviated fields are also replaced by “< 5” or “Not calculated” (NC) in these deviated fields. For example, if two calculated values need to be added and they are respectively listed as 16 and “< 5”, the sum of both should never be an absolute number, but is expected to be listed as “NC” or, if preferred, as “< 21” (using max n = 5).

- If the aggregated data are grouped per age category for example, and one of the categories does not contain 5 or more individual records, make sure that all data in the dataset pertaining to that age category are excluded from the export or listed as “< 5”.

Note:

Data governance is also looking into acquiring methodological expertise to help assess the risk of reporting cells below 5 where disclosure control has evolved significantly in the last 10–15 years. The traditional “rule of 5” is a threshold rule. Modern disclosure control increasingly uses quantitative risk assessment methods that go beyond simple cell suppression — especially when working inside SPEs.

References:

4.2. Metadata file requirements

To ensure traceability, transparency, and compliance with privacy policies, every file export must be accompanied by a standardized metadata file. This allows the data governance officer to quickly understand the content and intent of the export, and intervene when necessary.

The metadata file:

* Mandatory keys per export

Example metadata file:

Important notes:

Creating a metadata file in SAS:

A sample SAS code is available in the TeamShare directory. It includes 2 examples of how files and metadata files can be generated and exported (a SAS table or a PDF report).   

The macro accepts two optional keyword arguments:

Examples:

Different types of files can be exported: PDF, xls workbook, htlm pages, csv, SAS table,…

4.3. Exceptions to the SPE export requirements

SPE export requests deviating from the export requirements (e.g. non-aggregated data, non-compliance to the ‘rule of 5’,…) are not allowed and should not follow the process described in this document.

In case any specific requests are needed, the data analyst is required to inform the HD data governance team at least two days upfront by e-mail to datagov.healthdata@sciensano.be and provide any supporting document (e.g. agreement with the federal/regional authorities, ISC mandate, Data Protection Impact Assessment (DPIA),…).

5. Handling of SPE export request issues

Any issues encountered with the SPE export request  (e.g. issues with the macro, the frequency, the metadata file,…) should be raised via JSM (https://healthdatabe.atlassian.net/servicedesk/customer/portals), with ‘SPE / Export: <Your topic>’ as subject.