...
| Cookbook/ materials | Version | Location | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| eHealthConsent WS Cookbook | 1.9 | |||||||||
| KMEHR | - | https://www.ehealth.fgov.be/standards/kmehr/en | ||||||||
| Jira ticket MHEH-12 | - |
| ||||||||
| Jira ticket MHEH-13 | - |
| ||||||||
| Jira ticket MHEH-18 | - |
| ||||||||
| Jira ticket MHEH-20 | - |
| ||||||||
| Jira ticket MHEH-26 | - |
| ||||||||
| Jira ticket MHEH-31 | - |
| ||||||||
| Jira ticket MHEH-32 | - |
|
...
In the figure below, we present a logical view about the relationship between the three basic services of the ehealth platform that are the WS Consent, the Therapeutic link WS, and the Therapeutic exclusion services.
The following end users can declare or revoke a patient consent via the WS Consent :
...
A consent can be managed by different types of end-users:
- Health Care (HC) parties: a physician, a pharmacy (it is noteworthy that there is no difference between pharmacy and a pharmacist), Hospital, Dentist, Nurse, Midwife
...
- Management by Patient : Patient, Mandatary or Parent
...
- , Health Insurance Organization (HIO), Authorized organization in behalf of a HIO, Group of nurses
- Citizen: a patient, a parent of a patient, a mandatary
The Consent services provides four methods:
- The "PutPatientConsent" method allows an end-user to declare the patient consent (i.e. make a consent active)
- The "RevokePatientConsent" method enables an end-user to revoke the patient consent (i.e. make a consent inactive)
- The "GetPatientConsent" method allows an end-user to consult information about a consent and to check whether its status (i.e. active or inactive)
- The "GetPatientConsentStatus" method is similar as the "GetPatientConsent" method with the status of the consent returned in the response message.
Basic flow
| Flow | Specification | ||
|---|---|---|---|
Use case ID | ATH-UC-12-BF | ||
Use case name | Consult the consent of a patient | ||
Actors |
| ||
Short Description | In order to change a profile, the user should do a global logout and should authenticate him/herself a second time.consult the consent of a patient, | ||
| Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | ||
Pre-Conditions | The user has an active session in the IDP with an old profile |||
Post-Conditions | The user has a new open session with the new profile |||
Steps (basic flow) | 0 The user has an open session in the IDP with the old profile | ||
| 1The user do a global logout in order to close the session in the IDP | |||
2The user re-authenticates him/herself via the mobile application in order to change the profile | |||
| 3The mobile application sends an openID connect authorization request to the IAM connect | |||
4 The IAM connects redirects the message to the eHealth IDP in a browser | |||
| 5 | The IDP detects that there is not an open session with the NISS and the name of the user | ||
6The IDP redirects the request to the CSAM in order to open a session | |||
7The user selects the authentication way (i.e. itsme, eID, TOTP) | |||
| 8The user is authenticated and CSAM returns a SAML assertion to the IDP regarding the user | |||
| 9 | The user selects a new profile and the IDP returns the selected profile to the IAM connect | ||
| 10 | The IAM connect creates an access token JWT with the new profile and returns it to the clent | ||
| 11 | The user is authenticated and accesses to the permitted services in the mobile application with respect to the new profile | ||
Exceptions (exception flows) | |||
Frequency |
| ||