Versions Compared

Old Version 13

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


ID
AR
UC-
UC06
115-BF
NamePut Patient Consent - Patient
DescriptionA patient declares his own "Informed Patient Consent" by using the WS Consent. The Certificate from the eID of the patient is used to access to the WS Consent. 
Actor(s)
  • A 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
  • Consent WS is integrated in the software of the end-user
  • Patient software information
  • Identification of the patient 

      °SSIN number 

      °First and last name (optional)

  • Information on the consent 

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

      °Type of consent: retrospective

      °Signing date of consent

TriggerThe user wants to declare his Patient Consent 
Precondition
  • The user has an account for the application
  • The user is logged out
FLow
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. 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
    1. 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 Condition(s)
    • Request is logged
    • The informed patient consent is stored in the eHealth Database
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database
    RemarksIf support card number is provided then it must be compliant e.g. correct format, check-digit and combination
    Additional InformationAdditional information  about patient e.g. first name and family name may be added for the audit purpose



    Alternative Flow

    NAKIJKEN CHECK PARENT LINK

    FlowSpecifications


    ID
    AR
    UC-
    UC06
    115-AF01
    NamePut Patient Consent - Parent of Patient
    DescriptionParent of the patient declares an "Informed Patient Consent" in behalf of the patient by using the WS Consent. The Certificate from the eID of the parent is used to access to the WS Consent.
    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 of the parent
    • Consent WS is integrated in the software of the end-user
    • Parent software information
    • Identification of the parent 

          °SSIN number 

          °First and last name (optional)

    • Information on the consent 

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

          °Type of consent: retrospective

          °Signing date of consent

    TriggerThe user wants to declare his Patient 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. 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
    1. 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 flowIdentification of the parent
    Post Conditions
    • Request is logged
    • The informed patient consent is stored in the eHealth Database
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database
    RemarksIf support card number is provided then it must be compliant e.g. correct format, check-digit and combination
    Additional Information
    Alternative Flow NAKIJKEN CHECK MANDATARY!
    Additional information  about parent e.g. first name and family name may be added for the audit purpose



    Alternative Flow 

    FlowSpecifications


    ID
    AR
    UC-
    UC06
    115-AF02
    NamePut Patient Consent - Mandatary of Patient
    DescriptionMandatary of the patient declares an "Informed Patient Consent" in behalf of the patient by using the WS Consent. The Certificate from the eID of the mandatary is used to access to the WS Consent
    Actor(s)Mandatary of the concerned 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 of the mandatary
    • Consent WS is integrated in the software of the end-user
    • Mandatary software information
    • Identification of the mandatary

          °SSIN number 

          °First and last name (optional)

    • Information on the consent 

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

          °Type of consent: retrospective

          °Signing date of consent

    TriggerThe user wants to declare his Patient Consent 
    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      °
    1. 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
    1. 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 flowIdentification of the Mandatary
    Post Conditions
    • Request is logged
    • The informed patient consent is stored in the eHealth Database
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database
    RemarksIf support card number is provided then it must be compliant e.g. correct format, check-digit and combination
    Additional InformationAdditional information  about mandatary e.g. first name and family name may be added for the audit purpose



    Exception Flow 1

    FlowSpecifications


    IDUC-115-EF01
    NamePut Patient Consent - Parent of mandatary of concerned patient - Deceased patient
    DescriptionA parent of mandatary of a patient wants to update an "Informed Patient Consent" by using the WS Consent. The Certificate from the eID of the end-user is used to access to the WS Consent. Concerned patient is deceased. 
    Actor(s)Parent or mandatary of concerned patient
    Requirements
    • End-user is a parent or 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 of the end-user
    • Consent WS is integrated in the software of the end-user
    • End-user software information
    • Identification of the end-user

          °SSIN number 

          °First and last name (optional)

    • Information on the consent 

          °Identification of concerned patient: Patient SSIN, 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 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 

    ent

    To Do 

    2. The Put Patient Consent Request is sent to the WS Consent 
    3. The WS Consent responds with a Put Patient Consent Response: error message (an informed consent of a deceased patient cannot be updated
    Post Condition(s)error message (an informed consent of a deceased patient cannot be updated
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database



    Exception Flow 2

    FlowSpecifications


    IDUC-115-EF02
    NamePut Patient Consent - Patient, parent of mandatary of concerned patient - Active consent already exists for the concerned patient
    DescriptionPatient, parent of mandatary of a patient wants to update an "Informed Patient Consent" by using the WS Consent. The Certificate from the eID of the end-user is used to access to the WS Consent. Active consent already exists for the concerned patient 
    Actor(s)Patient, parent or mandatary of concerned patient
    Requirements
    • End-user is a parent or 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 of the end-user
    • Consent WS is integrated in the software of the end-user
    • End-user software information
    • Identification of the end-user

          °SSIN number 

          °First and last name (optional)

    • Information on the consent 

          °Identification of concerned patient: 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 
    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
    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
    Exceptional flows