Migration formats
Context
The migration formats aim to define a series of export/import formats enabling medical software to migrate medical content from one software application to another software application without loss of information.
Two types of migration formats can be distinguished
- ‘Software migration formats’ aim to define an export/import format enabling medical software to migrate the complete medical record of one patient from one software application to another software application for the same healthcare actor.
- ‘Patient migration formats’ aim to define an export/import format enabling medical software to export a medical record of one patient from the software application of one healthcare actor to the software application of another healthcare actor.
Both types specialize the KMEHR general message structure in order to fit with their purpose.
Guidelines
Generalities
Each Migration Format file follows the skeleton of a KMEHR message. Some elements must in addition follow the specific rules expressed below.
Basic elements
Id
Beyond the usual Kmehr id which identifies an item withing a Kmehr message, every medical item must mandatory have a local id that identifies the item within a patient record. This specific mechanism is intended to support the identification of duplicated items within the same Kmehr message.
For this, a LOCAL id element is used with the following attributes: SL='MF-ID' and SV='1.0'.
Lnk
Relations between items in the file will be indicated by the lnk element, in conjunction with local ids (items with multiple instances will have the same identifier).
- Multiple links are possible per item.
- The use of the url attribute with the XPath definition is mandatory. This XPath Query must point to the local MF-ID identifier of the element.
Example
<item>
<cd S="ID-KMEHR" SV="1.0">11</cd>
<id SV="5.2.1" S="LOCAL" SL="MF-ID">MED11</id>
<cd S="CD-ITEM" SV="1.3">medication</cd>
<content>
<text L="fr">Medrol 32</text>
</content>
...
<lnk TYPE="isaservicefor" URL="//item[id[@SL="MF-ID" and
.="HCA0001"] ]"/>
</item>
...
<item>
<cd S="ID-KMEHR" SV="1.0">9</cd>
<id SV="1.0" S="LOCAL" SL="MF-ID">HCA0001</id>
<cd S="CD-ITEM" SV="1.3">healthcareapproach</cd>
<content>
<text L="fr">treatment</text>
</content>
...
<lnk TYPE="isapproachfor" URL="//item[id[@SL="MF-ID" and
.="AF6510"] ]"/>
</item>
...
<item>
<cd S="ID-KMEHR" SV="1.0">10</cd>
<id SV="1.0" S="LOCAL" SL="MF-ID">AF6510</id>
<cd S="CD-ITEM" SV="1.3">healthcareelement</cd>
<content>
<cd S="CD-CLINICAL" SV="1.0">10008140</cd>
<cd S="ICPC" SV="2">R99</cd>
<cd S="ICD" SV="10">J80</cd>
</content>
<content>
<text L="fr">ards</text>
</content>
...
</item>
Header
Besides the usual header definition, the header must respect the following specific rules.
| standard | The standard element must contain the element ‘specialisation’ identifying the migration format type. |
| sender | The sender must at least contain an hcparty element describing the software. It should also contain a hcparty element corresponding to the end-user performing the export operation. |
| recipient | The recipient is not relevant. It may simply mention the name of the format (expressed within an hcparty element). |
Confidentiality
Where appropriate in 'software migration format' messages, confidential items can be marked with an element ‘confidentiality’ indicating that this item is only available for the ‘hcparty’ defined in the ‘confidentiality’ element. The 'software migration format' accepts only one hcparty in this element.
The 'patient migration formats' do not support 'confidentiality' information.
Patient
The patient element mainly follows the standard definition except for the following two points.
| id | The standard ID-KMEHR must be used if available. The software specific identifier must be exported as a 'LOCAL' id element, with the following attributes: SL='MF-ID' and SV='1.0'. |
| recorddatetime | This element is mandatory. It contains the date and time of the last update of the patient record within the software. |
Folders
- Software Migration File formats can concern more than one patient. Consequently, it is possible to have multiple folders in the message.
- Patient migration File formats can only contain one patient and folder per message.