Initiative for quality improvement and epidemiology in multidisciplinary diabetic foot clinics

Welcome to the technical documentation pages for the project "Initiative for quality improvement and epidemiology in multidisciplinary diabetic foot clinics (IQEDFOOT)", 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
The data transfer (documentation in progress)
The data validation (documentation in progress)
The data analysis (documentation in progress)
The data reporting and visualisation (documentation in progress)
The data and project monitoring (documentation in progress)

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

manager Wed, 05/10/2023 - 13:08

Documentation status

Documentation status Bart.Servaes Thu, 05/04/2023 - 15:42

General IQEDFOOT project information

Project name

Initiative for quality improvement and epidemiology in multidisciplinary diabetic foot clinics

Project abbreviation

IQEDFOOT

Project code

HDBP0010

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)

Brief project description

Since 2005, multidisciplinary tertiary diabetic foot clinics are recognized by the INAMI-RIZIV. IQED-Foot uses the audit-feedback method to monitor quality of care and support healthcare providers in improving quality of care. Periodically, recognised diabetic foot clinics are required to prospectively provide data of the first 52 individuals presenting with a deep diabetic foot ulcer or an active Charcot foot during a 1-year inclusion period. Included individuals are then followed up for 6 months.

The project is executed by Sciensano and governed by a group of national experts.

The activities within this initiative can be summarized as follows:

IQED-Foot conducts regular audits in the Belgian recognised diabetic foot clinics to evaluate quality of care using valid, evidence-based quality indicators whenever possible.
IQED-Foot helps the recognised diabetic foot clinics to improve quality of care by offering individual feedback with anonymous benchmarking and by organizing information meetings with expert speakers and discussions between colleagues, thus promoting the exchange of good treatment strategies.
IQED-Foot studies epidemiological aspects and increases scientific knowledge about the presentation, treatment and outcomes of patients with diabetic foot problems.

Regulatory framework of this project

Consult the regulatory framework information published on the fair.healthdata.be pages.

johanvanbussel Fri, 05/05/2023 - 12:11

The IQEDFOOT data collection

Organizations and/or individuals that provide data

All recognized diabetic foot clinics in Belgium that have signed the revalidation agreement concerning diabetic foot. At the moment, these are: A.Z. Groeninge, A.Z. Nikolaas, A.Z. Sint Elisabeth, A.Z. Sint-Blasius, A.Z. Sint-Jan Brugge Oostende, A.Z. Sint-Lucas, A.Z. Sint-Maarten, Ass. Hosp. Bxl. & Schaerbeek - C.H.U. Brugmann, AZ Delta, AZ Rivierenland, AZ Turnhout, AZ Vesalius, C.H.R. de la Citadelle, C.H.R. de Mouscron, C.H.R. Mons – Hainaut, C.H.U. de Charleroi MARIE CURIE, Centre Hospitalier de Jolimont-Lobbes, Centre Hospitalier Universitaire du Sart Tilman, CHwapi, Clinique Saint-Luc, Cliniques du Sud Luxembourg, Cliniques St. Joseph Liege, Cliniques Universitaires Saint-Luc, GZA, Heilig Hart Ziekenhuis Lier, Hôpital Erasme, Grand Hôpital de Charleroi, Onze-Lieve-Vrouwziekenhuis Aalst, R.Z. Jan Yperman, U.Z. Antwerpen, U.Z. Brussel, U.Z. Gent, U.Z. Leuven, Virga Jesse Ziekenhuis, VZW Imelda, Ziekenhuis Oost-Limburg, ZNA

Start date of the data collection

01/01/2022

End date of the data collection

31/07/2023

Periodicity of the data collection

Continuous, 2-yearly

johanvanbussel Mon, 04/24/2023 - 14:06

The IQEDFOOT Data Collection Definition (HDBP0010)

In the file below you can find the Data Collection Definition (DCD) specifications of the project Initiative for quality improvement and epidemiology in multidisciplinary diabetic foot clinics (IQEDFOOT). It is a detailed description of the content of one DCD

[[screenshot]]

with field names, formats, values, validation rules, help texts, error messages, translations... 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.

https://www.healthdata.be/dcd/#/collection/IQEDFoot/version/5

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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 Mon, 02/19/2024 - 09:01

XLSForm IQEDFOOT HDBP0010

Explanation of DCD specifications

The above Data Collection Definition (DCD) specifications are published in an MS Excel file using a slightly modified XLSForm format. XLSForm is a form standard created to simplify the creation of forms. The creation is done in a human readable format. XLSForms are a convenient standard for sharing and collaborating on form creation. For a detailed guide to the XLSForm standard, we refer you to https://xlsform.org/en/.

Each DCD Excel workbook has three worksheets: "settings", "survey" and "choices". Sometimes a project is composed of several DCDs. In this case, a "survey" worksheet is created for each DCD. The lists of values for all DCDs are listed in a single "choice" worksheet.

While not all survey and choice characteristics are used by healthdata.be to describe the data collection definitions, all standard XLSForm columns are present in the MS Excel file.

Note: healthdata.be itself does not use the XLSForm standard to create its DCD in its own applications (HD4DP, HD4Patient). The XLSForm standard (used by popular electronic data capture systems such as OpenClinica, LibreClinica, ODK,…) is chosen to describe the DCD only because it is a human readable format.

The "Survey" worksheet

This worksheet gives the general structure of the DCD and contains most of the content. It contains the complete list of variables and information on how they should appear in the form. Each row usually represents one variable.

The following columns are primarily used in the survey worksheet to describe DCD:

type: Defines the type of question/variable
name: Unique ID (name) of the question / variable
label::[English]: Question / variable in English, appears on the screen
label::[French]: Question / variable in French, appears on the screen
label::[Dutch]: Question / variable in Dutch, appears on the screen
label::[German]: Question / variable in German, appears on the screen
hint::[English]: Hint or explanatory text for a question, in English
hint::[French]: Hint or explanatory text for a question, in French
hint::[Dutch]: Hint or explanatory text for a question, in Dutch
hint::[German]: Hint or explanatory text for a question, in German
constraint_javascript: Constraint on the allowed values for a response defined in javascript
constraint_message::[English]: The message displayed to the user if the answer is not valid, in English
constraint_message::[French]: The message displayed to the user if the answer is not valid, in French
constraint_message::[Dutch]: The message displayed to the user if the answer is not valid, in Dutch
constraint_message::[German]: The message displayed to the user if the answer is not valid, in German
required: If a question or variable must be completed for the form to continue or be submitted
relevant_javascript: Skip logic condition (the relevant condition that must be met for this question to be displayed)
read_only: If a variable question/answer can be changed
calculation
repeat_count: Number of repetitions for a group of repetitions
hidden: Hidden fields in the HD4DP application

