Transaction: Incapacity notification 2.0

STATUS:

Published

OWNER:

eHealth Platform

STANDARD:

KMEHR

VERSION:

2.2

DATE:

2021-08-23

DEFINITION:

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.

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, a message with optional diagnosis (this includes also a small dataset specifically for a patient that is working professionally for an education organization), a message without diagnosis, a message without diagnosis concerning a student/pupil.

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

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) Iteration 1 : 
- the medical department of HR Rail for contractual
 
Planning to be definied: Certimed, Securex, Medconsult
A work incapacity message without diagnosis 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 Planning to be defined for the implementation for pupils and students. 
In the meantime, the provided schematron makes already some controls.

The specific documentation for Medex is available on the Medex site. Other organizations using the incapacity notification as the template for their incapacity notification may also make their specific implementation information available once ready.

Generalities

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.

Diagnosis description main principles

The following principles MUST be followed:

For certificates with mandatory diagnosis: 

- 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 the release. This date can be found as the “effectiveTime” that is indicated for every line of a SNOMED code in the reference tables. 

- 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 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)
 
Patient
 
The patient is, as usual, represented by the patient element of the folder. 
 
The considered dataset for this transaction is:
 
id 1 id of the transaction according to the ID-PATIENT conventions. A INSS number must be provided as identification.
firstname 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 Familyname of patient.
birthdate

0..1

or

0

Birthdate of patient

When the patient is a student/pupil (i.e. the incapacity is not ‘work’), this is NOT ALLOWED

sex

1

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

address

0..1

or

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)

When the patient is a student/pupil, a careaddress is NOT ALLOWED

telecom

0..*

or

0

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

Note the presence of a telecom element is ONLY ALLOWED for messages sent with a diagnosis element

usuallanguage 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

or

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.

Note the presence of a profession element is ONLY ALLOWED for messages sent with a diagnosis 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’.

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.

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. 
 
 
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 send. (Cfr. infra)

 
Item type (cd)   Item purpose Item structure
incapacity 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 an incapacity notification with an optional diagnosis, the value 'pregnancy' can still be used without making the diagnosis mandatory.
 
The presence of values ‘pregnancy’,’occupationaldisease’ and ‘workaccident’ are NOT ALLOWED when the message concerns a student/pupil.
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

beginmoment

Specifies when the incapacity starts.

Format : date

endmoment

Specifies when the current period of incapacity ends.

Format : date

diagnosis

0

or

1..3 diagnosis MAX

or

0..3

 

 

Describes the diagnosis that is the reason for this incapacity.

Note the presence of a diagnosis element is NOT ALLOWED when the message concerns a student/pupil.

Depending on the recipient (cfr. supra), this element is  NOT ALLOWED, OBLIGATORY or OPTIONAL. 
 
When obligatory or optional, 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..*

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 when a message is sent with a diagnosis, the contactperson may contain a telecom element.
encountertype 0..1 

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.
 
Note the presence of these 4 elements are ONLY ALLOWED when the message is sent with a (obligatory or optional) diagnosis.

content(cd)

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

encounterdatetime 0..1

content(date)

This signifies the startdate of the hospitalisation

dischargedatetime 0..1 content(date)

This signifies the enddate of the hospitalisation

encounterlocation  0..1

content(hcparty)

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.) 
 
expectedbirthgivingdate

0..1

or

0

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

Note the presence of pregnancy elements are ONLY ALLOWED when the message is sent with a  (obligatory or optional) diagnosis.

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

or

0

maternityleave shall have 1

beginmoment(date)

foreignstay

0..1

or

0

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

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