Versions Compared

Old Version 56

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

Version

Location

Consent WS

1.9

https://www.ehealth.fgov.be/ehealthplatform/nl/service-ehealthconsent

Secure 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 Cookbook 1.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-metahub

General Information


Basic Flow 

Basic Flow - Health care professional of 78 not linked to a hospital


FlowSpecifications 


ID
AR
UC-
UC01
116-BF
NamePut Patient Consent - Health Care professional of
AR78 not linked to a hospital
AR78 (Physician, Dentist, Nurse, midwife)
DescriptionA health care professional of AR78
not linked to a hospital (a health care giver  who has his own practice and isn't known in a Hub
(Physician - Dentist - Nurse - Midwife) declares an "Informed Patient Consent" on behalf of the patient by using the WS Consent. The personal eHealth Certificate of the health care giver is used to
log in
access to the WS Consent. 
Actor(s)
  • A health care giver of AR78
not linked to a hospital and not known by a Hub (e.g. general practitioner, dentist,..
  • (Physician - Dentist - Nurse - Midwife)
Requirements
  • End-user is a health care professional
not linked to a hospital (e.g. General Practitioner,dentist,...
  • AR78 (Physician - Dentist - Nurse - Pharmacist - Midwife)
  • End-user
is not known in a hub
  • acts as author of the request through his software and manages himself
  • Valid personal eHeatlh Certificate 
  • Consent WS is integrated in the software of the end-user
  • Health care professional is not holder of the Global Medical File of the concerned patient
The end-user is not a pharmacy
  • Identification of end-user: 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

Trigger

The 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
login to
  1. access the eHealth Consent WS
  2. The user needs to request a SAML Token by using
it's personal eHealth Certificate      °
  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
    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 
    Endpoint(s)
    Alternative Flow - End-user is holder of Global Medical File
    • 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 software and/or end-user e.g. first name and family name may be added for the audit purpose

    Remark end-usersShould be available soon for Physician, Nurse, Dentist, Midwife, Audician, Physiotherapist, Occupational therapist, Practical nurse, Dietician, Audiologist, Podologist, Truss maker, Logopedist, Orthoptist, Lab technologist, Imaging technologist, clinical orthopedic pedagogue, clinical orthopedic pedagogue, clinical psychologist, dental hygienist If the HC party is the GMF holder, then the number of the support card is not required



    Alternative Flow

    FlowSpecifications


    ID
    AR
    UC-
    UC01
    116-AF01

    Name

    		Put Patient Consent - Physician who is holder of the concerned patient Global Medical
    File and not linked to a hospital
    File 
    DescriptionA physician who is holder of the concerned patient Global Medical file
    and is not linked to a hospital
    declares an "Informed Patient Consent" on behalf of the patient by using the WS Consent. The personal eHealth Certificate of the physician is used to
    log in
    access the Consent WS. 
    Actor(s)Physician who is holder of the concerned patient Global Medical File 
    Requirements
    • Physician is holder of the patient's Global Medical File 
    • End-user acts as author of the request through his software and manages himself
    • Valid personal eHeatlh Certificate 
    • Consent WS is integrated in the software of the end-user
    • Identification of end-user: SSIN number, NIHII number (if available), professional category
    • Information on the consent

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

         °Type of consent: Retrospective

         °Signing date of consent

    Trigger

    The 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 his eID 
    3. A request for a SAML Token is
    a physician not linked to a hospital (e.g. General Practitioner)End-user is not known in a hub
    1. sent to the Secure Token Service (STS)
    2. The STS responds with a SAML Token
    3. The user has access to the eHealth WS Consent
    4. The user does a request for Put Patient Consent 
    5. The Put Patient Consent Request is sent to the WS Consent 
    6. The informed Patient Consent is stored in eHealth Database
    7. The request is logged
    8. The WS Consent responds with a Put patient consent response
    Difference in flowPut Patient Consent - Consent : Patient SSIN support card NOT 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 informationAdditional information about the software and/or physician e.g. first name and family name may be added for the audit purpose



    Exception Flow 1

    FlowSpecifications


    IDUC-116-EF01
    NamePut Patient Consent - Health Care professional of AR78 - Deceased patient
    DescriptionA health care professional of AR78 (Physician - Dentist - Nurse - Midwife) updates an "Informed Patient Consent" for a deceased patient by using the WS Consent. The personal eHealth Certificate of the health care giver is used to access to the WS Consent. 
    Actor(s)
    • A health care giver of AR78 (Physician - Dentist - Nurse - Midwife)
    Requirements
    • End-user is a health care professional AR78 (Physician - Dentist - Nurse - Pharmacist - Midwife)
    • End-user acts as author of the request through his software and manages himself
    • Valid personal eHeatlh Certificate 
    • Consent WS is integrated in the software of the end-user
    Physician
    • Health care professional is not holder of the
    patient's Global Medical File 
    • Global Medical File of the concerned patient
    • Identification of end-user: 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
    declare
    update 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
    login to
    1. access the eHealth Consent WS
    2. The user needs to request a SAML Token by using it's personal 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 Put Patient Consent 
    7. The Put Patient Consent Request is sent to the WS Consent 
    °
    1. The WS Consent responds with a Put Patient Consent Response
    1. : error message
    Post Condition(s)Error message (deceased patient cannot be updated)
    Test Data
    End point(s)
    • WS Consent
    • eHealth Database
    Remark end-usersShould be available soon for Physician, Nurse, Dentist, Midwife, Audician, Physiotherapist, Occupational therapist, Practical nurse, Dietician, Audiologist, Podologist, Truss maker, Logopedist, Orthoptist, Lab technologist, Imaging technologist, clinical orthopedic pedagogue, clinical orthopedic pedagogue, clinical psychologist, dental hygienist 



    Exception Flow 2

    FlowSpecifications


    IDUC-116-EF02
    NamePut Patient Consent - Health Care professional of AR78 - Active consent already exists for the concerned patient
    DescriptionA health care professional of AR78 (Physician - Dentist - Nurse - Midwife) updates an "Informed Patient Consent" for a patient by using the WS Consent. The personal eHealth Certificate of the health care giver is used to access to the WS Consent. Active consent already exists for the concerned patient. 
    Actor(s)
    • A health care giver of AR78 (Physician - Dentist - Nurse - Midwife)
    Requirements
    • End-user is a health care professional AR78 (Physician - Dentist - Nurse - Pharmacist - Midwife)
    • End-user acts as author of the request through his software and manages himself
    • Valid personal eHeatlh Certificate 
    • Consent WS is integrated in the software of the end-user
    • Health care professional is not holder of the Global Medical File of the concerned patient
    • Identification of end-user: 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 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 it's personal 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 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
    Remark end-usersShould be available soon for Physician, Nurse, Dentist, Midwife, Audician, Physiotherapist, Occupational therapist, Practical nurse, Dietician, Audiologist, Podologist, Truss maker, Logopedist, Orthoptist, Lab technologist, Imaging technologist, clinical orthopedic pedagogue, clinical orthopedic pedagogue, clinical psychologist, dental hygienist 

          ° The request is logged 

          ° The Informed Patient Consent is stored in eHealth Database

    Difference in flowPut Patient Consent - Consent : Patient SSIN support card NOT mandatory Post conditions
    • Request is logged
    • The informed patient consent is stored in the eHealth Database
    Test DataEndpoint(s)