System id of moved compositions not retained

[steveFuturePerfect]

Before reporting an issue

• I have searched existing issues
• I have reproduced the issue with the latest release

Environment information

ehrbase_version: 0.27.0-SNAPSHOT
openehr_sdk_version: 1.27.0-SNAPSHOT
archie_version: 3.0.0
jvm_version: Eclipse Adoptium 17.0.6+10
os_version: Linux amd64 5.4.0-1105-azure
postgres_version: PostgreSQL 11.18, compiled by Visual C++ build 1800, 64-bit

Steps to reproduce

Retrieve composition from non-Ehrbase CDR.
The UID is as follows, with the creating system id:

_"uid": {
"type": "OBJECT_VERSION_ID",
"value": "0cfe88b3-9c66-4c63-95dd-e0d7553173f9::example:1"
}

Submit the composition as is, to the EHRBase CDR

Expected behavior

The EHRBase CDR should respond with a 200 successful response, and the original creating system id retained in the Ehrbase CDR.

Actual result

Submitting the composition as is, the EHRBase CDR responds with an error:

"responseData": {
"error": "Precondition Failed",
"message": "Mismatch of creating_system_id: default !=: local.ehrbase.org"
}

Further information

The value of the non-ehrbase composition's UID needs to be manually updated to the ehrbase system id, before the composition can be successfully submitted:

_"uid": {
"type": "OBJECT_VERSION_ID",
"value": "0cfe88b3-9c66-4c63-95dd-e0d7553173f9::local.ehrbase.org::1"
}

Section 6.4.4 Moving Version Containers of the openEhr specification seems to indicate that the system id should be retained and taken as is.

[stefanspiska]

@steveFuturePerfect
ehrbase dos not yet support multiple system and will not do in near future

cc: @vidi42

[simonFuturePerfect]

@birgerhaarbrandt doesn't this contravene the standard? As openEHR records are imported from other CDR vendors we are losing the information of where those openEHR records came from ?

[stefanspiska]

@steveFuturePerfect

you can and should set the systemId of ehrbase via the server.nodename spring property.

[vmueller-vg]

@simonFuturePerfect @steveFuturePerfect Importing versions from other openEHR systems is part of the Semantics in Distributed Systems part of the RM specification. Ehrbase does not support the full scope of the openEHR spec at the moment and this is a part that is currently not implemented.

This is how the importing process is specified:
According to the spec the copy operation only preserves the object_id part and not the system. The copied ORIGINAL_VERSION will be imported as an IMPORTED_VERSION with the same UID, but the system identifier of the importing system. The unmodified input will be saved in IMPORTED_VERSION.item and the active COMPOSITION data in IMPORTED_VERSION.data. This means that when you load the composition via the GET composition endpoint you will get what is stored in IMPORTED_VERSION.data and this will have the OBJECT_VERSION_ID of the IMPORTED_VERSION and thus the system value of the importing system. To retrieve the source ORIGINAL_VERSION one would have to use the GET endpoint for getting the VERSION and look in IMPORTED_VERSION.item.

The important info here is that the COMPOSITION is supposed to be identified across systems just by its uid and the system part of the OBJECT_VERSION_ID provides information on which system is managing a specific VERSION of the COMPOSITION

This means that even after we properly implement importing ORIGINAL_VERSIONs from other systems, the composition you will receive through AQL or the GET endpoint will still have the system id configured for the importing ehrbase instance.

Also as mentioned by @stefanspiska one should not use the default system id for non testing purposes. since it is supposed to properly identify the actual system responsible for managing the VERSION identified by an OBJECT_VERSION_ID.