Manuel technique de l'application HD4DP v2
Manuel technique de l'application HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Installation de HD4DP v2
Installation de HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Instructions sur l'infrastructure de HD4DP v2
Instructions sur l'infrastructure de HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Fiche d'informations sur l'infrastructure de HD4DP v2
Fiche d'informations sur l'infrastructure de HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Conditions requises pour l'installation de HD4DP
Conditions requises pour l'installation de HD4DPLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Encryption module
Encryption moduleNote: the procedure for the Encryption module is the same for HD4DP v1 and v2.
While HD4DP is developed by healthdata.be, the EM module is not. It can be developed by data providers or third party vendors.
The architecture workgroup of the eHealth platform have strict rules concerning the encoding. Encryption and decryption from the HD4DP software are kept separate.
A new component, whose main functionality, is the encryption of the data before it leaves the organization. Since “data encryption” is the main purpose of this module, it will be referred to as Encryption Module (or EM).
Development by Data Providers
A cookbook containing detailed instructions onhow to implement the module are attached.
HD4DP needs to be configured for the encryption module (cf "How to configure HD4DP for an encryption module").
Finally, validation (cf. article "Encryption module validation scenario") the encryption module implementations is done by healthdata.
Development by Third Parties
The two main functionalities of the encryption module are:
- Encryption and decryption data
- Sending and receiving data
HD4DP needs to be configured for the encryption module (cf. article "How to configure HD4DP for an encryption module").
Encryption and decryption
Healthdata.be has validated (cf. Encryption module validation scenario) the encryption module implementations, developed by the following parties:
- Amaron (Amaron)
- HealthConnect (Hector/Unified Messaging)
- Hôpital Erasme (custom)
- NexuzHealth (NexuzHealth)
- Réseau Santé Wallon (XConnect)
Sending and receiving data
In Belgium, different eHealthBox client softwareapplications are available.
An eHealthBox client application provides an interface to use the eHealthBox service. The eHealth-platform communicates medical files, lab results or other sensible information.
The use of an eHealthBox client application is required for sending data to healthdata.
The main vendors are:
HD4DP v2 S2S API
HD4DP v2 S2S APIGeneral description
API is the acronym for Application Programming Interface, enabling two applications to communicate with each other. The HD4DP v2 System to System (S2S) API allows stakeholders (data providers, healthcare organizations ...) to submit registered data to HD4DP v2 in a fully automated way.
In the manual of the application HD4DP v2 we provide detailed information about the S2S API. Please read the below documentation before its project-specific use.
- API Endpoint for supporting the DCD submit process
- MDM Field description - DB Model
- Swagger API
- Postman collection
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.
Training
Below you can review the S2S API training organized by healthdata.be:
This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create a support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!
S2S API data submission for registries
S2S API data submission for registriesData submission procedure in Architecture 2 using S2S API
1. Requirements at Data Provider's side
In order to be able to communicate with the healthdata.be S2S API, the IT services of the healthcare organizations must setup their systems as follows:
- Ensure to have the credentials available for the endpoint/URL for which authorization is necessary. If this is not the case, please contact our service portal: https://sciensano.service-now.com/sp.
- Ensure to have the end-to-end API process in place in order to submit data registrations in a fully automated manner.
- Ensure capability of submitted data retrieval in the local database.
2. Preparing the JSON file
- To send data to healthdata.be by S2S API, the file must be in a .json file format.
- Extract the requested data from the electronic patient files and/or other local databases.
- Map the data according to the fields and formats as described in the DCD specifications of this section and the general code lists.
- Go here for additional information on the codes and the formats used for the Author group, SSIN code, Status, "Date" - "Date:Time", Repeatable fields and Multiple choice.
Note: The example files are only provided as a guideline and do not contain real life data.
Note: Below documentation contains generic example screens with the sole purpose to demonstrate how the process looks like regardless of the register.
3. Uploading the JSON file
- The IT department of the Data Provider implements a data transmission system (e.g. Postman) to send the API queries by means of a json file. The correct endpoints for uploading of the json file can be found here.
- The URL that needs to be entered after POST (selected method for uploading) should have a syntax similar to the one below:
POST {{baseURL}}/api/dcd/payload/submit?organization-id={organizationId}&dcd-id={dcdId}&dcd-version-id={dcdVersionId}&data-src-type={dataSrcType}
- Whereby:
- {organizationId} needs to be replaced by the id of your organization; go here for more information
- {dcdId} needs to be replaced by a register-specific numerical value; go here for more information
- <optional> {dcdVersionId} needs to be replaced by the intended version number; if not provided, the latest version of the dcd specifications is assumed; go here for more information
- <optional> {dataSrcType} needs to be replaced by the data source type. Permitted values are API or CSV; go here for more information
- a GET method URL should not contain /submit/ in the endpoint or path
- multiple query parameters need to be connected by an ampersand (&) (see example above)
- In the Authorization tab, select “Basic Auth” in the “Auth Type” drop-down list. Subsequently, fill out the API credentials in the username and password fields.

