In the file below you can find the Data Collection Definition (DCD) of the project COVID-19 Barometer: Triage Posts. It is a detailed description of the content with field names, formats, values, validation rules, help texts, warning texts, translations, ...

• 022c05d8-c232-4d66-a884-cf14c1996e80 Data Dictionary CSV
• 022c05d8-c232-4d66-a884-cf14c1996e80 Data Dictionary JSON

This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create a support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!

The FAIR portal of healthdata.be (https://fair.healthdata.be) is an open-data platform based on the DKAN open-source component on top of the open-source Drupal CMS (Content Management System). FAIR is an acronym of Findable, Accessible, Interoperable and Reusable and originates from academics and private stakeholders that came to the conclusion that a minimal set of guiding principles and practices would help them to more easily discover, access, appropriately integrate and re-use, and adequately cite, the vast quantities of information being generated by contemporary data-intensive science.

The FAIR principles guide healthdata.be in its ambition to facilitate the re-use of the patient registries and administrative databases in Belgium. Off course with respect for the privacy of the patient, the healthcare professional and the medical confidentiality. With the FAIR portal healthdata.be provides an overview of existing databases with Belgian health and health care related data and aims to steadily make this data discoverable and available to the public to increase public health knowledge.

The healthdata.be service (Sciensano) processes each incident report according to a Standard Operating Procedure (SOP). A public version of this SOP "HD Incident Management Process" is also available on this portal docs.healthdata.be.

To submit an incident related to registries and applications in production and facilitated or managed by Sciensano's healthdata.be service, you must first log into the HD Service and Support portal: Jira Service Management (JSM) portal.

More info concerning how to request an account is available here.

After the login step, you will arrive at the main page of the portal

To create a ticket click on "Create a Support ticket"' on the main page.

You will see the page below. Once you have filled in all the mandatory fields, click on "Send".

To request information about the healthdata.be platform, you first need to log in to the HD Service and Support portal: https://sciensano.service-now.com/sp.

Om informatie op te vragen over het healthdata.be platform, moet u eerst inloggen op het HD Service- en Supportportaal: Jira Service Management (JSM) portal

WHAT IS THE PROBLEM?

Sciensano blocks e-mails from organizations if the configuration of their e-mail and/or DNS services allow potential abuse by spammers/attackers. More specifically, if the configuration enables other senders to impersonate your organization by allowing them to mimic your organization’s e-mail “Header From”.

In other words, they can send phishing and spam mails that cannot be distinguished from genuine mails from your organization.

If you’re responsible for managing your ICT infrastructure, keep reading. If not, pass this message on to your ICT department or to the ICT service that’s managing your ICT infrastructure.

HOW TO SOLVE IT?

You’ll have to verify that your configuration complies with “Sender Alignment” security requirements.
More specifically, your mail services and DNS will have to be configured according to ICT standards.

These configurations are common, well-documented and supported by hosting companies. Some useful links:

• https://dmarcian.com/alignment/
• https://mxtoolbox.com/dmarc/spf/spf-alignment
• https://o365info.com/how-does-sender-verification-work-how-we-identify-spoof-mail-the-fiveheros-spf-dkim-dmarc-exchange-and-exchange-online-protection-part-9-of-9/

We’ve noticed that this issue frequently occurs in organizations which moved their ICT infrastructure to cloud services such as Microsoft (O365), Amazon, Google, and MS Azure without properly configuring the ICT infrastructure which is not managed by these providers.

The configurations and recommendations need to be implemented on the customer’s ICT infrastructure, either internally or externally. DNS and Mail services are the main ICT platforms for these actions.

THE USE OF DIFFERENT DOMAINS IN THE MAIL SENDING PROCESS

E-mails contain an “Envelope From” and a “Header From”. Both need to match to avoid that the mail is blocked.

Some examples:

1. A public service is using its new domain name in the “Header From” and its old domain name in the “Envelope From”.

• Envelope From = noreply@publicservice.fgov.be
• Header From = noreply@publicservice.belgium.be

➔ These e-mails will be blocked.

Remark: Because it’s a noreply address, the sender will not even be aware of us rejecting the e-mail …

2. An organization is using a cloud service (Freshservice) for its helpdesk tool and the “Envelope From” has not been customised.

• EnvelopeFrom = bounces+us.3.52773-helpdesk=organisation.be@emailus.freshservice.com
• Header From = helpdesk@organisation.be

➔ These e-mails will be blocked.

3. A company uses a cloud service (Amazon SES) to send the delivery notification and the “Envelope From” has not been customized.

• Envelope From = 01020188573f374-96de6437-9134-45f4-8aa6-3e9ac18d5848-000000@euwest-1.amazonses.com
• Header From = noreply@company.be

➔ These e-mails will be blocked.