THIS SPACE IS UNDER CONSTRUCTION

Used documentation

Cookbook/ materialsVersionLocation
Therapeutic Exclusion Cookbook1.2

https://www.ehealth.fgov.be/ehealthplatform/fr/data/file/view/ddac01f047142783690a4e7fa39019bfd0615e81?name=Therapeutic%20Exclusion%20WS%20-%20Cookbook%201.2%20dd%2025102018.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

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:

  • Citizen: a patient, a parent of a patient, a mandatary  

In order, to manage the Therapeutic Exclusions, it exists the following three methods (it is noteworthy that in this use case only the GetTherapeuticExlusion method is used):

  • The "PutTherapeuticExlusion" method allows an end-user to declare a therapeutic exclusion.
  • The "RevokeTherapeuticExlusion" method enables an end-user to revoke an active therapeutic exclusion.
  • The "GetTherapeuticExclusion" method allows an end-user to consult the active therapeutic exclusions.

Basic flow

FlowSpecification








Use case ID

ATH-UC-15-BF

Use case name

Consult the therapeutic exclusions of a patient

Actors

  • Citizen (i.e. a patient, a parent of a patient, a mandatary)

Short Description

In order to consult the therapeutic exclusions of a patient using the SOA-based version, it is important to use the Token exchange service in order to convert a JWT token into a SAML one (and vice versa). 

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)
  • Information about the therapeutic exclusion: 
    • The identification the concerned patient
    • Optionally, the first and last name of the patient
    • Optionally, the identification of the excluded HCP
      • if HCP is a professional: NISS*, NIHII (11 digits), category of the HCP*, the first and last name of the HCP
      • if HCP is an organization: NIHII* (8 digits), category of the HCP*, the name of the HCP.

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 list of the therapeutic exclusions (if there is no therapeutic exclusion, an empty list is returned)
    • if there is no specified HCP in the input: the list of all the therapeutic exclusions
    • if a HCP is specified in the input: the list of the therapeutic exclusion(s) corresponding to the given HC

Steps (basic flow)

1

The client sends a GetTherapeutic-Exclusion request 

2The IAM connect sends the request to the Therapeutic Exclusion WS

3

The Therapeutic exclusion WS finds information about the therapeutic exclusion(s) of a patient 

4The Therapeutic  link WS sends a response to the IAM  

5

The IAM connect receives the response and sends it to the client

6The client receives information about the therapeutic exclusion(s) of the patient

Exceptions (exception flows)



  • Every time the end-user wants to consult the therapeutic exclusions of a given patient
  • No labels

1 Comment

  1. Unknown User (fabian.steels@cetic.be)

    I think that normally this use case doesn't have to be used because it’s based on a SOAP technology.


    cf Architecture: Mock App

THIS SPACE IS UNDER CONSTRUCTION