Transaction: Incapacity notification 2.2
General information
STATUS:
Published
OWNER:
eHealth Platform
STANDARD:
KMEHR
VERSION:
2.2
DATE:
2023-03-24
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.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:
| Dataset | Recipient: |
|---|---|
| A work incapacity message with mandatory diagnosis (Dataset A) |
Iteration 1 : Iteration 2 : |
| 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 : |
| A work incapacity message without diagnosis (Dataset C) |
Iteration 2 : |
| 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. |
STATUS:
Published
OWNER:
eHealth Platform
STANDARD:
KMEHR
VERSION:
2.2
DATE:
2023-03-24
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.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:
| Dataset | Recipient: |
|---|---|
| A work incapacity message with mandatory diagnosis (Dataset A) |
Iteration 1 : Iteration 2 : |
| 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 : |
| A work incapacity message without diagnosis (Dataset C) |
Iteration 2 : |
| 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. |
Guidelines
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.
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.
| Element | Purpose |
|---|---|
| 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) |
| Element | Dataset | Purpose | |||
|---|---|---|---|---|---|
| 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 |
0..1 |
0 |
Birthdate of patient |
| 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. |
| Element | Purpose |
|---|---|
| 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. |
Please note: for a retraction of a previously send incapacity, only 1 KMEHR element shall be sent. (Cfr. infra)
| Item type (cd) | Dataset | Item purpose | Item structure | |||
|---|---|---|---|---|---|---|
| A | B | C | TBD | |||
| 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
|
||||||
|
beginmoment Specifies when the incapacity starts. Format : date |
||||||
|
endmoment Specifies when the current period of incapacity ends. Format : date |
||||||
| 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:
- 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 |
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 |
| 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. |
|
| Dataset | ||||||
| A | B | C | TBD | |||
| 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 |
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.
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.
| Element | Purpose |
|---|---|
| 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) |
| Element | Dataset | Purpose | |||
|---|---|---|---|---|---|
| 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 |
0..1 |
0 |
Birthdate of patient |
| 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. |
| Element | Purpose |
|---|---|
| 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. |
Please note: for a retraction of a previously send incapacity, only 1 KMEHR element shall be sent. (Cfr. infra)
| Item type (cd) | Dataset | Item purpose | Item structure | |||
|---|---|---|---|---|---|---|
| A | B | C | TBD | |||
| 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
|
||||||
|
beginmoment Specifies when the incapacity starts. Format : date |
||||||
|
endmoment Specifies when the current period of incapacity ends. Format : date |
||||||
| 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:
- 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 |
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 |
| 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. |
|
| Dataset | ||||||
| A | B | C | TBD | |||
| 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 |
| 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 |