Surveillance of Infectious diseases by sentinel laboratories

Surveillance of Infectious diseases by sentinel laboratories

Welcome to the technical documentation pages for the project "Surveillance of Infectious diseases by sentinel laboratories" (EPILABO), provided by the service healthdata.be (Sciensano).

These pages provide information about the technical processes of the project. The following sections are (will be) provided:

For scientific information of the project, please contact the primary organization that oversees implementation of project (see section "General project information").

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!
johanvanbussel Wed, 11/20/2024 - 16:32

General EPILABO project information

General EPILABO project information

Project name

Surveillance of Infectious diseases by sentinel laboratories

Project abbreviation

EPILABO

Project code

HDBP0037

Primary organization that oversees implementation of project

  • Sciensano

Partner organization participating in project

Organization that commissioned this project

  • Sciensano

Organization providing monetary or material support

Brief project description

  • The department Epidemiology of infectious diseases of Sciensano coordinates the national surveillance of infectious diseases from 1983 onwards by a network of microbiological laboratories, further called sentinel laboratories. Those laboratories are distributed evenly in Belgium and they notify and transfer voluntarily the data for well-defined pathogens. Most important tasks of the network are the surveillance of epidemiological trends and the warning of outbreaks.
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!
Bart.Servaes Tue, 10/15/2024 - 11:27

The EPILABO data collection

The EPILABO data collection

Organizations and/or individuals that provide data

Belgium sentinel labs

Start date of the data collection

Registration of infectious diseases was initiated in 1983. Data collection by Healthdata.be is expected from 2025 onwards.

End date of the data collection

No end date

Periodicity of the data collection

Continuous

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!
Bart.Servaes Tue, 10/15/2024 - 09:06

The EPILABO data collection definition (HDBP0037)

The EPILABO data collection definition (HDBP0037)

The information below contains the Data Collection Definition (DCD) specifications of the project Epilabo. It is a detailed description of the content of two registries:

  • the DCD used for the nominative dataflow for test results from patients residing in the Walloon / Brussels Capital region, data will be transmitted to the regional health authorities (AVIQ and Vivalis) in the context of the mandatory notifiable infectious diseases.
  • the DCD used for the pseudonomized dataflow for test results from patients residing in Flanders.

In terms of data reporting the fields and code lists to be extracted and sent are exactly the same for both DCDs. This will allow the data provider to extract the data only once. Subsequently, the data need to be split based on the postal code of the patient's residence in 2 data sets according to the regions: Flemish region versus the Walloon / Brussels Capital region. The list of the postal codes and their relation to the regions can be downloaded below:

Finally, the obtained data sets can either be sent via the nominative dataflow for the dataset for the Walloon / Brussels Capital region or the pseudonomized dataflow for the data set for the Flemish region.

(Links to new DCD specifications to be published on the FAIR portal will be added below)

with hd, settings, survey, choices (including general code lists) change log ... These specifications were used to build the forms, csv's, and API's for this project, which you also can find in this project manual. Go here for a detailed guide to the XLSForm standard.

In addition to this, more detailed information about the codes and the formats used for the Author group, SSIN code, status, Postal Code, "Date" - "Date:Time", repeatable fields and multiple choice fields is available here.

Additional Epilabo-specific information

  • In addition to the DCD specifications you can download the test codes mapping table below. This table is used to map the test codes (Loinc codes) linked to the Pathogen (Snomed codes), Test method (Snomed codes) and Sample type fields (Snomed codes).
  • Codes to be selected in case of missing information

In case of missing information (i.e. confidentiality of patient information for sexual transmitted diseases) for a required field, a “dummy” value needs to be entered. This allows the submission of the record without error message. A “dummy” code can be proposed to ensure consistency of the reporting field. See 'hint:English' column in the 'Survey' sheet of the XLSForm.

Required fieldExampleDummy code
DateDate of birth01/01/1900
Date:timeDate and time of test result01/01/1900:00:00:00
TextPatient nameNA
  • Codes to be selected in case of viral or bacterial culture

In case the field 'LaboratoryTestResult_LaboratoryTest_TestCode' is filled out with the code for a culture test = 11475-1: Microorganism identified in Specimen by Culture, then a pathogen SNOMED code from the 'qualifier_835 code list' needs to be entered in the field 'LaboratoryTestResult_LaboratoryTest_TestResultCodeableConcept'.

In all other cases, the codes "detected" or "inconclusive" or "Not detected" should be selected. See 'hint:English' column in the 'Survey' sheet of the XLSForm.

  • Selection of the NIHDI codes from laboratories

In the frame of this Epilabo registry, the values for the HCO_LAB_CBE codelist should only contain the recognized laboratories by NIHDI. Therefore, the 8-digit NIHDI ID’s should be selected, not the 10-digit CBE codes.

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!
Bart.Servaes Tue, 11/18/2025 - 11:31

HD4DP v2

HD4DP v2

In the following sections, we will provide you with information on how to proceed with the application HD4DP v2:

Bart.Servaes Tue, 04/04/2023 - 10:19

General description of the application HD4DP v2

General description of the application HD4DP v2

The HD4DP v2.x Local is an electronic data capture (EDC) system: a computerized system designed for the collection of clinical data in electronic format for use in research supporting human public health policy. HD4DP (Health Data for Data providers) replaces the traditional paper-based data collection methodology and the proliferation of websites to streamline data collection and expedite the time to analysis and reporting.

Components and features

The HD4DP v2.x Local application contains the following major components: NextGen Connect, Form.io, HD Connect (LOCAL Proxy), Local datawarehouse.

NextGen Connect

NextGen Connect is a health care integration engine that translates message standards into the standard required by the receiving system, including data formats and standards like HL7, DICOM, ANSI X12, ASCII, and XML. Main functionalities are filtering, transformation, extraction and routing.

The NextGen Connect component is used to handle all integrations within HD4DP v2.x itself but also all integrations with the external world.

Data collections API: The form.io server offers a REST API which can be used to submit data for each known data collection. Data provider Master Systems cannot access this API directly but need to use the API exposed by the NextGen Connect component. This API is simply a proxy for the form.io API, but allows extra features on top of the form.io API such as security, monitoring, throttling, …

CSV API: For each data collection data can be submitted file-based using a CSV. A CSV can contain multiple data entries for a single data collection definition. These data entries are transformed and pushed by the NextGen Connect component towards the form.io server for potential manual post-processing and validation.

HL7 FHIR API: For some data collections an HL7 FHIR API will be available. The NextGen Connect component performs the transformation towards the Data Collections API and push the data into the form.io server.

Data delivery: the NextGen Connect component handles all routing of data towards the external world. This means it verifies the form.io server for completed data entries which have not yet been delivered. For each data entry that needs to be delivered, it determines where to send the data to, how it needs to be transformed and how it needs to be split. It performs all these actions in a guaranteed delivery fashion: it makes sure the data reaches its destination, possibly retrying when something went wrong.

Feedback: the NextGen Connect component coordinates the reception of feedback, potentially transforming it and pushing it towards the corresponding data collection entry using the data collections API.

Form.io

Form.io is a data management platform that includes a form builder with a drag and drop interface, management of data with complete API platform, management of users, offline forms, dynamic forms, automatic creation of API, and application embedding. In HD4DP v2.x, and Angular frontend application is available in addition to the form.io server. This application provides a user interface to data providers in which they can see the different data collections for which they are allowed to record and submit data manually. A form.io backend server is responsible for providing the form definitions and registrations of new/updated entries.

HD Connect (LOCAL Proxy)

The HD Connect component is used to retrieve metadata from Master Data Management Database (MDM DB) residing within healthdata.be.

Local datawarehouse

Every single change in data entries on the form.io server is pushed towards the local datawarehouse (Local DWH) for easy reporting and data extraction.

Installation and maintenance

The HD4DP v2.x Local application is provided cost-free and installed remotely on the infrastructure of the healthcare organization by healthdata.be. Healthcare organizations are provided the system requirements for installation of the HD4DP v2.x application.
Healthcare organizations unable to provide the system requirements may opt to request the access and use of a HD4DP v2.x Local application of another healthcare organization.
Healthcare organizations unable to provide the system requirements nor access and use a HD4DP v2.x Local application of another healthcare organization, can request access and use of HD4DP v2 WEB hosted by healthdata.be.

The application HD4DP v2.x Local is maintained cost-free remotely on the infrastructure of the healthcare organization by healthdata.be. The infrastructure on which the application HD4DP v2.x Local is installed, should be maintained by the healthcare organization.

Bart.Servaes Tue, 04/04/2023 - 10:19

Position of HD4DP v2 in HD Architecture 2.0

Position of HD4DP v2 in HD Architecture 2.0
Bart.Servaes Tue, 04/04/2023 - 10:19

User manual of the application HD4DP v2

User manual of the application HD4DP v2

In this manual we describe the following functions of the application HD4DP v2:

Bart.Servaes Fri, 06/07/2024 - 09:04

Request access to an HD application for a specific project

