Belgian HIV Sequence Registry
Belgian HIV Sequence RegistryWelcome to the technical documentation pages for the project "Belgian HIV Sequence Registry (HIV_Sequence)", 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:
- General project information
- The data collection
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!General HIV_Sequence project information
General HIV_Sequence project informationProject name
HIV-AIDS Sequence Registry
Project abbreviation
HIV_Sequence
Project code
HDBP0263
Primary organization that oversees implementation of project
- Sciensano
Partner organization participating in project
- Not available
Organization that commissioned this project
- National Institute for Health and Disability Insurance (RIZIV-INAMI)
Organization providing monetary or material support
- National Institute for Health and Disability Insurance (RIZIV-INAMI)
Short project description
The service Epidemiology of Infectious Diseases of Sciensano collects pseudonymised personal data in order to monitor the number of diagnoses and follow-up of HIV patients. The registration of the nucleotide sequence is done by the AIDS Reference Laboratories and is necessary for the epidemiological analysis of antiretroviral drug resistance in relation to the characteristics of HIV-positive individuals. The objectives are to improve the understanding of epidemic dynamics to inform tailored health policies & actions. In the context of surveillance of baseline resistance: better understand individuals’ characteristics related to resistance (transmitted ART resistance). In the context of surveillance of other resistance patterns: better understand individuals’ characteristics and care trajectories related to resistance (acquired ART resistance).
The HIV_Sequence data collection
The HIV_Sequence data collectionOrganizations and/or individuals that provide data
| 81170489 | INSTITUUT TROPISCHE GENEESKUNDE - KLINISCH REFERENTIELABORATORIUM |
| 71014391 | UNIVERSITAIR ZIEKENHUIS BRUSSEL |
| 71032209 | UNIVERSITAIRE ZIEKENHUIZEN K.U.L. |
| 71040622 | HOPITAL ERASME (ULB) |
| 71007661 | CENTRE HOSPITALIER UNIV. ST.-PIERRE |
| 71070712 | CENTRE HOSPITALIER UNIVERSITAIRE DE LIEGE - SART TILMAN |
| 0248015142 | UNIVERSITEIT GENT |
| 0419052272 | UNIVERSITÉ CATHOLIQUE DE LOUVAIN |
Start date of the data collection
19/5/2025
End date of the data collection
Ongoing
Periodicity of the data collection
Continuous
The HIV_Sequence Data Collection Definition (HDBP0263)
The HIV_Sequence Data Collection Definition (HDBP0263)In the files below you can find the Data Collection Definition (DCD) specifications of the registry HIV_Sequence. It is a detailed description of the content of the DCD's with field names, formats, values, validation rules, help texts, error messages, translations... These specifications were used to build the forms and csv files for this project, which you also can find in this project manual.
- A metadata file containing the HIV sequence analysis information
2. The CSV file with the nucleotides should be a file containing only three columns called filename, recordname and genetic_sequence.
Records between both files are linked based on the fields 'File name' (called TX_ATT in the metadata file and called filename in the CSV file with nucleotides) and 'Record name' (called TX_ATT_RECRD in the metadata file and called recordname in the CSV file with nucleotides). These fields must follow the following nomenclature convention and are automatically generated if you use the RShiny application which was developed to help you with the data preparation (see https://collaboration.sciensano.be/sites/E1989/).
File name: This field is used as the first key for linkage between the data sent through HD4DP1 (patient & sample data) and SFTP (nucleotide sequences data). This field must contain the same value for both uploaded records to allow the 1 to many link. Please use this convention: ARL_yyyymmddHHMMSS (name of ARL and date-time stamp of the file, e.g. HSP_20240827092014). The name of the csv file with nucleotide sequences sent through SFTP must have this value in order to be linked with the record uploaded via HD4DP1 (patient & sample data), e.g. HSP_20240827092014.csv.
Record name: This field is used as the second key for linkage between the data sent through HD4DP1 (patient & sample data) and SFTP (nucleotide sequences data). This field must contain the same unique value for both uploaded records to allow the 1 to 1 link. Please use this convention: ARL_yyyymmddHHMMSS_xxxxx (name of ARL, date-time stamp of the file and a unique 5-digit number, e.g. HSP_20240827092014_00001).
This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create a support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!The HIV_Sequence Dataflow Description
The HIV_Sequence Dataflow DescriptionBelow we describe (high level) the HIV_Sequence dataflow between the data provider and the healthdata.be platform.
(source: DPD 01/2025)
For the registry “HIV sequence”, the basic architecture 1.0 of healthdata.be will be used as shown in figure 1.
The data of the laboratory will be entered in HD4DP1. Pseudonymization will take place at eHealth.
Figure 1: Data flow used for HIV Sequence registry
HD4DP v1
HD4DP v1A comprehensive user manual, for both participating healthcare organizations and their IT service providers, is available on this HD documentation portal: https://docs.healthdata.be/hd4dp-v1.
General description of the application HD4DP v1
General description of the application HD4DP v1HD4DP v1 is a local application developed by healthdata.be (Sciensano) and installed on the IT infrastructure of your organization or on the one of your partner organization. The application allows you to extract data from the primary system and map that data into one or more data collection projects.
The local HD4DP v1 application is accessible via a web browser, such as Internet Explorer or Chrome. The link is specific in each organization based on the server on which the application is running.
Fields that cannot be completed with the data from the primary systems, can be answered manually in (‘prefilled’) electronic forms after the CSV upload.
Once the registrations are complete, the data can be transferred towards the central data platform healthdata.be. For this transfer, HD4DP v1 connects with the ehealth messaging software of the data provider.
The access to the HD4DP v1 application is described here.
User manual of the application HD4DP v1
User manual of the application HD4DP v1A comprehensive user manual, for both participating healthcare organizations and their IT service providers, is available on this HD documentation portal: https://docs.healthdata.be/hd4dp-v1.
Request account for HD4DP v1
Request account for HD4DP v1To access the HD4DP v1 application, you need an account, a username and a password. If you do not have an account, you can request one by following the steps below. If you have an account, follow the instructions under “Sign In” at the end of this page.
- Open the link for the HD4DP v1 application. You will see the screen below.
Please contact your IT department to obtain the link of the HD4DP v1 application on the server of your organization. In case you could not be further helped, you can contact healthdata.be at support.healthdata@sciensano.be to get the link. The link is specific in every organization based on the server on which the HD4DP application is running.
- Click on the Request account link on the login page.
- Fill out the request form:
- Enter a username, first name, last name and e-mail address
- Select the organization and data collection(s)
- Fill in the Requester e-mail field if a person requests an account for a third person
- Submit the request using the Request button
- Confirmation e-mails are sent to the person for whom the account was requested as well as the requester, if the field "Requester e-mail" was filled.
- The approval or rejection for the user account is confirmed by mail. Depending on your organization, this could take a few hours.
- This action will be done by an HD4DP v1 administrator in your organization
- The confirmation mail will include all the necessary information to log in
Sign in
Logging in to the HD4DP v1 application is done in 3 steps:
- Enter your username and password in the appropriate fields
- Select the correct organization
- Click on "Log in"
Create a registration in HD4DP v1
Create a registration in HD4DP v1The Registrations tab shows the user the available registries. A user can start collecting data from this view.
Creating and submitting a registration consists of 4 steps:
- Select the registry for which you want to create a registration.
(The documentation below includes generic sample screens designed solely to illustrate what the process entails, irrespective of the registry involved.)
- Click on "New registration" button.
- Fill in the registration form and save or submit the registration with the buttons below.
- Save the registration temporarily if needed. The status of the record will be "Open" for saved registrations.
- Submit the registration if no validation errors present. The status of the registration will change to "Sending".
- When the record has been processed, the status will change to "Submitted".
As soon as a registration is sent, the "status confirmation" column will show "Pending".
- It shows "OK" once the registration has arrived, and "NOK" if the registration did not arrive within 48 hours. If the status is "NOK", the software will automatically try to resend the registration up to 10 days after the initial submission.
- For the statuses "Sending","Corrections needed" and "Approved" the status confirmation will be empty because the registration has not yet been submitted.
- A registration can be "Reopened" if needed as long as the status of the registration is "Submitted".
Change a registration in HD4DP v1
Change a registration in HD4DP v1A user can modify and complete a registration in four steps:
- Select the register from which you wish to modify one or more registration(s).
(The documentation below includes generic sample screens designed solely to illustrate what the process entails, irrespective of the registry involved.)
- Click on the registration to be changed, and complete the form. The status of the record is then:
- Open for registrations saved manually or by uploading a csv file
- Corrections needed for registrations with errors
- Save registration temporarily if necessary. Record status becomes Open for stored registrations.
- Send the registration if there are no more validation errors.
- Registration status changes to Sending
- When the record is processed, the status changes to Submitted.
Once a registration is sent, the message Pending appears in the status confirmation column.
- When the registration is received, the message OK appears; if the registration is not received within 48 hours, the message NOK appears. With the status "NOK", the software will automatically try to send the registration up to 10 days after the initial submission.
- For the statuses Sending, Corrections needed and Approved, the status confirmation is empty because the registration has not yet been sent.
- A registration can be Reopened if necessary, as long as the status of the registration is "Submitted".
Delete a registration in HD4DP v1
Delete a registration in HD4DP v1Only registrations with status Open or Corrections needed can be deleted.
The following steps are required to delete the registration:
- Select the record and version for which you wish to delete a registration
(The documentation below includes generic sample screens designed solely to illustrate what the process entails, irrespective of the registry involved.)
- Select the registration(s) you wish to delete
- Select the Actions button and select the Delete registrations option
- Select Yes to confirm
Technical manual of the application HD4DP v1
Technical manual of the application HD4DP v1 Bart.Servaes Mon, 12/02/2024 - 11:44HD4DP v1 csv upload
HD4DP v1 csv uploadThe documentation below includes generic sample screens designed solely to illustrate what the process entails, irrespective of the registry involved.
The upload center is introduced to make the upload of multiple registrations more performant and user friendly.
The link to the upload center can be reached by the main menu:
If uploads are processed, an overview with the name of the uploaded file, the status and a visual representation of the status, the number of records that were processed, the way of uploading, the user and the upload date is saved in the main screen of the upload center. This allows a quick and visual impression of the data uploaded in bulk:
In the right upper corner two buttons are shown.
- Configuration: the default settings for a register can be set by any user that is authorized to participate in a register.
Following options are available:
- Conflict mode: what needs to be done in case of conflict
- Conflict master: is the data from the new registration of from the record in the database saved in case of conflict
- Ignore duplicate records
- Autosubmit: send the data automatically for processing in HD4RES
- Validation: what need to be done after validation the registration:
- None: only the registrations without errors will be saved
- Save on validations: Save the registrations when there are validation errors upon uploading
- Validate all: Only perform commit if non of its records have (errors or) validation errors
4 steps need to be executed for a new upload. When the titel bar of a separate step turns green, orange or red and the icon of the step in the overview, the step has respectively ended with success, with warnings or errors.
Step 1 - Select file
The first step is to select the CSV file with the data to be uploaded. The default settings for a register can be found in the Configurations on the main screen of the upload center.
Be sure to deselect the "Use default configurations" when changing the default settings:
For the BCR register, the possibility exists to upload two files and link them during the process:
- Both documents will be validated separately. By using the link "Click here to see the linked upload" the user can switch between the linked documents. Refresh of push F5 on you to see the status of the upload.
After uploading succesfully, the title bar of this step will turn green.
Step 2 - Validity Check
Validation checks are executed for every record.
Step 3 - Upload
The file is being uploaded and the result is shown in this step per line of data added:
Step 4 - Finalize
The result is shown visually for all registrations and for all registrations in a CSV file in reports after finalization:
Succes report is a CSV file with all registrations who were processed succesfully.
In case of errors, a link to a detailed error report is shown too:
Please find below the movie that guides you through the functionalities of the Upload Center:
Create a csv for HD4DP v1
Create a csv for HD4DP v1A RShiny application has been developed to help the data provider with transforming the raw export from the Smartgene software to the required format for upload in HD4DP and on the SFTP server. The program and the documentation are accessible on the Sciensano-ARL Sharepoint (https://collaboration.sciensano.be/sites/E1989/). For additional guidance and bug-reports on this RShiny application: HIV_STIsurveillance@sciensano.be.
CSV upload of nucleotide sequences
CSV upload of nucleotide sequencesData submission procedure using CSV Upload
1. Preparing the csv file
- The CSV file should contain following fields “filename;recordname;genetic_sequence”
- Description of the values for the fields "filename" and "recordname" are :
Filename: This field is used as the first key for linkage between the data sent through HD4DP1 (patient & sample data) and SFTP (nucleotide sequences data). This field must contain the same value for both uploaded records to allow the 1 to many link. Please use this convention: ARL_yyyymmddHHMMSS (name of ARL and date-time stamp of the file, e.g. HSP_20240827092014). The name of the csv file with nucleotide sequences sent through SFTP must have this value in order to be linked with the record transferred via the HD4DP1 (patient & sample data).
Recordname: This field is used as the second key for linkage between the data sent through HD4DP1 (patient & sample data) and SFTP (nucleotide sequences data). This field must contain the same unique value for both uploaded records to allow the 1 to 1 link. Please use this convention: ARL_yyyymmddHHMMSS_xxxxx (name of ARL, date-time stamp of the file and a unique 5-digit number, e.g. HSP_20240827092014_00001). as described
- The values of the field “genetic_sequence” contain the nucleotide sequences of the HIV genes.
Example of the CSV file for sequence :
Disclaimer: The example files above are only provided as a guideline and do not contain real life data.
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 credentials are unavailable we advise you to request your credentials through our service portal at the Jira Service management (JSM) Portal 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
Below documentation contains generic example screens with the sole purpose to demonstrate how the process looks like. In the subsequent screens the desired HIV_sequence register needs to be selected.
Step 4: Select the desired HIV_sequence folder and open the upload folder 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: Refresh the right hand pane. The ownership of the file has been transfered from the ‘hiv_sequence’ user (1092) to our technical user (1001), thereby preventing the data providers from further accessing the uploaded files in any way.
The files are deleted by the load process when it picks them up once daily.
3. Validate csv upload
No validation of the files occurs
Support service of healthdata.be
Support service of healthdata.beThe 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:
Create a Support ticket
Create a Support ticketThe healthdata.be service (Sciensano) processes each incident report according to a Standard Operating Procedure (SOP). A public version of this SOP "HD Incident Management Process" is also available on this portal docs.healthdata.be.
To submit an incident related to registries and applications in production and facilitated or managed by Sciensano's healthdata.be service, you must first log into the HD Service and Support portal: Jira Service Management (JSM) portal.
More info concerning how to request an account is available here.
After the login step, you will arrive at the main page of the portal
To create a ticket click on "Create a Support ticket"' on the main page.
You will see the page below. Once you have filled in all the mandatory fields, click on "Send".
Suggest improvement
Suggest improvementTo 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.
On this page you need to fill in all the mandatory fields and click on "Send".
Email security policy
Email security policyWHAT IS THE PROBLEM?
Sciensano blocks e-mails from organizations if the configuration of their e-mail and/or DNS services allow potential abuse by spammers/attackers. More specifically, if the configuration enables other senders to impersonate your organization by allowing them to mimic your organization’s e-mail “Header From”.
In other words, they can send phishing and spam mails that cannot be distinguished from genuine mails from your organization.
If you’re responsible for managing your ICT infrastructure, keep reading. If not, pass this message on to your ICT department or to the ICT service that’s managing your ICT infrastructure.
HOW TO SOLVE IT?
You’ll have to verify that your configuration complies with “Sender Alignment” security requirements.
More specifically, your mail services and DNS will have to be configured according to ICT standards.
These configurations are common, well-documented and supported by hosting companies. Some useful links:
- https://dmarcian.com/alignment/
- https://mxtoolbox.com/dmarc/spf/spf-alignment
- https://o365info.com/how-does-sender-verification-work-how-we-identify-spoof-mail-the-fiveheros-spf-dkim-dmarc-exchange-and-exchange-online-protection-part-9-of-9/
We’ve noticed that this issue frequently occurs in organizations which moved their ICT infrastructure to cloud services such as Microsoft (O365), Amazon, Google, and MS Azure without properly configuring the ICT infrastructure which is not managed by these providers.
The configurations and recommendations need to be implemented on the customer’s ICT infrastructure, either internally or externally. DNS and Mail services are the main ICT platforms for these actions.
THE USE OF DIFFERENT DOMAINS IN THE MAIL SENDING PROCESS
E-mails contain an “Envelope From” and a “Header From”. Both need to match to avoid that the mail is blocked.
Some examples:
- 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.