-
Created by Unknown User (gaelle.laurent.ext@imec.be), last modified on Apr 30, 2019
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 43
Next »
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 Consent WS.
Basic Flow
Flow | Specifications |
---|
| ID | AR-UC06-BF | Name | Put Patient Consent - Patient | Description | A 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) | | 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 | Trigger | The user wants to declare his Patient Consent | Precondition | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using his eID
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Put Patient Consent
- The Put Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Put Patient Consent Response
° The request is logged ° The Informed Patient Consent is stored in eHealth Database | 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
| Remarks | If support card number is provided then it must be compliant e.g. correct format, check-digit and combination | Additional Information | Additional information about patient e.g. first name and family name may be added for the audit purpose |
|
Alternative Flow
Flow | Specifications |
---|
| ID | AR-UC06-AF01 | Name | Put Patient Consent - Parent of Patient | Description | Parent 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 | 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 | Trigger | The user wants to declare his Patient Consent | Precondition(s) | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using his eID
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Put Patient Consent
- The Put Patient Consent Request is sent to the WS Consent
- ° 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 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
| Remarks | If support card number is provided then it must be compliant e.g. correct format, check-digit and combination | Additional Information | Additional information about parent e.g. first name and family name may be added for the audit purpose |
|
Alternative Flow
Flow | Specifications |
---|
| ID | AR-UC06-AF02 | Name | Put Patient Consent - Mandatary of Patient | Description | Mandatary 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 | Trigger | The user wants to declare his Patient Consent | Preconditions | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using his eID
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Put Patient Consent
- The Put Patient Consent Request is sent to the WS Consent
- ° 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 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
| Remarks | If support card number is provided then it must be compliant e.g. correct format, check-digit and combination | Additional Information | Additional information about mandatary e.g. first name and family name may be added for the audit purpose |
|