- In Body tab, select the “raw” option from the top line and paste the content of the JSON file in the box.

- Once the request settings are completed, press the Send button to submit the records.
- After succesful submission of the data, the “Status: 202 Accepted” code will appear below the box where the data was pasted. The bottom box should return a message about the records uploaded or an error message if any.

- A 401 Unauthorized message instead indicates missing or incorrect credentials. Request the correct credentials as described above in the Requirements at Data Provider's side.

- A 400 Bad request might refer to incorrect syntax of the API query. Check the query parameters and ensure to connect multiple parameters with the ampersand (&) character.

4. Validating the JSON Upload
4.1 Validation of the S2S API Upload via the response:
Verify in the same way the request was sent, that the returned response is containing a valid Business key.
If a valid Business key has been provided, the registration upload via System 2 System API was succesful.
4.2 Validation of the S2S API via HD4DP 2.0:
Step 1: Open the HD4DP 2.0 application.

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

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

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

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

This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!
1. API endpoint description to support the data submission process
1. API endpoint description to support the data submission processTable of contents
- API endpoint overview
- Get organizations
- Get the DCD menu structure
- Get DCD field definitions
- Get DCD payload example
- Get DCD field definition list
- Get DCD code list values
- Get DCD menu translations
- Get DCD field definition translations
- Submit DCD registrations
- Search for SADMI medical devices
- User password
- Additional fields
API endpoint overview
The baseURL to be used has the following built: https://<hd4dp_url>/proxy.
Go here for further details on the syntax of API queries to ensure correct uploading of the json file.
| API endpoint | Respons | Notes |
|---|---|---|
| {{baseURL}}/api/organizations | List of organizations. Client must select the right organizationId | GET method Currently existing endpoint is: /api/installation/organizations We’ll create this new endpoint with a different signature re-routing the call to this existing one or we will refactor the existing one to this new signature. |
| {{baseURL}}/api/externalreference/sadmi?notificationCode={notificationCode} <optional> name={name} <optional> reference={reference} <optional> distributorName={distributorName} <optional> manufacturerName={manufacturerName} <optional> classificationCode={classificationCode} | List of Medical Device Types: - NotificationCode - Name - Reference URL - Distributor - Manufacturer - Classification - State Client must select the desired information. | GET method |
| {{baseURL}}/api/dcd/payload/submit?organization-id={organizationId} <optional> dcd-id={dcdId} <optional> dcd-version-id={dcdVersionId} <optional> data-src-type={dataSrcType} | Results info if succeed Error info if failed | POST method Some implementation tasks are needed 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> dcd-version-id={dcdVersionId}: 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>. |
| {{baseURL}}/api/dcd/payload/example?dcd-id={dcdId} <optional> version={version} | Example of payload in JSON format | GET method 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 |
| {{baseURL}}/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 | GET method 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 |
| {{baseURL}}/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. | GET method |
| {{baseURL}}/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. | GET method <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> 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 |
| {{baseURL}}/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 be provided just for getting this info but only for this fieldId. | GET method <optional parameter> dcd-version-id={dcdVersionId}: If this parameter is not provided, lastest 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 <optional parameter> field-name={fieldName}: A field name e.g: TX_AUTHOR_GR |
| {{baseURL}}/api/dcd/codelist?code-list-id={codelistId} <optional> language={language} | List of values for the codelist of the given codelistId.(List<CodeListItem>) | GET method 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> language={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 |
Get organizations
Request example
GET {{baseURL}}/api/organizations
Request response

Get the DCD menu structure
Request example
GET {{baseURL}}/api/dcd/menu/structure?organization-id={organizationId}
Request parameters
- {organizationId}: Id of the organization as provided by Healthdata.be and for which we want to list the menu structure
- {{baseURL}}: the value for this field is https://<hd4dp_url>/proxy
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.

Get DCD field definitions
Request example
GET {{baseURL}}/api/dcd/payload/definition?dcd-id={dcdId}&version={version}&language-id={languageId}
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

https://hd4dp.acceptance.healthdata.be/proxy/api/dcd/payload/definition?dcd-id=18&version=1&language-id=nl
Get DCD payload example
Request example
GET {{baseURL}}/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
}
Get DCD field definition list
Request example
GET {{baseURL}}/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 {{baseURL}}/api/dcd/codelist?code-list-id={codelistId}&language={languageId}
Request parameters
- {code-list-Id} : Id of codelist which we want to get the permitted values
- <optional parameter> {language} : 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 {{baseURL}}/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 {{baseURL}}/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"
}
Submit DCD registrations
Request example
POST {{baseURL}}/api/dcd/payload/submit?organization-id={organizationId}&dcd-id={dcdId}&dcd-version-id={dcdVersionId}&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> {dcdVersionId}: 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",
}
Search for SADMI medical devices
Request example
GET {{baseURL}}/api/externalreference/sadmi?notificationCode={notificationCode}&reference={reference}
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,
. . . . .
},
. . . . .
}
User / password
The username and password can be requested at our Servicedesk.
Additional fields
In addition to this, more in depth information about the codes and the formats used for the Author group, NISS code, status, Postal Code, "Date" - "Date:Time", repeatable fields and multiple choice fields are available here.
This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create a support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!
3. MDM Field description - DB Model
3. MDM Field description - DB ModelLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
4. Swagger API
4. Swagger APILe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
5. Postman collection
5. Postman collectionLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Téléchargement de CSV dans HD4DP v2
Téléchargement de CSV dans HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
CSV Upload data submission for registries
CSV Upload data submission for registriesData submission procedure in Architecture 2 using CSV Upload
1. Preparing the csv file
- Extract the requested data from the electronic patient files and/or other local databases.
- Mapping of the data according to the fields and formats as described in the DCD specifications of this section and the general code lists.
- Go here for additional information on the codes and the formats used for the Author group, NISS code, Status, "Date" - "Date:Time", Repeatable fields and Multiple choice.
- Make sure the name of the csv test file(s) has the correct format (see Examples below):
HD_DCD_submcsv_HDBPnumber_HDBPabbreviation_versionnumber_versionreleasedate - An alternative method for migrated projects would be to export the csv file from Architecture 1 and to manually add the additional fields that are required in Architecture 2. (see Additional fields below, if applicable
- Please use UTF-8 encoding when uploading your CSV
Disclaimer: The example files are only provided as a guideline and do not contain real life data.
2. Uploading the csv file
Step 1: Open the sftp tool like WinSCP

Step 2: Get the credentials (Host name, Port number, User name and Password) from the IT department of the Data Provider, to log on to the sftp server located on the Data Provider side. In case the credenials are unavailable we advise you to request your credentials through our service portal at the Jira Service Management (JSM) Portal via the Request something tab and subsequently the Request for Information box.
Step 3: Fill in the credentials into the Login screen and click on Login to be able to access the different upload folders:

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

Now the CSV Upload folder structure is displayed on the right-hand side panel. You will notice draftcsv folders and submcsv folders for the diverse HD business projects. Historically, a directly submitted csv file would end up in the submitted folder, whereas a csv file featuring ‘draft’ in the status field would have ended up in the draft folder. At this stage there is no real distinction between both folders, so you can save the csv file in either of them.
Attention: If you wish to create a draft to work on at a later stage, don’t forget to add ‘draft’ in the status column of the csv file.

Below documentation contains generic example screens with the sole purpose to demonstrate how the process looks like. In the subsequent screens the desired register needs to be selected.
Step 4: Select the desired folder and open it by double-clicking on it:

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

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

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

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

3.1 Validation of the csv upload via sftp tool:
Step 1: Double-click on the ERROR folder to open it, click on the refresh button and verify that there is no error file present.

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

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

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

3.2 Validation of the csv upload via HD4DP 2.0:
Step 1: Open the HD4DP 2.0 web application.

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

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

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

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

This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!
Additional field information for CSV and API
Additional field information for CSV and APITable of contents
Additional field information for S2S API
Author group, Author and Coauthor
When the values for Author Group, Author and Coauthor have been left out in the json file, the default values for Author group, Author and Coauthor will be used automatically.
In order to create a record with the desired Author Group, Author and Coauthor, the following fields TX_AUTHOR_GR, TX_AUTHOR and TX_COAUTHOR must be added to the json file with their respective values.
Example:

Note:
The Author group, Author and Coauthor must exist and are well configured at the back-end of the system. TX_AUTHOR_GR can be a string that identifies the Author group to which this Author belongs. Commonly, the first name and last name are used to identify the TX_AUTHOR_GROUP. Be sure to avoid leading and trailing spaces when entering the Author group value.
Submitting a Record Requiring Manual Intervention in HD4DP
In order to submit a record requiring a manual intervention in HD4DP before submission, you need to add the key STATUS (all upper case) with the value "draft" to the record as follows:
"STATUS": "draft",
If the status is sent as "draft", a record is created allowing further completion and/or validation before submission. In case of a successful submission the user receives a HTTP 202 (Accepted) notification with an empty business key, e.g.:

If the status key is not sent, the default value "submit" is used. The user performs a complete submission, and in case of a successful submission the user receives a HTTP 202 (Accepted) notification with a business key, e.g.:

Note that a record with "draft" status needs to be sent, when it needs completion and approval in HD4DP. The status "submit" is not necessary when performing a complete submission.
In the HD4DP front-end, the difference is that the draft submission has the status open while the complete submission has the status submitted:

Once the draft is submitted in the front-end, the business key is generated and the process completed.
SSIN code formatting
Adding separators to a SSIN code
It is not necessary to add separators in a SSIN code when uploading a file using S2S API. You can fill out the SSIN code both with or without separators. E.g.: 85.04.02-169.32 or 85040216932.
Example:

Formatting of 'Date' and 'Date:Time'
The correct format for a field reporting the Date is "dd/mm/yyyy".
Example:

The correct format for a field reporting the Date:Time is "dd/mm/yyyy:hh:mm:ss".
Example:

Formatting of repeatable fields
In the DCD specifications, some fields or block of fields may be defined as repeatable. In that case, the values have to be separated by a comma (",").
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"
}
],
Formatting of multiple choice
In some DCD specifications, some fields are defined as multiple choice. In that case, multiple values can be selected and need to be separated by a pipe ("|").
Example:

