HD4DP v.2 (Health Data For Data Providers)

Welcome to the technical documentation pages for the component "Health Data for Data Providers v.2, or HD4DP v.2", provided by the service healthdata.be (Sciensano).

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

General component information
How to request access for HD4DP v.2
How to access HD4DP v.2
The description of the data tables in HD4RES v.2 (documentation in progress)

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 Mon, 04/24/2023 - 15:20

General description of the application HD4DP v2

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

Components and features

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

NextGen Connect

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

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

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

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

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

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

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

Form.io

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

HD Connect (LOCAL Proxy)

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

Local datawarehouse

Each and every change in data entries on the form.io server is pushed towards the local datawarehouse (Local DWH) for easy reporting and data extraction. This local DWH consists of a PostgreSQL database.

Installation and maintenance

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

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

Typical use

A Local Study Lead (takes responsibility for the study or project within the participating health care organization. Often this is the head of the clinical department involved in the study or project) can:
- Log in using active directory
- Grant access to Local Study Associate and Local Study Support
- Select and access project
- Create, Find, Update, Delete, Submit (towards healthdata.be) and Correct a registration using form.io component
- Create, Find, Update, Delete, Submit and Correct a registration using form.io component
- View all registrations for project
A Local Study Associate (a health care professional that participates in the study or project) can:
- Log in using active directory
- Grant access to Local Study Support
- Select and access project
- Create, Find, Update, Delete, Submit (towards healthdata.be, MyCareNet and other destinations) and Correct a registration using form.io component
- View own registrations for project
A Local Study Support (A Local Study Associate can delegate registration to a Local Study Support. Often this is an administrative collaborator or staff of a department medical coding) can:
- Log in using active directory
- Select and access project
- Create, Find, Update, Delete, Submit (towards healthdata.be, MyCareNet and other destinations) and Correct a registration using form.io component
- Can view own registrations for project

manager Mon, 03/06/2023 - 12:14

Position of HD4DP v.2 in HD Architecture 2.0

The application HD4DP 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).

manager Wed, 11/09/2022 - 19:44

Dataflow description HD4DP v.2

Below we describe (high level) the dataflow between HD4DP v2 and the healthdata.be platform.

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

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

Step 3. Direct real time transfer of registry variables and technical ID of record from HD4DP v2 towards HD.

Step 4. Transfer of patient identifiers and technical ID of record from HD4DP v2 towards eHBox messaging client of HCO (HCO UM/EM).

Step 5. Transfer of patient identifiers and technical ID of record from eHBox messaging client of HCO (HCO UM/EM) towards TTP service of eHealth.

Step 6. Transfer of pseudonymized patient identifiers and technical ID of record from TTP service of eHealth towards eHBox messaging client of HD (HD UM/EM).

Step 7. Transfer of pseudonymized patient identifiers and technical ID of record from eHBox messaging client of HD (HD UM/EM) to HD Integration engine.

Step 8. Joining of pseudonymized patient IDs and the registry variables based on the technical ID and Transfer of the records from HD Integration engine towards Data Validation environment on DHW.

Step 9 - Option 1. Indirect transfer of patient identifiers and NIC-CIN variables from HD4DP v2 Local via the MyCareNet component of the HCO towards NIC-CIN (default).

Step 9 - Option 2. Direct real time transfer of patient identifiers and NIC-CIN variables from HD4DP v2 Local towards NIC-CIN (optional).

manager Mon, 03/06/2023 - 15:49

User manual of the application HD4DP v2

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

manager Tue, 09/20/2022 - 06:05

Request access to an HD application for a specific project

Healthdata.be applications such as HD4DP v2 and healthstat.be process sensitive personal information. Therefore, strictly controlled processes are used to grant access to these applications.

The Entity Access Management (EAM) portal of healthdata.be facilitates these processes. In this article we describe how to use it. To navigate to the EAM application, enter the URL https://eam.healthdata.be in your internet browser.

Note: As the documentation of the EAM portal is being updated on a regular basis, please be advised to check the Release notes first.

Select one of the following capacities that suits your position in order to request access to an HD application:

End-users
Single IT points-of-contact, also 'IT SPOC'
International users

Standard End-users

To request access to healthdata.be applications (such as HD4DP v2 and healthstat.be) as a standard end-user, you need to click on REQUEST ACCESS in the blue text box in the middle of the screen.

You will be directed to the next screen, where you select the button Log in with eID.

Clicking on this button leads you to the government's Federal Authentication Service (FAS), where you can log in with multiple digital keys with eID or digital identity.

If you choose to connect with ItsMe, you can enter your cell phone number.

Follow the instructions on your mobile device via the ItsMe application.

Once you have run through the ItsMe login procedure, you want to select the green confirmation button (available in FR and NL) in the screen below to access the Sciensano environment.

After selection of the confirmation button, you are logged in to the EAM portal page as indicated by the available My profile and Log out options to the top-left of your screen.

When selecting the REQUEST ACCESS link in the blue highlighted text box, in order to fill out the Request access form, the following message appears:

Click on the My profile link in the message, which redirects you to your profile page. Your user profile needs validation before being able to enter and complete the Request access form.

Select the Edit tab to complete your profile information.

Next to the profile information that is automatically prefilled based on your eID data, you need to complete the following fields:

NIHDI Number: Your NIHDI number if available.

Organization: Add the organization(s) you are affiliated with. This field includes the name and NIHDI number of the organization.

Email address: Mandatory field for which the content can't be retrieved from the eID. Your email address will be used for communication on the profile validation and access request.

State: Select one of the options (see image underneath):

Draft: This status indicates that you have not finished completing the profile fields yet. Only you can see the filled in data at this stage. Modification of the profile information is restricted to the status "Draft". You can however Save profile information as Draft to finalize and send it for validation lateron.
Validation Requested: The provided user profile information is complete and you want to send it for validation to the SPOC.

Click on the Save button to send your profile information to the SPOC. An Access Denied message appears on the screen, indicating you can't modify your filled in and sent profile information anymore.

Return to the My profile page to see your profile has the pending status. Also, the Edit tab has disappeared, preventing from modifications afterwards:

Your profile will soon be validated by the SPOC, which will be visible on your profile page as follows:

After validation of your profile by the SPOC, you select Home to return to the EAM portal page. Attention: Do not select the button "Request access" (soon: "Request SPOC rights"), since this leads to the process of requesting access as a SPOC.

In the EAM portal page you want to select the REQUEST ACCESS link in the blue highlighted text box again.

Select the hospital you are affiliated with for the application(s) and project(s) you want to request access to.

You can now start completing the Request Access form.

Please fill in all required fields (indicated with a red asterisk *), make a selection in the mandatory drop-down lists and, optionally, tick the check boxes for additional help and/or information.

Type of login field:

If you select "Belgium resident" for the field “Type of Login”, entering the mobile phone number is optional.

If you are a "Non-Belgium resident", the Mobile phone number field becomes mandatory to allow for the two factor authentication:

Role of requestor in project field

You must indicate your role in the project (Local Study Lead, Local Study Associate or Local Study Support). Your role determines your access options in HD4DP2 for this project. Read more about the scope of the roles in User roles in HD4DP v2.

When selecting Local Study Support you will be asked to select the name of your Local Study Associate in a drop-down list. This list is automatically populated and specific to the organization you have selected earlier.

HD4DP2.0 field

Click in the field under HD4DP2.0 if you want to access the application to make registrations for the selected project:

Healthstat.be field

Click in the field under healthstat.be if you want to access the reporting of the selected project:

It can happen that a user inadvertently submits requests for access to the same applications and/or projects. The requests are screened for duplicates by checking on organization number, role, author group and project code. In case duplicates are detected, the end-user will receive the following message:

Once you have completed the Request Access form, click on the Submit button. When the submission was successful, you will receive a confirmation message.

Single IT points-of-contact (IT SPOC)

A single-point of contact or SPOC is a role that extends beyond the function of a VTE/RAE. More specific, it can be any employee within an organization whom this role has been assigned to.

To request access to healthdata.be applications such as like HD4DP v2 and healthstat.be as a single-point of contact (SPOC), you want to select GIVE ACCESS in the white text box to the right of the screen.

If you have not yet requested access to these forms, and therefore are not recognized as a user with the SPOC role, you will receive the following message:

In this case you want to select My Profile (top left in the menu) and click on the button Request access (soon: "Request SPOC rights").

The Request access [RAE] screen pops up.

Fill in all requested fields and click on the Submit button.

After submission of the RAE form healthdata.be support carries out a background check considering your SPOC authority within the organization mentioned, and will send you a confirmation e-mail with a special token. Once you have received this token, return to the My Profile page and select the button Enter access token.

The Access token screen appears:

Fill in the NIHDI code for your organization and the access token you received per e-mail. After clicking on Submit, you will be redirected to the EAM portal page, where you again select GIVE ACCESS.

The ACCESS REQUEST form appears. By filling out the requested fields, a SPOC is able to give access to users within their organization who want to access a healthdata.be application (HD4DP2.0 or Healthstat).

Once you have completed the Access Request form, click on the Submit button. When the submission was successful, you will receive a confirmation message.

If you now return to My profile, you will see that it has been extended with the information "Responsible Access Entry" under User role(s). Also the tabs Profiles, Requests, Batch create requests and Edit have been added.

The Profiles tab of the validated SPOC profile offers the possibility to Search, Select and Sort profiles. Selected user profiles in the list can be Validated or Rejected via the Action drop-down menu.

In the Requests tab the SPOC can manage the overview of requests. More information is to be found on SPOC actions upon a request.

See documentation under Give access to multiple users in batch for more information on the Batch create requests tab.

Saved user profile information can't be modified, unless upon action of the SPOC. The Edit tab offers the option to enter the NIHDI number, add organizations, modify the email address and toggle the state between Validated or Rejected. Select the Save button to install the new profile information.

