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.

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

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.

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 to a an adverse drug reaction.	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. Recommended codifications: IBUI,ICPC-2, ICD-10.
allergy	Specifies a risk relative to an allergy.	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 risk factors.	same structure as 'adr'
contactperson An additional cd element with a value from CD-CONTACT-PERSON may be used to describe the link with the patient.	Specifies a patient related person (family, etc ...)	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 professional contact.	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. This item contains at least a textual content with the label of the risk (except when needed to explicitly express there are NO KNOWN relevant medical antecedents cfr. infra). It should also contain one cd elements content corresponding to the available codifications. Recommended codifications:IBUI,ICPC-2, ICD-10.
		[beginmoment] Specifies when the problem started.
		[endmoment] Specifies when the problem ended.
		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) <item> <id S="ID-KMEHR" SV="1.0">1</id> <cd S="CD-ITEM" SV="1.10" nullFlavor="NA">problem</cd> <lifecycle> <cd S="CD-LIFECYCLE" SV="1.0">inactive</cd> </lifecycle> </item> (If it is needed to express the absence of a specific problem: use the lifecycle value as described supra.)
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. This item contains at least a textual content with the label of the risk (except when needed to explicitly express there are NO KNOWN relevant therapeutical antecedents cfr. infra). It should also contain one cd elements content corresponding to the available codifications. Recommended codifications:IBUI,ICPC-2, ICD-10.
		[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 medicinal product or substance prescribed for this medication (when available). 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 administrated for this vaccine (when available) 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.

Examples

Name	XML
sumehr_2_0_basic	xml
sumehr_2_0_no_antecedents_and_patientwillhosp	xml