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
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 Therapeutic link can be managed by the following end-users:
- Health Care Parties (HCHCP) parties: a physician, nurse, dentist, midwife, a pharmacy (it is noteworthy that there is no difference between pharmacy and a pharmacist), authorized organization.
- Citizen: a patient, a parent of a patient, a mandatary
...
- The "PutTherapeuticLink" method allows an end-user to declare a therapeutic link.
- The "RevokeTherapeuticLink" method enables an end-user to revoke a therapeutic link.
- The "GetTherapeuticLink" method allows an end-user to consult the therapeutic links list of a given patient. Indeed, it enables to check the existence of a given therapeutic link between a patient and a HCP.
The "GetTherapeuticLink" method allows users to check the existence of therapeutic links between a HC party and a patient. Depending on the input parameters the service can support the following functionalities:
- check the existence of a specific link between a patient and a HC party;
- consult the list of therapeutic links related to a patient;
- consult the list of therapeutic links between given HC party and given patient over a certain time period.
Basic flow
Flow | Specification |
---|
Image Added
| | ATH-UC- |
1214-BF |
Use case name | Consult |
an active consent the therapeutic links of a patient |
Actors | |
Short Description | In order to consult the |
consent therapeutic links of a patient using the SOA-based version, it is important to use the Token exchange service in order to convert a JWT |
message into 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 | - The user is already logged in via the Token exchange service
- Information about the request (request identifier, end-user identifier, date and time of the request, the number of the therapeutic links to consult (=<1000))
- A set of criteria relative to the therapeutic links
- SSIN of the concerned patient
- Optionally, identification of the concerned HCP
- if the HCP is a professional: SSIN, NIHII number (11 digits), the HCP category, the first and last name
- if the HCP is an organization: NIHII number (8 digits), the HCP category, the name of the organization
- Optionally, the list of therapeutic link type
- Optionally, the time period [begin date - end date]
- Optionally, the status of the consulted therapeutic link: active, inactive, all
- Information about the evidence (Mandatory if the consultation is referral or historic)
- Type of the proof
- only if the type of proof is the reading of
|
the consent (optional)- the eID card with PIN code entering, the binary proof including the encryption method (mandatory) and the binary value (mandatory).
|
Post-Conditions | Information about the response (response identifier, end-user identifier, data and time of the response, initial request) - An acknowledgement about the request completion (status of the completion, errors if exist)
|
Information about the consent (SSIN of the patient, consent type, data of declaration, author of the declaration)- A list of the therapeutic links fulfilling the criteria:
- if the HCP is provided in the request
- if the HCP is a professional identified by his/her SSIN and his/her category: all the therapeutic links containing the given SSIN - category are returned;
- if the HCP is a professional identified by his/her NIHII and his/her category: all the therapeutic links containing the given NIHII - category are returned;
- if the HCP is a professional identified by his/her SSIN, his/her NIHII and his/her category: all therapeutic links containing the given SSIN - NIHII - category category are returned;
- if the HCP is an organization identified by its NIHII and its category: all the therapeutic links containing the given NIHII - category are returned.
- if the HCP is not provided in the request
- if the proof is not given
- if the end-user of the request acts as a HC professional: the therapeutic links of the concerned patient and the concerned author are returned;
- if the end-user of the request acts for an organization: the therapeutic links of the concerned patient and the concerned HC organization of the end-user are returned.
- if the proof is given
- if the end-user of the request acts as a HC professional: the therapeutic links of the concerned patient and the concerned end-user, the therapeutic links of the concerned patient and other concerned HCP are returned;
- if the end-user of the request acts for a HC organization: the therapeutic links of the concerned patient and the concerned organization, the therapeutic links of the concerned patient and other concerned HC parties are returned.
- If a (list of) therapeutic link type is provided: the therapeutic link(s) matching this (these) type(s) are returned
- If a time period is provided: the list of therapeutic links found over this given time period
- If a status (i.e. ‘active’, ‘inactive’, ‘all’) is provided: the therapeutic link matching the provided status are returned.
|
Steps (basic flow) | 1 | The |
user tries to consult the consent and the getPatientConsent request to the IAM connectGetTherapeuticLink request |
| 2 | The IAM connect |
routes sends the request to the Therapeutic link WS |
consent WS consent finds Therapeutic link WS finds information about the |
consent therapeutic link(s) of a patient |
| 4 | The Therapeutic link WS |
consent SAML-based response to the IAM |
| 5 | The IAM connect receives the response and sends it to the client |
using a JWT format by interacting with the token exchange service |
| 6 | The client receives information about the |
consent Frequency | therapeutic link(s) of the patient |
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.
| - Every time the end-user wants to consult the
|
consent - therapeutic link(s) of a given patient
|