| Table of Contents |
|---|
Used documentation
| Cookbook/ materials | Version | Location |
|---|---|---|
| eHealthConsent WS Cookbook | 1.9 | |
| API eHealth Consent | 2.0 | http://jira.ivlab.ilabt.imec.be/secure/attachment/17424/swagger_consent_2-0-2.json |
| KMEHR | - | https://www.ehealth.fgov.be/standards/kmehr/en |
| Jira | ||||||
|---|---|---|---|---|---|---|
|
| Jira | ||||||
|---|---|---|---|---|---|---|
|
| Jira | ||||||
|---|---|---|---|---|---|---|
|
| Jira | ||||||
|---|---|---|---|---|---|---|
|
| Jira | ||||||
|---|---|---|---|---|---|---|
|
| Jira | ||||||
|---|---|---|---|---|---|---|
|
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:
...
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. This does not mean that all documents with a medical date anterior to the signing date of the consent will automatically be made available
The The API eHealth Consent service provides four five methods (it . It is noteworthy that in this use case only the GetPatientConsent Ge tPatient Consent method is used):
...
.
...
Basic flow
| Flow | Specification | ||
|---|---|---|---|
| Use case ID | ATH-UC- | |
16-BF | ||
Use case name | Consult the consent of a patient using the | |
GET /consents/{patientSsin} operation | ||
Actors |
| |
Short Description | ||
This use case enables to consult the consent status of a given patient using the |
REST version of the WS Consent. | ||
| Priority | 1 (High) Must have: The system must implement this goal/ assumption to be accepted. | |
Pre-Conditions |
| |
|
Post-Conditions |
Information about the response (response identifier, end-user identifier, data and time of the response, initial request)
|
| ||
Steps (basic flow) | 1 | The |
| client sends a GET /consents/ {patientSsin} request | ||
| 2 | The IAM connect |
| sends the request to the 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 | |
Exceptions (exception flows) |
Frequency |
| |