Additional field information for CSV Upload
Author group, Author and Coauthor
When the values for Author Group, Author and Coauthor have been left out in the csv file, the default values for Author group, Author and Coauthor will be used automatically.
In order to create a record with the desired Author Group, Author and Coauthor, the following fields TX_AUTHOR_GR, TX_AUTHOR and TX_COAUTHOR must be added to the csv file with their respective values.
Example:TX_AUTHOR_GR;TX_AUTHOR;TX_COAUTHORTest group;test@sciensano.be;test@sciensano.be
Note:
The Author group, Author and Coauthor must exist and are well configured at the back-end of the system. TX_AUTHOR_GR can be a string that identifies the Author group to which this Author belongs. Commonly, the first name and last name are used to identify the TX_AUTHOR_GROUP. Be sure to avoid leading and trailing spaces when entering the Author group value.
Submitting a Record Requiring Manual Intervention in HD4DP
In order to submit a record requiring a manual intervention in HD4DP before submission, you need to do add the field name 'STATUS' in capitals in an additional column, and add the value 'draft'. If not, the record will be submitted without manual intervention.

SSIN code
Adding separators to a SSIN code
It is not necessary to add separators to a SSIN code when uploading a file using CSV Upload. You can fill out the SSIN code both with or without separators. E.g.: 85.04.02-169.32 or 85040216932.
Example:

