Technische handleiding van de applicatie HD4DP v2

Technische handleiding van de applicatie HD4DP v2

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Bart.Servaes wo, 11/22/2023 - 12:52

HD4DP v2 Installation

HD4DP v2 Installation

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

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

Server Installation and Configuration

Installing and configuring the server requires the following actions:

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

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

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

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

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

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

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

Server installation timing

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

  • Starting date;
  • Finalization date.

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

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

manager di, 02/20/2024 - 11:24

HD4DP v2 Infrastructure instructions

HD4DP v2 Infrastructure instructions

Introduction

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

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

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

Overview

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

An HD4DP v2 deployment comprises of following components:

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

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

Network configuration

IP

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

DNS

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

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

Firewall

The following connections should be possible in the firewall flow:

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

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

Server installation

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

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

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

Instructions

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

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

Please find the installation steps below.

Installation steps

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

Configuration steps

Connecting to the server

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

Instructions (from a Windows machine):

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

Administrator account for internal use

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

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

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

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

Create the user:

            sudo adduser <username>

Add the user to the sudo group

            sudo usermod -aG sudo <username>

Installation and configuration of the software stack

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

Backups

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

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

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

Patching and Updates

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

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

Antivirus and Monitoring

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

Contact information

https://support.healthdata.be

Email: support.healthdata@sciensano.be

Phone: +32 2 793 01 42 

johanvanbussel do, 06/29/2023 - 15:57

HD4DP v2 Infrastructure Sheet

HD4DP v2 Infrastructure Sheet

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

Below you can find the description of the necessary information:

SERVER CONNECTION

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

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

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

SERVER MACHINE

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

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

ATTACHED DRIVE FOR BACKUPS

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

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

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

USER MANAGEMENT

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

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

LDAP configuration (Optional)

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

  • Connection URL
  • Username
  • Password³

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

SOFTWARE CONFIGURATION

Encryption Module interface

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

  • REST web service
  • File system

REST web service interface

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

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

File system interface

  • "Incoming directory: Directory where HD4DP checks for incoming files"
  • "Incoming directory: Directory where HD4DP writes outgoing files"
  • "Incoming directory: Directory to which HD4DP moves successfully processed files"
  • "Incoming directory: Directory to which HD4DP moves unsuccessfully processed files"
johanvanbussel do, 08/31/2023 - 12:21

Requirements for the HD4DP installation

Requirements for the HD4DP installation

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

The file is available for download below.

Bart.Servaes wo, 12/06/2023 - 09:44

HD4DP v2 S2S API

HD4DP v2 S2S API

Introduction

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. Please read this documentation before its project specific use.

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:

pedro.fernandez vr, 04/12/2024 - 11:07

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

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

Table of contents

API description

The baseURL to be used has to following built: https://<hd4dp_url>/proxy