The "Choices" worksheet

This worksheet is used to specify answer choices for multiple choice questions. Each row represents an answer choice. Answer choices with the same list name are considered part of a set of related choices and appear together for a question/variable. This also allows a choice set to be reused for multiple questions/variables (for example, yes/no questions).

The following columns are primarily used in the choices worksheet to describe the DCD:

list_name: A unique name for each choice set
name: ID (name or code) of the specific choice
label::[English]: The choice label, in English, appears on the screen
label::[French]: The choice label, in French, appears on the screen
label::[Dutch]: The choice label, in Dutch, appears on the screen
label::[German]: The choice label, in German, appears on the screen

The "Settings" worksheet

form_title: Title displayed at beginning of form, in form list
public_key: Key required for encrypted forms
submission_url: Specific URL for uploading data
default_language: If form uses multiple languages, this one sets which to use by default
style: Separate questions groups into pages. Switch to a different theme.
instance_name: Allows user to create a dynamic naming convention for each submitted instance
status: status of the form: options are "final" and "draft"
start_date: date start form in production
end_date: date end form in production

Bart.Servaes Thu, 05/04/2023 - 15:46

The IQEDFOOT Dataflow Description

Below we describe (high level) the IQEDFOOT dataflow between the data provider and the healthdata.be platform.

Step 1. (Automatic) data export from systems of data provider towards HD4DP v1 and prefill of forms if not complete.

Step 2. Manual registration (de novo or completion) of data in form component of HD4DP v1.

Step 3. Transfer of patient identifiers and registry data from HD4DP v1 towards eHBox messaging client of HCO (HCO UM/EM)

Step 4. Transfer of patient identifiers and registry data from eHBox messaging client of HCO (HCO UM/EM) towards TTP service of eHealth.

Step 5. Transfer of pseudonymized patient identifiers and registry data from TTP service of eHealth towards eHBox messaging client of HD (HD UM/EM)

Step 6. Transfer of pseudonymized patient identifiers and registry data from eHBox messaging client of HD (HD UM/EM) to HDRES v1

Step 7. Transfer of pseudonymized patient IDs and registry variables from HD4RES v1 towards Data Validation environment on HD DHW.

johanvanbussel Tue, 04/12/2022 - 10:55

The future IQEDFOOT dataflow description

Step 1. (Automatic) data export from systems of data provider towards HD4DP v1 and prefill of forms if not complete.

Step 2. Manual registration (de novo or completion) of data in form component of HD4DP v1.

Step 3. Transfer of patient identifiers and registry data from HD4DP v1 towards eHBox messaging client of HCO (HCO UM/EM)

Step 4. Transfer of patient identifiers and registry data from eHBox messaging client of HCO (HCO UM/EM) towards TTP service of eHealth.

Step 5. Transfer of pseudonymized patient identifiers and registry data from TTP service of eHealth towards eHBox messaging client of HD (HD UM/EM)

Step 6. Transfer of pseudonymized patient identifiers and registry data from eHBox messaging client of HD (HD UM/EM) to HDRES v1

Step 7. Transfer of pseudonymized patient IDs and registry variables from HD4RES v1 towards Data Validation environment on HD DHW.

Bart.Servaes Fri, 05/05/2023 - 12:02

HD4DP v1

HD4DP v1 johanvanbussel Mon, 02/19/2024 - 08:50

General description of the application HD4DP v1

HD4DP v1 ("healthdata.be for data providers") is a local application accessible via web browser developed by healthdata.be (Sciensano) and installed at the site of the data provider (healthcare organizations). This application allows the data provider to extract data from the primary system and map that data into one or more data collections (if possible).

Clinical information that cannot be provided by the primary systems can be provided manually in the ‘prefilled’ form view of the Data Collection Definition (DCD).

The (form view of the) Data Collection Definitions (DCDs) are managed centrally via a metadata catalogue.

Jonas.VanBussel Wed, 08/30/2023 - 13:05

User manual of the application HD4DP v1

An extensive user manual, for both participating healthcare organizations and their IT service providers, is available on this docs.healthdata.be portal: https://docs.healthdata.be/hd4dp-v1.

Jonas.VanBussel Wed, 08/30/2023 - 13:06

Request account for HD4DP v1

To 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 "sign in" instructions at the end of this page.

Open the link for the HD4DP v1 application. You will see this screen:

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 user 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"

johanvanbussel Wed, 08/30/2023 - 13:06

Create a registration in HD4DP v1

The Data Collection view leads a user to the existing registers. A user can start collecting data from this view.

Creating and submitting a registration consists of 4 steps:

Select the register for creating a registration.

Click on "New registration" button.

Fill in the registration form and save or submit the registration

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".

johanvanbussel Wed, 08/30/2023 - 13:06

Change a registration in HD4DP v1

Een gebruiker kan een registratie wijzigen en voltooien in vier stappen:

Selecteer het register waarvan u een of meer registraties wenst te wijzigen

Klik op de registratie die moet worden gewijzigd, en vul het formulier volledig in. De status van de record is dan:
- Open voor registraties die handmatig werden opgeslagen of door een csv-bestand up te loaden
- Correcties nodig voor registraties met fouten

Sla de registratie tijdelijk op indien nodig. De status van de record wordt Open voor opgeslagen registraties

Verzend de registratie als er geen validatiefouten meer zijn
- De status van de registratie verandert in Verzenden bezig

Wanneer de record is verwerkt, verandert de status in Verzonden

Zodra een registratie verzonden is, verschijnt in de kolom van de statusbevestiging de melding In behandeling.

Bij ontvangst van de registratie verschijnt de melding OK; als de registratie niet binnen de 48 uur is ontvangen, verschijnt de melding NOK. Bij de status 'NOK' zal de software tot 10 dagen na de initiële verzending automatisch proberen om de registratie te verzenden
Voor de statussen Verzenden bezig, Correcties noodzakelijk en Goedgekeurd is de statusbevestiging leeg, omdat de registratie nog niet is verzonden
Een registratie kan eventueel Opnieuw geopend worden, zolang de status van de registratie 'Verzonden'

johanvanbussel Wed, 08/30/2023 - 13:07

Delete a registration in HD4DP v1

Only 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

Select the registration(s) you wish to delete
Select the Actions button and select the Delete registrations option

Select Yes to confirm

johanvanbussel Wed, 08/30/2023 - 13:07

Technical manual of the application HD4DP v1

Technical manual of the application HD4DP v1 Jonas.VanBussel Wed, 08/30/2023 - 13:07