Request access to an HD application for a specific project

Healthdata.be applications such as HD4DP v2 and healthstat.be process sensitive personal information. Therefore, strictly controlled processes are used to grant access to these applications. The Entity Access Management (EAM) portal of healthdata.be facilitates these processes.

Make sure to use the current version of the EAM system. The relevant user documentation can be found here.

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!
Bart.Servaes Fri, 06/07/2024 - 09:05

User roles in HD4DP v2

User roles in HD4DP v2

Each healthcare organization has at least one Access Manager who oversees the access rights to the applications of their own organization and manages them in the HD Entity Access Management (EAM) system. In this process, access requests by healthcare organization’s employees are analyzed and validated if legitimized. The scope of the accesses granted to HD4DP2 may differ, which is reflected in various user roles. Based on access rights, the following three user roles can be distinguished:

Local Study Lead (author):

The Local Study Lead can:  

  • edit and review all peer registrations (regardless of role) for the study or project;
  • make registrations in HD4DP v2.

This role might be, but should not be limited to, the individual responsible for the study or project within the participating healthcare institution.

Local Study Associate (author):

The Local Study Associate can: 

  • edit and review their own registrations, not those of other colleagues from the same healthcare organisation participating in the same study or project. The indicated registrations are limited to the patients treated by the Local Study Associate;
  • make registrations in HD4DP v2.

The Local Study Associate is a healthcare provider participating in the study or project. This is reflected in the registration form.

Local Study Support (co-author):

The Local Study Support can: 

  • edit and review registrations belonging to the author group they are linked to;
  • make registrations in HD4DP v2.

A Local Study Associate and Local Study Lead can delegate registration tasks to a Local Study Support. This might be, but should not be limited to, an administrative assistant or staff from a medical coding department. The Local Study Associate and Local Study Lead are still considered as the author of the registration; the Local Study Support is considered as the co-author. The Local Study Associate and Local Study Lead can view and modify Local Study Support entries.

The scope of the access rights is to prevent users of HD4DP v2 from seeing personal and sensitive information from individuals with whom they do not have a therapeutic relationship. The access rights therefore do not necessarily reflect the hierarchy within the healthcare organization. The healthcare organisation staff can consult their Data Protection Officer (DPO) for more in depth information concerning these access rights. It is up to the Access manager to approve or change roles from/to Local Study Lead, Local Study Associate and Local Study Support. These requests are carried out in the EAM system by the Access managers of each healthcare organization.

Remarks:

  • The scope of the access rights does not necessarily reflect the hierarchy within your healthcare organisation.
  • It is up to the Access manager to change roles from/to Local Study Lead, Local Study Associate and Local Study Support. These requests are carried out in the EAM system.
Bart.Servaes Sun, 01/07/2024 - 12:34

Access the application HD4DP v2

Access the application HD4DP v2

To access the HD4DP v2.0 application, you must first request an account. If you do not have an account yet, please consult "Request access to an HD application for a specific project" first.

Once your account has been created and the registry is put in production, you will receive an e-mail with the following information (Note that the text between the [ ] will be adapted):

  • Organization: [RIZIV number - Name] 
  • Login: [email] 
  • Password: [password] 
  • Application URL: [url] 

With these credentials you can access your organization's HD4DP v2.0 application:

  1. Go to the url mentioned in the email 
  2. Select "your organization" from the list 
  3. Your organization: [RIZIV number – Name] 
  4. Click on "Next
  5. Fill in your "username" and "password"
  6. Click on "Log in"

Please be sure to log off after making use of the HD4DP v2.0 application, or any other healthdata.be application. Just closing your internet browser does not guarantee that your application with registrations has been closed.

Bart.Servaes Fri, 06/07/2024 - 09:06

Navigate to the EPILABO project

Navigate to the EPILABO project

When logged in, you will see the Welcome page. In the left dark blue menu you can see all the study programs and projects you have access to.

When you select the study program Sentinel Laboratories Infection Diseases, you can see the study project Epilabo.

Select the study project Epilabo.

You will see that the study project Epilabo consists of 1 section: Clinical biology - Laboratory Test Results.

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!
Bart.Servaes Fri, 06/07/2024 - 09:06

Create an EPILABO registration

Create an EPILABO registration

To create a registration for the study project Epilabo, select "Clinical biology - Laboratory Test Result" in the dark blue left menu.

You will see the number of versions of this study section. In this case the third version: v1.

When you select the highest version of this study section for the first time, you will see an empty overview table in the main part of your screen. The table contains, among others, the following items: Registration IDProgressAuthorCo-authorUnique ID, Business keyRegistration codeNational registry ID of the patient...

NOTE:

The study section is not always available in the selected language. In that case the text frame pictured below covers the language selection buttons. It automatically disappears after a few seconds.

You will have to select now the desired language with one of the other language buttons:
NL for Dutch, FR for French or EN for English.

In the top right corner of the screen you can find a green button "+ New registration". Click this button.

After clicking the "+ New registration" button the main screen will be replaced by two sections: a study form in the middle of the screen and a table of contents on the right-hand side of the screen.

By completing the study form you will create a registration for the respective study project.

Table of contents

The Table of contents indicates which sections you must complete. You can also use the table of contents to navigate through the study form: clicking on a section in the table of contents will take you to this section in the study form.

Progress

By selecting the tab "Progress" on the right-hand side of the screen, the table of contents will be replaced by a progress bar and a list of open validation errors).

You can use the list of open validation errors to navigate through the study form: selection of a validation error in the list will take you to this section in the study form.

When the study form is completed and there are no validation errors, you can save or submit this registration: Save or Submit. Notice that the Submit button is in clear green.

When the study form is completed but there are validation errors, you can save but not submit this registration: Save but not submit. Notice that the Submit button is in dim green.

When the study form is saved or submitted, the screen switches to the overview table. Note, this table is no longer empty but shows the saved or submitted registration.

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!
Bart.Servaes Fri, 06/07/2024 - 09:07

Find an EPILABO registration

Find an EPILABO registration

To find a registration for the study project Epilabo select "Clinical Biology - Laboratory Test Results" in the dark blue left menu.

When you select a version of this study section, you will see the overview table in the main part of your screen. This table contains, among others, the following items Registration ID, Progress, Author, Co-author, Unique ID, Business Key, Registration Code, National Patient Registry Number…

Use the filter below each column label to find the registration that you are looking for.

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!
Bart.Servaes Fri, 06/07/2024 - 09:07

Update an EPILABO registration

Update an EPILABO registration

To update a registration for the study project Epilabo, select "Clinical Biology - Laboratory Test Results" in the dark blue left menu.

When you select a version of this study section , you will see the overview table in the main part of your screen. The table contains, among others, the following items: Registration IDProgressAuthorCo-authorUnique ID, Business keyRegistration codeNational registry ID of the patient...

Use the filters in the header of the overview table to find the registration you want to update.

If you have found the registration, you can open the study form of the registration by clicking on the corresponding row in the overview table.

You can complete the missing fields and / or change previously completed fields in the study form.

At the end of the study form you can Save or Submit the registration.

A registration can be updated as long as the registration has not yet been submitted. If the status of a registration is "Saved", the registration can still be updated.

If you save the registration, you can still edit it. A submitted registration can no longer be modified or deleted.

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!
Bart.Servaes Fri, 06/07/2024 - 09:08

Delete an EPILABO registration

Delete an EPILABO registration

To delete a registration for the study project Epilabo, select "Clinical Biology - Laboratory Test Results" in the dark blue left menu.

When you select a version of this study section , you will see the overview table in the main part of your screen. The table contains, among others, the following items: Registration IDProgressAuthorCo-authorUnique ID, Business keyRegistration codeNational registry ID of the patient...

Use the filters in the header of the overview table to find the registration you want to delete.

Once you have found the registration you want to delete, you must select the registration(s) by ticking the checkbox at the beginning of the row in the overview table.

Then you need to press the "Actions" button at the top right of the summary table.

There are now two options, "Submit" and "Delete". Now press "Delete".

After you press "Delete," a pop-up message will appear asking you to confirm the deletion of the selected registration(s). If you are sure about this action, press "Confirm." If not, press "Cancel."

If you delete the registration, you cannot change its status or content.

The deleted registration will not be removed from the summary table. It remains present, but the status has changed from "Open" to "Deleted".

If you want to see only Open and Sent registrations, you can adjust the filter on the "Status" item in the summary table.

A registration can be deleted as long as the registration has not yet been submitted. If the status of a registration is "Open", the registration can still be deleted.

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!
Bart.Servaes Fri, 06/07/2024 - 09:08

Submit an EPILABO registration

Submit an EPILABO registration

To submit a registration for the study project Epilabo using the overview table, select "Clinical Biology - Laboratory Test Results" in the dark blue left menu.

When you select a version of this course of study, you will see the overview table in the main body of your screen. The table includes, among others, the following items: Registration ID, Progress, Author, Co-author, Unique ID, Business Key, Registration Code, National registry number of the patient…

