Used documentation
Jira ticket MHEH-12 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-12 |
---|
|
|
Jira ticket MHEH-13 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-13 |
---|
|
Jira ticket MHEH-18 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-18 |
---|
|
Jira ticket MHEH-20 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-20 |
---|
|
|
Jira ticket MHEH-26 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-26 |
---|
|
|
Jira ticket MHEH-31 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-31 |
---|
|
|
Jira ticket MHEH-32 | - | Jira |
---|
server | imec Validation Lab |
---|
serverId | ac11aa92-3976-3161-9ddb-5020cc76f1c7 |
---|
key | MHEH-32 |
---|
|
|
General information
Basic flow
General information
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. 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, Health Insurance Organization (HIO), Authorized organization in behalf of a HIO, Group of nurses
- Citizen: a patient, a parent of a patient, a mandatary
Image Added
A consent may have two types. Indeed, it is called prospective when it is valuable for data posterior to the signing date (i.e. the date that should be taken into account is the ‘medical date’ of the transaction). It is referred to as retrospective in the opposite case.
The Consent service provides four methods (it is noteworthy that in this use case only the GetPatientConsent method is used):
- 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 |
---|
Image Added
|
Flow | Specification | | ATH-UC-12-BF |
Use case name | Consult the consent of a patient using the GetPatientConsent method |
Actors | |
Healthcare giverRepresentative of an institution |
Short Description | In order to |
change a profile, the user should do a global logout and should authenticate him/herself a second timeconsult the consent of a patient using the SOA-based version, it is important to use the Token exchange service in order to convert a JWT token into a SAML one (and vice versa). The aim of this use case is to check a consent status after its activation or revoke. |
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. |
Pre-Conditions | |
has an active session in the IDP with an old profile - is already logged in via the Token exchange service
- Information about the request (request identifier, end-user identifier, date and time of the request)
- SSIN of the concerned patient
- Type of the consent (optional)
|
Post-Conditions |
The user has a new open session with the new profile Information about the response (response identifier, end-user identifier, data and time of the response, initial request) - An acknowledgement (status of the completion, errors if exist)
- Information about the consent (SSIN of the patient, consent type, data of declaration, author of the declaration)
|
Steps (basic flow) |
0 | The user has an open session in the IDP with the old profile do a global logout in order to close the session in the IDP2 | The user re-authenticates him/herself via the mobile application in order to change the profile | 3 | The mobile application sends an openID connect authorization tries to consult the consent and the client sends a getPatientConsent request to the IAM connect |
4 connects redirects message eHealth IDP in a browser5 | The IDP detects that there is not an open session with the NISS and the name of the user | 6 | The IDP redirects the request to the CSAM in order to open a session | 7 | The user selects the authentication way (i.e. itsme, eID, TOTP) | 8 | The 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 | WS consent |
| 3 | The WS consent finds information about the consent of a patient |
| 4 | The WS consent sends a response to the IAM |
| 5 | The IAM connect receives the response and sends it to the client |
| 6 | The client receives information about the consent of the patient |
11 | The user is authenticated and accesses to the permitted services in the mobile application with respect to the new profile |
Exceptions (exception flows) | - Invalid or incorrect data:
- Invalid transaction identifier.
- Invalid request sender.
- Invalid healthcare party identifier.
- Invalid patient identifier (invalid SSIN, eID, SIS numbers).
- Invalid consent type.
|
Frequency | - Every time the user wants to
|
change the profile- consult the consent of a given patient
|