Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Used documentation

Cookbook/ materialsVersionLocation
eHealthConsent WS Cookbook1.9

https://www.ehealth.fgov.be/ehealthplatform/file/view/7cd655bc5f9ec7be387cfbc2d8710b5d?filename=cookbook_ehealthconsent_web_service.pdf

Identity & Authorization Management (I.AM) Token eXchange Technical specifications1.0https://www.ehealth.fgov.be/ehealthplatform/nl/data/file/view/83dd54fee269ec086696b0290d242907c6e9f994?name=IAM%20Connect%20Token%20eXchange%20-%20Tech%20Specs%20v1%20-%2004072018.pdf
KMEHR-https://www.ehealth.fgov.be/standards/kmehr/en
Jira ticket MHEH-12-

Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-12

Jira ticket MHEH-13-


Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-13
Jira ticket MHEH-18-
Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-18


Jira ticket MHEH-20-

Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-20

Jira ticket MHEH-26-

Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-26

Jira ticket MHEH-31-

Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-31

Jira ticket MHEH-32-
Jira
serverimec Validation Lab
serverIdac11aa92-3976-3161-9ddb-5020cc76f1c7
keyMHEH-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 consent can be managed by different types of end-users:

...

  • 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

FlowSpecification









Use case ID

ATH-UC-12-BF

Use case name

Consult an active consent of a patient

Actors

  • Citizen

  • HC party

Short Description

In order to consult 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 message 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)
  • SSIN of the concerned patient 
  • Type of the consent (optional)

Post-Conditions

  • 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)

1

The user tries to consult the consent and the client sends a getPatientConsent request to the IAM connect

2The IAM connect routes the request to the WS consent

3

The WS consent finds information about the consent of a patient 

4The WS consent sends a 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

6The client receives information about the consent 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.

Frequency

  • Every time the user wants to consult the consent of a given patient



Alternative flow 1

FlowSpecification


Use case ID

ATH-UC-12-AF-01

Use case name

Consult an inactive consent of a patient

Actors

  • Citizen

  • HC party

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

  • The user is logged in

Post-Conditions


Steps (basic flow)

0



1

2



3

4



5

6



7



8

9

10

11

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 consult the consent of a given patient


Alternative flow 2

FlowSpecification


Use case ID

ATH-UC-12-AF-02

Use case name

Unsuccessful completion

Actors

  • Citizen

  • HC party

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

  • The user is logged in

Post-Conditions


Steps (basic flow)

0



1

2



3

4



5

6



7



8

9

10

11

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 consult the consent of a given patient

Exception flow 1