API end-pointResponseAuthenticationNotes
{{baseURL}}/api/organizations  List of organizations. Client must select the right organizationId NoCurrent 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. 
{{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. Nohttps://github.com/Sciensano-Healthdata/hd4-formio/blob/develop/dev/mock_menu_structure/menu-structure.json  
{{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   YesThis 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/payload/example?dcd-id={dcdId}; <optional>version={version} Example of payload in JSON format YesProviding 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/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  YesSome 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>. 
{{baseURL}}/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 {{baseURL}}/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 {{baseURL}}/api/dcd/menu/structure?organization-id={organizationId} 

Request parameters 

  • {organizationtId}: Id of the organization 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.

  { 

    "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 {{baseURL}}/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 {{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 

Submit DCD registrations

Request example  

POST {{baseURL}}/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.

Submission of drafts

To submit a draft, the only thing to add is the key STATUS (all upper case) with the value "draft" to the request, like this:

"STATUS": "draft",

If the status is sent as "draft", a draft registration is created. In case of a successful submission the user receives a HTTP 202 (Accepted) notification with an empty business key, like this: 

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, like this: 

Note that only "draft" status needs to be sent when sending a draft. The status "submit" is not necessary when performing a complete submission.


In the GUI, 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 GUI, the business key is generated and the process completed.

Adding separators to a NISS number

It is not necessary to add separators in a NISS number when uploading a file using S2S API. You can fill the NISS number out both with or without seperators. E.g.: 85.04.02-169.32 or 85040216932.

pedro.fernandez wo, 04/10/2024 - 12:04

2. API Endpoint for supporting the DCD submit process

2. API Endpoint for supporting the DCD submit process

Table of contents

API description

The baseURL to be used has to following built: https://<hd4dp_url>/proxy

API end-pointResponseNotes
{{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. <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  
{{baseURL}}/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 
{{baseURL}}/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 
{{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 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 
{{baseURL}}/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 {{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?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 {{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" 

Search for SADMI medical devices 

Request example  

GET {{baseURL}}/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

. . . . .  

   }, 

. . . . .  

Adding 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 wo, 04/10/2024 - 11:51

3. MDM Field description - DB Model

3. MDM Field description - DB Model
pedro.fernandez do, 10/05/2023 - 15:13

4. Swagger API

4. Swagger API

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

Swagger api

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.

Attention: The baseURL to be used has to following built: https://<hd4dp_url>/proxy

jeroen.maelbrancke wo, 04/10/2024 - 11:58

5. Postman collection

5. Postman collection

Postman collection HD4DP2.0 can be downloaded here.

Attention: The baseURL to be used has to following built: https://<hd4dp_url>/proxy

jeroen.maelbrancke wo, 04/10/2024 - 11:58

HD4DP v2 CSV Upload

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.

Training

Below you can review the HD4D¨2 CSV Upload training organized by healthdata.be:

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 do, 04/11/2024 - 17:13

Process to upload a CSV file to submit DCD registrations

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 HD4DP 2.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 HD4DP 2.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 pick-up location will be identical for all registries.
Pre-registry handling will be based on a naming-convention of the csv file.

HOW TO: Upload data using CSV Upload

Steps To Upload data

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

  • Extract the csv file from the electronic patient files and/or other local databases.
  • Author group, Author and Coauthor:
    • When the Author Group, Author and Coauthor have been left out in the csv file, the default Author group, Author and Coauthor will be used automatically.
    • When the desired Author Group, Author and Coauthor are specified in the csv file, the following headers TX_AUTHOR_GR, TX_AUTHOR and TX_COAUTHOR must be added to the csv file with their values respectively.

      Example:
TX_AUTHOR_GR;TX_AUTHOR;TX_COAUTHOR
Test 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.

  • Similarly, add the field name 'STATUS' in capitals in an additional column. Add the value 'draft' in case a manual submission of the record is requested.
    If not, the record will be submitted without manual intervention.
  • Adding separators to a NISS number:
    It is not necessary to add separators in a NISS number when uploading a file using CSV Upload. You can fill out the NISS number both with or without separators. E.g.: 85.04.02-169.32 or 85040216932.

    Example:
  • Make sure the name of the csv file has the correct format:
    HD_DCD_submcsv_HDBPnumber_HDBPabbreviation_versionnumber_versionreleasedate

So FOR EXAMPLE for Orthopride Knee - Primo Implantation the format would be:
HD_DCD_submcsv_HDBP0288_Orthopride_Knee_Primo_02_20230505.csv

EXAMPLES:

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 ma, 12/18/2023 - 16:37

HD4DP v2 MyCareNet

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.

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

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 ma, 02/26/2024 - 09:15

Option 1: XML export for MyCareNet component of HCO

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)
Deze documentatie wordt regelmatig bijgewerkt. We proberen de informatie zo correct, volledig en zo duidelijk mogelijk weer te geven. Als u desondanks iets in de documentatie ziet dat niet correct is, niet overeenkomt met uw ervaring, of verdere verduidelijking vereist, maak dan een verzoek aan (type: verzoek om informatie) via ons portaal (https://sciensano.service-now.com/sp) of stuur ons een e-mail via support.healthdata@sciensano.be om dit documentatieprobleem te melden. Vergeet niet de URL of het webadres van de pagina met het documentatieprobleem te vermelden. Wij zullen de documentatie dan aanpassen. Bedankt!

hamza.kursun@s… zo, 10/02/2022 - 16:03

Option 2: MyCareNet integration in HD4DP v2

Option 2: MyCareNet integration in HD4DP v2

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

  1. Whitelisting URLs
  2. Upload eHealth certificate in HD4DP v.2
  3. Provide eHealth password to make the interface work with NIC/CIN.

Whitelist URL

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 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/

  1. Open KeyStore Explorer, and create a new KeyStore 

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

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

4. Select the type of key pair import required:

5. Browse the Ehealth NIHII-HOSPITAL P12 certificate and fill in the Decryption Password

6. mport the PKCS #12 Key Pair and give it the NIHII number as alias, ex 71001129 

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

8. The Key Pair is imported successfully

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

10. In the menu bar go to File -> Save All

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

12. Click OK and save the KeyStore as ehealth_certificate.p12

13. Click save and the P12 for HD4DP is created

Upload certificate

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

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

Deze documentatie wordt regelmatig bijgewerkt. We proberen de informatie zo correct, volledig en zo duidelijk mogelijk weer te geven. Als u desondanks iets in de documentatie ziet dat niet correct is, niet overeenkomt met uw ervaring, of verdere verduidelijking vereist, maak dan een verzoek aan (type: verzoek om informatie) via ons portaal (https://sciensano.service-now.com/sp) of stuur ons een e-mail via support.healthdata@sciensano.be om dit documentatieprobleem te melden. Vergeet niet de URL of het webadres van de pagina met het documentatieprobleem te vermelden. Wij zullen de documentatie dan aanpassen. Bedankt!

hamza.kursun@s… zo, 10/02/2022 - 16:04

Architectuur 2.5

Architectuur 2.5 Bart.Servaes do, 11/16/2023 - 16:37

Uniformed naming convention

Uniformed naming convention

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Bart.Servaes wo, 11/22/2023 - 22:38

Sending code values instead of code IDs in S2S requests

Sending code values instead of code IDs in S2S requests

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Bart.Servaes wo, 11/22/2023 - 22:51

MDM Mapping of billing codes for MyCareNet

MDM Mapping of billing codes for MyCareNet

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Bart.Servaes wo, 11/22/2023 - 23:08

Databases

Databases Bart.Servaes wo, 02/14/2024 - 17:32

Project data ophalen uit de lokale database van HD4DP v2

Project data ophalen uit de lokale database van HD4DP v2

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Bart.Servaes wo, 11/22/2023 - 23:48

Nippin database

Nippin database

The different statuses of a Nippin message in the database

StatusDescription
TO_SEND HD4DP v2 ready to be sent to MyCareNet or SFTP folder
ARCHIVEDMessages are set to ARCHIVED, only if the NippinCleanup table has 0 records. These messages will not be processed and won't receive any attention afterwards.
INVALIDXML payload is invalid, a ticket can be created at our service portal, including the payload of the invalid message.
BUFFEREDnot used
ERRORHD4DP v2 was not able to send the message to MyCareNet or SFTP folder
SENTHD4DP v2 was able to send the message to MyCareNet or SFTP folder
Column Name Data Type Description
id bigserial Primary Key
message_id varchar(255) Identifier for the message
identification_value text Identification value of the organization that is sending the message
name text Name of the organization that is sending the message
payload text Payload of the message
payload_after_validation text Payload after (xsd-)validation
response text Response to the message (received from myCarenet)
valid boolean Whether the message is valid or not
interface_type varchar(25) Type of interface used for the message (e.g. FILE_SYSTEM or REST)
status varchar(25) Current status of the message (possible states : INVALID (validation against xsd-scheme failed), TO_SEND (ready for sending to myCarenet), SENT (sent to myCarenet), ERROR (something went wrong during sending, e.g. unable to reach myCarenet))
created_on timestamp Timestamp of when the message was created
input_reference varchar(255) Reference for the input message (this is a unique identifier that can be used for debugging/tracing with myCarenet)
issuer text Issuer of the message
postresponse_tack_applies_to text Applies-to value for the TACK post-response (received from myCarenet)
postresponse_tack_id text ID of the TACK post-response (received from myCarenet)
postresponse_tack_reference text Reference for the TACK post-response (received from myCarenet)
postresponse_tack_resultMajor text Result major for the TACK post-response (received from myCarenet)
postresponse_tack_resultMinor text Result minor for the TACK post-response (received from myCarenet)
postresponse_tack_resultMessage text Result message for the TACK post-response (received from myCarenet)
previous_registrationcode varchar(255) Previous registration code for the message (obsolete)
current_registrationcode varchar(255) Current registration code for the message (value will be identical to previous_registrationcode)
version_tag varchar(255) Current application-version

Granted privileges

databaseuserprivileges
nippindpuserCONNECT/nippin_message:SELECT/nippin_cleanup:SELECT

Queries

  • Count records grouped by the type and status:
nippin=# select interface_type, status, count(id) from nippin_message group by interface_type,status;
 interface_type | status  | count
----------------+---------+-------
 FILE_SYSTEM    | SENT    |   117
 FILE_SYSTEM    | INVALID |   352
 FILE_SYSTEM    | TO_SEND |  9238
(3 rows)
  • Get all error and invalid information:
select id, message_id, project_id, dcd_id, payload_after_validation from nippin_message where status in ('INVALID', 'ERROR');
  • Get previous and current registration code:
select id, message_id, project_id, dcd_id, previous_registrationcode, current_registrationcode from nippin_message;
  • Get nippin cleanup information:
select * from nippin_cleanup;

MyCareNet integration-specific queries

Only for hospitals that are using the Nippin integration in HD4DP v2.

  • Count records with status SENT and group them based on the reference ID received from MyCareNet:
 select postresponse_tack_result_major, postresponse_tack_reference, count(*)  from nippin_message where status = 'SENT' group by status, postresponse_tack_result_major, postresponse_tack_reference;
  postresponse_tack_result_major   |     postresponse_tack_reference      | count
-----------------------------------+--------------------------------------+-------
 urn:nip:tack:result:major:success | ***** |   2
 urn:nip:tack:result:major:success | ***** |   88

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!

jeroen.maelbrancke vr, 04/12/2024 - 15:47

Online Acceptance Environment (OACC) voor HD4DP v2

Online Acceptance Environment (OACC) voor HD4DP v2

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Bart.Servaes do, 11/23/2023 - 00:11

Toegang aanvragen

Toegang aanvragen

De inhoud van deze pagina is alleen beschikbaar in het EN. Selecteer de EN knop om de pagina te openen.

Adelaide.DAmore zo, 01/07/2024 - 15:55