Used Documentation

Cookbook / Materials	Version	Location
Consent WS	1.9	https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthconsent

General Information

Informed Consent

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

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.

cd : This is the key element used to code information: this section is completely based on the description from the KMEHR standard, as can be found on: https://www.ehealth.fgov.be/standards/kmehr/en/page/key-elements#cd
id: This element is used to uniquely identify key elements like request, response of the WS, patient, HCParty. It can also be used to specify any unique identifier: this section is completely based on the description from the KMEHR standard, as can be found on: https://www.ehealth.fgov.be/standards/kmehr/en/page/key-elements#id
HC Party: The hcparty element is a generic element that aims to represent any kind of healthcare party: organization, physician, medical specialty, or even IT systems: this section is entirely based on the description from the KMEHR standard, as can be found on: https://www.ehealth.fgov.be/standards/kmehr/en/page/hcparty

Basic Flow

Flow

Specifications

ID	UC-140-BF
Name	Get Patient Consent Status - Doctor working in a recognized authorized organization that acts in behalf of a Health Insurance Organization (HIO)
Description	Get Patient Consent Status allows an end-user to check the existence and the latest status of the informed consent for the concerned patient. The difference between this method and the GetPatientConsent is that the consent status is displayed here. Request is done by a doctor, working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization.
Actor(s)	The actor is working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization.
Requirements	End-user is a doctor, working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization. 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 doctor: SSIN number, NIHII (if available), professional category Criteria relative to the consent: °Information concerned patient: INSS patient, Support card (optional) °Type of consent (optional)
Trigger	The user wants to retrieve the status of the informed 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 information relative to the consent is returned The request is logged The WS Consent responds with a Get Patient Consent Response
Post Condition(s)	The request is logged The information relative to the consent is returned °SSIN of concerned patient °Consent type °Date of declaration °Consent Status (GIVEN, REVOKED, DECEASED) °Author of declaration
Test Data	Example Get Patient Consent Status Request Example Get Patient Consent Status Response p64
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

Alternative Flow