Transaction: Incapacity notification 2.0




eHealth Platform








Due to different interpretations of this document by different stakeholders in the course of the development, some clarifications are added to this document. These changes in wording are in no way modifications to the original business rules that have been agreed upon by the different stakeholders, but only  clarifications that assist in the development of the software.

This transaction notifies of an incapacity of the patient. It is a specialization of the notification transaction.

This version 2.0 is the evolution of the incapacity notification requested and made possible by the Mult-eMediAtt project. This project was one of the initiatives under the umbrella of the action point 15 ‘Administrative simplification’ of the roadmap ‘e-health plan’ The Mult-eMediAtt project created a forum to bring together different organizations to define a basic set to use for the signaling of an incapacity.

The transaction described here was the output of this project: a new version of the incapacity notification definition as an evolution of the version used by Medex. 

This new version now serves in function of an agreed schedule as a template for a multitude of organizations, both governmental and private. Every organization can choose to use this definition in a more strict way; they must adhere however, to the minimum specification as described on this page. As such, please refer to their respective websites for more strict rules on how to use this message definition. 


Note that often in the specifications it is written something is only allowed ‘when a message is sent with a diagnosis.’ This is an important criterion. 

Other important criteria are whether the message concerns a student or pupil (i.e. the message concerns an attestation for a school in the context of absence during lectures,sport,..) and whether the person is working professionally for an education organization. These rules are explicitly mentioned below.

The wording of these criteria are causing a lot of confusion during the development process. Therefore, we will reformulate the same businessrules using the dataset types that can be obtained from the DAAS call.

In the Mult-eMediAtt context, the dataset that will be used will be decided by the response of the DAAS or by initiative of the healthcare party. 4 different datasets can thus be identified within that context: a message with obligatory diagnosis (this will be referred to as dataset A), a message with optional diagnosis (this includes also a small dataset specifically for a patient that is working professionally for an education organization) (this will be referred to as dataset B), a message without diagnosis (this will be referred to as dataset C), a message without diagnosis concerning a student/pupil (these datasets are yet to be defined, and have no id at this moment).

In practice this means in the context of a Mult-eMediAtt message the allowed dataset depends on the recipient of the message:

A work incapacity message with mandatory diagnosis (Dataset A)

Iteration 1: 
- Medex,
- HR RAIL (for statutaires),
- the mutualities (only incapacity > 14 days +  incapacity extension),

Planning to be definied: the medical department of Fedpol,..

A work incapacity message with optional diagnosis  (this may include also the data for a patient working for education when applicable) (Dataset B) Iteration 1 : 
- the medical department of HR Rail for contractual
Planning to be definied: Certimed, Securex, Medconsult
A work incapacity message without diagnosis (Dataset C) Planning to be definied: Employers
Note: this rule is not validated by Schematron in Iteration 1
A school incapacity message without diagnosis concerning a student/pupil (to be defined) Planning to be defined for the implementation for pupils and students. 
In the meantime, the provided schematron makes already some controls.



This transaction requires a level 3-4 of KMEHR normalization: contents are preferably coded however some textual contents are still allowed.

Note to software developers: a schematron file is provided to help creating correct messages. This can be used via the eHealth Platform connector (fr/nl) or via your own custom implementation. When the message contains a retraction of an incapacity (cfr. infra), the schematron file should not be used.

If the data has been entered by the physician/general practitioner, AND the data are allowed by the business rules linked to the dataset information by the DAAS, they SHALL be processed and displayed by both the sending and receiving parties. 

Diagnosis description main principles

The following principles MUST be followed:

For certificates with mandatory diagnosis (Dataset A): 

- Minimum 1 diagnosis item and Maximum 3 diagnosis items per certificate

- If certificate with more than 1 diagnosis item: indication of the main diagnosis item is mandatory

