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

A consent may have two types. Indeed, it is called prospective when it is valuable for data posterior to the signing date (i.e. the date that should be taken into account is the ‘medical date’ of the transaction). It is referred to as retrospective in the opposite case. This does not mean that all documents with a medical date anterior to the signing date of the consent will automatically be made available

The Consent service provides four methods (it is noteworthy that in this use case only the GetPatientConsent method is used):

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

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