Use the filters in the header of the table to find the registration(s) you want to submit. For example, you can use the filters "Status" (set to "Open") and "Validation Errors" (set to "0") to find the registrations that are eligible for submission.

Once you have found the registration(s) you want to submit, you must select the registration(s) by ticking the checkbox at the beginning of the row in the overview table.

Then you need to select the "Actions" button at the top right of the overview table.

Two options will be available: "Submit" and "Delete". Select "Submit".

After you have selected "Submit," a pop-up message will appear asking you to confirm the submission of the selected registration(s). If you are sure about this action, click on "Confirm." If not, click on "Cancel."

Once you have confirmed the submission, you can't change the content of the registration(s) anymore. Submitted registrations can also no longer be deleted.

The submitted registration remains present in the overview table, but the status has changed from "Open" to "Submitted".

If you want to see only "Open" registrations, you can adjust the filter on the "Status" item in the overview table.

A registration can be submitted at the end of the creation process using the study form (see: Create a [project name] registration).

When the registration was completed using the study form, saved and there are no more validation errors, the registration can also be submitted via the overview table. This method can be useful to submit multiple registrations in the same action.

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!
Bart.Servaes Fri, 06/07/2024 - 09:09

Send a correction of a registration

Send a correction of a registration

To send a correction of a submitted registration you need to submit the complete record again.

The Add corrections function (and button) to a registration form has been discontinued. It is no longer available, neither via the overview table, nor via the preview page of a registration.

Submitting the complete record again

Corrections are provided through a new submission. In doing so, the most recent version of a record which is received by healthdata.be will be considered to be the correct one.

Whether a record qualifies or not is determined by a so-called business key. This is a unique set of values of specific fields per record, such as a combination of the patient ID and the hospitalization date, or the niss code and the sample ID. The business key is created when submitting the original record, and so helps to identify the most recent record received in the healthdata.be database in case of resubmission.

Attention: In case any of the fields that builds the business key needs to be corrected, the record which will be resubmitted will have a different business key. Consequently, both records will be considered as correct ones, since there is no identical business key.
Unfortunately, we cannot immediately remove your incorrect registration. We are looking for a solution to do so eventually.

There are two options to resubmit a record:

Option 1: Submission via S2S API / CSV Upload

The correction of the values is performed directly in the json or csv file. To resubmit the complete record via the back-end, please refer to the applicable technical documentation pages. The examples shown in the links below are for Pacemaker Primo-Implantation:

  • For submitting the complete record as a .json file via S2S API, go here.
  • For submitting the complete record as a .csv file via CSV Upload, go here.

Option 2: Submission via the HD4DP 2.0 application

First, you need to access the HD4DP v2 web application, navigate to the study program and select the desired study project in the left dark blue menu. Then, fill out the complete registration form again manually with the correct values. Resubmit the completed registration form.

The previously submitted record will become irrelevant based on the business key.

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 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!
Bart.Servaes Thu, 07/11/2024 - 09:35

Registration statuses in HD4DP v2

Registration statuses in HD4DP v2

This article explains the different registration statuses in HD4DP v2.

Statuses are shown in Status column

You can select the columns you want to display via the menu Select visible columns located in the top-right corner:

Select the columns you want to display and click on Apply.

Description of the statuses:

Open: Registration is created and stored. It has not been submitted

Deleted: Registration has been deleted.

Submitted: Registration has been submitted and sent to Healthdata.be.

Bart.Servaes Tue, 04/04/2023 - 10:22

Reset password for HD4DP v2

Reset password for HD4DP v2

After having received your credentials to login to the HD4DP v2.0 application, you may consider resetting the password to one which is easier for you to remember.

Go to URL https://hd4dp.healthdata.be, select your organization and click on the Next button.

Fill in your e-mail address and the password you received. Click on the Log in button.

The main HD4DP v2.0 application screen appears. On the left you can see the menu of study programmes and study projects, on the right you have the section in which the relevant registrations will become available.

Click on the Reset password link button on the top right-hand corner of the screen.

Reset the password you have received by filling in the password of your preference. Repeat the new password in the verification field and click on the Submit button.

You will be redirected to the main screen, and the password will be automatically reset in the background. You don't need to log in again now.

When logging back in for a next registration session you will have to use your new password.

Jonas.VanBussel Fri, 06/07/2024 - 09:10

Technical manual of the application HD4DP v2

Technical manual of the application HD4DP v2 Bart.Servaes Wed, 11/06/2024 - 16:40

Technical user roles in HD4DP v2

Technical user roles in HD4DP v2

IT administrator: An IT administrator has the highest level of all roles and permissions and can:

  1. log in using Active Director;
  2. grant access to Local Study Lead, Local Study Associate and Local Study Support;
  3. select and access all projects;
  4. create, find, update, delete, send (to healthdata.be, MyCareNet and other destinations) and correct a record using the form.io component;
  5. create, update, send and correct a record using the API data collection;
  6. create, update, send and correct a record using CSV upload;
  7. create and send a MyCareNet record using MyCareNet XML;
  8. view all records for all projects;
  9. harvest all records for all projects from the local DWH using the PostgreSQL database.
Bart.Servaes Tue, 04/04/2023 - 10:23

HD4DP v2 Installation

HD4DP v2 Installation

HD4DP v2 Local is an application installed on the infrastructure of the Health Care Organisation participating in research projects facilitated by healthdata.be.

The installation of HD4DP v2 Local is executed by the DevOps team of healthdata.be.

Server Installation and Configuration

Installing and configuring the server requires the following actions:

The HD4DP v2 application is more modular and will support scaling up to meet the requirements of the various data collection projects we facilitate. It will offer several micro-services that will run concurrently on the same machine.

The server should therefore require more resources than the one currently hosting the HD4DP 1.0 application. Furthermore, the resources allocated should be increased.  It is therefore on the one hand imperative to use virtualization for the creation of the machine. On the other hand. It is also imperative to store files and make regular backups to a file server.

Below we take up our three categories of organizations sending data to healthdata.be and the resources we recommend allocating to their virtual machine:

  • "Small": Small data provider;
  • "Medium": Medium data provider;
  • "Large": Big data provider.
