In openEHR all top-level objects are versionable, that is:
When one of those objects is created, a VERSIONED_OBJECT wrapper is created for it. The VERSIONED_OBJECT is the container for all the VERSIONs of that specific object. So when the object is created, it also adds one VERSION to the VERSIONED_OBJECT, which is the first version of that object, and the VERSION contains the object itself.
Each VERSION has it's own identifier, which is an OBJECT_VERSION_ID from the openEHR RM. That identifier consists of three elements:
- object_id it's the containing VERSIONED_OBJECT ID
- creating_system_id this is kind of an identifier or namespace for the system that created the object version
- version_tree_id is a semantic versioning (semver) identifier like 1.0.2
Versioning in Atomik
Atomik follows the openEHR model for versioning, so it supports VERSIONED_OBJECT, VERSION and all the versionable classes that inherit from LOCATABLE. The only consideration is that the version_tree_id is lineal, not a full semver ID. So you will see version IDs like this in Atomik:
- Create: 1b2d2be2-24ff-48da-9ff0-e835ce36b80f::ATOMIK_EMR::1
- Modification: 1b2d2be2-24ff-48da-9ff0-e835ce36b80f::ATOMIK_EMR::2
- Modification: 1b2d2be2-24ff-48da-9ff0-e835ce36b80f::ATOMIK_EMR::3
Note that all those three version IDs reference the same VERSIONED_OBJECT ID 1b2d2be2-24ff-48da-9ff0-e835ce36b80f.
Versioning and the REST API
The openEHR REST API there are GET /xxx endpoints that will receive the full OBJECT_VERSION_ID as a parameter and retrieve that specific version if it exists, or the VERSIONED_OBJECT ID and retrieve the last VERSION from it.