HD4DP v1 csv upload

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 uploade 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 is given to the user a quick and visual impression of the data uploaded in bulk by using the upload center:

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 need 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:

johanvanbussel Wed, 08/30/2023 - 13:08

Create a csv for HD4DP v1

Processing registrations in bulk is done by uploading CSV files. These files are plain text files which can contain multiple registrations at once and are extracted from your primary system.

The first step is to create the file correctly.

Using a CSV editor

While Excel is a fine tool to view CSV’s, we do not recommend it to edit CSVs. Instead use notepad++ or any other text editor. Here are a few risks you should be aware of when editing a CSV in Excel. Excel will interpret the content, which may lead to changes:

Leading zeros disappear in fields that are recognized as numeric fields
Entries like 3-9 can become March-9
The only accepted date format DD/MM/YYYY can be modified (e.g. To DD/MM/YY)
The decimal separator can differ from that in HD4DP, a semicolon wil lead to a correct upload
When saving a file as .csv, Excel uses the default field separator. HD4DP only accepts CSV with a semicolon as separator. This default setting can be adapted in the properties of your computer.
CSV encoding must be in UTF-8.

Setting up the document

Every column in the CSV file needs to be recognized as a field of the register by the HD4DP application. Therefor each column in the file must be identical by the technical name of the field in the register.

Tip: Downloading (manually) entered data from HD4DP will guide you in formatting a CSV file and may help during the development of the CSV extraction from the primary systems.

The Data Collection Definition (DCD) specifications for a register and its fields are defined and documented on this documentation portal.

Each field in the form can be completed through a value in a CSV file.
An example field is “Date of last follow-up”, shown in the screenshot below.

This field is of the type “date” and is required (*). Within the technical documentation of this data collection, this is shown as follows:

To include this field in a CSV upload file, it is sufficient to create a column with the name “date_of_last_followup” and populate it with the appropriate data i.e. a date in the format dd/mm/yyyy.

Fields can be required, read-only and computed (automatically calculated). Fields can also have a default value.

This information is present in the detailed technical description for each data collection.

General requirements

The column separator is the semicolon (;)
The decimal separator for numbers is the comma (,)
The date format is dd/mm/yyyy

Basic content types

Depending on the type of the field, a different representation of the data is expected. The table below describes the different basic types and the rules on how to provide the content for these types.

Content type	Expected format/content
boolean	TRUE, FALSE
date	dd/mm/yyyy
choice	code from choice list
list	option1_label\|option2_label\|etc.
multiline	free text
number	number (decimal separator = ,)
patientID	SSIN number. If the person does not have a SSIN, leave this field blank.
questionnaire	code from questionnaire answer list
text	● free text ● if a binding reference list is used: a code from the reference list ● if a non-binding reference list is used: a code from the reference list or free text
attachment	● expected format/content: Name of the file that must be attached (e.g. protocol.txt). ● expected extension: .txt ● file must be stored in the same folder as the folder that is used for the CSV-upload

Advanced content types

Other than these simple types, more complex data structures can be used, as shown in the table below. Each of these types is explained in more detail below the table.

Content type	CSV column name	Expected format
fields within fieldset	fieldset_label\|field_label	depending on the field type
list (1 field)	list_label\|field	value1\|value2\|etc
list (block of fields)	list_label\|0\|field1 list_label\|0\|field2 list_label\|1\|field1 list_label\|1\|field2 etc.	depending on the field type
nested fields below choice or multichoice	choice_label\|nested_item	depending on the field type

Fieldset

A fieldset is a collection of fields, as shown in the image below:

Anthropometry is the title of the fieldset, and this fieldset contains two fields, weight and height. Fieldsets fieldsets do not have a number cfr. image below - Anthropometry.

Sections do not have an impact on the CSV file, whereas fieldsets do. The title of the fieldset must be included in the field name column as follows: fieldset_label|field_label.

E.g. for the two Anthropometry fieldset fields weight and height below, the correct CSV column headers are: anthropometry|weight en anthropometry|height.

Lists

A list is also a collection of fields, like a fieldset, but with the additional property that the collection of fields can be repeated.

An example is shown in the image below: “Birthdays of the biological children for this patient” is a list. One list item consists of two fields, “Child birth month” and “Child birth year”. For each child, a list item can be added.

The CSV column names consist of the list header label and the field label (as for fieldsets), together with a counter to distinguish the different list items. The correct CSV column names for the two list items below are:

birthdays_of_the_biological_children_for_this_patient|00|child_birth_month
birthdays_of_the_biological_children_for_this_patient|00|child_birth_month
birthdays_of_the_biological_children_for_this_patient|01|child_birth_month
birthdays_of_the_biological_children_for_this_patient|01|child_birth_year

Please note that for every line, the numbers should increment, starting from 0 (|00|,|01|, .. is ok, |01|, |03|, ... is not). You can't have blank values for |00| and filled values for a higher number.

Please note that the numbering requires a stable format, meaning the number of characters used by the number has to be constant. You can't have one record using |00| and another using |0|. Generally we advice to use a string length of 2 digits.

For lists consisting of 1 field a simplified implementation is possible. The CSV column header only consists of the list header label and multiple values are provided in the one column, separated by a pipe (|).

E.g. for the list in the image below, the CSV column header is diagnosis_orphacode and the content of the column is 562|702. This is the example of a text field with a reference list: providing the codes of the reference list is sufficient.

Nested fields

Nested fields are fields that only become available when specific options are selected in the form. An example is shown below: the field “Specify” only becomes available if the checkbox “Other” is marked. These fields also have a combined CSV column header, consisting of the choice list label and the field label. For the example below, the correct CSV column header is hence base_of_diagnosis|specify.

Attachments

When a CSV is prepared and put in the provisioning folder, it can contain references to attachments for data collections that specifically allow this.

These references are relative paths to the file location. If such a reference is present in the CSV file, the attachment content is uploaded and linked to the created registration. The attachment is then available in the HD4DP client as well as in the HD4RES client when the registration is submitted.

The maximum file size for attachments is 6 MB.

If a data collection permits you to send attachments you should have the column name to use in the CSV. If not, you should be able to find it at https://www.healthdata.be/dcd/#/collections or you can contact Support.Healthdata@sciensano.be.

Add the column name to the header of the CSV and add the file names as values in the column.
Example: “picture.png”

Put the CSV file in the correct provisioning folder (organization sub folder, then in the register sub folder), along with a “picture.png” file of your choice. The application picks the CSV file and creates a new registration.

Open the registration and verify the attachment has correctly been uploaded.

johanvanbussel Tue, 04/12/2022 - 13:25

CSV download and upload for stable data

