THIS SPACE IS UNDER CONSTRUCTION

Used documentation

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:

  • Health Care Parties (HCP): a physician, nurse, dentist, midwife, a pharmacy (it is noteworthy that there is no difference between pharmacy and a pharmacist), authorized organization.
  • Citizen: a patient, a parent of a patient, a mandatary  

The Therapeutic Link Web service provides three methods (it is noteworthy that in this use case only the GetTherapeuticLink method is used):

  • The "PutTherapeuticLink" method allows an end-user to declare a therapeutic link.
  • The "RevokeTherapeuticLink" method enables an end-user to revoke a therapeutic link.
  • The "GetTherapeuticLink" method allows an end-user to consult the therapeutic links list of a given patient. Indeed, it enables to check the existence of a given therapeutic link between a patient and a HCP.


The "GetTherapeuticLink" method allows users to check the existence of therapeutic links between a HC party and a patient. Depending on the input parameters the service can support the following functionalities:

  • check the existence of a specific link between a patient and a HC party;
  • consult the list of therapeutic links related to a patient;
  • consult the list of therapeutic links between given HC party and given patient over a certain time period.

Basic flow

FlowSpecification














Use case ID

ATH-UC-14-BF

Use case name

Consult the therapeutic links of a patient

Actors

  • Citizen

  • HC party

Short Description

In order to consult the therapeutic links 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, the number of the therapeutic links to consult (=<1000))
  • A set of criteria relative to the therapeutic links 
    • SSIN of the concerned patient 
    • Optionally, identification of the concerned HCP
      • if the HCP is a professional: SSIN,  NIHII number (11 digits), the HCP category, the first and last name
      • if the HCP is an organization: NIHII number (8 digits), the HCP category, the name of the organization
    • Optionally, the list of therapeutic link type
    • Optionally, the time period  [begin date - end date]
    • Optionally, the status of the consulted therapeutic link: active, inactive, all
  • Information about the evidence (Mandatory if the consultation is referral or historic)
    • Type of the proof
    • only if the type of proof is the reading of the eID card with PIN code entering, the binary proof including the encryption method (mandatory) and the binary value (mandatory).

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)
  • A list of the therapeutic links fulfilling the criteria:
    • if the HCP is provided in the request
      • if the HCP is a professional identified by his/her SSIN and his/her category: all the therapeutic links containing the given SSIN - category are returned;
      • if the HCP is a professional identified by his/her NIHII and his/her category: all the therapeutic links containing the given NIHII - category are returned;
      • if the HCP is a professional identified by his/her SSIN, his/her NIHII and his/her category: all therapeutic links containing the given SSIN - NIHII - category category are returned;
      • if the HCP is an organization identified by its NIHII and its category:  all the therapeutic links containing the given NIHII - category are returned.
    • if the HCP is not provided in the request
      • if the proof is not given
        • if the end-user of the request acts as a HC professional: the therapeutic links of the concerned patient and the concerned author are returned;
        • if the end-user of the request acts for an organization: the therapeutic links of the concerned patient and the concerned HC organization of the end-user are returned.
      • if the proof is given
        • if the end-user of the request acts as a HC professional: the therapeutic links of the concerned patient and the concerned end-user, the therapeutic links of the concerned patient and other concerned HCP are returned;
        • if the end-user of the request acts for a HC organization: the therapeutic links of the concerned patient and the concerned organization, the therapeutic links of the concerned patient and other concerned HC parties are returned.
  • If a (list of) therapeutic link type is provided: the therapeutic link(s) matching this (these) type(s) are returned 
  • If a time period is provided: the list of therapeutic links found over this given time period
  • If a status (i.e. ‘active’, ‘inactive’, ‘all’) is provided: the therapeutic link matching the provided status are returned.

Steps (basic flow)

1

The client sends a GetTherapeuticLink request 

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

3

The Therapeutic  link WS finds information about the therapeutic link(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 link(s) of the patient

Exceptions (exception flows)



  • Every time the end-user wants to consult the therapeutic link(s) 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