Transaction: Summarised Electronic Healthcare Record v2.0
General information
STATUS:
Published
OWNER:
eHealth Platform
STANDARD:
KMEHR
VERSION:
2.0
DATE:
2016-12-01
DEFINITION:
In 2017/2018 a planning was communicated when the use of this specification will become mandatory. Software packages will have to implement the Sumehr v2 towards end 2019. Until then, continue to use the Summarised Electronic Healthcare record v.1.1.
The functional content of this new version has been defined in 2016 by the Sumehr 2.0 workgroup. That workgroup functioned under the auspices of NIHDI and was created by the action points of the roadmap ‘e-health plan / the e-health landscape in 2019.’
Sumehr 2.0 requires the use of Kmehr 20161201 (or a more recent version).
To support the elaboration of messages that fulfil the Sumehr specification, a tool has been developed.
Each version of the Sumehr specification leads to a release of this tool. The support for Sumehr 2.0 in the validation tool is foreseen for 2018.
Please note only version 3.0.0 (or more recent) of the validation tool supports the Sumehr 2.0 specification.
• Version 1.0.0 validates a message according to the specification published in June 2010 (Kmehr standard 20100601).
• Version 1.0.1 validates a message according to the specification published in Augustus 2010 (Kmehr standard 20100601).
• Version 1.1.0 validates a message according to the specification published in September 2010 (Kmehr standard 20100901).
• Version 2.0.0 validates a message according to the specification published in July 2011 (Kmehr standard 20110701).
• Version 3.0.0 (release planned for 2018) validates a message according to the specification published in December 2016 (Kmehr standard 20161201).
Every patient has the right to have a Sumehr. The Sumehr is a snapshot of the health of the patient, validated by the author of the Sumehr. It is created on a specific date and contains those elements concerning the health of the patient that are deemed useful to guarantee the continuity of care. As such, the content of the Sumehr is by definition considered relevant.
The Sumehr is originally used in the context of unplanned care but can equally be used in the context of planned care (e.g. as a supplement to a referral letter for a hospitalisation or consultation.)
A Sumehr is considered unique, meaning only the most recent Sumehr is to be considered the valid Sumehr for a patient. Every time a new Sumehr is published, that Sumehr becomes the new unique Sumehr until it is replaced by a newer version. The Sumehr is complimentary to any other or faster means of communication.
A patient always has the right to ask the author of its Sumehr to not publish certain data.
By default the Sumehr is available to physicians and its patient subject. Respecting the wishes and freedom of its patient subject, the possibility of patient access to its Sumehr is foreseen in the future.
The specifications below do not explicitly mention the national reference terminology SNOMED-CT. However, efforts are ongoing to define recommendations where and how to use SNOMED-CT. As soon as certain elements of the Sumehr V.2 also have clear recommendations how to express them in SNOMED-CT, these specifications will be updated.
STATUS:
Published
OWNER:
eHealth Platform
STANDARD:
KMEHR
VERSION:
2.0
DATE:
2016-12-01
DEFINITION:
In 2017/2018 a planning was communicated when the use of this specification will become mandatory. Software packages will have to implement the Sumehr v2 towards end 2019. Until then, continue to use the Summarised Electronic Healthcare record v.1.1.
The functional content of this new version has been defined in 2016 by the Sumehr 2.0 workgroup. That workgroup functioned under the auspices of NIHDI and was created by the action points of the roadmap ‘e-health plan / the e-health landscape in 2019.’
Sumehr 2.0 requires the use of Kmehr 20161201 (or a more recent version).
To support the elaboration of messages that fulfil the Sumehr specification, a tool has been developed.
Each version of the Sumehr specification leads to a release of this tool. The support for Sumehr 2.0 in the validation tool is foreseen for 2018.
Please note only version 3.0.0 (or more recent) of the validation tool supports the Sumehr 2.0 specification.
• Version 1.0.0 validates a message according to the specification published in June 2010 (Kmehr standard 20100601).
• Version 1.0.1 validates a message according to the specification published in Augustus 2010 (Kmehr standard 20100601).
• Version 1.1.0 validates a message according to the specification published in September 2010 (Kmehr standard 20100901).
• Version 2.0.0 validates a message according to the specification published in July 2011 (Kmehr standard 20110701).
• Version 3.0.0 (release planned for 2018) validates a message according to the specification published in December 2016 (Kmehr standard 20161201).
Every patient has the right to have a Sumehr. The Sumehr is a snapshot of the health of the patient, validated by the author of the Sumehr. It is created on a specific date and contains those elements concerning the health of the patient that are deemed useful to guarantee the continuity of care. As such, the content of the Sumehr is by definition considered relevant.
The Sumehr is originally used in the context of unplanned care but can equally be used in the context of planned care (e.g. as a supplement to a referral letter for a hospitalisation or consultation.)
A Sumehr is considered unique, meaning only the most recent Sumehr is to be considered the valid Sumehr for a patient. Every time a new Sumehr is published, that Sumehr becomes the new unique Sumehr until it is replaced by a newer version. The Sumehr is complimentary to any other or faster means of communication.
A patient always has the right to ask the author of its Sumehr to not publish certain data.
By default the Sumehr is available to physicians and its patient subject. Respecting the wishes and freedom of its patient subject, the possibility of patient access to its Sumehr is foreseen in the future.
The specifications below do not explicitly mention the national reference terminology SNOMED-CT. However, efforts are ongoing to define recommendations where and how to use SNOMED-CT. As soon as certain elements of the Sumehr V.2 also have clear recommendations how to express them in SNOMED-CT, these specifications will be updated.
Guidelines
Generalities
This transaction requires a level 3-4 of kmehr normalization: content are preferably coded however some textual contents are still allowed.
Patient
The patient is, as usual, represented by the patient element of the folder. In the case of a Sumehr, the attribute id must contain the INSS number of the patient. The birthdate is also required and must be complete.
Transaction elements
| Element | Purpose |
|---|---|
|
id |
id of the transaction according to the ID-KMEHR conventions. |
|
cd |
Indicates that the transaction is a Sumehr by the use of the value 'sumehr' from CD-TRANSACTION. |
|
date |
Date of creation of the sumehr. |
|
time |
Time of creation of the Sumehr. |
|
author |
Describes the author of the Sumehr. This author must be a health care professional. Usually this is a physician and preferably a general practitioner (or group of GPs) who is also the manager of the global medical dossier. However, for certain types of patient, the author of the Sumehr can be a physician that is considered equivalent, i.e. the physician that ‘manages the patient’s dossier’. E.g. a paediatrician as author for kids that are followed closely or a gynaecologist for some of his or her patients. The author assumes the responsibility of the medical content of the Sumehr. The author is, as usual represented, by a hcparty element. In the case of a Sumehr, the id element must contain the INAMI/RIZIV/NIHDI number of the healthcare professional. Furthermore, the cd element will usually refer to the value ‘persphysician’ of CD-HCPARTY. The use of the address and telecom elements is recommended. Please note, as a general rule in KMEHR messages, an author defined on the item level overrules - for that item - the author on the transaction level. |
|
iscomplete |
This value must be set to true but does not carry any functional meaning in the context of the Sumehr. |
|
isvalidated |
This value must be set to true but does not carry any functional meaning in the context of the Sumehr. |
Structure overview
A Sumehr is only composed of recognized items and headings. It should at least contain one item.
Headings
The following headings values from CD-HEADING may be used.
| Heading | Purpose |
|---|---|
|
assessment |
The items describing the current problems and treatments may be placed under this heading value. |
|
history |
The items describing the medical and therapeutic antecedents may be placed under this heading value. |
Items
Those elements concerning the health of the patient that are deemed useful to guarantee the continuity of care must be included in the Sumehr transaction using one or more of the following items from CD-ITEM.
Optional attributes are set within squared braces.
| Item type (cd) | Item purpose | Item structure |
|---|---|---|
|
adr |
Specifies a risk relative |
content (text+) [content (cd+)] For each risk, an item is provided. This item contains textual content with the label of the risk at least. It should also contain one cd elements content corresponding to the available codifications. |
|
allergy |
Specifies a risk |
same structure as 'adr' Note it is highly recommended in case of allergies for specific medicines to also identify the medicine that causes the allergy. |
|
socialrisk |
Specifies a social risk factor. |
same structure as 'adr' |
|
risk |
Specifies other |
same structure as 'adr' |
|
contactperson
|
Specifies a patient related |
content (person) The contact person is described by a person element. Note it is expected this information will be available in a centralized personal health record in the future. Until that time it is recommended to provide this information (also) in the Sumehr transaction. |
|
contacthcparty |
Specifies a healthcare |
content (hcparty) The healthcare professional is described by, at least, one hcparty element. This HCParty should contain the INAMI/RIZIV/NIHDI number of the healthcare professional (if available). The role of the contact must be described within the cd element by a value from CD-HCPARTY. Note it is expected this information will be available in a multidisciplinary dossier in the future. Until that time it is recommended to provide this information (also) in the Sumehr transaction. |
|
gmdmanager |
Specifies the manager of the DMG/GMD |
content (hcparty) The GMD manager is described by an hcparty element whose id element must contain a INAMI/RIZIV/NIHDI number. If the GMD owner is a physical person, it also contains a familyname and firstname elements. If the GMD owner is a medical practice, it also contains a name element. The information here should match the GMD manager available via MyCareNet. |
|
patientwill |
Specifies a therapeutic limitation expressed for the patient (specified only if registered). |
content (cd+) [content (text+)] General therapeutic limitations are described using the values of CD-PATIENTWILL. To define any status concerning the resuscitation will of a patient, the table and the values of CD-PATIENTWILL-RES must be used To define any status concerning the hospitalisation will of a patient the table and the values of CD-PATIENTWILL-HOS must be used. |
|
problem
|
Specifies a current diagnosis, problem, complaint, symptom, etc OR a relevant medical antecedent. (depending on the value of the lifecycle)
|
content (text+) [content (cd+)] For each problem, an item is provided. |
|
[beginmoment] Specifies when the problem started. |
||
|
[endmoment] |
||
|
lifecycle Must be used to distinguish between problems (value ‘ active’ from CD-LIFECYCLE) and relevant passive care elements (value ‘inactive’). If needed to describe the absence of a specific problem: the value ‘notpresent’ must be used. |
||
|
If needed to explicitly express there are NO KNOWN relevant medical antecedents, include the following item (nullFlavor 'NA' = not applicable) |
||
| treatment |
Specifies a current treatment OR a relevant therapeutical antecedent. (depending on the value of the lifecycle)
|
content (text+) [content (cd+)] For each treatment, an item is provided. |
|
[beginmoment] Specifies when the treatment started. |
||
|
[endmoment] Specifies when the treatment ended. |
||
|
lifecycle Must be used to distinguish between an active treatment (value ‘ active’ from CD-LIFECYCLE) and a relevant therapeutical antecedent (value ‘inactive’). If needed to describe the absence of a specific treatment: the value ‘notpresent’ must be used. |
||
|
If needed to explicitly express there are NO KNOWN relevant therapeutical antecedents, include the following item (nullFlavor 'NA' = not applicable) <item> <id S="ID-KMEHR" SV="1.0">1</id> <cd S="CD-ITEM" SV="1.10" nullFlavor="NA">treatment</cd> <lifecycle> <cd S="CD-LIFECYCLE" SV="1.0">inactive</cd> </lifecycle> </item> (If it is needed to express the absence of a specific treatment: use the lifecycle value as described supra.)
|
||
|
medication |
Specifies a current patient's medication |
content (text) Textual description of the medication. |
|
[content (medicinalproduct | substanceproduct| coumpoundprescription)] This content should correspond to the last The element medicinalproduct supports the identification the prepacked medicinal product by a code and a textual description (element intendedname) whereas the element substanceproduct describes the INN or substance based cluster prescribed by using codes. The element coumpoundprescription is a textual description of a compound prescription. Please refere to pharmaceutical prescription 2.x to know which CD tables to use for codes. |
||
| [content (cd)]
Value from CD-ATC corresponding to the medication. |
||
| [beginmoment]
Specifies when the treatment starts. |
||
| [endmoment]
Specifies when the treatment ends. |
||
|
All the item elements (such as posology, frequency) described in pharmaceutical prescription 2.x may also be used. |
||
|
vaccine |
Specifies an administrated vaccine |
[content (medicinalproduct | substanceproduct)] This content should correspond to the medicinal product The element medicinalproduct supports the identification the prepacked medicinal product by a code and a textual description (element intendedname) whereas the element substanceproduct describes the INN or substance based cluster prescribed by using codes. Please refere to pharmaceutical prescription 2.x to know which CD tables to use for codes. |
| content (cd+)
Description of indications for the vaccine, using values from CD-VACCINEINDICATION. |
||
| [content (cd)]
Value from CD-ATC corresponding to the vaccine. |
||
| beginmoment
Specifies when the vaccine has been administrated. |
Text
When there is a need to comment on the Sumehr in its entirety, use a text item on the same level as the above items.
Generalities
This transaction requires a level 3-4 of kmehr normalization: content are preferably coded however some textual contents are still allowed.
Patient
The patient is, as usual, represented by the patient element of the folder. In the case of a Sumehr, the attribute id must contain the INSS number of the patient. The birthdate is also required and must be complete.
Transaction elements
| Element | Purpose |
|---|---|
|
id |
id of the transaction according to the ID-KMEHR conventions. |
|
cd |
Indicates that the transaction is a Sumehr by the use of the value 'sumehr' from CD-TRANSACTION. |
|
date |
Date of creation of the sumehr. |
|
time |
Time of creation of the Sumehr. |
|
author |
Describes the author of the Sumehr. This author must be a health care professional. Usually this is a physician and preferably a general practitioner (or group of GPs) who is also the manager of the global medical dossier. However, for certain types of patient, the author of the Sumehr can be a physician that is considered equivalent, i.e. the physician that ‘manages the patient’s dossier’. E.g. a paediatrician as author for kids that are followed closely or a gynaecologist for some of his or her patients. The author assumes the responsibility of the medical content of the Sumehr. The author is, as usual represented, by a hcparty element. In the case of a Sumehr, the id element must contain the INAMI/RIZIV/NIHDI number of the healthcare professional. Furthermore, the cd element will usually refer to the value ‘persphysician’ of CD-HCPARTY. The use of the address and telecom elements is recommended. Please note, as a general rule in KMEHR messages, an author defined on the item level overrules - for that item - the author on the transaction level. |
|
iscomplete |
This value must be set to true but does not carry any functional meaning in the context of the Sumehr. |
|
isvalidated |
This value must be set to true but does not carry any functional meaning in the context of the Sumehr. |
Structure overview
A Sumehr is only composed of recognized items and headings. It should at least contain one item.
Headings
The following headings values from CD-HEADING may be used.
| Heading | Purpose |
|---|---|
|
assessment |
The items describing the current problems and treatments may be placed under this heading value. |
|
history |
The items describing the medical and therapeutic antecedents may be placed under this heading value. |
Items
Those elements concerning the health of the patient that are deemed useful to guarantee the continuity of care must be included in the Sumehr transaction using one or more of the following items from CD-ITEM.
Optional attributes are set within squared braces.
| Item type (cd) | Item purpose | Item structure |
|---|---|---|
|
adr |
Specifies a risk relative |
content (text+) [content (cd+)] For each risk, an item is provided. This item contains textual content with the label of the risk at least. It should also contain one cd elements content corresponding to the available codifications. |
|
allergy |
Specifies a risk |
same structure as 'adr' Note it is highly recommended in case of allergies for specific medicines to also identify the medicine that causes the allergy. |
|
socialrisk |
Specifies a social risk factor. |
same structure as 'adr' |
|
risk |
Specifies other |
same structure as 'adr' |
|
contactperson
|
Specifies a patient related |
content (person) The contact person is described by a person element. Note it is expected this information will be available in a centralized personal health record in the future. Until that time it is recommended to provide this information (also) in the Sumehr transaction. |
|
contacthcparty |
Specifies a healthcare |
content (hcparty) The healthcare professional is described by, at least, one hcparty element. This HCParty should contain the INAMI/RIZIV/NIHDI number of the healthcare professional (if available). The role of the contact must be described within the cd element by a value from CD-HCPARTY. Note it is expected this information will be available in a multidisciplinary dossier in the future. Until that time it is recommended to provide this information (also) in the Sumehr transaction. |
|
gmdmanager |
Specifies the manager of the DMG/GMD |
content (hcparty) The GMD manager is described by an hcparty element whose id element must contain a INAMI/RIZIV/NIHDI number. If the GMD owner is a physical person, it also contains a familyname and firstname elements. If the GMD owner is a medical practice, it also contains a name element. The information here should match the GMD manager available via MyCareNet. |
|
patientwill |
Specifies a therapeutic limitation expressed for the patient (specified only if registered). |
content (cd+) [content (text+)] General therapeutic limitations are described using the values of CD-PATIENTWILL. To define any status concerning the resuscitation will of a patient, the table and the values of CD-PATIENTWILL-RES must be used To define any status concerning the hospitalisation will of a patient the table and the values of CD-PATIENTWILL-HOS must be used. |
|
problem
|
Specifies a current diagnosis, problem, complaint, symptom, etc OR a relevant medical antecedent. (depending on the value of the lifecycle)
|
content (text+) [content (cd+)] For each problem, an item is provided. |
|
[beginmoment] Specifies when the problem started. |
||
|
[endmoment] |
||
|
lifecycle Must be used to distinguish between problems (value ‘ active’ from CD-LIFECYCLE) and relevant passive care elements (value ‘inactive’). If needed to describe the absence of a specific problem: the value ‘notpresent’ must be used. |
||
|
If needed to explicitly express there are NO KNOWN relevant medical antecedents, include the following item (nullFlavor 'NA' = not applicable) |
||
| treatment |
Specifies a current treatment OR a relevant therapeutical antecedent. (depending on the value of the lifecycle)
|
content (text+) [content (cd+)] For each treatment, an item is provided. |
|
[beginmoment] Specifies when the treatment started. |
||
|
[endmoment] Specifies when the treatment ended. |
||
|
lifecycle Must be used to distinguish between an active treatment (value ‘ active’ from CD-LIFECYCLE) and a relevant therapeutical antecedent (value ‘inactive’). If needed to describe the absence of a specific treatment: the value ‘notpresent’ must be used. |
||
|
If needed to explicitly express there are NO KNOWN relevant therapeutical antecedents, include the following item (nullFlavor 'NA' = not applicable) <item> <id S="ID-KMEHR" SV="1.0">1</id> <cd S="CD-ITEM" SV="1.10" nullFlavor="NA">treatment</cd> <lifecycle> <cd S="CD-LIFECYCLE" SV="1.0">inactive</cd> </lifecycle> </item> (If it is needed to express the absence of a specific treatment: use the lifecycle value as described supra.)
|
||
|
medication |
Specifies a current patient's medication |
content (text) Textual description of the medication. |
|
[content (medicinalproduct | substanceproduct| coumpoundprescription)] This content should correspond to the last The element medicinalproduct supports the identification the prepacked medicinal product by a code and a textual description (element intendedname) whereas the element substanceproduct describes the INN or substance based cluster prescribed by using codes. The element coumpoundprescription is a textual description of a compound prescription. Please refere to pharmaceutical prescription 2.x to know which CD tables to use for codes. |
||
| [content (cd)]
Value from CD-ATC corresponding to the medication. |
||
| [beginmoment]
Specifies when the treatment starts. |
||
| [endmoment]
Specifies when the treatment ends. |
||
|
All the item elements (such as posology, frequency) described in pharmaceutical prescription 2.x may also be used. |
||
|
vaccine |
Specifies an administrated vaccine |
[content (medicinalproduct | substanceproduct)] This content should correspond to the medicinal product The element medicinalproduct supports the identification the prepacked medicinal product by a code and a textual description (element intendedname) whereas the element substanceproduct describes the INN or substance based cluster prescribed by using codes. Please refere to pharmaceutical prescription 2.x to know which CD tables to use for codes. |
| content (cd+)
Description of indications for the vaccine, using values from CD-VACCINEINDICATION. |
||
| [content (cd)]
Value from CD-ATC corresponding to the vaccine. |
||
| beginmoment
Specifies when the vaccine has been administrated. |
Text
When there is a need to comment on the Sumehr in its entirety, use a text item on the same level as the above items.