Before starting a new data collection based on stable data of another data collection, you need to finalize the data collection which serves as the starting point of your new data collection cf. article "Finalize the data collection"

To start the new data collection select the new version in the Data collection section. In this case v3.

Click the button "Go to the participation page":

Click on ‘Participate’:

The Start date in the Participation status will be updated and access to the new version is completed and the user can return to the Data Collection section:

Once the previous data collection is finalized and the new one has been started, you can download data from the first version and add those to the next version.

Go to the Registrations tab:

Download the data by using the Download button "CSV Download All (Stable Data)":

When everything is downloaded, you can start uploading by Using the upload center.

Bart.Servaes Thu, 05/04/2023 - 16:09

Support Service of healthdata.be

The Service Desk of healthdata.be (Sciensano) helps users of our applications and services and deals with requests and problems when they arise.

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 to the managing research organizations.

For most efficient processing of your request, we advise you to use our service portal: https://sciensano.service-now.com/sp.

Please find below our support window hours:

johanvanbussel Thu, 08/11/2022 - 18:55

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 projects 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: https://sciensano.service-now.com/sp.

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

On the main page, you must select "Get Help".

A new page with the title "Create an incident" will appear.

You can now document your incident or problem by providing the following information:

Please indicate the urgency of resolving your issue based on its criticality to the business.

Please indicate the type of problem you are experiencing.

When the problem type "Application" is selected, two additional fields appear: "Project Name" and "Application".

Please select the appropriate information.

Please describe clearly and briefly (1 sentence) the subject of your problem.

Please describe the problem in detail. The following aspects are important for us to understand and solve the problem:

a description of the actions you want to perform but fail to perform (e.g. provide us with a field name, a validation rule, a button, etc.)
a description (if possible) of the sequential steps you follow to use the service or the application of healthdata.be for which you need support;
a brief description of the technical problem you are experiencing (e.g. error messages)

We strongly recommend that you add a screenshot describing the problem (IMPORTANT: do not provide us with patient data!).

You can add the screenshot by clicking on "Add attachments".

On the right side of the form, the mandatory information items of the incident form are listed. When these fields are completed, their names disappear from the "required information" box.

The form can only be submitted if all required fields are filled in, by pressing the green "Submit" button.

If all required fields have not been completed, a warning message will appear at the top of the form.

In addition, missing mandatory fields will be highlighted in green.

When the incident form has been successfully submitted, a preview of your submission appears in a new screen.

On the right side of the screen you will find the details, including the incident number.

On the left side of the screen, you will find a chronology of your incident processing, starting with your creation.

johanvanbussel Sun, 04/10/2022 - 19:31

Submit a request for information about HD

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

Om informatie op te vragen over het healthdata.be platform, moet u eerst inloggen op het HD Service- en Supportportaal.

Jonas.VanBussel Tue, 08/08/2023 - 10:24

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 organisation 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:

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:21

Release notes

Release notes Bart.Servaes Thu, 05/04/2023 - 18:04

The IQEDFOOT data and project monitoring

HD4RES v1 is an application developed by healthdata.be and installed at Sciensano that allows the manager of the data collection to communicate with the data provider without knowing the identification of the patient. Data are sent automatically or by pressing a submit button to the central HD4RES v1 application via eHealth. A mechanism of encryption is put in place assuring that nobody has access to the patient identifier and medical information except the data provider.

Jonas.VanBussel Thu, 08/31/2023 - 12:45

General description of the application HD4RES v2

What?

The component HD4RES v2 can be seen as a monitoring tool that provides researchers who are managing a research project on the healthdata.be platform a set of (non scientific) operational reports. The first reports foreseen by healthdata.be are:

Count of study records in the different components of healthdata.be (HD4DP v2 Local, HD4DP v2 web, HD DWH Staging, HD DWH CDW, HD DWH Exploitation, ...)
Count of unique study subjects in the different components of healthdata.be
Count of unique study subjects in multiple studies available at the healthdata.be platform
List of data providers (organisations) for the research project
List of data providers (individuals) for the research project
List of data users (organisations) on the healthdata.be platform
List of data users (individuals) on the healthdata.be platform
Status of all technical components of healthdata.be used for the research project
List of incidents related to the research project
List of requests related to the research project

In its current form, HD4RES v2 is a collection of data tables accessible via the SAS eGuide component at the data warehouse of healthdata.be. It is thus integrated in the core of the research environment. In a next stage, the data tables will be visualized using the SAS Visual Analytics component at the data warehouse. While a predefined set of visualizations will be offered by healthdata.be, the researcher will be able to create and execute workflows for interactive reporting and exploration.

In contrast with HD4RES v1, HD4RES v2 is not a communication tool with the data providers to verify the quality of the submitted data. This functionality is now only available in the Data Validation Tool of the healthdata.be platform.

Who?

The HD4RES v2 component is only accessible by researchers formally involved in the management of a research project on the healthdata.be platform.

Where?

The component HD4RES v2 is part of the data warehouse environment of the healthdata.be platform.

When?

The HD4RES v2 component is available as of Thursday 20th of October 2022 and can be accessed 24/7/365.

How?

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:24

HD4RES v1 versus HD4RES v2

HD4RES v1

HD4RES v1 is an application developed by healthdata.be Sciensano that allows the manager of a specific data collection project to communicate with the data provider without knowing the identification of the patient. Data are sent to the central HD4RES application via eHealth. A mechanism of encryption is put in place assuring that nobody has access to the patient identifier and medical information except the data provider.

The researcher receives the data in the software component HD4RES where he/she can monitor the status of his/her data collection, check the data and, if necessary, ask additional questions to the data provider, e.g. regarding the quality of the data.

To this end, healthdata.be sends a message back to the data provider via ehBox coding. This contains the encrypted data, together with the medical-scientific data that are encrypted with respect to the data provider. eHealth-platform takes care of the decryption of the encrypted data and delivers the data to the data provider.

The challenge for healthdata.be in Architecture 1 was that all healthcare organizations and all healthcare professionals should be able to provide data in a structured and encoded way to the researcher. The records collected from the data providers could follow many itineraries, making monitoring a complex matter.

HD4RES v2

The main objective of HD4RES v2 is to simplify HD4RES.

Like in Architecture 1.0, the researcher will be able to monitor the Architecture 2.0 dataflow end-to-end. The feedback loop, however, will be taken out of HD4RES v2 and will be integrated into the Quality Control tool. The application HD4RES as such disappears and becomes a block SAS eGuide in DWH that takes over that function.

HD4RES v2 has now become a mere monitoring tool offering researchers an overview and status of all (external and internal) dataflows for his/her project only, as well as an overview of all HD4DP v2 and healthstat.be accounts for his/her project only.

