-
Created by Unknown User (gaelle.laurent.ext@imec.be), last modified on May 24, 2019
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 12
Next »
The existence of an active ‘informed patient consent’ is one of the fundamental prerequisites for the healthcare providers to access patient’s medical data. Therefore, the eHealth platform makes available to the concerned patients and the health care actors involved in the exchange,
storage or referencing personal data a service to manage the ‘informed patient consent’ as defined by the deliberation 12/047 of the CSSSS/SCSZG1.
Technically, we identify the following attributes for an ‘informed patient consent’:
- The SSIN of the patient.
- The date of the consent registration (at the end-user side).
- The “type” of the consent If the consent is only valuable for data posterior to the signing date, it is called ‘prospective’ and ‘retrospective’ in the other case . According to the rules defined now, the only possible value for this attribute is ‘retrospective’. The attribute is present for backwards compatibility.
- The identity of the HCParty acting in the patient’s name (if applicable).
![](/download/attachments/17891552/Consent%20overview.PNG?version=1&modificationDate=1556094355832&api=v2)
The “informed consent” can be managed and verified throughout several ways and associated components. The above scheme provides an overview of all those components.
The “eHealth Consent WS” described here is only available for the software of the authorized healthcare professionals and institutions.
KMEHR
This service is a ‘KMEHR-based’ WS. We thus strongly recommend consulting the documentation related to the KMEHR normative elements. The KMEHR site aims to offer a central point for the documentation of the KMEHR normative elements.
https://www.ehealth.fgov.be/standards/kmehr/en
The three following generic elements are, in particular, essentials to build the request and the reply of eHealth Consent WS.
Basic Flow
Flow | Specifications |
---|
| ID | AR-UC146-BF | Name | Get Patient Consent - Doctor working in a recognized authorized organization that acts in behalf of a Health Insurance Organization (HIO) | Description | Get Patient consent allows end-users to check the existence and the latest status of the informed patient consent for the concerned patient. Get consent is done by a doctor working in a recognized authorized organization that acts in behalf of a Health Insurance Organization (HIO) | Actor(s) | Doctor working in a recognized authorized organization that acts in behalf of a Health Insurance Organization (HIO) | Requirements | - End-user is a doctor working in a recognized authorized organization that acts in behalf of a Health Insurance Organization (HIO)
- The informed patient consent is managed by a recognized authorized organization thru its usual software in behalf a HIO
- Valid eHealth Certificate of the authorized organization
- Consent WS is integrated in the software of the end-user
- Identification HIO: CBE number, HIO category
- Identification end-user: SSIN number, NIHII (if available), professional category
- Criteria relative to the consent
°Information concerned patient: INSS, Support card number (optional) °Type op consent (optional) | Trigger | The user wants to get a Patient Consent | Precondition(s) | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using a eHealth Certificate
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Get Patient Consent
- The Get Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Get Patient Consent Response
° The request is logged ° The information relative to the consent is returned | Post condition(s) | - The request is logged
- The information relative to the consent is returned
°SSIN of concerned patient °Consent type °Date of declaration °Author of declaration | Test Data | | End point(s) | - WS Consent
- eHealth Database
| Additional Information | - The SSIN & NIHII of the doctor end-user are optional for consultation method. If provided, they must be compliant with SSIN, NIHII validation (format and check-digit)
- SSIN support card number is not mandatory, if provided then it is discarded i.e. not submitted to the compliance validation in order to increase the performance of the consultation
|
|
Alternative Flow
Flow | Specifications |
---|
| ID | AR-UC146-AF01 | Name | Get Patient Consent - Administrative working in a recognized authorized organization under responsibility of a doctor, that acts in behalf of a Health Insurance Organization (HIO) | Description | Get Patient consent allows end-users to check the existence and the latest status of the informed patient consent for the concerned patient. Get consent is done by an administrative working in a recognized authorized organization under responsibility of a doctor, that acts in behalf of a Health Insurance Organization (HIO) | Actor(s) | Administrative working in a recognized authorized organization under responsibility of a doctor, that acts in behalf of a Health Insurance Organization (HIO) | Requirements | - End-user is an administrative working in a recognized authorized organization under responsibility of a doctor, that acts in behalf of a Health Insurance Organization (HIO)
- The informed patient consent is managed by a recognized authorized organization thru its usual software in behalf a HIO
- Valid eHealth Certificate of the authorized organization
- Consent WS is integrated in the software of the end-user
- Identification HIO: CBE number, HIO category
- Identification end-user: SSIN number, NIHII (if available), professional category
- Identification admin: SSIN number, professional category
- Criteria relative to the consent
°Information concerned patient: INSS, Support card number (optional) °Type op consent (optional) | Trigger | The user wants to get a Patient Consent | Precondition(s) | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using a eHealth Certificate
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Get Patient Consent
- The Get Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Get Patient Consent Response
° The request is logged ° The information relative to the consent is returned | Post Condition(s) | - The request is logged
- The information relative to the consent is returned
°SSIN of concerned patient °Consent type °Date of declaration °Author of declaration | Test Data | | End point(s) | - WS Consent
- eHealth Database
| Additional Information | - The SSIN & NIHII of the doctor end-user are optional for consultation method. If provided, they must be compliant with SSIN, NIHII validation (format and check-digit)
- SSIN support card number is not mandatory, if provided then it is discarded i.e. not submitted to the compliance validation in order to increase the performance of the consultation
|
|
Alternative Flow
Flow | Specifications |
---|
| ID | AR-UC146-AF02 | Name | Get Patient Consent - Patient | Description | Get Patient consent allows end-users to check the existence and the latest status of the informed patient consent for the concerned patient. Get consent is done by the concerned patient | Actor(s) | The concerned patient | Requirements | - End-user is a patient
- The informed patient consent is managed by a recognized authorized organization thru its usual software in behalf a HIO
- Valid eHealth Certificate of the authorized organization
- Consent WS is integrated in the software of the end-user
- Identification HIO: CBE number, HIO category
- Identification end-user: SSIN number
- Criteria relative to the consent
°Information concerned patient: INSS, Support card number (optional) °Type op consent (optional) | Trigger | The user wants to get a Patient Consent | Precondition(s) | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using a eHealth Certificate
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Get Patient Consent
- The Get Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Get Patient Consent Response
° The request is logged ° The information relative to the consent is returned | Post Condition(s) | - The request is logged
- The information relative to the consent is returned
°SSIN of concerned patient °Consent type °Date of declaration °Author of declaration | Test Data | | End point(s) | - WS Consent
- eHealth Database
| Additional Information | - SSIN support card number is not mandatory, if provided then it is discarded i.e. not submitted to the compliance validation in order to increase the performance of the consultation
|
|