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 21 Next »

Table of contents

Used documentation


General information

End-to-End Encryption for known recipients

The message to send to the WS may be encrypted.
To encrypt the message, you should retrieve the public key of all recipients plus yours from the eHealth Token Key (ETK) depot.
Then, you should encrypt the message using the obtained public keys via the eHealth platform Crypto Libraries.

Encrypted message convention

If an encrypted message is to be sent, ALL “Encryptable” fields MUST contain (all) encrypted content.
In other words, first encrypt the content of each of those fields separately and set IsEncrypted to True.
If IsEncrypted is set to True, and non-encrypted content is being transported, unexpected errors can occur.
Conversely, if IsEncrypted is set to False, and encrypted content is being transported, unexpected errors can also occur.
You cannot choose to encrypt some “Encryptable” fields solely.

Out-of-Office

This system enables the sender to know whether one of the recipients is absent and send his message to a
substitute or substitutes, so the sender’s message can be treated. For example, physicians on holiday may want
to ensure continuity of healthcare services for their patients. To do this, they can automatically transfer their
messages to another colleague responsible during their holidays thanks to the “Out-of-Office” system. If a
recipient is absent, a special SendMessageResponse with the substitutes is returned.

When sending a message, the system checks if some of the recipients of the message have an active OoO. If so,
a specific OoO Business error is returned (in SendMessageResponse). This response contains the period during
which the original recipient is absent, the substitutes of the recipient (if specified) and their qualities.

It is possible that the person absent did not introduce a replacement. In this case, the same OoO Business error
will be returned but without a substitute.

SendMessageRequest must then be called again and substitutes should be added next to the original
recipient. OoOProcessed under DestinationContext is set to true for the original recipient. For this recipient,
there will be no more OoO verification during the second request. If the message is to be sent encrypted, the
message must be encrypted again for the added substitute(s).

If the substitute himself is absent, a new OoO Business error will be returned, and so on.

The OoO activates automatically when the time is reached.

OoO system is inactive for a mass mailing: no notification will be sent.

Basic flow

x


  • No labels