Equally, the dataflow from ServiceNow on incidents and requests is only made visible to researchers for projects in which they are involved.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:55

Position of HD4RES v2 in HD Architecture 2.0

The application HD4RES v2 is one of the components of the broader data collection and management architecture managed by the healthdata.be service of Sciensano. Below you can find a high level view of that data collection and management architecture (version 2). The HD4RES v2 component (red block) is part of the datawarehouse environment of healthdata.be.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:26

Dataflow description of the application HD4RES v2

The component HD4RES v2 is a monitoring tool on several operational processes relevant for the researcher. As a result, HD4RES v2 receives data from very diverse applications and environments, within and outside the healthdata.be platform.

Count of study records in the different components of healthdata.be

There are many different components of healthdata.be that contain study records. Outside the healthdata.be platform, study records are available in :

HD4DP v2 Local
HD4DP v2 web
HD4Patient
HERA platform
BioIT platform (Integration)
NRC platform (Integration)

These external components are monitored by a tool (HD4DevOps) used for the real time monitoring of the technical status and operations within these components. The HD4DevOps component also collects counts (aggregated and thus anonymously) of records in these external components. The monitoring by this component, however, is not possible in HD4RES v1 Local since this component is not configured to gather data in the new Architecture 2 setup.

Study records are also available in following internal components of the healthdata.be platform:

HD Integration
HD DWH Staging
HD DWH CDW
HD DWH Exploitation

The HD4RES2 component collects on a daily basis the counts (aggregated and thus anonymously) of records in these internal components and consolidates them with the counts collected by HD4DevOps component.

The publication of the Count of study records in the different components of healthdata.be is currently under development and thus not yet available in HD4RES v2.

Count of unique study subjects in the different components of healthdata.be

There are many different components of healthdata.be that contain information about the study subjects (either nominatively or pseudonomized). Outside the healthdata.be platform, this information is available in :

HD4DP v2 Local
HD4DP v2 web
HD4Patient
HERA platform
NRC platform (Integration)

These external components are monitored by a tool (HD4DevOps) used for the real time monitoring of the technical status and operations within these components. The HD4DevOps component also collects counts (aggregated and thus anonymously) of unique study subjects in these external components. The monitoring by this component, however, is not possible in HD4RES v1 Local since this component is not configured to gather data in the new Architecture 2 setup.

Study records are also available in following internal components of the healthdata.be platform:

HD Integration
HD DWH Staging
HD DWH CDW
HD DWH Exploitation

The HD4RES2 component collects on a daily basis the counts ( aggregated and thus anonymously) of unique study subjects in these internal components and consolidates them with the counts collected by HD4DevOps component.

The publication of the Count of unique study subjects in the different components of healthdata.be is currently under development and thus not yet available in HD4RES v2.

Count of unique study subjects in multiple studies available at the healthdata.be platform

The publication of the Count of unique study subjects in multiple studies available at the healthdata.be platform is currently under development and thus not yet available in HD4RES v2.

List of data providers (organisations) for the research project

The publication of the list of data providers (organisations) for the research project is currently under development and thus not yet available in HD4RES v2.

List of data providers (individuals) for the research project

The publication of the List of data providers (individuals) for the research project is currently under development and thus not yet available in HD4RES v2.

List of data users (organisations) on the healthdata.be platform

The publication of the list of data users (organisations) on the healthdata.be platform is currently under development and thus not yet available in HD4RES v2.

List of data users (individuals) on the healthdata.be platform

The publication of the list of data users (individuals) on the healthdata.be platform is currently under development and thus not yet available in HD4RES v2.

Status of all technical components of healthdata.be used for the research project

There are many different components managed by healthdata.be both inside and outside the healthdata.be platform:

HD4DP v2 Local
HD4DP v2 web
HD4Patient
HERA platform
BioIT platform (Integration)
NRC platform (Integration)
HD Integration
HD DWH Staging
HD DWH CDW
HD DWH Exploitation
HD MDM
healthstat.be
fair.healthdata.be
eam.healthdata.be
docs.healthdata.be

These components are monitored by a tool (HD4DevOps) used for the real time monitoring of the technical status and operations within these components. The HD4DevOps component collects information like availability and performance of these services.

The HD4DevOps component provides the availability statistics to the HD4RES2 component so that they are available for the researchers.

The publication of the status of all technical components of healthdata.be used for the research project is currently under development and thus not yet available in HD4RES v2.

List of incidents related to the research project

The healthdata.be service (Sciensano) processes each incident report according to a standard operating procedure (SOP). To submit an incident related to projects and applications in production and facilitated or managed by healthdata.be, users create a ticket in the HD Service and Support portal.

Healthdata.be uses the application ServiceNow for its service and support portal. This application is provided in an external public cloud environment. Healthdata.be extracts on a daily basis all incidents recorded in it's portal, and integrates this information in the data warehouse of the healthdata.be platform. On a daily basis, an extract is published in HD4RES v2.

List of requests related to the research project

The healthdata.be service (Sciensano) processes each request according to a standard operating procedure (SOP). To submit an request related to projects, applications and services, users create a ticket in the HD Service and Support portal.

Healthdata.be uses the application ServiceNow for its service and support portal. This application is provided in an external public cloud environment. Healthdata.be extracts on a daily basis all requests recorded in it's portal, and integrates this information in the data warehouse of the healthdata.be platform. On a daily basis, an extract is published in HD4RES v2.

The publication of the list of requests related to a research project is currently under development and thus not yet available in HD4RES v2.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:46

How to access HD4RES v2

Follow the required steps underneath to get access to HD4RES v2.

Login into the healthdata platform

The healthdata platform is accessible through website https://remote.healthstat.be
Login using the received user credentials:

During the login process an SMS Passcode is received on your mobile phone (from 8645), enter this SMS Passcode in the next screen:

* The PASSCODE will also be send to the e-mail address if not entered in the screen within 2 minutes.

Start the SAS Enterprise Guide application

After providing the PASSCODE, install the Citrix Receiver by clicking on ‘Detect Receiver’:

* This step will only appear upon the initial setup.

Selecting ‘APPS’ from the top menu displays the available applications:

Click on the ‘SAS Enterprise Guide’ icon to start the application:

Open the data table

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

Open the path Servers >> SASAppRES >> Libraries >> HD4RES2

The tables currently stored in the library are:

V_HDM_SNOW_INCDNT (incident life-cycle)

Open the data table by double clicking its name:

Change the column width

Extend the column width if needed (similar to Excel):

Put the cursor on the right side of the column title cell, move the cursor to the appropriate width, or double-click to extend to max width:

