THIS SPACE IS UNDER CONSTRUCTION

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Used documentation

Cookbook/ materialsVersionLocation
eHealthConsent WS Cookbook1.9

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

KMEHR-https://www.ehealth.fgov.be/standards/kmehr/en
Jira ticket MHEH-12-

MHEH-12 - Getting issue details... STATUS

Jira ticket MHEH-13-


MHEH-13 - Getting issue details... STATUS
Jira ticket MHEH-18- MHEH-18 - Getting issue details... STATUS


Jira ticket MHEH-20-

MHEH-20 - Getting issue details... STATUS

Jira ticket MHEH-26-

MHEH-26 - Getting issue details... STATUS

Jira ticket MHEH-31-

MHEH-31 - Getting issue details... STATUS

Jira ticket MHEH-32-
MHEH-32 - Getting issue details... STATUS

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:

  • Health Care (HC) parties: a physician, a pharmacy (it is noteworthy that there is no difference between pharmacy and a pharmacist), Hospital, Dentist, Nurse, Midwife, Health Insurance Organization (HIO), Authorized organization in behalf of a HIO, Group of nurses
  • Citizen: a patient, a parent of a patient, a mandatary  

The Consent services provides four methods:

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

Priority

1 (High)

Must have: The system must implement this goal/ assumption to be accepted.

Pre-Conditions

  • The user is logged in
    • 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

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






  • No labels