Guided tour

Header and folders

A KMEHR message is composed of a header and at least one folder.

The header describes the sender, the recipient(s) and a few technical status.
The folder gathers the information about one patient.

Patient and transactions

Each folder identifies the subject of care (patient) and contains at least one medical transaction.

The transaction gathers the information reported by one healthcare professional at one given moment. It is a consultation report, a laboratory result, a drug prescription, a discharge letter, ...

The transaction has key attributes: type, author, date and time. A transaction cannot contain another transaction. KMEHR proposes a dictionary of transactions.


A transaction can be organised using optional headings.

For example, a discharge letter could make use of the following headings: patient history, current treatment, clinical findings, technical findings, assessment, proposed treatment, ...

The clinical information can be placed as free text directly within the transaction or within headings.


Headings can be nested to represent chapters and paragraphs.
KMEHR proposes a dictionary of headings.


The clinical information can be described using optional items like allergy, reason for encounter, complaint, risk factor, medication, etc ...

Items can be placed directly within the transaction or within headings. KMEHR proposes a dictionary of items. Their content can be of various data types: free text, number, date, ... or coded value. Items can be further described using elements like: severity, certainty, quantity, unit, ....

Resulting message

As a result of this general architecture, a KMEHR message would look like as follows:

     <patient> ... identification of the patient ... </patient> 
       <item> ... type of encounter ... </item> 
       <item> ... date of encounter ... </item> 
        <item> ... diagnosis ... </item> 
        <item> ... drug delivery ... </item>  
        <item> ... drug prescription ... </item> 

KMEHR levels

Using KMEHR you can transfer the same information as a free text as well as fully coded and structured. For example, a medication can be described using codes for galenic form, route of administration, body site of administration, units of dosage, etc ...

KMEHR proposes a set of dictionaries: transaction types, heading types, item types, severity levels, administration routes, ...
In parallel with those national codes, the structure always supports international or local codes.

We usually refer to 4 levels of standardisation when speaking about a KMEHR message:

  • The first level requires that transactions are coded using the national dictionary. All KMEHR messages must have a coded transaction type. The rest of the information can remain as free text.
  • The second level consists in coding headings.
  • The third level consists in coding items.
  • The fourth level consists in coding the content of the items.

You are free to mix different levels of structuration within a same KMEHR message.

The concept of links is important within KMEHR to support advanced features like:

  • the link to an external object (an image on a web server, another Kmehr message somewhere on the internet),
  • the link to an internal object (an embedded multimedia object within the message itself). This can be used to transfer a Word or a PDF document for example,
  • the order-result communication process,
  • the history of versions of a same message (replacements, cancellation, ...),
  • sophisticated structural links like the POMR concept,
  • ...

This concept is implemented throughout the lnk element. This key element is the most complex of KMEHR specification.