Querying the table

On the top left of the table you’ll have point-and-click interface to query the table: Filter and Sort

Exit the table

To exit the table right close button (‘X’) at the top right corner of the table.

Close the SAS Enterprise Guide application

Upon finishing the visualization or querying you can close the SAS Enterprise Guide application.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:49

HD4RES v2 Data tables

The data tables are not created for each research project separately. HD4RES v2 offers a view based on the master data table on which Row-Column Access Control (RCAC) has been applied to grant access to the researcher to only the records related to his/her project.

The following data tables are foreseen by healthdata.be:

Jonas.VanBussel Wed, 08/30/2023 - 14:58

List of incidents

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 projects and applications in production and facilitated or managed by Sciensano's healthdata.be service, users can submit a ticket in the HD Service and Support portal.

The researchers have access to the list of incidents related to their project. This list is available in a data table in HD4RES v2.

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

First open the following path Servers >> SASAppRES >> Libraries >> HD4RES2

Then, open the following table "V_HDM_SNOW_INCDNT" (incident life-cycle)

This data table contains the following fields:

SNOW db field	HD4RES2 column names	Description
Number	IDC_INCIDENT_NUMBER	Unique number that is created once the incident is submitted (INCxxxxxx)
State	TX_STATE	The state in which the incident is at that moment : - New : the ticket is not handled yet - Work in progress : incident is being worked on - On hold : the IT-colleague is waiting for info from another party to continue - Resolved : the incident is resolved. The caller can reopen the incident if not satisfied, within 14 days. - Closed : ticket cannot be reopend anymore
Caller	TX_CALLER_ID	The person who has submitted the incident
Service	T_U_SVC	The projectname on which the incident is created. Reflects on incidents opened before January 14, 2022. After this date, this field is replaced by the field 'Related Project Name'
Category	TX_CAT	The category to which the incident is related (data transfer, infrastructure, application, account, other)
Subcategory	TX_SUBCATEGORY	Depending on the category, the type of subcategory will appear that has been chosen. For example : if categroy=application, the list of applications will appear
Related Project Name	TX_U_RELATED_PROJ_NAM	The name of the project (full name, abbreviation and projectcode)
Opened	DT_OPENED_AT	The date and time when the incident was opened
Updated	DT_SYS_UPD_ON	The date and time when the incident was last updated with comments, change of state, …
Short description	TX_SHORT_DESC	A short description of the incident
Customer Communication	TX_COMMENTS	Communication that has been sent to or received from the caller
Organisation	TX_COMP	The organization to which the caller belongs, if filled in in the profile of the caller
Assignment group	TX_ASSIGNMENT_GR	The team that is handling the incident. The person of this team that works on the incident, is visible in the portal.
Due date	DT_DUE_DATE	The person working on the incident can plan his work by filling in this field.
--none--	CD_PROJ_BUS	The internal project business code (HDBPxxxx)
--none--	TX_PROJ_BUS_ABBREV	Project business abbreviation

Jonas.VanBussel Wed, 08/30/2023 - 15:04

List of requests

The healthdata.be service (Sciensano) processes each request according to a standard operating procedure (SOP). A public version of this SOP "HD Request Management Process" is also available on this portal docs.healthdata.be.

To submit a request related to projects and applications in production and facilitated or managed by Sciensano's healthdata.be service, users can submit a ticket in the HD Service and Support portal.

The researchers have access to the list of requests related to their project. This list is available in a data table in HD4RES v2.

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

First open the following path Servers >> SASAppRES >> Libraries >> HD4RES2

Then, open the following table "V_HDM_SNOW_REQ_ITEM" (incident life-cycle)

This data table contains the following fields:

SNOW db field	HD4RES2 column names	Description
Number	IDC_REQ_ITEM_NUMBER	Unique number that is created once the request is submitted (RITMxxxxxx)
State	TX_STATE	The state in which the request is at that moment: - Open: ticket is open but has not yet been assigned to a group to begin work - Work in progress: ticket is being worked on - Pending: the ticket has been placed on-hold and is awaiting action before work can recommence - Closed complete: ticket has been closed and the work has been completed - Closed incomplete: ticket has been closed and the work has not been completed - Closed skipped: ticket has been closed and no work was carried out
Caller	TX_REQD_FOR	The person who has submitted the request
Category	TX_CAT_ITEM	The category to which the incident is related (Access to a HD Application, Information about HD, Infrastructure by HD, New project with HD, Request Access to a HD Application, Request for information about HD, Request for infrastructure by HD, Request for new project with HD)
Related Project Name	TX_U_RELATED_PROJ_NAM	The name of the project (full name, abbreviation and projectcode)
Opened	DT_OPENED_AT	The date and time when the request was opened
Updated	DT_SYS_UPD_ON	The date and time when the request was last updated with comments, change of state, …
Short description	TX_SHORT_DESC	A short description of the request. As from the 22th of December 2022 the field reflects the appropriate request short description.
Describe the information you need	TX_DESC	A detailed description of the request. As from the 22th of December 2022 the field reflects the appropriate request description.
Customer Communication	TX_COMMENTS	Communication that has been sent to or received from the caller
Organisation	TX_COMP	The organization to which the caller belongs, if filled in in the profile of the caller
Assignment group	TX_ASSIGNMENT_GR	The team that is handling the incident. The person of this team that works on the incident, is visible in the portal.
Due date	DT_DUE_DATE	The person working on the request can plan his work by filling in this field.
--none--	CD_PROJ_BUS	The internal project business code (HDBPxxxx)
--none--	TX_PROJ_BUS_ABBREV	Project business abbreviation

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 15:06

Count of study records

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:31

Count of unique study subjects

Introduction

The purpose of the data table described below is to provide an up-to-date and end-to-end view on the operational dataflow of their project. The obtained metrics on the number of study records and unique study subjects consolidated on a daily base in the HD4RES2 application aims to fulfill this requirement.

Data table: V_HDM_REC_SUBJ_CNT

The researchers have access to a view on the number of study records and unique study subject related to their project. Those figures are available in the data table V_HDM_REC_SUBJ_CNT in HD4RES2 application.

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

First open the following path Servers >> SASAppRES >> Libraries >> HD4RES2

Then, open the following table "V_HDM_REC_SUBJ_CNT"

This data table contains the following fields:

