Data versioning

In openEHR all top-level objects are versionable, that is:

  • EHR_STATUS
  • FOLDER
  • COMPOSITION
  • PERSON
  • ORGANISATION
  • GROUP
  • AGENT
  • PARTY_RELATIONSHIP

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.

openEHR Versioning Structures

Each VERSION has it's own identifier, which is an OBJECT_VERSION_ID from the openEHR RM. That identifier consists of three elements:

  1. object_id it's the containing VERSIONED_OBJECT ID
  2. creating_system_id this is kind of an identifier or namespace for the system that created the object version
  3. 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.