-
Created by Unknown User (gaelle.laurent.ext@imec.be), last modified on Mar 27, 2019
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 17
Next »
Basic Flow
Flow | Specifications |
---|
| ID | AR-UC06-BF | Name | Put Patient Consent - Patient | Description | A patient declares his own "Informed Patient Consent" by using the WS Consent. The Certificate from the eID of the patient is used to access to the WS Consent. | Actor(s) | | Requirements | - End-user is a patient
- End-user acts as author of the request through his software and manages himself throughout his usual software
- Valid eID
- Consent WS is integrated in the software of the end-user
| Trigger | The user wants to declare his Patient Consent | Precondition | - The user has an account for the application
- The user is logged out
| FLow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using his eID
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Put Patient Consent
- The Put Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Put Patient Consent Response
° The request is logged ° The Informed Patient Consent is stored in eHealth Database | Post Condition(s) | - Request is logged
- The informed patient consent is stored in the eHealth Database
| Test Data |
| End point(s) | - WS Consent
- eHealth Database
| Remarks | If support card number is provided then it must be compliant e.g. correct format, check-digit and combination | Additional Information | Additional information about patient e.g. first name and family name may be added for the audit purpose |
|
Alternative Flow NAKIJKEN CHECK PARENT LINK
Flow | Specifications |
---|
| ID | AR-UC06-AF01 | Name | Put Patient Consent - Parent of Patient | Description | Parent of the patient declares an "Informed Patient Consent" in behalf of the patient by using the WS Consent. The Certificate from the eID of the parent is used to access to the WS Consent. | Actor(s) | Parent of the concerned patient | Requirements | - End-user is a parent of the concerned patient
- End-user acts as author of the request through his software and manages himself throughout his usual software
- Valid eID of the parent
- Consent WS is integrated in the software of the end-user
| Trigger | The user wants to declare his Patient Consent | Precondition(s) | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using his eID
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Put Patient Consent
- The Put Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Put Patient Consent Response
° The request is logged ° The Informed Patient Consent is stored in eHealth Database | Difference in flow | Identification of the parent | Post Conditions | - Request is logged
- The informed patient consent is stored in the eHealth Database
| Test Data |
| End point(s) | - WS Consent
- eHealth Database
| Remarks | If support card number is provided then it must be compliant e.g. correct format, check-digit and combination | Additional Information | Additional information about parent e.g. first name and family name may be added for the audit purpose |
|
Alternative Flow NAKIJKEN CHECK MANDATARY!
Flow | Specifications |
---|
| ID | AR-UC06-AF02 | Name | Put Patient Consent - Mandatary of Patient | Description | Mandatary of the patient declares an "Informed Patient Consent" in behalf of the patient by using the WS Consent. The Certificate from the eID of the mandatary is used to access to the WS Consent | Actor(s) | Mandatary of the concerned patient | Requirements | - End-user is a mandatary of the concerned patient
- End-user acts as author of the request through his software and manages himself throughout his usual software
- Valid eID of the mandatary
- Consent WS is integrated in the software of the end-user
| Trigger | The user wants to declare his Patient Consent | Preconditions | - The user has an account for the application
- The user is logged out
| Flow | - The user attempts to access the eHealth Consent WS
- The user needs to request a SAML Token by using his eID
- A request for a SAML Token is sent to the Secure Token Service (STS)
- The STS responds with a SAML Token
- The user has access to the eHealth WS Consent
- The user does a request for Put Patient Consent
- The Put Patient Consent Request is sent to the WS Consent
- ° The WS Consent responds with a Put Patient Consent Response
° The request is logged ° The Informed Patient Consent is stored in eHealth Database | Difference in flow | Identification of the Mandatary | Post Conditions | - Request is logged
- The informed patient consent is stored in the eHealth Database
| Test Data |
| End point(s) | - WS Consent
- eHealth Database
| Remarks | If support card number is provided then it must be compliant e.g. correct format, check-digit and combination | Additional Information | Additional information about mandatary e.g. first name and family name may be added for the audit purpose |
|