Versions Compared

Old Version 5

changes.mady.by.user Unknown User (gaelle.laurent.ext@imec.be)

Saved on

compared with

New Version Current

changes.mady.by.user Unknown User (gaelle.laurent.ext@imec.be)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Used Documentation

Cookbook / MaterialsVersionLocation
Consent WS1.9https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthconsent
Secure Token Service1.3https://www.ehealth.fgov.be/ehealthplatform/nl/service-iam-identity-access-management
MetaHub V2 Cookbook1.9

https://www.ehealth.fgov.be/ehealthplatform/nl/service-verwijzingsrepertorium-hubs-metahub


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

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

FlowSpecifications


ID
AR
UC-
UC149
136-BF
NameGet Patient Consent Status - Patient
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 the concerned patient.

Actor(s)Concerned patient
Requirements
  • End-user is a patient
  • End-user acts as author of the request through his software and manages himself throughout his usual software
  • Valid eID
  • Identification end-user: patient software information - SSIN number
  • Criteria relative to the consent: 

     °Information concerned patient: INSS patient, Support card (optional)

     °Type of consent (optional)

TriggerThe 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
  1. The user attempts to access the eHealth Consent WS
  2. The user needs to request a SAML Token by using a eHealth Certificate
  3. A request for a SAML Token is sent to the Secure Token Service (STS)
  4. The STS responds with a SAML Token
  5. The user has access to the eHealth WS
is integrated in the software of the end-user
  • INSS concerned patient
    • An active consent
    1. Consent
    2. The user does a request for Get Patient Consent 
    3. The Get Patient Consent Request is sent to the WS Consent 
    4. The information relative to the consent is returned
    5. The request is logged 
    6. 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
    End point(s)
    • WS Consent
    • eHealth Database
    Additional InformationSSIN 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

    FlowSpecifications


    IDUC-136-AF01
    NameGet Patient Consent Status - Parent of patient
    DescriptionGet 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 parent of the concerned patient.
    Actor(s)Parent of the concerned patient, who is younger than 18 years of age.
    Requirements
    • End-user is a parent of the concerned patient
    • End-user acts as author of the request through his software and manages himself throughout his usual software
    • Valid eID
    • Identification end-user: parent software information - SSIN number
    • Criteria relative to the consent: 

         °Information concerned patient: INSS patient, Support card (optional)

         °Type of consent (optional)

    TriggerThe user wants to
    get a Patient Consent Status
    retrieve the status of the informed consent
    Precondition(s)
    • The user has an account for the application
    • The user is logged out
    Flow
    1. The user attempts to access the eHealth Consent WS
    2. The user needs to request a SAML Token by
    using his eID 
    1. using a eHealth Certificate
    2. A request for a SAML Token is sent to the Secure Token Service (STS)
    3. The STS responds with a SAML Token
    4. The user has access to the eHealth WS Consent
    5. The user does a request for Get Patient
    Consent Status
    1. Consent 
    2. The Get Patient Consent
    Status
    1. Request is sent to the WS Consent 
    °
    2. The information relative to the consent is returned
    3. The request is logged 
    4. The WS Consent responds with a Get Patient Consent
    Status Response

          ° The request is logged 

    1. 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
    End point(s)
    • WS Consent
    • eHealth Database
    Additional InformationSSIN 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

    Alternative Flow
          °
    FlowSpecifications


    IDUC-136-AF02
    NameGet Patient Consent Status - Mandatary of patient
    DescriptionGet 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 mandatary of the concerned patient.
    Actor(s)Parent of patient
    Requirements
    • End-user is a mandatary of the concerned patient
    • End-user acts as author of the request through his software and manages himself throughout his usual software
    • Valid eID
    • Identification end-user:  mandatary software information - SSIN number
    • Criteria relative to the consent: 

         °Information concerned patient: INSS patient, Support card (optional)

         °Type of consent (optional)

    TriggerThe 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
    1. The user attempts to access the eHealth Consent WS
    2. The user needs to request a SAML Token by using a eHealth Certificate
    3. A request for a SAML Token is sent to the Secure Token Service (STS)
    4. The STS responds with a SAML Token
    5. The user has access to the eHealth WS Consent
    6. The user does a request for Get Patient Consent 
    7. The Get Patient Consent Request is sent to the WS Consent 
    1. The information relative to the consent is returned
    2. The request is logged 
    3. 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
    End point(s)
    • WS Consent
    • eHealth Database
    Additional InformationSSIN 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