Requested	FieldName	Description
HDBP_code	CD_PROJ_BUS	HD internal business project code (HDBPxxxx)
HDBP_name	TX_PROJ_BUS_NAME	Project business name
HDBP_abbreviation	TX_PROJ_BUS_ABBREV	Project business abbreviation
HCO_NIDHICode	TX_DATA_PROV_VAL	NIDHI data provider code
HCO_name	TX_DATA_PROV_NAME	NIDHI data provider name
HD4DP_MASTER_CHILD	(not yet implemented)	HD4DP user type (technically) of the Health Care Organisation: 'Master' = Data provider has his own instance of HD4DP2 'Child' = Data provider uses the HD4DP instance of a Master
HD4DP_MASTER_HCO_NIDHICode	(not yet implemented)	Master NIDHI data provider code
HD4DP_MASTER_HCO_name	(not yet implemented)	Master NIDHI data provider name
HD_ARCH	(not yet implemented)
HD_ARCH_component	TX_ARCH_COMPONENT	Database component/DWH layer
HD4DP_record_status	(not yet implemented)
Count_Date	D_COUNT	Datepart of the metrics calculation made at the end of the day
Count (records)	MS_RECS	Count of the total number of study records
Count_New (records)	MS_NEW_RECS	New number of study records as from previous date and time
Count (subjects)	MS_UNQ_SUBJ	Count of unique study subject/patient
Count_New (subjects)	MS_NEW_UNQ_SUBJ	New number of study subject/patient as from previous date and time

Reference table: V_HDM_MAP_TBL_PROJ

As business projects/data collections often led to the creation of several data tables the figures are resulting from the consolidation of the most representative business project data tables. Consequently those data tables must be treated with respect to their own functional and structural properties.

To this end, researchers may consult an additional data table V_HDM_MAP_TBL_PROJ related to their project on the HD4RES2 application which describes the content and rules applied on each data table by business project.

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

First open the following path Servers >> SASAppRES >> Libraries >> HD4RES2

Then, open the following table "V_HDM_MAP_TBL_PROJ"

FieldName	Description	Used for dimension
TX_SCHEMA_NAM	Schema location of the data table	HD_ARCH_component
TX_TBL_NAM	Table name of the data table
TX_REG_NAM	HD internal DWH register name	HDBP_code
CD_PROJ_BUS	HD Project business code (HDBPxxxx)	HDBP_code
TX_PROJ_BUS_NAME	HD Project business code name
TX_PROJ_BUS_ABBREV	HD Project business abbreviation
TX_SQL_DP_TPE	Field or SQL statement used to identify the type of the data provider	HCO_NIDHICode
TX_SQL_DP_VAL	Field or SQL statement used to identify the data provider	HCO_NIDHICode
TX_SQL_SUBJ	Field or SQL statement used to identify the study subject
FL_INCL_METRIC_CNT_REC_PAT	Flag which indicates whether the table contributes toward the calculation of the metrics: 1, 2 => included in the figures calculation 0 => explicitly excluded from the calculation null => implicitly excluded from the calculation
DT_VALID_FROM	Timestamp as from when above properties are applicable
DT_VALID_TO	Timestamp as to when above properties are discarded

Calculation of the study records:

One study record is defined as one record in a data table.

Therefore the delivered figures corresponds to the sum of number of records of each data tables as used as defined in the reference table V_HDM_MAP_TBL_PROJ. One must understand that the figures have no other purpose than to provide a synthetic technical count on the number of records available by provided dimensions.
The figures have by no means any scientific value and shouldn't be used in any context other then the metrics project.

Calculation example code:
A hypothetical Business project (HDBP000n) is made of three data tables, two stored in the STG layer and one in the CDW layer. The total study records are calculated as follow on the latest available data :

select 'HDBP000n' as HDBP_code,HD_ARCH_component,HCO_NIHDI_code,
sum(total_table_records) as total_study_records
from (
select 'STG' as HD_ARCH_component, assigned-rules as HCO_NIHDI_code,
count(*) as total_table_records
from STG.datatable1
group by HD_ARCH_component,HCO_NIHDI_code
union all
select 'STG' as HD_ARCH_component, assigned-rules HCO_NIHDI_code,
count(*) as total_table_records
from STG.datatable2
group by HD_ARCH_component,HCO_NIHDI_code
union all
select 'CDW' as HD_ARCH_component, assigned-rules as HCO_NIHDI_code,
count(*) as total_table_records
from CDW.datatable3
group by HD_ARCH_component,HCO_NIHDI_code
) as hdbp
group by HDBP_Code,HD_Arch_component,HCO_NIHDI_code

Calculation of the unique study subjects:

One study subject is defined as the entity for which data has been collected. Depending the data collection most of the time a study subject represent the patient.

Therefore the delivered figures corresponds to the sum of all uniquely identified subjects over the complete set of data tables by provided dimensions. One must understand that the figures have no other purpose than to provide a synthetic technical count on the number of subjects available at the level - and only at the level - of the provided dimensions. All summarization over less dimensions combination are erroneous and Healthdata.be neither DWH-team can be held responsible for any misuse of the obtained figures.
The figures have by no means any scientific value and shouldn't be used in any context other then the metrics project.

Calculation example code:
A hypothetical business project is made of three data tables, two in STG and one in CDW. In all three tables the patient field has been identified as IDC_PAT. The total unique study subject are calculated as follow on the latest available data :

select 'HDBP000n' as HDBP_code,HD_ARCH_component,HCO_NIHDI_code,
count(distinct study_subject) as total_unq_subject
from (
select distinct 'STG' as HD_ARCH_component, assigned-rules as HCO_NIHDI_code,
IDC_PAT as study_subject
from STG.datatable1
union
select distinct 'STG' as HD_ARCH_component, assigned-rules HCO_NIHDI_code,
IDC_PAT as study_subject
from STG.datatable2
union
select distinct 'CDW' as HD_ARCH_component, assigned-rules as HCO_NIHDI_code,
IDC_PAT as study_subject
from CDW.datatable3
) as hdbp
group by HDBP_Code,HD_Arch_component,HCO_NIHDI_code

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:32

Count of unique study subjects in multiple studies

Introduction

As the reduction of administrative burden at side of data providers is part of Healthdata’s mission. Knowing the number of patients (study subjects) in their own study project that are in multiple study projects supported by healthdata.be (and thus available at data warehouse of healthdata.be), facilitates the reuse of data collected, instead of starting a new data collection to obtain that same information.

Based on the provided solution the client can decide whether it is feasible or not to link its own study project with other projects (i.c. “there are enough unique study subjects that are in both study projects”).

Linking of databases increases the reuse of data, reduces the need to start new data collections, and thus contributes to the reduction of administrative burden of the data providers. It is also less expensive compared with the creation of new data collections.

Through the HD4RES2 application Heathdata delivers a data table on daily bases which aims to provide the necessary insight on the business project common study subject. Those figures are available in the data table V_HDM_COMMON_SUBJ detailed below.

