Versions Compared

Old Version 18

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

1.3
Cookbook / MaterialVersionLocation
Consent WS1.9https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthconsentSecure Token Service


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/

ehealthplatform

standards/

nl/service-iam-identity-access-managementMetaHub V2 Cookbook1.9.

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/
ehealthplatform/nl/service-verwijzingsrepertorium-hubs-metahub

General Information


Basic Flow

Basic Flow 

FlowSpecifications


ID
AR
UC-
UC04
119-BF
NamePut Patient Consent -
Pharmacy
HC Organization- Authorized organization in behalf of HIO - Doctor
Description
A pharmacist who is holder of the pharmacy declares an "

The doctor, working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization, 

declares an Informed Patient Consent
"
on behalf of the patient
by using the WS Consent. The personal
. Using the eHealth Certificate of the
pharmacy is used to log in
Authorized Organization to access the Consent WS. 
Actor(s)
A pharmacist who is the pharmacy holder
  • The actor is working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization. 
Requirements
End
  • The end-user is
a pharmacist who is the pharmacy holder 
  • End-user is not known in a hub
    • working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization.
    • 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
    Valid eHeatlh Certificate of the pharmacy
    • Consent WS is integrated in the software of the end-user
    Trigger 
    • Identification of the HIO: CBE number, HIO category
    • Identification of the doctor: SSIN number, NIHII (if available), professional category
    • Information consent 

          °Identification of concerned patient: SSIN, First and family name (optional)

          °Type of consent: retrospective

          °Signing date of consent 

    TriggerThe user wants to declare a Patient Consent
    on
    in the behalf of
    the patient
    a HIO
    Precondition(s)
    • The user has an account for the application
    • The user is logged out
    Flow
    1. The user attempts to
    login to
    1. access the eHealth Consent WS
    2. The user needs to request a SAML Token by using
    the eHealth Certificate of the pharmacy
    1. his eID 
    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 Put Patient Consent 
    6. The Put Patient Consent Request is sent to the WS Consent 
    °
    1. The informed Patient Consent is stored in eHealth Database
    2. The request is logged
    3. The WS Consent responds with a Put patient consent response
    Post Conditions
    • Request is logged
    • Informed Patient Consent is stored in the eHealth Database
    Test Data
    Endpoint(s)
    • WS Consent
    • eHealth Database
    Remarks
    • The identification of the Authorized organization is not mandatory in the Author of the request as the Trusted Third Party rule is applied
    • If support card number is provided then it must be compliant e.g. correct format, check-digit and combination
    • Support card number is not mandatory if the concerned patient is a
    Put Patient Consent Response

          ° The request is logged 

    • new born (0 < patient < 3 months)
    Additional InformationAdditional information about the HIO, doctor, administrative, patient e.g. software name, address, doctor, administrative, patient first and family name may be added for the audit purpose



    Alternative Flow

    FlowSpecifications


    IDUC-119-AF01
    NamePut Patient Consent - HC Organization - Authorized organization in behalf of HIO - Administrative 
    Description

    An administrative, working in a Health Insurance Organization (HIO) under the responsibility of a doctor and the request is transmitted via a recognized authorized organization, declares an Informed Patient Consent. Using the eHealth Certificate of the Authorized Organization to access the Consent WS.

    Actor(s)
    • An administrative working in a Health Insurance Organization (HIO) under the responsibility of a doctor and the request is transmitted via a recognized authorized organization. 
    Requirements
    • An administrative working in a Health Insurance Organization (HIO) under the responsibility of a doctor and the request is transmitted via a recognized authorized organization
    • 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 of the HIO: CBE number, HIO category
    • Identification of the doctor: SSIN number, NIHII (if available), professional category
    • Identification of the admin: SSIN number, professional category
    • Information consent 

          °Identification of concerned patient: SSIN, First and family name (optional)

          °Type of consent: retrospective

          °Signing date of consent 

    TriggerThe user wants to declare a Patient Consent in the behalf of a HIO
    Preconditions
    • 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 
    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 Put Patient Consent 
    7. The Put Patient Consent Request is sent to the WS Consent 
    8. The informed
          ° The Informed
    1. Patient Consent is stored in eHealth Database
    2. The request is logged
    3. The WS Consent responds with a Put patient consent response
    Post Condition(s)
    Difference in flowIdentification of the end-user --> Identification of the admin: SSIN Number, professional category needs to be added to the request
    Post Conditions
    • Request is logged
    • Informed Patient Consent is stored in the eHealth Database
    Test Data
    Endpoint(s)
    Alternative flow 
    • WS Consent
    • eHealth Database
    Remarks
    • The identification of the Authorized organization is not mandatory in the Author of the request as the Trusted Third Party rule is applied
    • If support card number is provided then it must be compliant e.g. correct format, check-digit and combination
    • Support card number is not mandatory if the concerned patient is a new born (0 < patient < 3 months)
    Additional InformationAdditional information about the HIO, doctor, administrative, patient e.g. software name, address, doctor, administrative, patient first and family name may be added for the audit purpose



    Exception Flow 1

    FlowSpecifications


    ID
    AR
    UC-
    UC04
    119-
    AF01
    EF01
    NamePut Patient Consent
    - Pharmacy end-user is not the pharmacy holderDescriptionA pharmacist who is holder of the pharmacy declares an "Informed Patient Consent" on behalf of the patient by using the WS Consent. The personal eHealth Certificate of the pharmacy is used to log in.Actor(s)
    • A pharmacist who isn't the holder of the pharmacy
    - HC Organization- Authorized organization in behalf of HIO - Doctor - Deceased patient
    Description

    The doctor, working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization, updates an Informed Patient Consent. Using the eHealth Certificate of the Authorized Organization to access the Consent WS. Deceased patient

    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. 
    • 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
    Requirements
  • End-user is a pharmacist who isn't the pharmacy holder 
  • End-user is not known in a hub
    • Valid eHeatlh Certificate of the pharmacy
    • Consent WS is integrated in the software of the end-user
    • Identification of the HIO: CBE number, HIO category
    • Identification of the doctor: SSIN number, NIHII (if available), professional category
    • Information consent 

          °Identification of concerned patient: SSIN, First and family name (optional)

          °Type of consent: retrospective

          °Signing date of consent 

    • Concerned patient is deceased
    TriggerThe user wants to
    declare
    update a Patient Consent
    on
    in the behalf of
    the patient
    a HIO
    Precondition(s)
    • The user has an account for the application
    • The user is logged out
    Flow
    1. The user attempts to
    login to
    1. access the eHealth Consent WS
    2. The user needs to request a SAML Token by using the eHealth Certificate of the
    pharmacy
    1. Authorized Organization
    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 Put Patient Consent 
    6. The Put Patient Consent Request is sent to the WS Consent 
    °
    1. The WS Consent responds with a Put Patient Consent Response: error message
    Post Condition(s)Error message
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database



    Exception Flow 2

    FlowSpecifications


    IDUC-119-EF02
    NamePut Patient Consent - HC Organization- Authorized organization in behalf of HIO - Doctor - Active consent already exists for the concerned patient
    Description

    The doctor, working in a Health Insurance Organization (HIO) and the request is transmitted via a recognized authorized organization, 

      ° The request is logged 

          ° The Informed Patient Consent is stored in eHealth Database

    updates an Informed Patient Consent. Using the eHealth Certificate of the Authorized Organization to access the Consent WS. Active consent already exists for the concerned patient

    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. 
    • 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 of the HIO: CBE number, HIO category
    • Identification of the doctor
    Difference in flowPut Patient Consent Request - Request : Identification of the end-user
    • : SSIN number, NIHII
    number
    • (if available), professional category
    Post conditions
    • Request is logged
    • Informed Patient Consent is stored in the eHealth Database
    • Information consent 

          °Identification of concerned patient: SSIN, First and family name (optional)

          °Type of consent: retrospective

          °Signing date of consent 

    • Active consent already exists for the concerned patient
    TriggerThe user wants to put a Patient Consent in the behalf of a HIO
    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 the eHealth Certificate of the Authorized Organization
    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 Put Patient Consent 
    7. The Put Patient Consent Request is sent to the WS Consent 
    8. The WS Consent responds with a Put Patient Consent Response: error message
    Post Condition(s)Error message
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database
    Test DataEndpoint(s)