Transaction: Incapacity notification 2.3 + partial work reuptake (Iteration 2)
General information
STATUS:
Draft
OWNER:
eHealth Platform
STANDARD:
KMEHR
VERSION:
2.3
DATE:
2025-11-26
DEFINITION:
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.3 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.
This version also caters for the "request for partial reuptake of work" (ADA - aanvraag deeltijdse arbeidshervatting - requête de reprise partielle du travail). The same rules are valid as for the incapacity notification, taking into account that the aim is to request the reuptake of activities.
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. 5 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), an administrative dataset (dataset D), a message without diagnosis concerning a student/pupil (these datasets are for future use, 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:
|
|
Recipient: |
|---|---|
|
A work incapacity message with mandatory diagnosis (Dataset A) |
Iteration 1: Iteration 2 : - medical department of HR RAIL (for statutaires only incapacity>28 days or prolongation, beware: the medical department of HR RAIL is not a recipient in the case of partial reuptake of work), |
|
A work incapacity message with optional diagnosis (this may include also the data for a patient working for education when applicable) (Dataset B) |
Iteration 2 : - medical department of Certimed, Securex contrôle medical, Medicheck |
|
A work incapacity message without diagnosis (Dataset C) |
Iteration 2 (each of these is a recipient in the case of partial reuptake of work) - the medical department of HR Rail for contractual - the employers who work with Certimed, Securex contrôle medical, Medicheck (voluntary basis) - the employers |
| An administrative message (Dataset D) | A list of a recipients of the message, only for citizens who have activated the citizen ebox, an for whom at least one Mult-eMediatt has successfully been sent electronically. |
|
A school incapacity message without diagnosis concerning a student/pupil (for future use) |
Planning to be defined for the implementation for pupils and students. |
POINT OF ATTENTION: If the DAAS suggests the CIN as the recipient because the incapacity for work exceeds 14 days and/or concerns an extension, starting from January 2026, the certificate must obligatory be sent via the electronic system of Mult-eMediatt.
For incapacity for work certificates to the CIN with a duration less than 15 days or without extension, the doctor must use the paper certificate.
STATUS:
Draft
OWNER:
eHealth Platform
STANDARD:
KMEHR
VERSION:
2.3
DATE:
2025-11-26
DEFINITION:
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.3 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.
This version also caters for the "request for partial reuptake of work" (ADA - aanvraag deeltijdse arbeidshervatting - requête de reprise partielle du travail). The same rules are valid as for the incapacity notification, taking into account that the aim is to request the reuptake of activities.
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. 5 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), an administrative dataset (dataset D), a message without diagnosis concerning a student/pupil (these datasets are for future use, 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:
|
|
Recipient: |
|---|---|
|
A work incapacity message with mandatory diagnosis (Dataset A) |
Iteration 1: Iteration 2 : - medical department of HR RAIL (for statutaires only incapacity>28 days or prolongation, beware: the medical department of HR RAIL is not a recipient in the case of partial reuptake of work), |
|
A work incapacity message with optional diagnosis (this may include also the data for a patient working for education when applicable) (Dataset B) |
Iteration 2 : - medical department of Certimed, Securex contrôle medical, Medicheck |
|
A work incapacity message without diagnosis (Dataset C) |
Iteration 2 (each of these is a recipient in the case of partial reuptake of work) - the medical department of HR Rail for contractual - the employers who work with Certimed, Securex contrôle medical, Medicheck (voluntary basis) - the employers |
| An administrative message (Dataset D) | A list of a recipients of the message, only for citizens who have activated the citizen ebox, an for whom at least one Mult-eMediatt has successfully been sent electronically. |
|
A school incapacity message without diagnosis concerning a student/pupil (for future use) |
Planning to be defined for the implementation for pupils and students. |
POINT OF ATTENTION: If the DAAS suggests the CIN as the recipient because the incapacity for work exceeds 14 days and/or concerns an extension, starting from January 2026, the certificate must obligatory be sent via the electronic system of Mult-eMediatt.
For incapacity for work certificates to the CIN with a duration less than 15 days or without extension, the doctor must use the paper certificate.
Guidelines
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), or if the DAAS indicates a dataset "d", the schematron file should not be used. For each infrastructure environment (INT, ACC, PROD), there will always be two versions of the schematron available, the current version, and the previous version. The presence of the previous version allows the client software a grace period to perform the update to the current version. See the cookbook for a detailed explanation of the way of working.
The Schematron to validate this Iteration 2 version is available in the acceptance branch on GitHub.
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”
Header
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. The phonenumber of the <hcparty> SHALL not be added if the dataset is C. 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. 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) |
Patient
The patient is, as usual, represented by the patient element of the folder.
The considered dataset for this transaction is:
|
|
Dataset |
||||
|
|
A |
B |
C |
For future use |
|
|
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 |
0 |
0 |
Birthdate of patient (SHALL not be present in the case of dataset C (private employer) and D) |
|
sex |
1 |
1 |
1 |
1 |
Sex of the patient, using a value from CD-SEX |
|
address |
0..1 |
0..1 |
0
|
0 |
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..* |
0 |
TBD |
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 |
0
|
TBD |
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 |
|
cd |
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’, in the case of the notification of an incapacity. . In case of a request for reuptake of work, this must be combined with one of the following values: "adanormal" (first request after incapacity)
"adaextension" (request following a previous request, to extend the previous period, possibly with a change of percentage)
"adarelapse" (request for a reduced reuptake after a period of full reuptake of work)
It is mandatory to include a cd of type "CD-TRANSACTION-INC-NOT" ("a", "b", "c" (beware: lowercase)), containing the value that is returned by the DAAS. The DAAS sends the list of recipients to the client software, and for every recipient the list contains the dataset and the technical endpoint. The dataset value should be added by the client software to the KMEHR document for each recipient. This value is used by the schematron to apply the necessary business rules. 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 |
|
date |
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 |
|
author |
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 (especially in case of a dataset C). A fixed and/or mobile phone number (using the correct value of the table CD-TELECOM) is recommended to include but not obligatory. The phonenumber is not allowed in case of dataset C (private employer) |
|
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.
Items
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)
|
|
Dataset |
|
||||
|
|
A |
B |
C |
For future use |
|
|
|
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, only the values "accident" and "illness" can be used, even if the DAAS provides a more detailed value.
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 (incapacity(percentage)) This is within the same content(incapacity) as the above. Indicates the percentage of incapacity in case of an incapacity notification (default: 100), or the percentage of incapacity remaining (i.e. 90 means a reuptake of 10) in the case of a request for reuptake of work (ADA). In the latter case, this information is mandatory. |
||||||
|
[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. In case of dataset C and "accident", the use of the date is forbidden.
Format : date |
||||||
|
beginmoment Specifies when the incapacity starts. Format : date |
||||||
|
endmoment Specifies when the current period of incapacity ends. Format : date IMPORTANT: Starting from January 2026, if the recipient is the CIN or Medex, the maximum duration of each Mult-eMediatt is limited to a period of 3 months. |
||||||
|
text Fixed text indicating the intention of the physician. This indication is mandatory in case of dataset C. It will look like this: <text L="nl">Ik, ondergetekende, dokter in de geneeskunde, verklaar vandaag te hebben ondervraagd</text> <text L="fr">Je soussigné, Docteur en médecine, certifie avoir interrogé ce jour</text>
|
||||||
|
diagnosis |
1..3 |
0..3 |
0 |
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: |
[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) No diagnoses will be present in case of dataset C (private employer) |
|
[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: |
|||||
|
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 |
content(person) 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.
|
content(cd) Use CD-ENCOUNTER and use the value ‘hospital’ to clarify this is hospitalisation info. The values 'hospitalisation' and 'relapse' SHALL not be used for dataset C (private employer) |
|
encounterdatetime |
0..1 |
0..1 |
0 |
0 |
content(date) 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 |
content(hcparty) To model the hospital of the hospitalisation. |
|
| involvedparty | 0..1 | 0..1 | 0..1 | 0..1 | This item indicates the employer that is concerned. He is mentioned in the call to the DAAS, and for each employer a separate KMEHR message must be sent. |
content(hcparty) To model the involved party content(hcparty(id)) use the CBE code content(hcparty(cd)) use the role "target" content(hcparty(name)) a textual form of the company name |
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 (dataset C) or a student/pupil, all elements below are never allowed (i.e. cardinality = 0.)
|
|
Dataset |
|
||||
|
|
A |
B |
C |
For future use |
|
|
|
expectedbirthgivingdate |
0..1 |
0..1 |
0 |
0 |
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 content(date) |
|
maternityleave |
0..1 |
0..1 |
0 |
0 |
maternityleave shall have 1 beginmoment(date) |
|
|
foreignstay |
0 |
0..1 |
0 |
TBD |
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! |
beginmoment(date) endmoment(date) |
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 |
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), or if the DAAS indicates a dataset "d", the schematron file should not be used. For each infrastructure environment (INT, ACC, PROD), there will always be two versions of the schematron available, the current version, and the previous version. The presence of the previous version allows the client software a grace period to perform the update to the current version. See the cookbook for a detailed explanation of the way of working.
The Schematron to validate this Iteration 2 version is available in the acceptance branch on GitHub.
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”
Header
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. The phonenumber of the <hcparty> SHALL not be added if the dataset is C. 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. 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) |
Patient
The patient is, as usual, represented by the patient element of the folder.
The considered dataset for this transaction is:
|
|
Dataset |
||||
|
|
A |
B |
C |
For future use |
|
|
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 |
0 |
0 |
Birthdate of patient (SHALL not be present in the case of dataset C (private employer) and D) |
|
sex |
1 |
1 |
1 |
1 |
Sex of the patient, using a value from CD-SEX |
|
address |
0..1 |
0..1 |
0
|
0 |
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..* |
0 |
TBD |
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 |
0
|
TBD |
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 |
|
cd |
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’, in the case of the notification of an incapacity. . In case of a request for reuptake of work, this must be combined with one of the following values: "adanormal" (first request after incapacity)
"adaextension" (request following a previous request, to extend the previous period, possibly with a change of percentage)
"adarelapse" (request for a reduced reuptake after a period of full reuptake of work)
It is mandatory to include a cd of type "CD-TRANSACTION-INC-NOT" ("a", "b", "c" (beware: lowercase)), containing the value that is returned by the DAAS. The DAAS sends the list of recipients to the client software, and for every recipient the list contains the dataset and the technical endpoint. The dataset value should be added by the client software to the KMEHR document for each recipient. This value is used by the schematron to apply the necessary business rules. 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 |
|
date |
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 |
|
author |
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 (especially in case of a dataset C). A fixed and/or mobile phone number (using the correct value of the table CD-TELECOM) is recommended to include but not obligatory. The phonenumber is not allowed in case of dataset C (private employer) |
|
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.
Items
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)
|
|
Dataset |
|
||||
|
|
A |
B |
C |
For future use |
|
|
|
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, only the values "accident" and "illness" can be used, even if the DAAS provides a more detailed value.
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 (incapacity(percentage)) This is within the same content(incapacity) as the above. Indicates the percentage of incapacity in case of an incapacity notification (default: 100), or the percentage of incapacity remaining (i.e. 90 means a reuptake of 10) in the case of a request for reuptake of work (ADA). In the latter case, this information is mandatory. |
||||||
|
[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. In case of dataset C and "accident", the use of the date is forbidden.
Format : date |
||||||
|
beginmoment Specifies when the incapacity starts. Format : date |
||||||
|
endmoment Specifies when the current period of incapacity ends. Format : date IMPORTANT: Starting from January 2026, if the recipient is the CIN or Medex, the maximum duration of each Mult-eMediatt is limited to a period of 3 months. |
||||||
|
text Fixed text indicating the intention of the physician. This indication is mandatory in case of dataset C. It will look like this: <text L="nl">Ik, ondergetekende, dokter in de geneeskunde, verklaar vandaag te hebben ondervraagd</text> <text L="fr">Je soussigné, Docteur en médecine, certifie avoir interrogé ce jour</text>
|
||||||
|
diagnosis |
1..3 |
0..3 |
0 |
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: |
[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) No diagnoses will be present in case of dataset C (private employer) |
|
[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: |
|||||
|
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 |
content(person) 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.
|
content(cd) Use CD-ENCOUNTER and use the value ‘hospital’ to clarify this is hospitalisation info. The values 'hospitalisation' and 'relapse' SHALL not be used for dataset C (private employer) |
|
encounterdatetime |
0..1 |
0..1 |
0 |
0 |
content(date) 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 |
content(hcparty) To model the hospital of the hospitalisation. |
|
| involvedparty | 0..1 | 0..1 | 0..1 | 0..1 | This item indicates the employer that is concerned. He is mentioned in the call to the DAAS, and for each employer a separate KMEHR message must be sent. |
content(hcparty) To model the involved party content(hcparty(id)) use the CBE code content(hcparty(cd)) use the role "target" content(hcparty(name)) a textual form of the company name |
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 (dataset C) or a student/pupil, all elements below are never allowed (i.e. cardinality = 0.)
|
|
Dataset |
|
||||
|
|
A |
B |
C |
For future use |
|
|
|
expectedbirthgivingdate |
0..1 |
0..1 |
0 |
0 |
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 content(date) |
|
maternityleave |
0..1 |
0..1 |
0 |
0 |
maternityleave shall have 1 beginmoment(date) |
|
|
foreignstay |
0 |
0..1 |
0 |
TBD |
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! |
beginmoment(date) endmoment(date) |
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 |
Examples
| Name | XML |
|---|---|
| testcase1_illness_with_diagnosis.xml | xml |
| testcase1bis_retraction.xml | xml |
| testcase2_workaccident_with_2_diagonosis.xml | xml |
| testcase3_illness_part_of_2_attestations_in_1_usecase.xml | xml |
| testcase3_workaccident_part_of_2_attestations_in_1_usecase.xml | xml |
| testcase4_illness_with_hospitalisation.xml | xml |
| testcase5_workaccident_police.xml | xml |
| testcase6_workaccident_with_2_diagnosis.xml | xml |
| testcase7_illness_teacher_1_diagnosis.xml | xml |
| testcase8_illness_extension_with_diagnosis.xml | xml |
| testcase9_workaccident_police_hospitalisation_details.xml | xml |
| testcase10_illness_without_diagnosis_with_care_address.xml | xml |
| testcase11_illness_with_diagnosis_with_workregime_info.xml | xml |
| testcase12_illness_with_diagnosis_with_contactperson.xml | xml |
| testcase13_workaccident_with_3_diagnoses.xml | xml |
| testcase14_workaccident_with_3_diagnoses_differently_coded.xml | xml |
| testcase15_with_involved_party.xml | xml |
| testcase16_adanormal.xml | xml |
| testcase17_incapacity_CIN_endmoment_exceeds_3months.xml | xml |
| Name | XML |
|---|---|
| testcase1_illness_with_diagnosis.xml | xml |
| testcase1bis_retraction.xml | xml |
| testcase2_workaccident_with_2_diagonosis.xml | xml |
| testcase3_illness_part_of_2_attestations_in_1_usecase.xml | xml |
| testcase3_workaccident_part_of_2_attestations_in_1_usecase.xml | xml |
| testcase4_illness_with_hospitalisation.xml | xml |
| testcase5_workaccident_police.xml | xml |
| testcase6_workaccident_with_2_diagnosis.xml | xml |
| testcase7_illness_teacher_1_diagnosis.xml | xml |
| testcase8_illness_extension_with_diagnosis.xml | xml |
| testcase9_workaccident_police_hospitalisation_details.xml | xml |
| testcase10_illness_without_diagnosis_with_care_address.xml | xml |
| testcase11_illness_with_diagnosis_with_workregime_info.xml | xml |
| testcase12_illness_with_diagnosis_with_contactperson.xml | xml |
| testcase13_workaccident_with_3_diagnoses.xml | xml |
| testcase14_workaccident_with_3_diagnoses_differently_coded.xml | xml |
| testcase15_with_involved_party.xml | xml |
| testcase16_adanormal.xml | xml |
| testcase17_incapacity_CIN_endmoment_exceeds_3months.xml | xml |