Versions Compared

Old Version 33

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/MaterialsVersionLocation
eHealth 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.

ehealthplatformnlservice-verwijzingsrepertorium-hubs-metahubGeneral Information


Basic Flow 


FlowSpecifications


IDARUC-UC08117-BF
NamePut Patient Consent -Health care professional of AR 78 in a hospital 
DescriptionA health care professional of AR 78 in a hospital declares an Informed Patient Consent on behalf of the patient by using the WS Consent. The eHealth Certificate of the hospital is used to access the WS Consent. Only the hospital is checked in the rules of access.
Actor(s)
  • A health care professional of AR 78 in a hospital 
Requirements
  • End-user is a professional of AR 78 working in a hospital 
  • Valid eHealth certificate of the hospital
  • Consent WS is integrated in the software of the hospital
  • The informed patient consent is managed in a recognized hospital throughout its usual software
  • Identification hospital: NIHII, the organization category
  • Identification of care giver: SSIN number, NIHII number (if available), professional category
  • Information on the consent

     °Identification concerned patient: SSIN, SSIN support card number, First and family name (optional)

     °Type of consent: Retrospective

     °Signing date of consent

TriggerThe user wants to declare a Patient Consent on behalf of the patient
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
the eHealth Certificate of the hospital
  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 
  • ° The WS Consent responds with a Put Patient Consent Response
    •       °
    1. The informed Patient Consent is stored in eHealth Database
    2. The request is
    logged 
    1. logged

          ° The Informed Patient Consent is stored in eHealth Database

    1. The WS Consent responds with a Put patient consent response
    Post ConditionPostcondition(s)
    • Request is logged
    • The informed patient consent is stored in the eHealth Database
    Test Data
    Endpoint(s)
    • WS Consent
    • eHealth Database
    Remarks
    • 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 hospital, doctor, software name, address, doctor name, may be added for the audit purpose



    Alternative Flow 


    FlowSpecifications


    IDARUC-UC08117-AF01
    NamePut Patient Consent -Administrative working in a hospital  
    Description

    An administrative working in a hospital under the responsibility of a doctor declares an Informed Patient Consent on behalf of the patient by using the WS Consent. The eHealth Certificate of the hospital is used to access the WS Consent. 

    Actor(s)
    • An administrative working in a hospital under the responsibility of a doctor
    Requirements
    • Administrative working a hospital under the responsibility of a doctor
    • Valid eHealth certificate of the hospital
    • Consent WS is integrated in the software of the hospital
    • The informed patient consent is managed in a recognized hospital throughout its usual software
    • Identification hospital: NIHII, the organization category
    • Identification of physician: SSIN number, NIHII number (if available), professional category
    • Identification of admin: SSIN number, professional category
    • Information on the consent

         °Identification concerned patient: SSIN, SSIN support card number, First and family name (optional)

         °Type of consent: Retrospective

         °Signing date of consent

    TriggerThe user wants to declare a Patient Consent on behalf of the patient
    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 hospital
    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 
  • ° The WS Consent responds with a Put Patient Consent Response
    •       °
    1. The informed Patient Consent is stored in eHealth Database
    2. The request is
    logged 
    1. logged
          ° The Informed Patient Consent is stored in eHealth Database
    1. The WS Consent responds with a Put patient consent response
    Difference in flowPut Patient Consent Request - Request: Identification of the admin: SSIN number, the professional category is mandatory
    Post conditions
    • Request is logged
    • The informed patient consent is stored in the eHealth Database
    Test Data
    Endpoint(s)
    • WS Consent
    • eHealth Database
    Remarks
    • 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 Information Additional information about the hospital, doctor, administrative e.g. software name, address, doctor name, administrative name may be added for the audit purpose



    Exception Flow 1

    FlowSpecifications


    IDUC-117-EF01
    NamePut Patient Consent -Health care professional of AR 78 in a hospital - Deceased patient
    DescriptionA health care professional of AR 78 in a hospital updates an Informed Patient Consent for a deceased patient by using the WS Consent. The eHealth Certificate of the hospital is used to access the WS Consent. Only the hospital is checked in the rules of access.
    Actor(s)
    • A health care professional of AR 78 in a hospital 
    Requirements 
    • End-user is a professional of AR 78 working in a hospital 
    • Valid eHealth certificate of the hospital
    • Consent WS is integrated in the software of the hospital
    • The informed patient consent is managed in a recognized hospital throughout its usual software
    • Identification hospital: NIHII, the organization category
    • Identification of care giver: SSIN number, NIHII number (if available), professional category
    • Information on the consent

         °Identification concerned patient: SSIN, SSIN support card number, First and family name (optional)

         °Type of consent: Retrospective

         °Signing date of consent

    • Concerned patient is deceased
    TriggerThe user wants to update a Patient Consent
    Precondition(s)
    • The user has an account for the application
    • The user is logged out
    Flow
    1. The user attempts access the eHealth Consent WS
    2. The user needs to request a SAML Token by using the eHealth Certificate of the hospital
    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



    Exception Flow 2

    FlowSpecifications


    IDUC-117-EF02
    NamePut Patient Consent -Health care professional of AR 78 in a hospital - Active consent already exists for the concerned patient
    DescriptionA health care professional of AR 78 in a hospital updates an Informed Patient Consent for a patient by using the WS Consent. The eHealth Certificate of the hospital is used to access the WS Consent. Only the hospital is checked in the rules of access. Active consent already exists for the concerned patient
    Actor(s)
    • A health care professional of AR 78 in a hospital 
    Requirements
    • End-user is a professional of AR 78 working in a hospital 
    • Valid eHealth certificate of the hospital
    • Consent WS is integrated in the software of the hospital
    • The informed patient consent is managed in a recognized hospital throughout its usual software
    • Identification hospital: NIHII, the organization category
    • Identification of care giver: SSIN number, NIHII number (if available), professional category
    • Information on the consent

         °Identification concerned patient: SSIN, SSIN support card number, 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
    Precondition(s)
    • The user has an account for the application
    • The user is logged out
    Flow
    1. The user attempts access the eHealth Consent WS
    2. The user needs to request a SAML Token by using the eHealth Certificate of the hospital
    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