- Each diagnosis item can be displayed in the following ways:

  • Only a SNOMED code and text with the description of the code, code and description are mandatory

    The description of the code can be found in the Belgian extension of the SNOMED codes and the “preferred” term must be used. Preferred term is also called “Preferred Synonym” in a specific language

    When the Belgian extension of the SNOMED codes is not implemented yet, the SNOMED code can be found in the mapping table (3BT/IBUI -> SNOMED), and the description the doctor selected from the 3BT must be given

  • Only an ICD10 and an ICPC2 code and text with the description of the code, code and description are mandatory

    The description the doctor selected from the 3BT must be given

  • Free text only. This is a separate diagnose item

- The versions of a diagnosis described by a code must be : 

  • For ICD: version = 10 
  • For ICPC: version = 2 
  • For SNOMED:

    • version = the date of release of the mapping table (Format = YYYYMMDD) if only the 3BT thesaurus and mapping table are used

    • version = the date of release of the Belgian SNOMED CT extension (Format = YYYYMMDD) if the GP refset is already used

- The description of the diagnosis described by a code must be in the language of the patient. For German and English the French description may be used.

Note about ICD10 coding system: 

When an ICD10 code is provided, it must follow one of the rules here below:

- Case 1 

  • At least 4 positions: 
    • 1 letter uppercase (A-Y)
    • 2 digits (0-9)
    • 1 point (.)
  • Optionally more alphanumeric positions
  • Example:  “A99.”, “T33.512A”,” S12.14XA”

- Case 2

  • At least 5 positions: 
    • 1 letter uppercase (Z)
    • 2 digits (0-9)
    • 1 point (.)
    • 1 digit (0-9) 
  • Optionally more alphanumeric positions
  • Example:  “Z73.0”,” Z72.820”


The header of the message follows the general KMEHR guidelines. The table below gives some extra contextual information.

sender Besides a <hcparty> element identifying the medical party, a <hcparty> 'application' should be added to the sender element that identifies the sending software application, both in name as in version. Refer to the examples for the structure.
recipient e.g. in case of a Medex message: the recipient will be the application ‘medex’. Note in the context of a Mult-eMediAtt message, for the same patient potentially multiple messages will be send to multiple recipients containing different datasets.

When possible, for a message in the context of Mult-eMediAtt, please also add an <id> element in the recipient referring to the ID-CBE or the ID-EHP. (Cfr. examples) 
date date of the creation of the technical message (no functional value concerning the incapacity attestation)
time time of the creation of the technical message (no functional value concerning the incapacity attestation)
The patient is, as usual, represented by the patient element of the folder. 
The considered dataset for this transaction is:
  A B C TBD  
id 1 1 1 1 id of the transaction according to the ID-PATIENT conventions. A INSS number must be provided as identification.
firstname 1 1 1 1 The element must be present but is allowed to have no value. If the firstname is known by the sending party it must be given.
familyname 1 1 1 1 Familyname of patient.
birthdate 0..1 0..1



Birthdate of patient

sex 1 1



Sex of the patient, using a value from CD-SEX

address 0..1 0..1




This is the care address where the patient is recovering. Always accompany this with the value ‘careaddress’ from CD-ADDRESS

Use the elements cd (CD-ADDRESS), zip, city, street, housenumber and postboxnumber (if needed)

telecom 0..* 0..*



Using the correct values of CD-TELECOM, a fixed and/or mobile phone of the patient.

usuallanguage 1 1 1 1 The preferred language of the patient. Please take extra note this is obligatory, even though in the paper version of the incapacity notification it is considered optional.
profession 0..1 0..1





To define whether the patient is self employed or not: this is done by using <cd> and the value 'selfemployed' from CD-EMPLOYMENTSITUATION.

And/or the profession itself may be given using free text using the <text> element.

Transaction elements
id id of the transaction according to the ID-KMEHR conventions

Must use the value ‘notification’ from CD-TRANSACTION.

This must be combined with an appropriate value from CD-TRANSACTION-TYPE: either ‘incapacity’, ‘incapacityextension’ or ‘incapacityrelapse’.

Please note when the attestation concerns a hospitalization, also minimally include an 'encountertype' item element with a content and cd element with the value 'hospital' from CD-ENCOUNTER (as described infra.)  

When the patient is a student/pupil, the value ‘incapacityrelapse’ is NOT ALLOWED


This is the certificate date, the date on which the medical practioner writes the attestation, that is the actual date on which the incapacity is determined. 