International users

For international users a link to a special form will be provided:

https://eam.healthdata.be/forms/hd_eam_access_request_user_int

Selecting this link redirects you to a more extensive Request Access form. Fill in all required fields (indicated with a red asterisk *), make a selection in the mandatory drop-down lists and, optionally, tick the check boxes for additional help and/or information:

After submitting the form, an e-mail is sent to the Service Desk staff for an identification and authorization process. If the request is approved, the international user receives an e-mail with account information. International users, however, are not able to log in, nor can they consult overviews of requests at this moment.

Bart.Servaes Tue, 03/21/2023 - 16:12

User roles in HD4DP v2

Several user roles are possible in the HD4DP v2 application:

Local Study Lead: This role takes responsibility for the study or project within the participating healthcare organization. Often this is the head of the clinical department involved in the study or project. The Local Study Lead can:

make registrations in HD4DP v2
view all registrations made by colleagues (regardless of role) for the study or project

Local Study Associate (author): The Local Study Associate is a healthcare professional that participates in the study or project. He/she reports/records medical information towards the researcher using HD4DP v2 and thereby assumes responsibility on the correctness of the reported information. He/she is considered to be the author of the registration. For each author an author group will be created. This will be represented in the registration form. The Local Study Associate can:

make registrations in HD4DP v2
only see all registrations assigned to his/her author group, not those of other colleagues (other author groups) in the same healthcare organization participating in the same study or project

Local Study Support (co-author): A Local Study Associate can delegate registration to a Local Study Support. Often this is an administrative collaborator or staff of a department medical coding. The Local Study Associate is still considered the author of the registration; the Local Study Support is considered co-author. The Local Study Associate can view and change registrations made by Local Study Support. The Local Study Support can:

make registrations in HD4DP v2
only see all registrations assigned to his/her author group, not those of other colleagues (other author groups) in the same healthcare organization participating in the same study or project

By default, only 1 Local Study Lead is created by healthdata.be (Sciensano) for each project within each organization. This means that only 1 person can see all registrations made for that project within that organization. This policy prevents HD4DP v2 users to see personal and sensitive information from persons they do not have a therapeutic relationship with.

In case organizations create more then 1 Local Study Leads for a project within that organization, so that they all can see each others registrations, and thus personal and sensitive information from persons they do not have a therapeutic relationship with, the organizations are fully responsible and accountable for this policy deviation. Healthdata.be (Sciensano) cannot be held responsible or accountable for this policy deviation. Professionals wanting to participate in projects are kindly suggested to contact the Data Protection Officer (DPO) of their organization to consult them about this intended policy deviation.

johanvanbussel Mon, 03/20/2023 - 11:51

Give access to an HD application for someone from your organization

To give access to the applications of healthdata.be (like HD4DP v2 and healthstat.be), you need to click on GIVE ACCESS in the white text box on the EAM portal page.

You can give access to

a single user
multiple users in batch

Give access to a single user

After selection of GIVE ACCESS on the EAM portal page, an ACCESS REQUEST form is shown.

Completing this form is similar to the process on the Request Access page for standard end-users. In the capacity of a SPOC, however, you will now fill in an Access Request form for a user within your organization.

Please fill in all required fields (indicated with a red asterisk *), make a selection in the mandatory drop-down lists and, optionally, tick the check boxes for additional help and/or information.

Organization NIHDI number

The NIHDI number of the organization is already provided, since your account is connected to this organization.

Role in project

When selecting Local Study Support, you will be asked to make a selection in the drop-down list of Author groups. These author groups are specified for the organization in question.

HD4DP2.0 field

Click in the field under HD4DP2.0 if you want to access the application to make registrations for the selected project:

Healthstat.be field

Click in the field under healthstat.be if you want to access the reporting of the selected project:

Once you have completed the access request form, click on the Submit button. When the submisson was successful, you will receive a confirmation message.

In the Requests tab the SPOC can manage the overview of requests. More information is to be found on SPOC actions upon a request.

See documentation under Give access to multiple users in batch for more information on the Batch create requests tab.

The Edit tab (see image below) offers the possibility for a SPOC to modify the own profile regarding NIHDI number, Organization, Email address and State. Select the Save button to install the new profile information.

Continue to Give access to multiple users in batch in order to give access to multiple users in one operation.

Give access to multiple users in batch

The person whom has been assigned the SPOC role for the healthcare organization (HCO) is able to give access to multiple users in batch. The SPOC therefore needs to return to the User profile page and select the tab Batch create requests.

In the tab Batch create requests a CSV file can be selected via the file selection button.

Upload the CSV file and click on the Run the batch creation button. An example of a CSV file structure is available here:

hd_eam_bulk_access_requests_example.csvDownload

By doing so, a master request per line will be automatically generated, and then the information will be split into sub-requests (one per application or project) and saved in the healthdata.be DB2 for further processing.

A table schema (https://specs.frictionlessdata.io//table-schema/) to validate CSV looks as follows. An example file is available here: eam_csv_batch_requests_schema.json

User roles and corresponding values

To complete the “role”, 3 different choices are possible:

1= Local Study Lead: Only 1 Local Study Lead can be created by healthdata.be (Sciensano) for each registry within each organization.
2= Local Study Associate (= author). This will be the default role a user will receive, the reason why it was prefilled with “2”.
3= Local Study Support (= co-author). This role can be given if it is more suitable for the user. A Support will always need an Associate to which he/she will be assigned.

When selecting role 1 and 2 (= Local Study Lead and Local Study Associate), the name of the ‘Local Study Lead or Associate’ is expected in the field “author_group”. To be filled in in the format <first_name last_name> of the Associate, with just 1 space (tab) between the two names).

When selecting role 3 (= Local Study Support), the name of the ‘Local Study Associate’ is expected in the field “author_group”. To be filled in in the format <first_name last_name> of the Associate, with just 1 space (tab) between the two names).

Bart.Servaes Mon, 03/20/2023 - 11:53

Overview of the requests

After submission of the requests for access and receipt of the confirmation message, you are able to consult the validation process and other features of the requests via the tab Requests overview on the My Profile page.

Based on the scope of the requests overview, we can distinguish between

end-user, and
IT SPOC (single point-of-contact).

Overview of the requests for end-users

In order to view their own requests, end-users can open the My Profile page and click on the tab Requests overview.

The overview shown can be searched and sorted in the top row as needed (see figure below). End-users will only see a list of requests they have created for themselves.

Request UUID field

This field contains the unique ID’s of the requests. The occurence of the same unique ID in several rows indicates that this master request consists of several subrequests, each one per project and per application that has been selected in the request form. These subrequests are than saved in the healthdata.be DB2 for further processing.

Status field

The Status field indicates whether the request has been created (value “created”; meaning to be approved by the SPOC) or approved (value “approved_rae”; meaning the request was approved by the SPOC and will be ready for sharing credentials).

Role in project field

The values in this field are Local Study Lead, Local Study Associate, Local Study Support. More detailed information about these roles can be found in User roles in HD4DP v2.

Application field

This field contains the application you have selected in the Request Access (End-User) or Access Request form to access the public health projects: HD4DP2.0 or Healthstat.be.

Project code field

The value in this field is the Healthdata.be business project code. Entering this code in the publically accessible FAIR portal (fair.healthdata.be) results in the dataset for this project.

Or you can enter this code in the Advanced search field on the Healthdata.be docs pages to find the respective project’s documentation.

Overview of the requests for IT single points-of-contact (IT SPOC)

SPOCs have the capacity to view all requests for their organization.

To view the Status of the request of the users of their affiliation, the SPOC needs to select the My Profile page and to click on the tab Requests overview (see screenshot below). Requests in this overview can be searched and sorted as needed.

New: Actions field

This field describes the extra actions a SPOC can take, i.e. approve or reject requests. This functionality is explained in SPOC actions upon a request in more detail.

Request UUID field

Status field

The Status field can only receive the status “approved_rae” since the request was made by the SPOC.

Role in project field

The values in this field are Local Study Lead, Local Study Associate, Local Study Support. More detailed information about these roles can be found in User roles in HD4DP v2.

Application field

This field contains the application you have selected in the Request Access (End-User) or Access Request form to access the public health projects: HD4DP2.0 or Healthstat.be.

Project code field

The value in this field is the Healthdata.be business project code. Entering this code in the publically accessible FAIR portal (fair.healthdata.be) results in the dataset for this project.

Or you can enter this code in the Advanced search field on the Healthdata.be docs pages to find the respective project’s documentation.

Bart.Servaes Wed, 04/05/2023 - 09:58

SPOC actions

In this article, we cover the different actions of a SPOC in more detail.

SPOC actions upon a request

SPOCs will be notified in case a request for access was made by a colleague, allowing them to review the overview table to manage all requests for their organization.

To open the overview table, the SPOC needs to navigate to "My Profile" followed by selection of the "Requests" tab. The overview of the requests appears (see below).

In the Actions field an Approve/Reject selection button is displayed next to each request with the status created or approval_requested (framed in blue). Two actions are possible now: the SPOC can either approve or reject the user's request.

When selecting Approve, and after confirmation of this action, the status of the request changes to "approved_rae" and the dates in both fields Updated and Completed are updated accordingly as demonstrated in the screenshots below. Once the registry goes in production the account will be created automatically and the credentials will be shared to the user by e-mail.

Approve action:

Pop-up confirmation query:

Approved:

When returning to the overview, you will notice that the status of the request has changed to "approved_rae". The Approve/Reject button in the Actions field has disappeared.

When selecting Reject, and after confirmation of this action, the request receives the status "rejected", the dates in the fields Updated and Completed are updated accordingly. A rejected request remains in the overview for information purposes. Compare following screens:

Reject action:

Pop-up confirmation query:

Rejected:

The requester will also be notified of the rejected request by e-mail:

Dear,

Your request for access to EAM was rejected.

Please contact your HD4DP SPOC for more information.

Best regards
Healthdata Support

Bart.Servaes Wed, 04/05/2023 - 09:44

Access the application HD4DP v2

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

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

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

With these credentials you can access the application HD4DP v2 of your organization:

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

manager Wed, 02/08/2023 - 12:13

Navigate to a project

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

Suppose we want to participate in study Orthopride Hip. In that case, we must select the study program QERMID Orthopedics first. You can see now three study projects: Orthopride Hip, Orthopride Knee and Orthopride Total femur.

Select the study project Orthopride Hip.

You will see that the study project Orthopride Hip consists of three study sections: Primo-implantation, Revision and Resection.

manager Wed, 02/08/2023 - 12:17

Create a registration

Suppose we want to create a "Primo-implantation" registration for the study project Orthopride Hip. In that case, we need to navigate to the study program QERMID Orthopedics and then to the study project Orthopride Hip. There we need to select "Primo-implantation" in the dark blue left menu.

You will see the number of versions of this study section. In this case, there is only one version.

When you select the highest version of this study section for the first time, you will see an empty table in the main part of your screen. The table contains, among others, the following items: Registration ID, Progress, Author, Co-author, Unique ID, Business key, Registration code, National registry ID of the patient...

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

After pressing the button "+ New registration", the main screen will now be replaced with 2 sections: a study form (in the middle of the screen) and a Table of contents (on the right side of the screen).

By completing the study form, you will create a "Primo-implantation" registration for the study project Orthopride Hip.

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

By pressing the tab "Progress" on the right side of the screen , the Table of contents will be replaced by a progress bar and a list of open validation errors.

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

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

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

When the study form is saved or submitted, the screen switches to the overview table. Now, this table is not empty anymore but shows the saved or submitted registration.

manager Fri, 01/07/2022 - 15:19

Find a registration

Suppose we want to find a "Primo-implantation" registration of the study project Orthopride Hip. In that case, we need to navigate to the study program QERMID Orthopedics and then to the study project Orthopride Hip. There we need to select "Primo-implantation" in the dark blue left menu.

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

In the header of the summary table, you can use the filter below each column label. In the example below, the last name "Khan" has been entered in the filter (text field), so only the record with "Khan" is displayed.

manager Fri, 01/07/2022 - 15:21

Update a registration

Suppose we want to update a "Primo-implantation" registration of the study project Orthopride Hip. In that case, we need to navigate to the study program QERMID Orthopedics and then to the study project Orthopride Hip. There we need to select "Primo-implantation" in the dark blue left menu.

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

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

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

Once you have found the registration, you can open the registration's study form by clicking on the corresponding row in the summary table.

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

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

A registration can be updated as long as it has the status "Saved" and as long as the registration not has been submitted. A submitted registration cannot be updated or deleted again.

manager Fri, 01/07/2022 - 15:22

Delete a registration

Suppose we want to delete a "Primo-implantation" registration of the study project Orthopride Hip. In that case, we need to navigate to the study program QERMID Orthopedics and then to the study project Orthopride Hip. There we need to select "Primo-implantation" in the dark blue left menu.

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

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

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

Once you have found the registration you want to delete, you must select the registration by checking the checkbox at the beginning of the row in the summary table.

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

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

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

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

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

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

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

manager Fri, 01/07/2022 - 15:24

Submit a registration

Suppose we want to submit a "Primo-implantation" registration of the study project Orthopride Hip. In that case, we need to navigate to the study program QERMID Orthopedics and then to the study project Orthopride Hip. There we need to select "Primo-implantation" in the dark blue left menu.

A registration can be submitted in two ways. The first way is at the end of the creation process using the study form (see: "Create a registration").

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

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

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

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

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

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

Once you confirm the submission, you cannot change the content of the registration(s). Sent registrations can also no longer be deleted.

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

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

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

manager Thu, 12/08/2022 - 15:32

Send a correction registration

Suppose you want to send a correction to a submitted registration. In that case you need to navigate in the dark blue left menu to the study program and next to the study project concerned. Then, select the respective part.

Important: A correction registration can only be added, if the status of the registration is submitted.

A correction registration can be added in two ways:

via the overview table;
via the preview page of a registration.

Send a correction via the Overview table

When the registration was submitted, the correction registration can be added via the overview table. This table will appear in the main part of your screen, when selecting a version of a study section. It contains, among others, the following items: Registration ID, Progress, Author, Co-author, Unique ID, Business Key, Registration Code, National Registry ID of the patient…

Use the filters in the table header to find the registrations that need a correction. For example, you can use the "Status" (set to "Sent") filter to get only submitted registrations.

Then, you must select the "Action" button at the top right of the overview table.

Three options are displayed: "Submit", "Delete" and "Add correction", but only the option "Add correction" is available for submitted registrations. Now select "Add selection".

After you have selected "Add correction", a pop-up window will appear asking you to confirm the action of adding a correction registration for the selected registration. If you are sure of this action, click on "Confirm". If not, click on "Cancel".

If you confirm, you will be redirected to the correction registration form.

The correction DCD only contains:

Business key of original registration,
The name of Data Collection,
The field or variable which is wrong,
The correction value,
Comment field.

Some fields are automatically filled with values of the original registration, e.g "Data collection " and "Business_KEY" .

The number of fields to correct in the same correction registration is limited to three. You can add another field to correct by clicking on "Add another".

When you finish filling the correction registration, you can add a comment and send the correction by clicking on the "Submit" button.

Send a correction via the Preview page

We can also add a correction form in the preview page of a registration. Therefore, open the overview table and click on the registration you want to correct. Now, you will be redirected to the preview page.

Click on the "Add correction" button to add a correction for current registration.

Follow same steps described in previous section (See "Send a correction via the Overview table")

Preview a correction registration

The correction form is a generic form available in the left dark blue menu for all projects and DCDs.

If you want to preview "correction registrations" already submitted, you navigate to the study program Correction form and then to the study project Correction form. Finally, you select the last version of "Correction form" in the dark blue left menu.

All correction registrations (of different projects) will be displayed. You can use the filters in the table header to find a specific registration.

If you want to preview a correction registration, you need to click on the desired registration in the overview table. You will now be redirected to the preview page.

Bart.Servaes Thu, 03/23/2023 - 11:23

Registration statuses in HD4DP v2

This article explains the different registration statuses in HD4DP v2.

Statuses are shown in Status column

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

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

Description of the statuses:

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

Deleted: Registration has been deleted.

Submitted: Registration has been submitted and sent.

hamza.kursun@s… Thu, 11/03/2022 - 15:07

Technical manual of the application HD4DP v2

Technical documentation for IT services

manager Tue, 07/05/2022 - 14:23

HD4DP v2 Installation

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

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

Server Installation and Configuration

Installing and configuring the server requires the following actions:

install and configure the server as described in the article "HD4DP 2.0 Infrastructure instructions";
- complete and return to support.healthdata@sciensano.be the server configuration file "HD4DP v2 Infrastructure Sheet".

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

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

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

"Small": Small data provider;
"Medium": Medium data provider;
"Large": Big data provider.

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

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

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

Server installation timing

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

Starting date;
Finalization date.

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

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

manager Wed, 02/08/2023 - 14:39

HD4DP v2 Infrastructure instructions

Introduction

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

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

Overview

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

An HD4DP v2 deployment comprises of following components:

Form.io component
MongoDB
PostgreSQL
Nextgen Connect

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

Network configuration

IP

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

DNS

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

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

Firewall

The following connections should be possible in the firewall flow:

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

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

Server installation

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

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

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

Instructions

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

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

Please find the installation steps below.

Installation steps

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

Configuration steps

Connecting to the server

Log into the machine with the healthdata.be user created in the previous section.

Instructions (from a Windows machine):

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

Administrator account for internal use

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

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

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

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

Create the user:

sudo adduser <username>

Add the user to the sudo group

sudo usermod -aG sudo <username>

Installation and configuration of the software stack

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

Backups

The configuration of the HD4DP v2 server is administered by healthdata.be and does not require backups.

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

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

Patching and Updates

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

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

Antivirus and Monitoring

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

Contact information

johanvanbussel Wed, 02/08/2023 - 15:05

HD4DP v2 Infrastructure Sheet

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

Below you can find the description of the necessary information:

SERVER CONNECTION

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

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

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

SERVER MACHINE

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

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

ATTACHED DRIVE FOR BACKUPS

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

Link / IP address
Path
Username
Password ³

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

USER MANAGEMENT

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

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

LDAP configuration (Optional)

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

Connection URL
Username
Password³

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

SOFTWARE CONFIGURATION

Encryption Module interface

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

Note: if the encryption module is not yet purchased (or developed), HD4DP can already be installed; the EM can then be configured in HD4DP once it is available. Please note that HD4DP 1.x and HD4DP 2.0 cannot use the same EM.

REST web service
File system

REST web service interface

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

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

File system interface

"Incoming directory: Directory where HD4DP checks for incoming files"
"Incoming directory: Directory where HD4DP writes outgoing files"
"Incoming directory: Directory to which HD4DP moves successfully processed files"
"Incoming directory: Directory to which HD4DP moves unsuccessfully processed files"

johanvanbussel Wed, 02/08/2023 - 15:25

HD4DP v2 S2S API

The HD4DP v2 S2S API is a unified Application Programming Interface (API) that will allow participating Healthcare Organizations (HCO) to submit DCDs data to HD4DP2.0 fully automated. In the manual of the application HD4DP v2 we provide detailed information about the S2S API:

Important note: For code fields (fieldType = 'CODE') the id of the codeListValue item must be sent, not the code value or the label. In future releases it will be made possible to also send the code value.

Please read this documentation before its project specific use.

API description

