Used documentation
Cookbook/ materials | Version | Location |
---|---|---|
eHealthConsent WS Cookbook | 1.9 | |
KMEHR | - | https://www.ehealth.fgov.be/standards/kmehr/en |
Jira ticket MHEH-12 | - | MHEH-12 - Getting issue details... STATUS |
Jira ticket MHEH-13 | - | |
Jira ticket MHEH-18 | - |
MHEH-18
-
Getting issue details...
STATUS
|
Jira ticket MHEH-20 | - | MHEH-20 - Getting issue details... STATUS |
Jira ticket MHEH-26 | - | MHEH-26 - Getting issue details... STATUS |
Jira ticket MHEH-31 | - | MHEH-31 - Getting issue details... STATUS |
Jira ticket MHEH-32 | - |
MHEH-32
-
Getting issue details...
STATUS
|
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
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 an active consent of a patient | ||
Actors |
| ||
Short Description | In order to consult the consent of a patient, | ||
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | ||
Pre-Conditions |
| ||
Post-Conditions | |||
Steps (basic flow) | 0 | ||
1 | |||
2 | |||
3 | |||
4 | |||
5 | |||
6 | |||
7 | |||
8 | |||
9 | |||
10 | |||
11 | |||
Exceptions (exception flows) |
| ||
Frequency |
|
Alternative flow 1
Flow | Specification | ||
---|---|---|---|
Use case ID | ATH-UC-12-AF-01 | ||
Use case name | Consult an inactive consent of a patient | ||
Actors |
| ||
Short Description | In order to consult the consent of a patient, | ||
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | ||
Pre-Conditions |
| ||
Post-Conditions | |||
Steps (basic flow) | 0 | ||
1 | |||
2 | |||
3 | |||
4 | |||
5 | |||
6 | |||
7 | |||
8 | |||
9 | |||
10 | |||
11 | |||
Exceptions (exception flows) |
| ||
Frequency |
|
Alternative flow 2
Flow | Specification | ||
---|---|---|---|
Use case ID | ATH-UC-12-AF-02 | ||
Use case name | Unsuccessful completion | ||
Actors |
| ||
Short Description | In order to consult the consent of a patient, | ||
Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | ||
Pre-Conditions |
| ||
Post-Conditions | |||
Steps (basic flow) | 0 | ||
1 | |||
2 | |||
3 | |||
4 | |||
5 | |||
6 | |||
7 | |||
8 | |||
9 | |||
10 | |||
11 | |||
Exceptions (exception flows) |
| ||
Frequency |
|