Table of contents

Used documentation

General information

SendMesssage

The request that must be sent in order to publish the eHealthBox content for one or more recipients will be
discussed here. You can send a message of the type “Document” or “News item”. A document contains a
PublicationId that you define and that cannot be used twice. A News item, on the other hand, can be updated
and this is done by sending a new news item with the same PublicationId. You cannot update a “Document”
type.

Request

• Example request
• UML request

Response

The response contains a success status code if no major error could be found in the request. 
Still, remember that the system is asynchronous: a successful response does not guarantee that the message 
will be correctly published at the end of the process. In chapter 8, you will find the possible business errors returned by the method.

• Example response
• UML response
• Status codes

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.

Lifetime of a message

• When the expiration date of a message is reached, it has been read, AND it has already been placed in
  the recycle bin, the message is definitely removed from the application.

• When a message is older than 1 year (counted from publication date), it is definitely removed from the
  application, even if it has not been read.

Treatment of NIHII-11 numbers

When sending a message via the Publication WS, the identification of the sender is by default, retrieved from
the STS Token. The recipient will see the identifier of the sender when retrieving the message via the
Consultation WS. If the sender is a healthcare professional, his SSIN can be retrieved from the STS token and
used as identifier for the sender. If the sender is a hospital or some other healthcare organization, the identifier
in the STS token will be of the type NIHII. Finally, if the sender is an organization, the identifier type will be a
CBE. Exception is made if BoxId (optional element) is filled out. In that case, the person connected to the WS is
sending the message “in name of the person or organization” specified in the element BoxId. Thus, if a
healthcare professional (a person) wants to send a message using his NIHII (INAMI) number instead of his SSIN
number, he has to submit the request and fill out his NIHII number in the BoxId.

For example, the sender is connected as a doctor with an STS token containing his INSS number as attribute:

Id = 12345678910
Type = INSS
Quality = DOCTOR

But he does not want to display his SSIN number to the recipient, since he prefers to display his NIHII number;
he then uses the BoxId element in the request, and fills it out as follows:

 <BoxId>
 <Id>104025888</Id>
 <Type>NIHII</Type>
 <Quality>DOCTOR</Quality>
</BoxId>

The sender will then be stored in the application with the data found in BoxId (after access validation).
Note: a NIHII number consists out of 11 numbers (with the 3 qualification numbers) or 8 numbers (without the
3 qualification numbers).
When authenticated as an organization, it is not possible to use the BoxId.

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.

Mass mailings

You can send a message to a specific person or to multiple persons by specifying one DestinationContext per
person. You can also send a message to a list of persons sharing the same “Quality”. Please refer to Annex 1 –
Publish a message to a list of professionals. In order to be able to send a message to all persons sharing the same
quality (all nurses, or all doctors), prior authorization from the eHealth platform (info@ehealth.fgov.be) is
required. The eHealth platform will investigate your request, and then allow you to publish this type of message.

Send Message Method

You can send a message of the type “Document” or “News item”. A document contains a
PublicationId that you define and that cannot be used twice. A News item, on the other hand, can be updated
and this is done by sending a new news item with the same PublicationId. You cannot update a “Document” type.

Possible file types for attachments

MHEH-5 - Getting issue details... STATUS

All file types are possible. There are no limitations from the eHealthBox.

Content type

Content type NEWS isn't being used and will be removed in v4 of the eHealthBox.
Therefore it doesn't need to be tested.

Source: Wolf Wauters, eHealth (23/04/2019).

Basic flow

Alternative flow 1

Alternative flow 2

Alternative flow 3

Alternative flow 4

Alternative flow 5

NOTE: All different combinations for the SendMessageRequest.