There can be a difference with the begin date of the incapacity.

time This is the time at which the incapacity is determined

This is the person assuming the responsibility of the medical content of the record. It can be specified by a combination of the the elements available in hcparty. There must be at least one hcparty identifying a person. 

It must contain the ID-HCPARTY of this healthcare professional and it must contain its INSS number and its NIHII number.

As always, when defining a healthcare party that is a person in KMEHR, a firstname and familyname must be given.

A fixed and/or mobile phone number (using the correct value of the table CD-TELECOM) is recommended to include but not obligatory.

iscomplete Expresses if the incapacity notification is completed.
isvalidated Expresses if the incapacity notification is validated.
Structure overview
An Incapacity Notification transaction is composed of multiple items (from CD-ITEM
In the context of a Mult-eMediAtt message, a few items defined according to a LOCAL table are also optionally used. For the convenience of implementors, these and some other general guidelines in the context of Mult-eMediatt messages are also mentioned on this page. 
The following items from CD-ITEM must be used to compose an incapacity notification transaction, according to the proposed cardinalities. Optional elements in item structure are set within squared braces.

Please note: for a retraction of a previously send incapacity, only 1 KMEHR element shall be sent. (Cfr. infra)

  A B C TBD    
Item type (cd)         Item purpose Item structure
incapacity 1 1 1 1 Specifies an incapacity of the patient

content (incapacity(cd))

identifies the type of incapacity, with values from CD-INCAPACITY.

In the context of a Mult-eMediAtt message, this should normally be the value ‘work.’

When this message is used in the context of an incapacity of a student or pupil, the value should be ‘school’, ‘swim’, ‘schoolsports’ or ‘heavyphysicalactivity’

content (incapacity(incapacityreason(cd)))
This is within the same content(incapacity) as the above.
identifies the reason of incapacity, with a value from CD-INCAPACITYREASON.
Note in the context of a Mult-eMediAtt message, the values to consider are: ‘illness’, ‘pregnancy’, ‘occupationaldisease’, ‘accident’, ‘workaccident’ and ‘traveltofromworkaccident’.
Please note when the value of ‘pregnancy’ is chosen: this is by itself not the reason of the incapacity; it will be accompanied by a value specifying the illness if the diagnosis is mandatory. 
In case of dataset B, the value 'pregnancy' can still be used without making the diagnosis mandatory.
In case of dataset C, the value 'pregnancy' is forbidden.
Future datasets may restrict the number of values that can be used in this field.
content (incapacity(outofhomeallowed))
This is within the same content(incapacity) as the above.
Indicates if the patient is allowed to leave his home during the incapacity.
Possible values : true/false

[content (date)]

In case of accident (incapacityreason = ‘accident’, ‘workaccident’ or ‘traveltofromworkaccident’ ) this is obligatory and = the date of the accident.

In the case of an Occupational disease (incapacityreason = ‘occupationaldisease’) this is obligatory and = the request date for a dossier for occupational disease.
Format : date


Specifies when the incapacity starts.

Format : date


Specifies when the current period of incapacity ends.

Format : date

diagnosis 1..3  0..3




TBD Describes the diagnosis that is the reason for this incapacity.


Each diagnosis shall then be expressed by 1 content element containing code(s) AND/OR 1 content element containing text. Note however the use of coded diagnosis is STRONGLY recommended.

It is strongly recommended to follow the following decision tree for the codesystem usage:
  -    Search in priority the SNOMED-CT code
  -    IF the SNOMED-CT code is not available, you SHOULD use the ICD10 and ICPC2

[content (cd+)]

A coded form of the diagnosis.

Note different coding systems are allowed (ICD,ICPC, CD-SNOMED and must be accompanied by a version number)

When multiple coding systems are used, they are only supposed to point to 1 diagnosis.
(If it is needed to give multiple different diagnoses: include multiple diagnosis items – one for each diagnosis.)
A maximum of 3 diagnosis can be provided (meaning a maximum of 6 codes)

[content (text)]

A text with the description of the diagnosis.

When there are more than 1 diagnosis items, one – and only one – diagnosis item SHALL  have an extra <cd> element to clarify this is the principal diagnosis.(If there is 1 diagnosis, this is automatically considered the principal diagnosis).  This extra cd is this:
<cd S="LOCAL" SV="1.0" SL="MMEDIATT-ITEM">principal</cd>
contactperson 0..* 0..* 0..* 0..*

Describes a contactperson to contact the patient

Optionally, the item is further refined by adding an extra <cd> with a value from CD-CONTACTPERSON


A contactperson item must at least contain one content element with a person element.

The person element must contain at least an id (a LOCAL identifier is allowed here), a firstname (allowed to be empty), familyname and sex.
Only in case of dataset A or dataset B, the contactperson may contain a telecom element.
encountertype 0..1 0..1 0 0

These 4 items are optional: they refer to the fact the patient is hospitalized but this is not the main reason for being incapacitated.

If one or more of these items are used, they should ALWAYS include the first item ‘encounter’ (This signifies the encounter that is modeled is the hospitalisation)
They are aligned with how a hospitalisation is modeled in the generic discharge letter transaction.


Use CD-ENCOUNTER and use the value ‘hospital’ to clarify this is hospitalisation info

encounterdatetime 0..1 0..1 0 0


This signifies the startdate of the hospitalisation

dischargedatetime 0..1 0..1 0 0 content(date)

This signifies the enddate of the hospitalisation

encounterlocation  0..1 0..1 0 0


To model the hospital of the hospitalisation. 

The final block of items below are using a local table ‘MMEDIATT-ITEM’ (<cd S="LOCAL" SV="1.0" SL="MMEDIATT-ITEM">). This means these items do not use CD-ITEM but are used e.g. <cd S="LOCAL" SV="1.0" SL="MMEDIATT-ITEM">expectedbirthgivingdate</cd>.
These items may be used to compose an incapacity notification transaction in the context of a Mult-eMediAtt message, according to the proposed cardinalities. Optional elements in item structure are set within squared braces.
Note when the message concerns an employee of the private sector or a student/pupil, all elements below are never allowed (i.e. cardinality = 0.) 
  A B C TBD    
expectedbirthgivingdate 0..1 0..1



These items are only allowed when the patient is a woman according to <sex> in <patient>

In case of dataset A or dataset B these data can be used if the physician entered them.

Please note: if the recipient is a mutuality and the message is sent  for a female patient and she is working self employed (cfr. the value in the 'profession' element supra) and she is pregnant, then these 2 elements (expectedbirthgivingdate and maternityleave) MUST be present.

expectedbirthgivingdate shall have 1


maternityleave 0..1 0..1



maternityleave shall have 1


foreignstay 0 0..1



This is only optionally used when the patient is working in educationsector.

When the element is present, please note both begin- and endmoment are obligatory!  




When an incapactity needs to be retracted, CD-TRANSACTION-TYPE: is always ‘incapacity’and only 1 KMEHR element is sent in the message:


Item type (cd)   Item purpose Item structure
incapacity 1 Specifies which incapacity needs to be retracted The value of the id refers to the incapacity message that needs to be retracted

lifecycle (cd)

a cd element is used with the value ‘retracted’ from CD-LIFECYCLE

Name XML
testcase1_illness_with_diagnosis xml
testcase1Bis_retraction xml
testcase2_workaccident_with_2_diagonosis xml
testcase3_illness_part_of_2_attestations_in_1_usecase xml
testcase3_workaccident_part_of_2_attestations_in_1_usecase xml
testcase4_illness_with_hospitalisation xml
testcase5_workaccident_police xml
testcase6_workaccident_with_2_diagnosis xml
testcase7_illness_teacher_1_diagnosis xml
testcase8_illness_extension_with_diagnosis xml
testcase9_workaccident_police_hospitalisation_details xml
testcase10_illness_without_diagnosis_with_care_address xml
testcase11_illness_with_diagnosis_with_workregime_info xml
testcase12_illness_with_diagnosis_with_contactperson xml
testcase13_workaccident_with_3_diagnoses xml
testcase14_workaccident_with_3_diagnoses_differently_coded xml