API end-point	Response	Authentication	Notes
/api/organizations	List of organizations. Client must select the right *organizationId*	No	Current existing end-point is: /api/installation/organizations We’ll create this new end-point with a different signature re-routing the call to this existing one or we will refactor the existing one to this new signature.
/api/dcd/menu/structure? organization-id={organizationId}	List of projects of the given organization, dcds of each project, dcdVersions of each dcd in a JSON format Client can get *dcdId* and *dcdVersionId* (optional) which are needed on following API calls.	No	https://github.com/Sciensano-Healthdata/hd4-formio/blob/develop/dev/mock_menu_structure/menu-structure.json
/api/dcd/payload/definition? dcd-id={dcdId}; <optional>version={version}; <optional>language-id={languageId}	List of all the fields of the form as well as their corresponding data-types that are allowed in the json data structure for the *Payload*	Yes	This field names values are the key properties in the formIO json config form. When we implement this new api end-point, we need to parse the json content in order to get the key properties. Given these field keys, we’ll get each field definition from new API end-points helpers: /api/dcd/field?field-id={fieldId} /api/dcd/codelist?codelist-id={codelistId} These ones are described in the next table. <optional parameter> version={version} : If this parameter is not provided, latest one is assumed <optional parameter> language-id = {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values: en: English nl: Dutch fr: French Client must build this json object as the payload data to be sent based on this list of fields, on the last api call
/api/dcd/payload/example?dcd-id={dcdId}; <optional>version={version}	Example of payload in JSON format	Yes	Providing this API end-point in order to help the Client on the Payload build with an example <optional parameter> version={version} : If this parameter is not provided, latest one is assumed
/api/dcd/payload/submit? organization-id={*organizationId}; dcd-id={**dcdId}; <optional>version={**version}; <optional>data-src-type={**dataSrcType}; POST* *Payload*	Results info if succeed Error info if failed	Yes	Some implementation tasks is needed in here in order to return the result info (either succeed or failed). Similar like the one in *HDConnectProxyRestTemplate.postCsv* method, and the *CsvExecutionResult* object build. <optional parameter> version={version} : If this parameter is not provided, latest one is assumed. <optional parameter> data-src-type={dataSrcType} : permitted values: API CSV If this parameter is not provided, default values is <HD4DP>.
api/dcd/payload/submit?organization-id={organizationtId};dcd-id={dcd-id};<optional>dcd-version-id={dcdVersionId};<optional>incl-submit-data={inclSubmitData}; <optional>incl-submit-results={inclSubmitResults}; *GET method*	List of submitted dcds data and/or their corresponding business keys or validation errors.	Yes	<optional parameter> dcd-version-id={dcdVersionId} : If this parameter is not provided, lastest one is assumed <optional parameter> incl-submit-data={inclSubmitData} : If this parameter is not provided, default values is <false> <optional parameter> incl-submit-results={inclSubmitResults} : If this parameter is not provided, default values is <true>

Get organizations

Request example

GET /api/organizations

Request response

[

{

"organizationId": 1,

"organizationCode":"12345",

"name":"First Organization Name",

"loginMethods":[

"USERNAME_PASSWORD",

"EID"

]

{

"organizationId": 2,

"organizationCode":"32154",

"name":"Second Organization Name",

"loginMethods":[

"EID"

]

}

]

Get the DCD menu structure

Request example

GET /api/dcd/menu/structure?organization-id={organizationId}

Request parameters

{organizationtId}: Id of the organization for which we want to list the menu structure

Request response

All the menu structure for that organization, including projects, dcds of each project and dcd versions of each dcd, in a JSON format.

[

{

"id": 4,

"key": "zephyr_pneumo_program",

"projects": [

{

"id": 4,

"key": "zephyr_pneumo_project",

"dcds": [{

"id": 9,

"key": "zephyr_pneumo_t1_dcd",

"dcdVersions": [{

"id": 9,

"version": 1,

"supportsEN": false,

"supportsFR": true,

"supportsNL": true

}]

{

"id": 10,

"key": "zephyr_pneumo_tr_dcd",

"dcdVersions": [{

"id": 10,

"version": 1,

"supportsEN": false,

"supportsFR": true,

"supportsNL": true

}]

. . .

]

Get DCD field definitions

Request example

GET /api/dcd/payload/definition?dcd-id={dcdId};version={version};language-id={languagerId}

Request parameters

{dcdId}: Id of the dcd
<optional parameter> {version}: If this parameter is not provided, latest one is assumed
<optional parameter> {languageId}: language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values:
- en: English
- nl: Dutch
- fr: French

Request response

{

"CD_SURGL_APPR_FEMO": {

"field_type": "CODE",

"data_type": "number",

"code_list": [

{

"ID": 68224,

"CODE_VALUE": "870646003",

"LABEL_EN": "Femoral (Hemi)"

{

"ID": 68225,

"CODE_VALUE": "465954006",

"LABEL_EN": "Femoral + Cup"

}

]

"D_IMPLANT": {

"field_type": "DATE",

"data_type": "timestamp",

"code_list": null

"TX_TPE_INSTRU": {

"field_type": "FREE TEXT",

"data_type": "string",

"code_list": null

"MS_PAT_HGHT": {

"field_type": "FREE TEXT",

"data_type": "number",

"code_list": null

}

Get DCD payload example

Request example

GET /api/dcd/payload/example?dcd-id={dcdId};version={version}

Request parameters

{dcdId}: Id of the dcd
<optional parameter> {version}: If this parameter is not provided, latest one is assumed

Request response

Given the previous Payload field definition example on previous chapter, we build a payload content example accordingly.

{

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-04-30T22:00:00",

"TX_TPE_INSTRU": "P-432",

"MS_PAT_HGHT": 180

}

Submit DCD registrations

Request example

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

Header:

MediaType.APPLICATION_JSON

Body:

{

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-04-30T22:00:00",

"TX_TPE_INSTRU": "P-432",

"MS_PAT_HGHT": 180

{

"CD_SURGL_APPR_FEMO": 68225,

"D_IMPLANT": "2021-04-14T22:00:00",

"TX_TPE_INSTRU": "P-545",

"MS_PAT_HGHT": 1209

{

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-05-01T22:00:00",

"TX_TPE_INSTRU": "T-678",

"MS_PAT_HGHT": 210

}

Request parameters

{organizationtId}: Id of the organization for which we want to submit the DCD registration.

{dcdId}: Id of the DCD we want to submit.
<optional parameter> {version}: Id of the DCD Version we want to submit. If this parameter is not provided, latest one is assumed.
<optional parameter> {dataSrcType}: The data source type e.g: API or CSV.

Request payload

{Header}: MediaType.APPLICATION_JSON
{Body}: JSON object with an array of DCDs data to be submitted, following the specifications and examples provided by the described api end-points:

GET /api/dcd/payload/definition
GET /api/dcd/payload/example

Request response

Client get a response per each DCD line. If the DCD submission was successful, Client will get a TXT_BUSINESS_KEY value. If it was failed, Client will get an error detailed info: Http Status Code, Name and Exception details:

{

"TX_BUSINESS_KEY": "NISS 12.06.01-052.46 30/04/2021 67864",

{

"HTTP_STATUS_CODE": 405,

"HTTP_STATUS_NAME": "Method Not Allowed",

"HTTP_STATUS_EXCEPTION_DETAILS": "Exception details for Method Not Allowed example",

"TX_BUSINESS_KEY": "NISS 12.06.01-071.48 01/05/2021 67864",

}

User / password

The username and password can be requested at our Servicedesk.

pedro.fernandez Tue, 03/14/2023 - 18:30

1. End-to-End process to submit DCD registrations

API description

API end-point	Response	Authentication	Notes
/api/organizations	List of organizations. Client must select the right *organizationId*	No	Current existing end-point is: /api/installation/organizations We’ll create this new end-point with a different signature re-routing the call to this existing one or we will refactor the existing one to this new signature.
/api/dcd/menu/structure? organization-id={organizationId}	List of projects of the given organization, dcds of each project, dcdVersions of each dcd in a JSON format Client can get *dcdId* and *dcdVersionId* (optional) which are needed on following API calls.	No	https://github.com/Sciensano-Healthdata/hd4-formio/blob/develop/dev/mock_menu_structure/menu-structure.json
/api/dcd/payload/definition? dcd-id={dcdId}; <optional>version={version}; <optional>language-id={languageId}	List of all the fields of the form as well as their corresponding data-types that are allowed in the json data structure for the *Payload*	Yes	This field names values are the key properties in the formIO json config form. When we implement this new api end-point, we need to parse the json content in order to get the key properties. Given these field keys, we’ll get each field definition from new API end-points helpers: /api/dcd/field?field-id={fieldId} /api/dcd/codelist?codelist-id={codelistId} These ones are described in the next table. <optional parameter> version={version} : If this parameter is not provided, latest one is assumed <optional parameter> language-id = {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values: en: English nl: Dutch fr: French Client must build this json object as the payload data to be sent based on this list of fields, on the last api call
/api/dcd/payload/example?dcd-id={dcdId}; <optional>version={version}	Example of payload in JSON format	Yes	Providing this API end-point in order to help the Client on the Payload build with an example <optional parameter> version={version} : If this parameter is not provided, latest one is assumed
/api/dcd/payload/submit? organization-id={*organizationId}; dcd-id={**dcdId}; <optional>version={**version}; <optional>data-src-type={**dataSrcType}; POST* *Payload*	Results info if succeed Error info if failed	Yes	Some implementation tasks is needed in here in order to return the result info (either succeed or failed). Similar like the one in *HDConnectProxyRestTemplate.postCsv* method, and the *CsvExecutionResult* object build. <optional parameter> version={version} : If this parameter is not provided, latest one is assumed. <optional parameter> data-src-type={dataSrcType} : permitted values: API CSV If this parameter is not provided, default values is <HD4DP>.
api/dcd/payload/submit?organization-id={organizationtId};dcd-id={dcd-id};<optional>dcd-version-id={dcdVersionId};<optional>incl-submit-data={inclSubmitData}; <optional>incl-submit-results={inclSubmitResults}; *GET method*	List of submitted dcds data and/or their corresponding business keys or validation errors.	Yes	<optional parameter> dcd-version-id={dcdVersionId} : If this parameter is not provided, lastest one is assumed <optional parameter> incl-submit-data={inclSubmitData} : If this parameter is not provided, default values is <false> <optional parameter> incl-submit-results={inclSubmitResults} : If this parameter is not provided, default values is <true>

Get organizations

Request example

GET /api/organizations

Request response

[

{

"organizationId": 1,

"organizationCode":"12345",

"name":"First Organization Name",

"loginMethods":[

"USERNAME_PASSWORD",

"EID"

]

{

"organizationId": 2,

"organizationCode":"32154",

"name":"Second Organization Name",

"loginMethods":[

"EID"

]

}

]

Get the DCD menu structure

Request example

GET /api/dcd/menu/structure?organization-id={organizationId}

Request parameters

{organizationtId}: Id of the organization for which we want to list the menu structure

Request response

All the menu structure for that organization, including projects, dcds of each project and dcd versions of each dcd, in a JSON format.

[

{

"id": 4,

"key": "zephyr_pneumo_program",

"projects": [

{

"id": 4,

"key": "zephyr_pneumo_project",

"dcds": [{

"id": 9,

"key": "zephyr_pneumo_t1_dcd",

"dcdVersions": [{

"id": 9,

"version": 1,

"supportsEN": false,

"supportsFR": true,

"supportsNL": true

}]

{

"id": 10,

"key": "zephyr_pneumo_tr_dcd",

"dcdVersions": [{

"id": 10,

"version": 1,

"supportsEN": false,

"supportsFR": true,

"supportsNL": true

}]

. . .

]

Get DCD field definitions

Request example

GET /api/dcd/payload/definition?dcd-id={dcdId};version={version};language-id={languagerId}

Request parameters

{dcdId}: Id of the dcd
<optional parameter> {version}: If this parameter is not provided, latest one is assumed
<optional parameter> {languageId}: language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values:
- en: English
- nl: Dutch
- fr: French

Request response

{

"CD_SURGL_APPR_FEMO": {

"field_type": "CODE",

"data_type": "number",

"code_list": [

{

"ID": 68224,

"CODE_VALUE": "870646003",

"LABEL_EN": "Femoral (Hemi)"

{

"ID": 68225,

"CODE_VALUE": "465954006",

"LABEL_EN": "Femoral + Cup"

}

]

"D_IMPLANT": {

"field_type": "DATE",

"data_type": "timestamp",

"code_list": null

"TX_TPE_INSTRU": {

"field_type": "FREE TEXT",

"data_type": "string",

"code_list": null

"MS_PAT_HGHT": {

"field_type": "FREE TEXT",

"data_type": "number",

"code_list": null

}

Get DCD payload example

Request example

GET /api/dcd/payload/example?dcd-id={dcdId};version={version}

Request parameters

{dcdId}: Id of the dcd
<optional parameter> {version}: If this parameter is not provided, latest one is assumed

Request response

Given the previous Payload field definition example on previous chapter, we build a payload content example accordingly.

{

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-04-30T22:00:00",

"TX_TPE_INSTRU": "P-432",

"MS_PAT_HGHT": 180

}

Submit DCD registrations

Request example

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

Header:

MediaType.APPLICATION_JSON

Body:

{

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-04-30T22:00:00",

"TX_TPE_INSTRU": "P-432",

"MS_PAT_HGHT": 180

{

"CD_SURGL_APPR_FEMO": 68225,

"D_IMPLANT": "2021-04-14T22:00:00",

"TX_TPE_INSTRU": "P-545",

"MS_PAT_HGHT": 1209

{

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-05-01T22:00:00",

"TX_TPE_INSTRU": "T-678",

"MS_PAT_HGHT": 210

}

Request parameters

{organizationtId}: Id of the organization for which we want to submit the DCD registration.

{dcdId}: Id of the DCD we want to submit.
<optional parameter> {version}: Id of the DCD Version we want to submit. If this parameter is not provided, latest one is assumed.
<optional parameter> {dataSrcType}: The data source type e.g: API or CSV.

Request payload

{Header}: MediaType.APPLICATION_JSON
{Body}: JSON object with an array of DCDs data to be submitted, following the specifications and examples provided by the described api end-points:

GET /api/dcd/payload/definition
GET /api/dcd/payload/example

Request response

{

"TX_BUSINESS_KEY": "NISS 12.06.01-052.46 30/04/2021 67864",

{

"HTTP_STATUS_CODE": 405,

"HTTP_STATUS_NAME": "Method Not Allowed",

"HTTP_STATUS_EXCEPTION_DETAILS": "Exception details for Method Not Allowed example",

"TX_BUSINESS_KEY": "NISS 12.06.01-071.48 01/05/2021 67864",

}

User / password

The username and password can be requested at our Servicedesk.

pedro.fernandez Mon, 10/03/2022 - 08:44

2. API Endpoint for supporting the DCD submit process

API description

API end-point	Response	Notes
api/dcd/field? dcd-id={dcdId}; <optional>dcd-version-id={dcdVersionId}; <optional>included-codelist-values={inclCodelistValues}; <optional>field-name={fieldname}; <optional>language-id={languageId}	List of DCD fields definition, even with codelist values if the field is CODE field type.	<optional parameter> dcd-version-id={dcdVersionId} : If this parameter is not provided, latest one is assumed <optional parameter> included-codelist-values={inclCodelistValues}: permitted values: true False If this parameter is not provided, default value is <true>. <optional parameter> field-name={fieldname}: A field name e.g: TX_AUTHOR_GR <optional parameter> {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values: en: English nl: Dutch fr: French
/api/dcd/codelist? code-list-id={codelistId}; <optional>language={language}	List of values for the codelist of the given codelistId.(List<CodeListItem>)	Checking and getting this info based on MDM -> CODE_LIST table and the relationed tables (CODE, CODE_CONTENT, etc.) See *MDM – Field description – DB model* diagram at the Attachment chapter for more details. <optional parameter> {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values: en: English nl: Dutch fr: French
/api/dcd/menu-translations? dcd-id={dcdId}; <optional>dcd-version-id={dcdVersionId}; <optional>language-id={languageId}		<optional parameter> dcd-version-id={dcdVersionId} : If this parameter is not provided, lastest one is assumed <optional parameter> {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values: en: English nl: Dutch fr: French
/api/dcd/field/translation? dcd-id={dcdId}; <optional>dcd-version-id={dcdVersionId}; <optional>language-id={languageId}; <optional>field-name={fieldName}	List of fields translations for a given dcdId in the specified languageId (English if it is not provided) in a JSON format. Optional fieldId parameter can provided just for getting this info but only for this fieldId.	<optional parameter> dcd-version-id={dcdVersionId} : If this parameter is not provided, lastest one is assumed <optional parameter> {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values: en: English nl: Dutch fr: French <optional parameter> field-name={fieldName}: A field name e.g: TX_AUTHOR_GR
/api/externalreference/sadmi? notificationCode={notificationCode}; name={name}; reference={reference}; distributorName={distributorName}; manufacturerName={manufacturerName}; classificationCode={classificationCode}	List of Medical Device Types: NotificationCode Name Reference URL Distributor Manufacturer Classification State Client must select the right info needed.

Get DCD field definition list

Request example

GET /api/dcd/field?dcd-id={dcdId};dcd-version-id={dcdVersionId};included-codelist-values={inclCodelistValues};field-name={fieldName};language-id={languageId};

Request parameters

{dcdId} : Id of the menu dcd which we want to get all the translations.
<optional parameter> {dcdVersionId} : If this parameter is not provided, latest one is assumed.
<optional parameter> {includedCodelistValues}: boolean value (true or false). If this parameter is not provided, default value will be true. If true and for those fields with type equal to CODE, codelist values will be provided in the result.

<optional parameter> {fieldName}: A field name e.g: TX_AUTHOR_GR
<optional parameter> {languageId} : language id for the menu options example results. If this parameter is not provided, default language will be English. Current permitted values:
- en: English
- nl: Dutch
- fr: French

Request response

with parameter includeCodelistValues equal to true (default value)

{

"TX_TPE_INSTRU": {

"field_type": "FREE TEXT",

"code_list": null

"D_IMPLANT": {

"field_type": "DATE",

"code_list": null

"MS_PAT_XXXX": {

"field_type": "UNKNOWN",

"code_list": null

"MS_PAT_HGHT": {

"field_type": "CODE",

"code_list": [

{

"ID": 68224,

"CODE_VALUE": "870646003",

"LABEL_EN": "Femoral (Hemi)"

{

"ID": 68225,

"CODE_VALUE": "465954006",

"LABEL_EN": "Femoral + Cup"

}

]

}

with parameter includeCodelistValues equal to false

{

"TX_TPE_INSTRU": {

"field_type": "FREE TEXT",

"code_list": null

"D_IMPLANT": {

"field_type": "DATE",

"code_list": null

"MS_PAT_XXXX": {

"field_type": "UNKNOWN",

"code_list": null

"MS_PAT_HGHT": {

"field_type": "CODE",

"code_list": 23

}

Get DCD code list values

Request example

GET /api/dcd/codelist?codelist-id={codelistId};language-id={languageId}

Request parameters

{codelistId} : Id of codelist which we want to get the permitted values
<optional parameter> {languageId} : language id for the code_list example results. If this parameter is not provided, default language will be English. Current permitted values:
- en: English
- nl: Dutch
- fr: French

Request response

{

"ID": 68224,

"CODE_VALUE": "870646003",

"LABEL_EN": "Femoral (Hemi)"

{

"ID": 68225,

"CODE_VALUE": "465954006",

"LABEL_EN": "Femoral + Cup"

}

Get DCD menu translations

Request example

GET /api/dcd/menu-translations?dcd-id={dcdId};dcd-version-id={dcdVersionId};language-id={languageId}

Request parameters

{dcdId} : Id of the menu dcd which we want to get all the translations.
<optional parameter> {dcdVersionId} : If this parameter is not provided, lastest one is assumed.
<optional parameter> {languageId} : language id for the menu options example results. If this parameter is not provided, default language will be English. Current permitted values:
- en: English
- nl: Dutch
- fr: French

Request response

Example 1: languageId = “en” - English language menu translations

{

"zephyr_ortho_program": "QERMID - Orthopedics",

"zephyr_ortho_knee_project": "Orthopride knee",

"zephyr_ortho_knee_t1_dcd": "Primo-implantation"

{

"zephyr_ortho_program": "QERMID - Orthopedics",

"zephyr_ortho_knee_project": "Orthopride knee",

"zephyr_ortho_knee_t2_dcd": "Revision"

}

. . . . .

}

Example 2: languageId = “nl” - Dutch language menu translations

{

"zephyr_ortho_program": "QERMID - Orthopedie",

"zephyr_ortho_knee_project": "Orthopride knie",

"zephyr_ortho_knee_t1_dcd": "Primo-implantatie"

{

"zephyr_ortho_program": "QERMID - Orthopedie",

"zephyr_ortho_knee_project": "Orthopride knie",

"zephyr_ortho_knee_t2_dcd": "Revisie"

. . . . .

}

Example 3: languageId = “fr” French language menu translations

{

"zephyr_ortho_program": "QERMID - Orthopédie",

"zephyr_ortho_knee_project": "Orthopride genou",

"zephyr_ortho_knee_t1_dcd": "Primo-implantation"

{

"zephyr_ortho_program": "QERMID - Orthopédie",

"zephyr_ortho_knee_project": "Orthopride genou",

"zephyr_ortho_knee_t2_dcd": "Revision"

}

Get DCD field definition translations

Request example

GET /api/dcd/fields/translation?dcd-id={dcdId};dcd-version-id={dcdVersionId};language-id={languageId};field-id={fieldId}

Request parameters

{dcdId} : Id of the menu dcd which we want to get all the translations.
<optional parameter> {dcdVersionId} : If this parameter is not provided, lastest one is assumed.
<optional parameter> {languageId} : language id for the menu options example results. If this parameter is not provided, default language will be English. Current permitted values:
- en: English
- nl: Dutch
- fr: French

<optional parameter> {fieldName} : Id of field which we want to get the translation from

Request response

Example 1: languageId = "en" - English language fields translations

{

"author_group": "Authors group",

"CD_SLEEVE_LON": "Long sleeves",

"TX_TTL_UNT": "Unit",

"TX_CTNT_BEF_CONT_VEN_ARTER": "Before venous/arterial contact",

"CD_NAIL_DIRT": "Dirty nails",

"CD_PLSH": "Nail polish",

"TX_NHH": "No hand hygiene",

"CD_SITE": "Site number",

"CD_NAIL_EXT": "Nail extensions",

"TX_TTL_STDY": "Study design",

"CD_WATCH": "Wearing a watch",

"D_OBS": "Observation date",

"T_STP_OBS": "Time end observation period",

"CD_OPT_MDL": "Participation module optional",

"CD_SPLTY": "Specialty of the ward",

"CD_PROF": "Profession",

"TX_TTL_OBS": "Observations",

"CD_NAIL_LON": "Long nails",

"CD_RING": "Wearing a ring"

}

Example 2: languageId = "nl" - Dutch language fields translations

{

"author_group": "Auteursgroep",

"CD_SLEEVE_LON": "Lange mouwen",

"TX_TTL_UNT": "Eenheid",

"TX_CTNT_BEF_CONT_VEN_ARTER": "Voor contact met intravasculair stelsel",

"CD_NAIL_DIRT": "Vuile nagels",

"CD_PLSH": "Nagellak",

"TX_NHH": "Geen handhygiëne",

"CD_SITE": "Campus nummer",

"CD_NAIL_EXT": "Kunst-nagels",

"TX_TTL_STDY": "Study design",

"CD_WATCH": "Het dragen van polshorloge",

"D_OBS": "Observatiedatum",

"T_STP_OBS": "Tijdstip einde observatieperiode",

"CD_OPT_MDL": "Deelname optioneel module",

"CD_SPLTY": "Specialiteit van de dienst",

"CD_PROF": "Beroepsgroep",

"TX_TTL_OBS": "Observaties",

"CD_NAIL_LON": "Lange nagels",

"CD_RING": "Het dragen van ring"

}

Example 3: languageId = "fr" - French language fields translations

{

"author_group": "Groupe d’auteurs",

"CD_SLEEVE_LON": "Longues manches",

"TX_TTL_UNT": "Unité",

"TX_CTNT_BEF_CONT_VEN_ARTER": "Avant contact veineux/artériel",

"CD_NAIL_DIRT": "Ongles sales",

"CD_PLSH": "Ongles vernis",

"TX_NHH": "Pas d’hygiène des mains",

"CD_SITE": "Numéro du site",

"CD_NAIL_EXT": "Ongles artificiels",

"TX_TTL_STDY": "Study design",

"CD_WATCH": "Le port d’une montre",

"D_OBS": "Date de l’observation",

"T_STP_OBS": "Heure fin de la période d’observation",

"CD_OPT_MDL": "Participation module optionel",

"CD_SPLTY": "Spécialité du service",

"CD_PROF": "Profession",

"TX_TTL_OBS": "Observations",

"CD_NAIL_LON": "Ongles longs",

"CD_RING": "Le port d’une bague"

}

Search for SADMI medical devices

Request example

GET /api/externalreference/sadmi?

notificationCode={notificationCode};

name={name};

reference={reference};

distributorName={distributorName};

manufacturerName={manufacturerName};

classificationCode={classificationCode}

Request parameters

<optional parameter> {notificationCode}
<optional parameter> {name}
<optional parameter> {reference}
<optional parameter> {distributorName}

<optional parameter> {manufacturerName}
<optional parameter> {classificationCode}

Request response

{

"NotificationCode": "First Notification Code Example",

"Name": "First Name Example",

"Reference": "First Reference Example",

"URL": "http://first.url.example",

"Distributor": {

"NotificationNumber": "First Notification Number Example",

"Name": "First Distribuitor Name Example"

"Manufacturer": {

"Name": "First Manufacturer Name Example",

"CountryCode": {

"value": "First Country Code Value Example",

"standard": "First Country Code Standard Example"

"CountryName": {

"value": "First Country Name Value Example",

"lang": "First Country Name Lang Example"

}

"Classification": {

"Code": "First Classification Code Example",

"Description": "First Classification Description Example"

"State": {

"Name": "First State Name Example",

"ValidFrom": "First State ValidFrom Example",

"ValidTo": "First State ValidTo Example"

}

{

"NotificationCode": "Second Notification Code Example",

"Name": "Second Name Example",

"Reference": "Second Reference Example",

"URL": http://second.url.example,

. . . . .

}

Add repeatable blocks to payload

Example

    "TX_TTL_IMPLANT_DATA": [
        {
            "CD_IMPLANT": "127909",
            "CD_PAC_SADMI_NOTIFIC": "000017811475",
            "CD_IMPLANT_CAT": "",
            "CD_IMPLANT_PRD_NM": "",
            "TX_IMPLANT_PRODUC": "",
            "TX_IMPLANT_DSTRBTR": "",
            "TX_IMPLANT_DESC": ""
        },
        {
            "CD_IMPLANT": "127910",
            "CD_PAC_SADMI_NOTIFIC": "",
            "CD_IMPLANT_CAT": "127906",
            "CD_IMPLANT_PRD_NM": "productnaam",
            "TX_IMPLANT_PRODUC": "fabrikant",
            "TX_IMPLANT_DSTRBTR": "verdeler",
            "TX_IMPLANT_DESC": "opmerking product"
        }
    ],

pedro.fernandez Sun, 05/07/2023 - 11:01

3. API Endpoint for searches DCD registrations

API description

API end-point	Response	Notes
/api/dcd/submissions/searching? organization-id={organizationId}; dcd-id={dcdId}; dcd-version-id={dcdVersionId}	*See below for detailed response types*	organization-id={organizationtId} : Id of the organization for which we want to search the DCD registrations submitted info. dcd-id={dcdId} : Id of the DCD we want to search the DCD registrations submitted info. <optional parameter> dcd-version-id={dcdVersionId} : If this parameter is not provided, latest one is assumed

Search for submitted DCD registrations

Request example

GET /api/dcd/submissions/searching?organization-id={organizationId};dcd-id={dcdId};dcd-version-id={dcdVersionId}

Header:

MediaType.APPLICATION_JSON

Body:

{

"CD_SURGL_APPR_FEMO": {"BCOMP": "equals", "VALUE": 68224},

"D_IMPLANT": {"BCOMP": "gte", "VALUE": "2021-04-30T22:00:00"}

}

// conditional expression in the example above would be:

// CD_SURGL_APPR_FEMO = 68224 and D_IMPLANT >= "2021-04-30T22:00:00"

// (gte boolean comparator in the example means: greater than or equal to) See table below for details

// about rest of the boolean comparators.

Request parameters

{organizationtId} : Id of the organization for which we want to search the DCD registrations submitted info.

{dcdId} : Id of the DCD we want to search the DCD registrations submitted info.
<optional parameter> {dcdVersionId} : Id of the DCD Version we want to search submitted info. If this parameter is not provided, lastest one is assumed.

Request payload

{Header} : MediaType.APPLICATION_JSON
{Body} : JSON object with the DCD searching criteria, following the specifications and examples in terms of data types and permitted values, provided by the described api end-points:
- GET /api/dcd/payload/definition
- GET /api/dcd/payload/example

And following searching rules specifications:

{

"FIELD_NAME": {"BCOMP": "gte", "VALUE": "example value 1"}

}

Valid boolean comparators (BCOMP):

(for the following examples purpose, we will use patients´s attributes (fields), for instance)

Filter	Query	Example	Description
equal	equals	"gender": {"BCOMP": "equals", "VALUE": "male"}	both return all submitted DCDs whose patients’ gender is male
not equal	ne	"gender": {"BCOMP": "ne", "VALUE": "male"}	returns all submitted DCDs whose patients’ gender are not male
greater than	gt	"age": {"BCOMP": "gt", "VALUE": "18"}	returns all submitted DCDs whose patients are older than 18
greater than or equal to	gte	"age": {"BCOMP": "gte", "VALUE": "18"}	returns all submitted DCDs whose patients are 18 and older
less than	lt	"age": {"BCOMP": "lt", "VALUE": "30"}	returns all submitted DCDs whose patients are 29 and younger
less than or equal to	lte	"age": {"BCOMP": "lte", "VALUE": "30"}	returns all submitted DCDs whose patients are 30 and younger
in	in	"gender": {"BCOMP": "in", "VALUE": "female,male"}	returns all submitted DCDs whose patients’ gender are female and male

nin	nin	"age": {"BCOMP": "nin", "VALUE": "18,21"}	returns all submitted DCDs whose patients are not 18 or 21
exists=true	exists	"age": {"BCOMP": "exists", "VALUE": "true"}	returns all submitted DCDs whose patients get some value in the age
exists=false	exists	"age": {"BCOMP": "exists", "VALUE": "false"}	returns all submitted DCDs whose patients don’t get any value in the age
Regex	regex	"username": {"BCOMP": "regex", "VALUE": "/^travis/i"}	returns all submitted DCDs whose patients’ username start with travis

We’ll apply same query operators than in the Formio API, and in this way, its implementation will be straight forward. See this link for details about FormIO API: https://documenter.getpostman.com/view/684631/formio-api/2Jvuks#1f207caa-9d04-3e81-2973-e4bf82ee5190

Request response

If succeed result:

{

"TX_BUSINESS_KEY": "NISS 12.06.01-053.46 30/04/2021 67864"

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-04-30T22:00:00",

"TX_TPE_INSTRU": "P-432",

"MS_PAT_HGHT": 160

{

"TX_BUSINESS_KEY": "NISS 68.06.01-053.29 04/05/2021 67864"

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-05-04T22:00:00",

"TX_TPE_INSTRU": "X-333",

"MS_PAT_HGHT": 180

{

"TX_BUSINESS_KEY": "NISS 72.06.01-053.81 08/05/2021 67864"

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-05-08T22:00:00",

"TX_TPE_INSTRU": "Z-345",

"MS_PAT_HGHT": 195

{

"TX_BUSINESS_KEY": "NISS 91.06.01-053.12 12/05/2021 67864"

"CD_SURGL_APPR_FEMO": 68224,

"D_IMPLANT": "2021-05-12T22:00:00",

"TX_TPE_INSTRU": "R-987",

"MS_PAT_HGHT": 170

}

If failed result:

{

"HTTP_STATUS_CODE": 405,

"HTTP_STATUS_NAME": "Method Not Allowed",

"HTTP_STATUS_EXCEPTION_DETAILS": "Exception details for Method Not Allowed example",

}

pedro.fernandez Mon, 10/03/2022 - 08:45

4. MDM Field description - DB Model

pedro.fernandez Mon, 10/03/2022 - 08:46

5. Swagger API

The Swagger API is available on the local installation of HD4DP2.0. Go to https://<internal_dns>/proxy/api-docs.html.

The internal DNS needs to work for the Swagger api. <server_ip>:4201 will not work.

Some API calls are password protected (S2S api). If you want access to this API, you can request the user/password by creating a ticket in our servicedesk.

jeroen.maelbrancke Mon, 10/03/2022 - 16:31

HD4DP v2 csv upload

Introduction

This page explains the functioning of the CSVUploader feature. The CSVUploader feature is aimed to do a bulk upload of records : by filling a csv file, one record per row represents one submission so a user can fill as much records as needed.

Architecture

The CSVUploader is located under hd-connect/csvuploader. It uses both hd-connect-csvuploader and hd-connect-proxy modules.

The general architecture of the CSVUploader is explained in the sequence diagram below.

Third-party libraries and frameworks

Apache Camel: https://camel.apache.org/
Spring Boot

Testing and working

The CSVUploader creates a folder at root level (SFTP for end-user, or hd-all for developer) that contains a subfolder per existing organisation.
The CSVUploader will poll with a delay of 1 min, process the csv file and then create 3 folders:
- ARCHIVE folder: contains the source csv file.
- RESULTS folder: contains the results of processing the csv file. This file contains the specified data, and the final status of the processing: Success or Error. If an error occurred, the error message is displayed. For multiple uploads, the result is added to the end of the result file each time.
- ERROR folder: this folder is created if the csv test file was not processed, due to an I/O error (file corrupted, not found etc.). So for now, only technical errors are caught and the source csv file is moved to that folder instead of the ARCHIVE folder. In principle, this folder should contain any result that is an error. The RESULT folder should only contain results that end with a SUCCESS status.

Formats

Some formats are specific:

Dates: should be dd/mm/yyyy
Boolean: true / false
Codes: the value of the code (not the translation)
Multi codes: there is only one column per field. So when a select box is set as multiple, values have to be separated by a "|". e.g.: 68452|68453|68454
Repeatable blocks: in some DCDs, a complete block of fields is repeatable. In that case, value have to be separated by a ";"
- e.g.: A block is containing 3 fields: A (Lob), B (Type klep) and C (Aantal kleppen)

Examples:

In case of a multiple choice:

Example of a multiple choice as presented in the DCD:

As presented in the form:

For reporting fields with a multiple choice formatting, the selected answers can be reported separated by the pipe symbol (|).

Example of a multiple field reporting:

cftr_modulating_therapy_1;

1|2|3|4|5|6;

In case of a repeatable block

Example of a repeatable block as presented in the DCD:

As presented in the form:

Manually enter the repeatable fields as shown in the following template: field_category|<index>|field.

Example of a repeatable block reporting:

Repeatable 1:

Transplants

transplant_status

Repeatable 2:

Transplants

transplant_status

becomes:

transplants|0|transplant_status;transplants|1|transplant_status

manager Tue, 04/04/2023 - 13:20

Process to upload a CSV file to submit DCD registrations

Documentation for CSV Upload on Architecture 2.0

Description of the service

The CSV upload functionality gives the possibility to import multiple parameters from a set of patients in one time into HD4DP2.0. The csv-file is based on an extract of the electronic patient files and/or other local databases.

Currently there is no user-interface in HD4DP2.0 for uploading csv-files. If a data provider wants to upload a csv-file, the file has to be dropped at a specific location. These files will be picked up and processed periodically. The files should be “final”, meaning that no application is writing to them. The pickup-location will be identical for all registries.
Pre-registry handling will be based on a naming-convention of the csv file.

HOW TO: Upload a DCD using CSVUpload

Steps To Upload DCD records

1. Prepare the CSV file (example file in this section)

Extract the CSV file from the electronic patient files and/or other local databases.

Make sure the name of the CSV file has the correct format: HD_DCD_submcsv_HDBPnumber_HDBPabbreviation_versionnumber_versionreleasedate
So for Orthopride knee the format would be : HD_DCD_submcsv_HD0048_Orthopride_knee_Primo-implantation_01_28022023
Please find here an example file for Orthopride knee

content of the csv file

TX_BUSINESS_KEY;TX_REGN_CD;CD_NIC_TPE;IDC_PAT;FL_IDC_PAT_GENER;D_PAT_DOB;CD_PAT_SEX;CD_PAT_PLC_RESDC;CD_HPIN;CD_DIAGS;CD_ANATCL_LOC_KNEE;CD_PROB_TPE_DIAGS;CD_COMORB;CD_PROB_TPE_COMORB;CD_ASA_CLASS;MS_PAT_WGHT;MS_PAT_HGHT;CD_PREO_PROC_KNEE;CD_DRCT_ALIGN;D_IMPLANT;CD_LTRLTY;CD_LTRLTY_KNEE;CD_SURGL_APPR;CD_PROC_SURGL_APPR;CD_TBRST_OSTEO;CD_QUADR_SNIP;CD_USE_NAV;CD_USE_AR;CD_USE_ROBOT;CD_TPE_ROBOT;TX_MODEL_ROBOT;CD_INSTRU_USE;TX_INSTRU_MANU;TX_TPE_INSTRU;CD_IMPLANT;CD_ANATCL_LOC_IMPLANT_KNEE;CD_MED_DEVICE_KNEE;CD_IMPLANT_INS;CD_FEMO_CEM;CD_FEMO_CEM_NO_AB;CD_TIB_CEM;CD_TIB_CEM_AB;CD_PTR;CD_PTR_CEM;CD_PTR_CEM_AB;CD_QERMID_TPE_IMPLANT;CD_IMPLANT_KNEE;TX_IMPLANT_PROD;TX_IMPLANT_MANU;TX_IMPLANT_DSTRBTR;CD_STATUS_REC;TX_LANG;TX_REG_NAM
NISS 58.03.12-007.96 02/02/2022 67864;206.22.000144.61;NI0001;58.03.12-007.96;false;01/02/2022;248152002;1000;10159048006;397758007;72696002;282291009;77465005|56265001;404684003;413497009;65;154;271505003|239431009;QL0011;02/02/2022;7771000;72696002;261127003;392238003;1;1;UN0005|UN0003;UN0003|UN0004;711364006;TR0002;ORT_KNEE_PRIMO 4487;1;Ortho Knee Incorporated;KNEE PRIMO KNP-4785;466936000;72696002;109228008;261011007;356498006;CN0058;CE0001;CN0002;1;CE0001;CN0003;QT0002;705864000;Test resection productnaam;Test fabrikant;Test distributeur;status_submitted;nl;OP_KNEE_PRIM_IMPLT

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.

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

Now the CSVUpload folder structure is displayed on the right-hand side panel:

Step 4: Select the project folder Orthoprideknee-8 and open it by double-clicking on it:

Step 5: Double-click on the DCD folder to open it:

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

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

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

3. Validate CSV Upload

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

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

3.1 Validation of the CSV Upload via sftp tool:

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

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

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

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

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

3.2 Validation of the CSV Upload via HD4DP 2.0:

Step 1: Open the web application HD4DP 2.0.

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

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

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

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

peter.luijpers Wed, 05/24/2023 - 09:40

HD4DP v2 MyCareNet

HD4DP v.2 permits the administrative obligation of reporting to the insurance institutions. The limited necessary data are sent via HD4DP v.2 to the MyCarenet interface of the National Intermutual College (NIC). This transmission of nominative data occurs in parallel with the transmission of pseudonymized data to the healthdata.be platform.

Note: At this moment the MyCareNet process flow is not yet operational. We are in close collaboration with RIZIV and MyCareNet to get the process up and running as soon as possible.

Two options are available to enable data transmission from HD4DP v.2 to the National Intermutualist College:

This documentation is under construction. 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 send us an email 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 Thu, 06/08/2023 - 09:11

Option 1: XML export for MyCareNet component of HCO

This configuration is by default active in HD4DP v.2. The XML files can be downloaded with an SFTP client of your choice. The XML files you download can be sent with the MyCareNet component available in your organization. You can attach the XML files to the Web Service call to MyCareNet and sign the message with your eHealth P12 certificate. The XML files are ready for use, thus contain the required fields. There is no additional edit required.

SFTP Connection

The server name and the SFTP credentials can be requested via our Service Portal

Server: IP of HD4DP v.2 server 
Port: 22 
Username: (your SFTP credentials)
Password: (your SFTP credentials)
Path: /data/localsftp/upload/nippin (Upload is the home directory of the sftp user)

johanvanbussel Mon, 10/03/2022 - 08:46

Option 2: MyCareNet integration in HD4DP v2

Four major actions are required in order to setup MyCareNet in HD4DP v.2:

Whitelisting URLs
Create certificate (ehealth_certificate.p12) with labels
Upload eHealth certificate in HD4DP v.2
Request credentials needed to upload the eHealth certificate

Whitelisting URL's

The following URLs must be whitelisted to communicate with MyCareNet and E-health. Without a direct connection from HD4DP v.2 server to these URLs, a registration to MyCareNet will not work.

https://prod.mycarenet.be:9443/*

https://services.ehealth.fgov.be/*

Create certificate (ehealth_certificate.p12) with labels

This part requires your organization's eHealth certificate. Create a certificate that has the name ehealth_certificate.p12 using the open source GUI KeyStore Explorer. Download and install the tool from https://keystore-explorer.org/

Open your organization's eHealth certificate

2. Export both certificates as a Key Pair

3. Open KeyStore Explorer, and create a new KeyStore

4. Select the type of the new KeyStore: PKCS#12

5. In the menu bar go to Tools -> Import Key Pair

6. Select the type of key pair import required:

7. Browse the authentication certificate and fill in the Decryption Password

8. Import the authentication PKCS #12 Key Pair and give it the NIHII number as alias, ex 71001129

9. Click OK and give it a password that needs to be same for all imported certs in the P12 KeyStore

10. The Key Pair is imported Successfully

11. Repeat steps 5 to 10 for importing the serial number PKCS #12 Key Pair and give it the same serial number as alias

12. Repeat step 3 to 8 to add more NIHII-HOSPITAL P12 certificates to this KeyStore

13. In the menu bar goto File-> Save All

14. Set the KeyStore Password and give it a password that needs to be same for all certificates

15. Click OK and save the KeyStore asehealth_certificate.p12

16. Click save and the P12 for HD4DP is created

Upload eHealth certificate in HD4DP v.2

The filename of your P12 certificate must be ehealth_certificate.p12

Server: IP of HD4DP v. 2 server

Username: (your SFTP credentials)

Password: (your SFTP credentials)

Path: /data/localsftp/upload (home directory of thesftpuser)

File: ehealth_certificate.p12

Request credentials needed to upload the eHealth certificate

The server name and the sftp credentials can be requested via our Service Portal. The password of your P12 certificate can be delivered to healthdata.be either via a secure password sharing tool of your choice or via Belnet Filesender to hd-architecture-2@sciensano.be. You can request a Belnet Filesender voucher via our Service Portal as well.

johanvanbussel Sat, 02/25/2023 - 09:25

Retrieve data from the local database of HD4DP v2

Warning

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

Requirements

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

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

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

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

"data_collection_name" in local database

Query examples

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

local_dwhmessage_key_value:
msg_document_id:
document_id:
local_dwhmessage:
local_dwhmessage_key_value_plus:
key_value_id:
local_dwhmessage_key_value:

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

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

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

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

Query 2: Get all registrations and key value.

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

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

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

Query 4: Get all MyCareNet registrations, key value and key value plus.

SELECT value from local_dwhmessage as ldm left join local_dwhmessage_key_value as ldmkv on ldmkv.msg_document_id = ldm.document_id WHERE ldm.data_collection_name = 'add data_collection_name'and key = 'TX_REGN_CD';

select * from local_dwhmessage_key_value where msg_document_id in ( select msg_document_id from local_dwhmessage_key_value where key = 'TX_REGN_CD' and value = 'use value from first query');

select * from local_dwhmessage where document_id in ( select msg_document_id from local_dwhmessage_key_value where key = 'TX_REGN_CD' and value = 'use value from first query');

Query 5: Connect to the Nippin database postgresql://<server_ip>:5432/nippin (same user/password) to validate the current state and payload for the nippin message based on the registration code.

select * from nippin_message where current_registrationcode = 'use the value of Query 4 (first query)';

jeroen.maelbrancke Mon, 05/15/2023 - 17:35

HD4DP v2 Online Acceptance Environment

Introduction

To support development and validation of data transfers using S2S API or CSV upload, a central Online Acceptance Environment is available for the IT services or IT partners of data providers. It is meant to replace the locally installed acceptance environments at the side of the data providers. With the Online Acceptance Environment the three types of data transfer can be tested and validated: data transfer via an API platform, via an SFTP client and via manual input in the study form.

In order to keep the acceptance environment light, it is redeployed once a week, deleting all data that were entered for testing. The data are stored locally and will not be sent to Healthdata.be infrastructure. The testing is limited to the upload to the HD4DP v2 application.

Application URLs and port

Front-End Application URL: https://hd4dp.acceptance.healthdata.be
SFTP URL: sftp.acceptance.healthdata.be and port 2220
S2S API: https://hd4dp.acceptance.healthdata.be/proxy/api/dcd/payload/submit?organization-id=00&dcd-id=00&version=1

Navigate to and access the Online Acceptance Environment

The Online Acceptance Environment can be found on https://hd4dp.acceptance.healthdata.be, which is a publically accessible URL.

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

Since the list of organizations to choose from is limited, you might not find your organization in it. In that case we advise you to request your credentials through our service portal at https://sciensano.service-now.com/sp via the Request something tab and subsequently the Request for Information box.

When requesting an account for this acceptance environment you will receive 3 types of credentials:
⦁ credentials to log in to the front end of the online acceptance environment
⦁ credentials to use the API (-> authorization tab in Postman)
⦁ credentials for the SFTP server you use to test the CSV Upload

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

The data transfer methods

As mentioned above, the Online Acceptance Environment enables the testing of the uploads for the following three types of data transfer. They are described in order of preference underneath:

Data transfer via an API platform

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

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

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

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

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

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

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

In the production environment records sent through API are sent directly to the healthdata.be infrastructure (status “Submitted” in the Progress field).

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

The call https://hd4dp.acceptance.healthdata.be/proxy/api/organization (see below) will return an organization id:

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

More information about the API data transfer can be found at https://docs.healthdata.be/documentation/hd4dp-v2-health-data-data-providers/hd4dp-v2-s2s-api

Data transfer via an SFTP client

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

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

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

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

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

Author Group (TX_AUTHOR_GR)
Author (TX_AUTHOR)
Coauthor (TX_COAUTHOR).

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

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

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

More information about the CSV data transfer can be found at https://docs.healthdata.be/documentation/hd4dp-v2-health-data-data-providers/hd4dp-v2-csv-upload.

Manual input in the study form

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

This documentation is under construction. 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 send us an email 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!

kurt.vanbrabant Mon, 06/12/2023 - 13:03

Requesting access

A request for access to the online acceptance environment will be made available in the Entity Access Management tool available via eam.healthdata.be. See also https://docs.healthdata.be/EAM

This feature is foreseen to be added to the EAM portal during the summer of 2023. In the meantime or when the EAM portal should be unavailable, you can use the service portal to request access to the online acceptance environment by creating an incident and clearly mentioning you are an IT Department or IT partner of a data provider requesting access to the online acceptance environment.

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

You will receive 3 types of credentials:

Credentials for the HD4DP2 web form application.
Credentials for the API data transfer.
Credentials for the SFTP server to upload CSV files.

Bart.Servaes Mon, 06/12/2023 - 10:20

Support services HD4DP v2

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:

manager Sat, 09/17/2022 - 15:51

How to report an incident

The service healthdata.be (Sciensano) handels 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.

johanvanbussel Sat, 09/17/2022 - 16:04