SmallMediumLarge
CPU (# of CPU/total cores)1/82/163/24
Memory16GB32GB48GB
Disk Space100GB400GB1TB
OSMinimum Ubuntu 22.04 LTS, preferable 24.04 LTSMinimum Ubuntu 22.04 LTS, preferable 24.04 LTSMinimum Ubuntu 22.04 LTS, preferable 24.04 LTS
VirtualizationYesYesYes
VM Backups by DPYesYesYes
Database backupsNot by default, network share needed (create ticket)Not by default, network share needed (create ticket)Not by default, network share needed (create ticket)
Specifications

Finally, we also offer the possibility for each hospital to have an integration server and a production server. Healthdata.be will deploy the new release of the application on the integration server. This will allow you to accept or decline the promotion of a new release of the HD4DP 2.0 application to the production server. This option is highly recommended, but not mandatory.

Therefore, could you answer the question: Do you want to first deploy HD4DP on an integration server? Yes/No. If Yes, Could you provide a server whose label used for specifications is "Small" (following the instructions in section 1 of this mail), that is:

  • Processors number: 1
  • Physical cores/Processor: 8
  • RAM memory: 16 Go
  • Disk space: 100 Go
  • Network Station Mount with Space for Backups
  • Operating System: Ubuntu LTS v22.04
  • Virtualization

Server installation timing

In order to establish the deployment schedule for the HD4DP 2.0 application within your organization, we would like to know when the server could be installed and configured. To this end, could you give us the 2 dates relating to the installation of the server:

  • Starting date;
  • Finalization date.

Based on these dates, an employee of healthdata.be will regularly monitor the operations linked to the installation of the server.

For any request for information on installing the HD4DP 2.0 server, please send an email to hd-architecture-20@sciensano.be.

Bart.Servaes Tue, 04/04/2023 - 10:23

HD4DP v2 Infrastructure instructions

HD4DP v2 Infrastructure instructions

Introduction

This document is written for IT staff / system engineers of data providers and therefore assumes technical knowledge. It acts as a guide through the on-boarding process of HD4DP v2 and covers installation of the server, user configuration, network configuration and remote access.

The order of steps in this document should be respected during execution.

If you need more informationor have any questions, feel free to contact us.

Overview

HD4DP v2 consists of a modular application stack, which allows Healthdata to seamlessly upgrade individual elements.

An HD4DP v2 deployment comprises of following components:

  • Form.io component
  • MongoDB
  • PostgreSQL
  • Nextgen Connect

As it is the case in HD4DP 1.0, an Encryption Module with a connection to the eHealthBox is still required for HD4DP v2 and must be provided by the data provider.

Network configuration

IP

The HD4DP server needs to be accessible via domain names in DNS, and must have a static IP in your private network.

DNS

The application stack of HD4DP v2 requires four domain names pointing to the IP of the locally installed HD4DP v2 server. Use the following names in your DNS:

  • nextgenconnect.hd4dp.<yourdomain.be>
  • hd4dp.<yourdomain.be>
  • metabase.hd4dp.<yourdomain.be>
  • admin.hd4dp.<yourdomain.be>

Firewall

The following connections should be possible in the firewall flow:

  • To and from (a) machine(s) in your IT department on port 22 for initial configuration and local support.
  • To and from the Encryption Module server. The protocol and ports depend on your local EM implementation. Contact your EM vendor if more information is necessary.
  • Reachable by your staff who uses HD4DP, on ports 80 and 443 for HTTP(s) traffic.
  • To and from the LDAP server (this is not mandatory if you are not using LDAP to authenticate) (port 389 by default)

The Healthdata proxy server is used as a gateway to the internet for the security of HD4DP servers. The configuration of this proxy server will be provided to you by Healthdata at a later date.

Server installation

To install the application stack of HD4DP v2, Healthdata requires a fresh installed operating system, specifically Ubuntu Server 22.04 LTS.

Please use these instructions even if you have previous experience with installing this operating system, as its configuration is specific for Healthdata.

These instructions assume that the network configuration described in the previous section is completed.

Instructions

HD4DP v2 requires a (virtual) machine running Ubuntu Server 22.04 LTS.

We assume knowledge of loading an .iso file onto a (virtual) machine. Healthdata can’t provide instructions for this, as the environment of your center is unknown. Should you have any trouble, however, please contact Healthdata support so that we can help out.

Please find the installation steps below.

Installation steps

  1. Download the .iso file from the link below.
    Download Ubuntu Server 22.04 LTS
  2. Create a new (virtual) machine with Linux Ubuntu 64 bit as the OS family
  3. When prompted, select the .iso file downloaded in step 1.
  4. After some time, you will be prompted to select a system language. Select English.
  5. “Keyboard configuration”
    Select your preferred keyboard layout and press enter
  6. “Network Connections”
    Highlight the network interface and press enter. Navigate as follows:
    Edit IPv4 -> Manual -> enter the network details -> save -> Done
  7. Proxy IP -> Leave default/empty.
  8. “Configure Ubuntu Archive Mirror” -> leave default
  9. “File system Setup” -> Use An Entire Disk
  10. Proceed until “Confirm destructive action” -> press continue. The installation process starts, this can take several minutes.
  11. In the meantime, create the user for Healthdata.
    username = healthdata,
    Password = choose a secure password and communicate it to Healthdata.
  12. Mark “Install OpenSSH server”. This will be used for remote access. “Import SSH Identity” -> no -> done
  13. “Featured Server Snaps” -> Select nothing and press Done.
  14. Wait until installation is finished.

Configuration steps

Connecting to the server

Log into the machine with the Healthdata user created in the previous section.

Instructions (from a Windows machine):

  1. Install the tool Putty and open the application.
  2. On the configuration screen, enter the following (replace cursive text with the appropriate values)
    • Host Name: healthdata@server_private_ip
    • Port: 22
    • Connection type: SSH
  3. Click Open. Enter the Healthdata password (you will not see text as you type, you can paste into putty by right-clicking in the terminal).
  4. You should now be logged in and see a prompt  “healthdata@server_name:~$”

Administrator account for internal use

An administrator account for internal use can be created on the HD4DP v2 server.

The configuration of remote access (described below) should not happen on this account, but on the Healthdata account.

The internal account can later be used to install and configure OS monitoring software and antivirus software by the internal IT team. For more information, see the section on Antivirus and Monitoring.

(Text with a gray background should be entered as a command in the terminal of the server)

Create the user:

            sudo adduser <username>

Add the user to the sudo group

            sudo usermod -aG sudo <username>

Installation and configuration of the software stack

Healthdata.be support will instruct you when to execute the next step, which is to enable remote access so that Healthdata can execute the software installation and configuration.

Backups

The configuration of the HD4DP v2 server is administered by Healthdata and does not require backups. This configuration will be based on the information shared on the infrastructure sheet. If no network drive information is shared with Healthdata, no backups of the databases will be foreseen.

HD4DP v2 regularly dumps its databases automatically to the /backup directory on the server. A network storage should be mounted at this location.

Please fill out the infrastructure sheet with the required credentials, domain name/url, protocol… to connect to the network drive. The connection will then be configured by Healthdata.

Patching and Updates

Healthdata configures HD4DP v2 servers to automatically receive recommended security updates. The choice for Ubuntu 22.04 is motivated by the long-term support for this version. Security flaws are rare in this distribution, and security updates are quick and often don’t require a system reboot.

If the IT department of your organization prefers to manage patches, this is possible but not encouraged. Please use the account for internal use created in Section Server installation for this purpose.

Antivirus and Monitoring

Most data providers will want to manage their own antivirus and OS monitoring on all machines in their network. Installation of such software on the HD4DP v2 server is allowed, but Healthdata should be informed about all extra software installed on the server. Additionally, Healthdata will not provide support for the installation of this software.

Contact information

https://support.healthdata.be

Email: support.healthdata@sciensano.be

Phone: +32 2 793 01 42 

Bart.Servaes Tue, 04/04/2023 - 10:23

HD4DP v2 Infrastructure Sheet

HD4DP v2 Infrastructure Sheet

The HD4DP v2 Infrastructure Sheet contains information that healthdata.be needs in order to start the installation of the HD4DP 2.0 Software at your organization.

Below you can find the description of the necessary information:

SERVER CONNECTION

Healthdata.be performs its installation and support tasks remotely (using VPN or remote port forwarding via SSH). Please provide the required credentials.

  • Type of connection (VPN / Remote port forwarding via SSH)
  • Link (IF VPN)
  • Username, token, other (if VPN)
  • Password (if VPN)³
  • Public SSH Key (if remote port forwarding)

³ For security reasons, we advise to communicate passwords to us either by phone, or via a link using a secret-sharing service such as onetimesecret.com.

SERVER MACHINE

  • Server Name
  • Internal IP-Address
  • Ram (in GB)
  • CPU (number of CPU's and number of cores)
  • Disk space (in GB)
  • Username: Healthdata
  • Password ³

³ For security reasons, we advise to communicate passwords to us either by phone, or via a link using a secret-sharing service such as onetimesecret.com.

ATTACHED DRIVE FOR BACKUPS

HD4DP 2.0 regularly performs data dumps for backup purposes. Please provide connection information to a network share volume.

  • Link / IP address
  • Path
  • Username
  • Password ³

³ For security reasons, we advise to communicate passwords to us either by phone, or via a link using a secret-sharing service such as onetimesecret.com.

USER MANAGEMENT

HD4DP can either connect to a LDAP server or use its own application database for performing user authentication and management. Please check the user management mechanism you want to use.

  • LDAP user management : Yes / No
  • Application user management : Yes / No

LDAP configuration (Optional)

If you chose ‘LDAP user management’ as user management mechanism, please provide the following information that allows us to connect to your LDAP system.

  • Connection URL
  • Username
  • Password³

³ For security reasons, we advise to communicate passwords to us either by phone, or via a link using a secret-sharing service such as onetimesecret.com.

SOFTWARE CONFIGURATION

Encryption Module interface

HD4DP communicates with the Encryption Module (EM) either using the file system interface or by calling a REST web service. Please choose which interface HD4DP should use for its communication with the Encryption Module.

  • REST web service
  • File system

REST web service interface

If you chose to communicate with the Encryption Module using a REST interface, please provide the web service URLs that should be used by HD4DP for its communication with EM.

  • "Outgoing flow URL: Example: http://host:8080/encryptionmodule/send"
  • "Incoming flow URL : Example: http://host:8080/encryptionmodule/receive"

File system interface

  • "Incoming directory: Directory where HD4DP checks for incoming files"
  • "Incoming directory: Directory where HD4DP writes outgoing files"
  • "Incoming directory: Directory to which HD4DP moves successfully processed files"
  • "Incoming directory: Directory to which HD4DP moves unsuccessfully processed files"
Bart.Servaes Tue, 04/04/2023 - 10:23

Requirements for the HD4DP installation

Requirements for the HD4DP installation

This documentation details the necessary adaptations to be performed in order to allow the necessary technical accesses and smooth operation of the different healthdata.be platforms and interfaces.

The file is available for download below.

Jonas.VanBussel Thu, 08/03/2023 - 10:43

S2S API data submission for the Epilabo registry

S2S API data submission for the Epilabo registry

General description of S2S API

  • Go here for a general description of the S2S API data submission service.

Training

  • Go here to watch the S2S API training organized by healthdata.be.

API endpoint description

  • Go here for an overview of API endpoints and the relevant information.

Data submission procedure in Architecture 2 using S2S API

1. Requirements at Data Provider's side

In order to be able to communicate with the healthdata.be S2S API, the IT services of the healthcare organizations must setup their systems as follows:

  • Ensure to have the credentials available for the endpoint/URL for which authorization is necessary. If this is not the case, please contact our service portalhttps://sciensano.service-now.com/sp.
  • Ensure to have the end-to-end API process in place in order to submit data registrations in a fully automated manner.
  • Ensure capability of submitted data retrieval in the local database.

2. Preparing the JSON file

  • To send data to healthdata.be by S2S API, the file must be in a .json file format.
  • Extract the requested data from the electronic patient files and/or other local databases.
  • Map the data according to the fields and formats as described in the DCD specifications of this section and the general code lists.
  • Go here for additional information on the codes and the formats used for the Author group, SSIN code, Status, "Date" - "Date:Time", Repeatable fields and Multiple choice.

Note: The example files below are only provided as a guideline and do not contain real life data.

Epilabo - Clinical Biology - Laboratory Test Results

  • Example

Note: Below documentation contains generic example screens with the sole purpose to demonstrate how the process looks like regardless of the registry.

3. Uploading the JSON file

  • The IT department of the Data Provider implements a data transmission system (e.g. Postman) to send the API queries by means of a json file. The correct endpoints for uploading of the json file can be found here.
  • The URL that needs to be entered after POST (selected method for uploading) should have a syntax similar to the one below:

POST {{baseURL}}/api/dcd/payload/submit?organization-id={organizationId}&dcd-id={dcdId}&dcd-version-id={dcdVersionId}&data-src-type={dataSrcType}

  • Whereby:
    • {organizationId} needs to be replaced by the id of your organization; go here for more information
    • {dcdId} needs to be replaced by a register-specific numerical value; go here for more information
    • <optional> {dcdVersionId} needs to be replaced by the intended version number; if not provided, the latest version of the dcd specifications is assumed; go here for more information
    • <optional> {dataSrcType} needs to be replaced by the data source type. Permitted values are API or CSV; go here for more information
    • a GET method URL should not contain /submit/ in the endpoint or path
    • multiple query parameters need to be connected by an ampersand (&) (see example above)
  • In the Authorization tab, select “Basic Auth” in the “Auth Type” drop-down list. Subsequently, fill out the API credentials in the username and password fields.
  • In Body tab, select the “raw” option from the top line and paste the content of the JSON file in the box.
  • Once the request settings are completed, press the Send button to submit the records.
  • After succesful submission of the data, the “Status: 202 Accepted” code will appear below the box where the data was pasted. The bottom box should return a message about the records uploaded or an error message if any.
  • A 401 Unauthorized message instead indicates missing or incorrect credentials. Request the correct credentials as described above in the Requirements at Data Provider's side.
  • A 400 Bad request might refer to incorrect syntax of the API query. Check the query parameters and ensure to connect multiple parameters with the ampersand (&) character.

4. Validating the JSON Upload

4.1 Validation of the S2S API Upload via the response:

Verify in the same way the request was sent, that the returned response is containing a valid Business key.

If a valid Business key has been provided, the registration upload via System 2 System API was succesful.

4.2 Validation of the S2S API via HD4DP 2.0:

Step 1: Open the HD4DP 2.0 application.

Step 2: Select the organization in the dropdown list and click on Volgende (Next).

Step 3: Fill in the username and password, that has been provided by your IT Department or Healthdata team, and click on Log in to access the HD4DP v2.0 application.

Step 4: Navigate in the menu on the left-hand side panel to the desired study program:

Step 5: Check that the uploaded registration(s) is/are displayed in the overview table:

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 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!
Bart.Servaes Wed, 10/30/2024 - 22:25

CSV Upload data submission for the Epilabo registry

CSV Upload data submission for the Epilabo registry

General description of CSV Upload

  • Go here for a general description of the data submission service via CSV Upload.

Training

  • Go here to watch the CSV Upload training organized by healthdata.be.

Data submission procedure in Architecture 2 using CSV Upload

1. Preparing the csv file

  • Extract the requested data from the electronic patient files and/or other local databases.
  • Map the data according to the fields and formats as described in the DCD specifications of this section and the general code lists.
  • Go here for additional information on the codes and the formats used for the Author group, NISS code, Status, "Date" - "Date:Time", Repeatable fields and Multiple choice.
  • Make sure the name of the csv test file(s) has the correct format as follows:
    HD_DCD_submcsv_HDBPnumber_HDBPabbreviation_versionnumber_versionreleasedate

Note: For Epilabo you can use the csv example file below, only containing the data for the required fields for Epilabo – Clinical Biology – Laboratory Test Results:

HD_Submcsv_HDBP0037_EPILABO_18112025

2. Uploading the csv file

Step 1: Open the sftp tool like WinSCP

Step 2: Get the credentials (Host name, Port number, User name and Password) from the IT department of the Data Provider, to log on to the sftp server located on the Data Provider side. In case the credenials are unavailable we advise you to request your credentials through our service portal at https://sciensano.service-now.com/sp via the Request something tab and subsequently the Request for Information box.

Step 3: Fill in the credentials into the Login screen and click on Login to be able to access the different upload folders:

Note: a warning might be given, just click on Update

In the CSV Upload folder structure that is displayed on the right-hand side panel, you will notice draftcsv folders and submcsv folders for the diverse HD business projects.

Historically, a directly submitted csv file would end up in the submitted folder (submcsv), whereas a csv file featuring ‘draft’ in the status field would have ended up in the draft folder (draftcsv). At this stage there is no real distinction between both folders, so you can save the csv file in either of them.

Attention: If you wish to create a draft to work on at a later stage, don’t forget to add ‘draft’ in the status column of the csv file.

Below documentation contains generic example screens with the sole purpose to demonstrate how the process looks like. In the subsequent screens the desired EPILABO registry (Laboratory Test Results) needs to be selected.

Step 4: Select the desired EPILABO folder and open it by double-clicking on it:

Step 5: Now go to the folder on the left-hand side panel where the csv file to be uploaded is located:

Step 6: Drag the csv file to be uploaded from the left-hand side panel into the folder on the right-hand side panel:

Step 7: Wait until the polling system of the CSV Uploader has picked up the CSV file and has processed it.
Once the csv file has been processed it will disappear from the folder, when the page is manually refreshed!

3. Validate csv upload

Once the csv file has been processed, 3 folders will be created (if they haven't been created already) in the DCD folder:

  • ARCHIVE (after a csv file has been processed, the original csv file will be saved in this folder)
  • RESULT (when the csv file is placed in this folder, it means that the csv file has been processed, a file will be created (or appended, if the file already existed) with the result of the upload of the csv file).
    All the errors that are described in this file are business related, which means that they are technically correct, but in violation with the business rules or contain wrong values for that field.
  • ERROR (when the csv file is placed in this folder, it means that a technical error has occurred like the csv file contained erroneous formatting. The csv file won't get processed and an error file will be created with the errors and reason why the csv file couldn't be processed)

3.1 Validation of the csv upload via sftp tool:

Step 1: Double-click on the ERROR folder to open it, click on the refresh button and verify that there is no error file present.

Step 2: Return to the DCD folder. Now double-click on the RESULT folder to open it, click on the refresh button and verify that the result file is present.

Step 3: Double-click on the result file to open it.

Step 4: If there are multiple records in the result file, scroll to the entry of the current csv upload by looking at the upload date (Started at dd/mm/yyyy hh:mm).
Verify the result file that the upload was successful by searching for the word SUCCESS and having a look at the Status. This Status must contain: Success;Success Count:1;Error Count:0

3.2 Validation of the csv upload via HD4DP 2.0:

Step 1: Open the HD4DP 2.0 web application.

Step 2: Select the organization in the dropdown list and click on Volgende (Next)

Step 3: Fill in the username and password, that has been provided by your IT Department or Healthdata team, and click on Log in to access the HD4DP v2.0 application.

Step 4: Navigate in the menu on the left-hand side panel to the desired study program:

Step 5: Check that the uploaded registration(s) is/are displayed in the overview table.

Bart.Servaes Tue, 11/18/2025 - 11:22

Architecture 2.5

Architecture 2.5 Bart.Servaes Sat, 01/06/2024 - 17:15

Uniformed naming convention

Uniformed naming convention

Change name: 

Create DCD formio naming structure using a general overall naming convention of healthdata.be projects.

Change Description:

The change is to refactor the formio DCD naming to have a structure as:

HDBPnumberHDBPabbreviationdcdname/abbreviationversionnumber

Where the abbreviation will be used as seen in the column “TX_PROJ_BUS_ABBREV” of the document below, that will be a reference to fill the MDM:

Example 1: 

So for the formio DCDs of the project “Mandatory registration of spine surgery” (full name) it would be something like:

HDBP0240_SPINE_1 and because there is only 1 dcd for the project we do not use a dcd name.

Example 2:
So for the formio DCDs of the project “Pneumology Endobronchial valve” (full name) it would be something like:

HDBP0231_ZEPHYR_ZEPHYR_REPLAC_1
HDBP0231_ZEPHYR_ZEPHYR_PRIM_IMPLT_1

Full example:

dcdname/abbreviation: will be the TX_REG_NAME of the DCD.

form titleform nameform pathcollection name
HDBP0240_SPINEhdbp0240Spine1hdbp0240spine1HDBP0240SPINE1
HDBP0231_ZEPHYR_ZEPHYR_PRIM_IMPLThdbp0231ZephyrZephyrPrimImplt1hdbp0231zephyrzephyrprimimplt1HDBP0231ZEPHYRZEPHYRPRIMIMPLT1

Bart.Servaes Fri, 01/26/2024 - 22:04

Sending code values instead of code IDs in S2S requests

Sending code values instead of code IDs in S2S requests

In the following example we will demonstrate sending code values instead of code IDs. We want, for instance, to send a patient's country and zip code information, more specifically for someone who lives in Brussels, Belgium:

Currently, in the case of fields containing code list elements with S2S submissions, we send the code ID in the body of the message, like so:

"CD_CNTRY_RES": "130349",
"CD_POSTCODE": "4525",

In CSV upload, however, we send the code value of the code object.

From the new Architecture 2.5 onward, we will do so too for S2S submissions using the API. So, for the example above, the new way of sending the same values will be as follows:

"CD_CNTRY_RES": "BE", "CD_POSTCODE": "1000",

The image below shows the relationship between these fields in the database, in the case of the country:

And for the postal code:

The purpose of this change is to stop sending the code IDs in System-to-System and start sending the code values, hence to be consistent with the CSV upload method. The performance improvements that go along with this result from the fact that the service that returns the code value for a given ID is done through a single request per submission to the MDM, thus saving a lot of time in calls to get these values.

Since the code value is not unique, we need to get the codelist ID of an element, given its key, from a given DCD version ID. This could be summarized for this example as follows:

The key CD_CNTRY_RES on DCD version ID 55 (BSACC Police And Public Prosecutor) has the codelist id 347.
The key CD_POSTCODE on DCD version ID 55 (BSACC Police And Public Prosecutor) has the codelist id 12.

Code Lists and Code Values are agreed upon by IAT and the Researchers. These are sent to DC by IAT via the DCD specifications. A Code ID is the identification of a Code Value in MDM. So how is the translation done?

In the case of sending code IDs, the user calls our services to retrieve the code IDs through requests to our API. In these requests, the user always receives the complete code object, containing not only the code ID, but also the code value. Let’s have a look at an example for the country code (code list 347):

The image shows how we were sending the code ID 130349 in System-to-System and how we can send the code value “BE” in Architecture 2.5, the same way it was already done using the CSV Uploader.

In terms of code, if we were already calling the services to get the code ID, the only thing that is necessary is changing the returned value from CodeID to CodeValue from the same Code object that is returned.

FROM:

mappedCode = codeFieldService.getFieldCode(field.getFieldId(), codeContent).codeId();

TO: 

mappedCode = codeFieldService.getFieldCode(field.getFieldId(), codeContent).codeValue();

That’s the only change needed in the mapping. All the rest remains exactly the same.

For more information, please check our documentation at 1. End-to-End process to submit DCD registrations | docs.healthdata.be

Architecture 2.0 and Architecture 2.5 proxies

Below you find an example of how the service to get a project-result is called in both proxies:

Architecture 2.0

https://hd4dp.acceptance.healthdata.be/proxy/api/installation/project-result?organization-id=120

[{"projectId":4,"dcdId":9,"dcdVersionId":9,"version":1,"formioName":"hdbp0231ZephyrZephyrPrimImplt1"}, {"projectId":4,"dcdId":10,"dcdVersionId":10,"version":1,"formioName":"hdbp0231ZephyrZephyrReplac1"}, {"projectId":4,"dcdId":11,"dcdVersionId":11,"version":1,"formioName":"hdbp0231ZephyrZephyrFllwup1"}, {"projectId":5,"dcdId":12,"dcdVersionId":12,"version":3,"formioName":"hdbp0062BelPstSpineTangoIntake1"}, {"projectId":5,"dcdId":13,"dcdVersionId":13,"version":3,"formioName":"hdbp0062BelPstSpineTangoConservativeTherapy1"}, {"projectId":5,"dcdId":14,"dcdVersionId":14,"version":3,"formioName":"hdbp0062BelPstSpineTangoPatientQuestionnaire1"}, {"projectId":5,"dcdId":15,"dcdVersionId":15,"version":3,"formioName":"hdbp0062BelPstSpineTangoSurgery1"}, {"projectId":6,"dcdId":16,"dcdVersionId":16,"version":1,"formioName":"hdbp0000TestTestDcd011"}, {"projectId":6,"dcdId":17,"dcdVersionId":17,"version":1,"formioName":"hdbp0000TestTestDcd021"}, {"projectId":7,"dcdId":18,"dcdVersionId":18,"version":1,"formioName":"hdbp0386OrthoprideHipOpHipPrimImplt1"}, {"projectId":7,"dcdId":19,"dcdVersionId":19,"version":1,"formioName":"hdbp0386OrthoprideHipOpHipRevis1"}, {"projectId":7,"dcdId":20,"dcdVersionId":20,"version":1,"formioName":"hdbp0386OrthoprideHipOpHipResec1"}, {"projectId":8,"dcdId":21,"dcdVersionId":21,"version":1,"formioName":"hdbp0288OrthoprideKneeOpKneePrimImplt1"}, {"projectId":8,"dcdId":22,"dcdVersionId":22,"version":1,"formioName":"hdbp0288OrthoprideKneeOpKneeRevis1"}, {"projectId":8,"dcdId":23,"dcdVersionId":23,"version":1,"formioName":"hdbp0288OrthoprideKneeOpKneeResec1"}, {"projectId":9,"dcdId":24,"dcdVersionId":24,"version":1,"formioName":"hdbp0048OrthoprideMegaOpMpPrimImplt1"}, {"projectId":9,"dcdId":25,"dcdVersionId":25,"version":1,"formioName":"hdbp0048OrthoprideMegaOpMpRevis1"}, {"projectId":9,"dcdId":26,"dcdVersionId":26,"version":1,"formioName":"hdbp0048OrthoprideMegaOpMpResec1"}, {"projectId":1,"dcdId":1,"dcdVersionId":30,"version":3,"formioName":"hdbp0025HhNsihHhPre3"}, {"projectId":1,"dcdId":2,"dcdVersionId":31,"version":3,"formioName":"hdbp0025HhNsihHhIo3"}, {"projectId":1,"dcdId":3,"dcdVersionId":32,"version":3,"formioName":"hdbp0025HhNsihHhPost3"}, {"projectId":10,"dcdId":27,"dcdVersionId":33,"version":1,"formioName":"hdbp0245TaviTaviImplt1"}, {"projectId":10,"dcdId":28,"dcdVersionId":34,"version":1,"formioName":"hdbp0245TaviTaviFllwup1"}, {"projectId":11,"dcdId":29,"dcdVersionId":35,"version":1,"formioName":"hdbp0000CorrectionForm1"}, {"projectId":13,"dcdId":34,"dcdVersionId":40,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerPrimoImplantation2"}, {"projectId":13,"dcdId":35,"dcdVersionId":41,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerAjoutRemplacementElectrode2"}, {"projectId":13,"dcdId":36,"dcdVersionId":42,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerRemplacement2"}, {"projectId":13,"dcdId":37,"dcdVersionId":43,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerExplantation2"}, {"projectId":13,"dcdId":38,"dcdVersionId":44,"version":2,"formioName":"hdbp0016PacemakerQermidPacemakerSuivi2"}, {"projectId":14,"dcdId":39,"dcdVersionId":45,"version":3,"formioName":"hdbp0019Bewsd3"}, {"projectId":15,"dcdId":40,"dcdVersionId":46,"version":2,"formioName":"hdbp0012AngioHospitalisatie2"}, {"projectId":15,"dcdId":41,"dcdVersionId":47,"version":2,"formioName":"hdbp0012AngioHospitalisatieMetPci2"}, {"projectId":15,"dcdId":42,"dcdVersionId":48,"version":2,"formioName":"hdbp0012AngioHospitalisatieMetFfr2"}, {"projectId":15,"dcdId":43,"dcdVersionId":49,"version":2,"formioName":"hdbp0012AngioHospitalisatieMetFfrEnPci2"}, {"projectId":15,"dcdId":44,"dcdVersionId":50,"version":2,"formioName":"hdbp0012AngioFollowUpNaPci2"}, {"projectId":16,"dcdId":45,"dcdVersionId":51,"version":1,"formioName":"hdbp0240Spine1"}, {"projectId":17,"dcdId":46,"dcdVersionId":52,"version":4,"formioName":"hdbp0008Crrd4"}, {"projectId":19,"dcdId":48,"dcdVersionId":54,"version":1,"formioName":"hdbp0242BsaccMeBsaccReprt1"}, {"projectId":19,"dcdId":49,"dcdVersionId":55,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuPolce1"}, {"projectId":19,"dcdId":50,"dcdVersionId":56,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuCont1"}, {"projectId":19,"dcdId":51,"dcdVersionId":57,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuReferral1"}, {"projectId":19,"dcdId":52,"dcdVersionId":58,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuMed1"}, {"projectId":19,"dcdId":53,"dcdVersionId":59,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuPsychc1"}, {"projectId":20,"dcdId":54,"dcdVersionId":60,"version":9,"formioName":"hdbp0001Bcfr9"}, {"projectId":21,"dcdId":55,"dcdVersionId":61,"version":3,"formioName":"hdbp0078Pitter3"}, {"projectId":22,"dcdId":56,"dcdVersionId":62,"version":3,"formioName":"hdbp0051Becpr3"}, {"projectId":23,"dcdId":57,"dcdVersionId":63,"version":1,"formioName":"hdbp0037Epilabo1"}, {"projectId":24,"dcdId":58,"dcdVersionId":64,"version":1,"formioName":"hdbp0244RProfildRprofildTreat1"}, {"projectId":24,"dcdId":59,"dcdVersionId":65,"version":1,"formioName":"hdbp0244RProfildRprofildRenewal1"}, {"projectId":25,"dcdId":60,"dcdVersionId":66,"version":1,"formioName":"hdbp0274HartDefibDefibPrimImplt1"}, {"projectId":26,"dcdId":61,"dcdVersionId":67,"version":1,"formioName":"hdbp0056MvoMvoImp1"}, {"projectId":26,"dcdId":62,"dcdVersionId":68,"version":1,"formioName":"hdbp0056MvoMvoFu1"}, {"projectId":25,"dcdId":63,"dcdVersionId":69,"version":1,"formioName":"hdbp0274HartDefibDefibExpl1"}, {"projectId":25,"dcdId":64,"dcdVersionId":70,"version":1,"formioName":"hdbp0274HartDefibDefibRepl1"}, {"projectId":25,"dcdId":65,"dcdVersionId":71,"version":1,"formioName":"hdbp0274HartDefibDefibElect1"}, {"projectId":27,"dcdId":67,"dcdVersionId":72,"version":1,"formioName":"hdbp0000DvrForm1"}]

Architecture 2.5

https://hd4dp.acceptance.healthdata.be/proxy/api/installation/project-result?organization-id=120&dcd-id=49

[{"projectId":19,"dcdId":49,"dcdVersionId":55,"version":1,"formioName":"hdbp0242BsaccMeBsaccFuPolce1"}]

As we can see, using proxy (Architecture 2.0) we have all projects from organization 120, while proxy (Architecture 2.5) returns only one element in its response. This is because the DCD filter in proxy (Architecture 2.5) is done in the database more efficiently, while in the proxy Architecture 2.0 the same filter was done in the code after the service call.
So, the filter is not used in the first call and if Architecture 2.0 calls the same service in Architecture 2.5 without the filter (https://hd4dp.acceptance.healthdata.be/proxy/api/installation/project-result?organization-id=120) it will get exactly the same result.

Architecture 2.0 and Architecture 2.5 proxies tests

CSV Uploader

For the CSV Upload, nothing has changed. So the same inputs are valid for both architectures. Here are the example of some successful tests:

System-To-System

For S2S, as already mentioned, the only difference is that Architecture 2.0 sends Code IDs while Architecture 2.5 sends Code Values. Here are the same tests in both architectures:

Proxy (Architecture 2.0):

Proxy (Architecture 2.5):

As we can see, we have the same request, where the first sends Code IDs and the second sends Code Values; both return a successful response.

Front-end

In the front-end (GUI) everything is received normally as the same request was sent twice. After all, S2S will always send the same request with Code IDs to FormIO.

Data Warehouse

Once again, all the information arrives seamlessly, due to the fact that the FormIO validation already happened in the previous step:

First call (Architecture 2.0):

Second call (Architecture 2.5):

Bart.Servaes Fri, 06/07/2024 - 09:14

MDM Mapping of billing codes for MyCareNet

MDM Mapping of billing codes for MyCareNet

Note: The below described mapping solution only applies to the study project of PACEMAKER.

In Architecture 2.0 the DCD fields related to billing codes for MyCareNet do not contain the billing code as their code value, instead this is just a numerical value, and the code value is only displayed in the label, e.g.:

When then sending key values to localdwh and dwh, the submission will contain a key value as follows:

When generating a message for MyCareNet, however, this same numerical value is used in the message payload. Keeping these numerical values, will generate MyCareNet messages with a incorrect billingcode, in this case <BillingCode>2</BillingCode>.

In Architecture 2.5 an MDM Mapping of billing codes for MyCarenet has been implemented. The value for the key will no longer be a numerical value such as 1,2,3… but an actual billing code. To facilitate this requirement, a new column has been introduced in the MDM to associate the billing code with the correct 13 character value, such as "182932-182943". This billing code will be accepted by MyCareNet.

Bart.Servaes Sat, 01/06/2024 - 17:15

Databases

Databases Bart.Servaes Fri, 06/07/2024 - 09:15

Retrieve EPILABO data from the local database of HD4DP v2

Retrieve EPILABO data from the local database of HD4DP v2

Warning

The person with the login for the local database of "HD4DP v2 local" has access to all the data stored in the database. This means that the personal data of the patients will be VISIBLE to that user.

Requirements

URL Local DWH Database: postgresql://<server_ip>:5432/localdwh. If this is not the case, the IT department hosting HD4DP v2.0 needs to open the port and allow traffic to this port.

URL NIPPIN Database: postgresql://<server_ip>:5432/nippin

Username/Password: The service desk of healthdata.be will forward, via a secure link, the username and password.

Client: Download one of the clients that support PostgreSQL . A list is available here.

IP network/subnet: Provide us with the IP network/subnet from where you will contact the database. The database only accepts incoming traffic of known IP networks/subnets. example: 0.0.0.0/32

Granted privileges

databaseuserprivileges
localdwhdpuserCONNECT/local_dwhmessage:SELECT/local_dwhmessage_key_value:SELECT/local_dwhmessage_key_value_plus:SELECT
nippindpuserCONNECT/nippin_message:SELECT/nippin_cleanup:SELECT
Privileges table

"data_collection_name" in local database

  • "data_collection_name" =

Query examples

With the "data_collection_name" and the following information, you will be able to link multiple tables with each other.

  • local_dwhmessage_key_value: Key value table with more information about the registration
  • msg_document_id: document id of your message located in local_dwhmessage table
  • document_id: document id of your registration
  • local_dwhmessage: table where you can find all the registrations
  • local_dwhmessage_key_value_plus: Extra table to define attribute type and value of a key value
  • key_value_id: Key value id linked to the id of the local_dwh_message_key_value
  • local_dwhmessage_key_value:

"local_dwhmessage_key_value" column "msg_document_id" refer to the "document_id" of "local_dwhmessage".

"local_dwhmessage_key_value_plus" column "key_value_id" refer to the id of "local_dwhmessage_key_value".

Query 1: Get all registrations from the last 15 days.

SELECT * from local_dwhmessage WHERE data_collection_name = 'add data_collection_name' and created_on > current_date - interval '15' day;

Query 2: Get all registrations and key value.

SELECT * from local_dwhmessage as ldm left join local_dwhmessage_key_value as ldmkv on ldmkv.msg_document_id = ldm.document_id WHERE ldm.data_collection_name = 'add data_collection_name';

Query 3: Get all registrations, key value and key value plus from.

SELECT * from local_dwhmessage as ldm left join local_dwhmessage_key_value as ldmkv on ldmkv.msg_document_id = ldm.document_id left join local_dwhmessage_key_value_plus as ldmkvp on ldmkvp.key_value_id = ldmkv.id WHERE ldm.data_collection_name = 'add data_collection_name';

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!
Bart.Servaes Fri, 06/07/2024 - 09:16

HD4DP v2 Online Acceptance Environment

HD4DP v2 Online Acceptance Environment

Introduction

To support the development and validation of data transfers using S2S API or CSV upload, a central Online Acceptance (OACC) environment has been made available for the IT services or IT partners of data providers. This environment is meant to replace the locally installed acceptance environments at the side of the data providers. In the OACC Environment you can test and validate the three types of data transfer:

Visit the S2S API and CSV Upload documentation for a general description of the respective data transfer methods.

In order to keep the OACC environment light, it is rebuilt once a week (each Saturday). The data are stored locally and will not be sent to healthdata.be infrastructure. The testing is limited to the upload to the HD4DP v2 application.

Additional field information about the codes and the formats used for the Author group, NISS code, status, Country and Postal Code, "Date" - "Date:Time", Repeatable fields and Multiple choice fields is to be found here.

Application URLs and port

Credentials for accessing the Online Acceptance (OACC) environment

Upon requesting credentials to access the OACC environment, you will receive 3 different types of credentials:
⦁ credentials to log in to the front end of the online acceptance environment
⦁ credentials to use the API (-> authorization tab in Postman)
⦁ credentials for the SFTP server you use to test the CSV Upload

If your organization is not available for selection in the drop-down list, we advise you to request your credentials through our service portal at https://sciensano.service-now.com/sp via the Request something tab and subsequently the Request for Information box.

The OACC environment can be found on https://hd4dp.acceptance.healthdata.be, which is a publically accessible URL.

On the homepage you are requested to select your organization from the drop-down list in order to proceed.

Log in with the credentials you have received upon request. The username is test@sciensano.be for all users.

Once logged in, the layout looks very familiar: to the left you will find the navigation panel with all running projects . Note that the list of projects featuring in our Online Acceptance Environment is not filtered out for the organization you have selected.

The data transfer methods

As mentioned above, the Online Acceptance Environment enables the testing of the uploads for the following three types of data transfer. They are described below according to the timeline of developement:

Manual input in the study form

This data transfer method is the form entry, carried out manually. For this you can use a common browser such as Google Chrome. This method can also be used to validate data sent via S2S API or CSV Upload.

Data transfer via an SFTP client

The csv upload is the second type of data transfer. The data are transferred to an SFTP server and subsequently picked up by the healthdata.be system. This transfer method requires the use of an SFTP client, such as WinSCP (freely available).

The Login window will look as follows:

Herein, you enter Host name (sftp.acceptance.healthdata.be) and Port number (2220).

Credentials for the SFTP folder are shared together with the Front-end and API credentials as described in the section “Navigate to and access the Online Acceptance Environment”.

When logging in to WinSCP, you will need to navigate to the correct csv folder : csv/<project>/<dcd>. Here you need to drag and drop the csv you want to upload from the left panel to the right panel. The CSV file will now be picked up by the polling system of the CSV Uploader, which checks for new CSV files every minute.

The folders Archive and Result will only be created after the first CSV file has been uploaded for testing.

The Result folder shows a log file containing CSV Upload reports. The status Error Count shows technical errors such as incorrect name, code …

CSV files that were uploaded in Architecure 1 can be reused in Architecture 2. Prerequisite for this is the addition of necessary fields that are typical for Architecture 2, e.g.:

  • Author Group (TX_AUTHOR_GR) with the value "Test group"
  • Author (TX_AUTHOR) with the value "test@sciensano.be"
  • Coauthor (TX_COAUTHOR) with the value "test@sciensano.be"

To further facilitate the process of reusing CSV files a mapping table with old and new CSV names is provided.

Next to adding fields, you can also leave out fields, which is indicated in the log file reports as a warning.

Once again the download process can be checked in the study forms on the front-end interface. You want to refresh the window to update to the newest status.

Data transfer via an API platform

The data are extracted directly from the EPD systems and sent to HD4DP v2.0 local using S2S API before they are sent to healthdata.be. This third data transfer method requires the use of an API development platform, such as Postman (freely available).

The endpoint (URL) to send your payload to for testing is

https://hd4dp.acceptance.healthdata.be/proxy/api/dcd/payload/submit

This endpoint needs to be completed with some parameters, such as the ID of an organization, the ID of a dcd, the version number:

https://hd4dp.acceptance.healthdata.be/proxy/api/dcd/payload/submit?organization-id=6&dcd-id=18&Version=1

Click on the Send button to post the payload. A succesful submission is indicated with the status message “202 Accepted”. This can also be checked visually in the front end of the Online Acceptance Environment.

The field Data source in the top selection bar indicates whether the data were transferred via S2S API, CSV Upload or manually with HD4DP.

In the production environment, records that are sent via the API platform, go directly to the healthdata.be infrastructure. These records will receive the status “Submitted” in the Progress field.

Next to posting payloads (POST) you can also retrieve information (GET). Examples of such "calls":

  • The call https://hd4dp.acceptance.healthdata.be/proxy/api/organization (see below) will return an organization id:
  • The call https://hd4dp.acceptance.healthdata.be/proxy/api/dcd/menu/structure?organization-id=6 (see below) will return the menu structure with all projects your organization is registered for.

Go here for a description of the API data transfer method. For additional detailed information about the codes and the formats used for the Author group, NISS code, status, Postal Code, "Date" - "Date:Time", repeatable fields and multiple choice fields please go here.

Bart.Servaes Tue, 10/22/2024 - 10:32

Requesting access

Requesting access

The credentials for access to the online acceptance environment can be requested by sending a mail to support.healthdata@sciensano.be.

More information on how to create an incident in the service portal is available on https://docs.healthdata.be/documentation/hd4dp-v2-health-data-data-providers/how-report-incident

You will receive 3 types of credentials:

  • Credentials for the HD4DP2 web form application.
  • Credentials for the API data transfer.
  • Credentials for the SFTP server to upload CSV files.
Bart.Servaes Fri, 06/07/2024 - 09:17

How to report an incident

How to report an incident

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.

This image has an empty alt attribute

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

This image has an empty alt attribute
Adelaide.DAmore Fri, 06/07/2024 - 09:18

The EPILABO Dataflow description

The EPILABO Dataflow description

Please find below the schematic overview of the Epilabo data collection within the be.Prepared architecture. The architecture components and data flows in red are not used by the Epilabo data collection. The be.Prepared architecture combined with the Epilabo data collection allows for scalability in terms of pandemic preparedness and for support of the reporting systems of mandatory notifiable diseases managed by the federated health authorities.

The Epilabo data collection makes use of the following components:

Component Ref.Component nameComponent Description
C1HCO (LIMS)Data provider (DP) Healthcare organisation (HCO)/Laboratory Information (Management) System (LIMS).
C2HD4DP v2Full Health Data 4 Data Providers version 2 (HD4DP v2) Front end installation at the DP side.
C4be.Prepared ODSbe.Prepared Operational Data Store.
C5HD-DWHHealthData Data WareHouse.
C7Web ServiceWeb Service for federated health authorities
eHealtheHealth TTPPseudonymization of data via eHealth as Trusted Third Party

The Epilabo data collection uses the following flows:

Flow Ref.Flow nameFlow Description
F2Transfer of Epilabo data to HD4DP v2.0Epilabo data is transferred from the HCO by the use of Data Collection Definitions (DCDs). Two DCDs are in use: CB_MO_NOM – the DCD used for the nominative dataflow for test results from patients residing in the Walloon / Brussels Capital region / German speaking community; data will be transmitted to the federated health authorities (AVIQ and Vivalis) to support the reporting systems of mandatory notifiable infectious diseases; CB_MO_PSEUD – the DCD used for the pseudonomized dataflow for test results from patients residing in Flanders.
F4Transfer to be.Prepared ODSTransfer of complete data of CB_MO_NOM and business data of CB_MO_PSEUD to be.Prepared ODS
F13Pseudonymization via eHealthTransfer of subset of CB_MO_PSEUD to eHealth for pseudonymization of identifiers
F6Transfer to be.Prepared ODSTransfer of complete data of CB_MO_NOM and business data of CB_MO_PSEUD to be.Prepared ODS
F7Pseudonymization via eHealthTransfer of subset of CB_MO_NOM to eHealth for pseudonymization of identifiers
F8Transfer to HD-DWHTransfer of pseudonymized subset of CB_MO_NOM and of CB_MO_PSEUD to HD-DWH
F15Transfer to Web ServiceTransfer of CB_MO_NOM data to Web Service for federated health authorities (AViQ and Vivalis)
F12Transfer to HD-DWHTransfer of business data of CB_MO_NOM and of CB_MO_PSEUD to HD-DWH
F14Feedback loop HD-DWH/be.Prepared ODSFeedback loop between HD-DWH and be.Prepared ODS for data load confirmation

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!
Bart.Servaes Wed, 04/30/2025 - 15:05

Support service of healthdata.be

Support service of healthdata.be

The Service Desk of healthdata.be (Sciensano) helps users of our applications and services and deals with requests and incidents.

The Service Desk focuses on those services run by our IT Services (HD4DP, HD4RES, healthstat.be,...) and helps you with accounts and passwords. For questions about the content and objective(s) of the projects, we kindly refer users to the managing research organizations.

For most efficient processing of your request, we advise you to use our service portal: Jira Service management (JSM) portal.

Please find below our support window hours:

Bart.Servaes Fri, 06/07/2024 - 09:19

Create a Support ticket

Create a Support ticket

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.

This image has an empty alt attribute

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

This image has an empty alt attribute
Bart.Servaes Tue, 12/02/2025 - 15:21

Suggest improvement

Suggest improvement

To suggest improvement about the healthdata.be platform, you first need to log in to 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.

If you have questions, remarks or if you would like to submit a complaint, you can do so by clicking on the "Suggest improvement" button on the main page of the Jira Service Management portal.

This image has an empty alt attribute

On this page you need to fill in all the mandatory fields and click on "Send".

This image has an empty alt attribute
Jonas.VanBussel Tue, 12/02/2025 - 15:21

Email security policy

Email security policy

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:

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.

Jonas.VanBussel Fri, 08/04/2023 - 09:22

Release notes

Release notes

September 8th, 2023

Version 1.0.5

  • Addition of json test files to be used in upcoming Architecture 2.5
Bart.Servaes Wed, 12/18/2024 - 19:10