Formatting of 'Date' and 'Date:Time'
The correct format for a field reporting the Date is dd/mm/yyyy.
Example:

The correct format for a field reporting the Date:Time is "dd/mm/yyyy:hh:mm:ss".
Example:

Formatting of repeatable fields
In the DCD specifications, some fields or block of fields may be defined as repeatable. In that case, manually enter the repeatable fields as shown in the following template: field_category|<index>|field.
The values have to be separated by a semi-colon (";").
Example:
- Fields:
Transplants
Repeatable 1:
transplant_status
Repeatable 2:
transplant_status
- Formatting:
transplants|0|transplant_status;transplants|1|transplant_status
4;6
- as presented in the DCD:

- as presented in the form:

Formatting of a multiple choice
In some DCD specifications, some fields are defined as multiple choice. In that case, the selected values can be reported separately by means of the pipe symbol (|), e.g. 68452|68453|68454.
- Example:
cftr_modulating_therapy_1
1|2|3|4|5|6
- as presented in the DCD:

- as presented in the form:

Other formatting
- Boolean: true / false
- Codes: the value of the code (not the translation)
- CSV file name: HD_DCD_submcsv_HDBPnumber_HDBPabbreviation_versionnumber_versionreleasedate
This documentation is being updated regularly. We try to provide as correct, complete and clear as possible information on these pages. Nevertheless, if you see anything in the documentation that is not correct, does not match your experience or requires further clarification, please create support ticket via our portal (https://healthdatabe.atlassian.net/servicedesk/customer/portals) or send us an e-mail via support.healthdata@sciensano.be to report this documentation issue. Please, do not forget to mention the URL or web address of the page with the documentation issue. We will then adjust the documentation as soon as possible. Thank you!
MyCareNet dans HD4DP v2
MyCareNet dans HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Option 1 : Exportation XML via MyCareNet pour [nom de la DCD]
Option 1 : Exportation XML via MyCareNet pour [nom de la DCD]Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Option 2 : Intégration de MyCareNet dans HD4DP v2
Option 2 : Intégration de MyCareNet dans HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Nippin validation
Nippin validationScope
To support the Data Provider with the validation of the MyCarenet message, every night a CSV file is generated with the latest MyCareNet message information.
NexuzHealth hospitals are not able to validate this.
Requirements
The data provider needs access to the sftp folder of HD4DP2.0.
Request the credentials if you did not receive this in our support portal.
Server: IP of HD4DP v. 2 server
Username: (your SFTP credentials)
Password: (your SFTP credentials)
Path: /data/localsftp/upload (home directory of the user)
Output
Example output CSV file:
head -n2 output.csv
localdwh_id,localdwh_created_on,localdwh_registration_code,localdwh_register,nippin_message,nippin_interface_type,nippin_status,nippin_created_on,nippin_payload_after_validation,nippin_postresponse_tack_reference,result
16686,2024-06-18T06:38:01.449820+00:00,206.24.000214.88,OP_KNEE_PRIM_IMPLT,208f3aab-c97a-4ea0-aa70-6cba5e23ce72,REST,SENT,2024-06-18T06:38:01.938909+00:00,,11b7aeb0-4e41-496c-a9f0-8e506744b064,urn:nip:tack:result:major:success,valid
Interface type
| Interface type | Info |
| FILE_SYSTEM | HD4DP2.0 is configured with option 1 (DP will deliver the xml files to mycarenet) |
| REST | HD4DP2.0 is configured with option 2 (HD4DP2.0 will deliver the xml files to mycarenet) |
Status
| Status | Info |
| valid | A valid status means the payload looks okay and the nippin_status is SENT or TO_SEND. |
| invalid | An invalid status means the payload is wrong and the nippin_status is INVALID or ARCHIVED. The issue needs to be investigated by healthdata.be. Please create a ticket in our support portal. |
| not_found | No nippin message was created for the localdwh message. The issue needs to be investigated by healthdata.be. Please create a ticket in our support portal. |
| not_sent | This status is used when a payload is not able to be delivered to MyCareNet. The communication problem needs to be resolved and the messages need to be resend to MyCareNet. Please create a ticket in our support portal. |
Architecture 2.5
Architecture 2.5 Bart.Servaes sam 06/01/2024 - 15:52Convention de dénomination uniformisée
Convention de dénomination uniformiséeLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Envoi de valeurs de code au lieu de codes ID dans les demandes S2S
Envoi de valeurs de code au lieu de codes ID dans les demandes S2SLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Mapping MDM des codes de facturation pour MyCareNet
Mapping MDM des codes de facturation pour MyCareNetLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Bases de données
Bases de données Adelaide.DAmore mar 12/03/2024 - 16:26Obtenir les données du projet de la base de données locale de HD4DP v2
Obtenir les données du projet de la base de données locale de HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Base de données Nippin
Base de données NippinLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Online Acceptance Environment pour HD4DP v2
Online Acceptance Environment pour HD4DP v2Le contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.
Demande d'accès
Demande d'accèsLe contenu de cette page n'est disponible qu'en anglais. Sélectionnez le bouton de la langue EN dans le coin supérieur droit de l'écran pour le consulter.