Versions Compared

Old Version 40

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

Saved on

compared with

New Version 41

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 / MaterialVersionLocation
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).

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 MetaHub WS.


Basic Flow

FlowSpecifications


IDAR-UC10-BF
NamePut Patient Consent - HC Organization- Authorized organization in behalf of HIO - Doctor
DescriptionA doctor working in the authorized organization that acts in behalf of a Health Insurance Organization (HIO) declares an Informed Patient Consent on behalf of the patient. Using the eHealth Certificate of the Authorized Organization to access the Consent WS. 
Actor(s)
  • A doctor working in the authorized organization
Requirements
  • End-user is a doctor working in the authorized organisation that acts in behalf of a HIO
  • 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
TriggerThe user wants to declare 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

      ° The request is logged 

      ° The Informed Patient Consent is stored in eHealth Database

Post Conditions
  • Request is logged
  • Informed Patient Consent is stored in the eHealth Database
Test DataExample Request Authorized organization - Doctor
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 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



IDAR-UC10-AF01
NamePut Patient Consent - HC Organization - Authorized organization in behalf of HIO - Administrative 
DescriptionAn administrative working under the responsibility of a doctor in the authorized organization that acts in behalf of a Health Insurance Organization (HIO) declares an Informed Patient Consent. Using the eHealth Certificate of the Authorized Organization to access the Consent WS.
Actor(s)
  • An administrative working in the Authorized Organization under the responsibility of a doctor 
Requirements
  • End-user is an administrative working in the Authorized Organization under the responsibility of a doctor 
  • 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
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 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

      ° The request is logged 

      ° The Informed Patient Consent is stored in eHealth Database

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 DataExample Request Authorized organization - Administrative
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 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


IDAR-UC10-AF02
NamePut Patient Consent - HC Organization - Authorized organization in behalf of HIO - Patient
DescriptionA patient declares his Informed Patient Consent via an Authorized organization in behalf a HIO. Using the eHealth Certificate of the Authorized Organization to access the Consent WS.
Actor(s)
  • A patient
Requirements
  • End-user is a patient 
  • 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
TriggerThe user wants to declare 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

      ° The request is logged 

      ° The Informed Patient Consent is stored in eHealth Database

Difference in flow

Identification of the end-user 

→ Identification of HIO 

→ Identification of patient

Post Conditions 
  • Request is logged
  • Informed Patient Consent is stored in the eHealth Database
Test DataExample Request Authorized organization - Patient
End point(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 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



To Do 

Exceptional flows