Data table: V_HDM_COMMON_SUBJ_CNT

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

First open the following path Servers >> SASAppRES >> Libraries >> HD4RES2

Then, open the following table "V_HDM_COMMON_SUBJ_CNT"

This data table contains the following fields:

Label	FieldName	Description
HDBP1_code	CD_PROJ_BUS	HD business project code (HDBPxxxx) of the base project
HDBP1_name	TX_PROJ_BUS_NAME	HD Project business name of the base project
HDBP1_abbreviation	TX_PROJ_BUS_ABBREV	HD Project business abbreviation of the base project
HDBP2_code	CD_PROJ_BUS2	HD business project code (HDBPxxxx) of the compared project
HDBP2_name	TX_PROJ_BUS2_NAME	Project business name of the compared project
HDBP2_abbreviation	TX_PROJ_BUS2_ABBREV	Project business abbreviation of the compared project
HD_ARCH_component	TX_ARCH_COMPONENT	Database component/DWH layer
Count_Date	D_COUNT	Datepart of the metrics calculation timestamp (at 23:59:59)
Count	MS_COMMON_SUBJ	Count of the total number of study records in common between the base and compared project
Count_New	MS_NEW_ COMMON_SUBJ	New number of common study subjects as from previous date and time

Reference table: V_HDM_MAP_TBL_PROJ

In SAS Enterprise Guide, the data table is accessible via the ‘Servers’ window, located at the bottom left.

First open the following path Servers >> SASAppRES >> Libraries >> HD4RES2

Then, open the following table "V_HDM_MAP_TBL_PROJ"

FieldName	Description	Used for dimension
TX_SCHEMA_NAM	Schema location of the data table	HD_ARCH_component
TX_TBL_NAM	Table name of the data table
TX_REG_NAM	HD internal DWH register name	HDBP_code
CD_PROJ_BUS	HD Project business code (HDBPxxxx)	HDBP_code
TX_PROJ_BUS_NAME	HD Project business code name
TX_PROJ_BUS_ABBREV	HD Project business abbreviation
TX_SQL_DP_TPE	Field or SQL statement used to identify the type of the data provider	HCO_NIDHICode
TX_SQL_DP_VAL	Field or SQL statement used to identify the data provider	HCO_NIDHICode
TX_SQL_SUBJ	Field or SQL statement used to identify the study subject
FL_INCL_METRIC_CNT_REC_PAT	Flag which indicates whether the table contributes toward the calculation of the metrics: 1, 2 => included in the figures calculation 0 => explicitly excluded from the calculation null => implicitly excluded from the calculation
DT_VALID_FROM	Timestamp as from when above properties are applicable
DT_VALID_TO	Timestamp as to when above properties are discarded

Calculation of common study subject

One study subject is defined as the entity for which data has been collected. Depending the data collection most of the time a study subject represent the patient.

Because of the respect for privacy it is important to understand that each data collection set of data tables were build in such a way that it has been made impossible to users to link data of the same patient from different data collections. Consequently it will be impossible to reproduce the same figures as the table provides.

For every new eHealth patient identification key a new identification key PER patient and PER data collection is created. Because access to different data collections does not imply access to a combination of them, this eHealth identification key has been hidden from all the users of the data collections. Consequently to deliver the requested metric, we have at our disposal a table not accessible to the users, which provide the link between the initial eHealth patient identification and the data collection specific identification.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:33

List of data providers (organizations)

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:34

List of data providers (individuals)

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:36

List of data users (organizations)

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:36

List of data users (individuals)

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:38

Status technical components

This data table is currently in development by the healthdata.be team.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Thu, 08/31/2023 - 08:38

Support Services for HD4RES v2

The Service Desk of healthdata.be (Sciensano) helps users of our applications and services and deals with requests and problems when they arise.

For most efficient processing of your request, we advise you to use our service portal: https://sciensano.service-now.com/sp.

Please find below our support window hours:

Jonas.VanBussel Wed, 08/30/2023 - 14:52

How to report an incident

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

To submit an incident related to the projects and applications that are in production, and facilitated or managed by the service healthdata.be of Sciensano, you first need to log in to the HD Service and Support portal.

After the log in step, you will arrive at the main page of the portal.

On the main page, you have to select "Get Help"

A new page with the title "Create Incident" will appear.

You can now document your incident or problem by providing following information:

Please indicate the urgency your problem needs to be resolved according to its business criticality.

Please indicate the type of problem you are experiencing.

When the problem type "Application" is selected, two extra fields appear: "Project name" and "Application".

Please select the appropriate information.

Please describe clearly and briefly (1 sentence) the subject of your problem.

Please describe in detail the problem. Following aspects are important for us to understand and to solve the problem:

a description of the actions you want to perform but fail to accomplish (Ex: provide us field name, validation rule, button, etc.);
a description (if possible) of the sequential steps you take to use the healthdata.be service or application you need support for;
a brief description of the technical problem you are experiencing (e.g. error messages)

We highly recommend to add a screenshot describing the problem (IMPORTANT: do not provide us patient data!).

You can add the screenshot by pressing "Add attachments"

On the right side of the form, the required information elements of the Incident form are listed. When these fields are completed, these field names will disappear in the "required information" box.

Only if all required fields are completed , a form can be submitted., by pressing the green "Submit" button.

If not all required fields were completed, a warning message will appear on top of the form.

Also, the missing required fields will be highlighted in green.

When the incident form was successfully submitted, an overview of your submission will appear in an new screen.

On the right of the screen, you will find the details , including the Incident number.

On the left of the screen, you will find a timeline of the handling your incident, starting with your creation.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:54

Submit a request for information about HD4RES v2

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

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

On the main page select "Request something".

A new page with the different types of request will appear.

Select the box "Request for information about HD".

A new page with the titles of the Request for information about HD will appear.

You can now document your request by providing following information:

Provide a short and clear description of your request for information (1 sentence).

Provide a detailed description of your request for information.

If available, please upload additional documents relevant for this request for information about HD.

On the right side of the form, the required information elements of the request form are listed. When these fields are completed, these field names will disappear in the "required information" box.

Only after all required fields have been completed, a form can be submitted by selecting the green Submit button.

If not all required fields were completed a warning message will appear on top of the form.

Also the missing required fields will be highlighting in green.

When the request form was successfully submitted, an overview of your request will appear in a new screen.

On the right of the screen, you will find the details , including the Request number

On the left of the screen, you will find a timeline of the handling your request, starting with your creation.

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 request (type : request for information) via our portal (https://sciensano.service-now.com/sp) 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!

Jonas.VanBussel Wed, 08/30/2023 - 14:54