AUDIT_DETAILS.system_id‏ semantics not well defined

Description

The definition of the AUDIT_DETAILS.system_id is not 100% clear: "Identity of the system where the change was committed. Ideally this is a machine- and human-processable identifier, but it may not be".

Some implementers use the system_id of the commit service/server (a technical id), others use this as a system id more at a logical / organizational level (for multi-tenant systems maybe the same commit service / server is used as backend of different systems and each of those systems client + backend have a different system id).
In a distributed system, maybe a set of clients + backend servers have only one system id, like in a nation-wide or regional EHR system.
Also about the id itself, Thomas mentioned that was thought to be something like a URI, but a lot of implementations are using UIDs.

So, the definition leads to different interpretations and identification schemas. It might be good to clarify the specification and define a specific id schema like using just URIs or UIDs or something else. I would prefer to use random UUIDs because those can be generated in a distributed way and URIs might need some level of coordination / centralization.

For context: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2014-August/008468.html

Environment

None

Activity

Show:
Sebastian Iancu
April 25, 2018, 7:01 PM

Indeed there is a small room for interpretations here and there in specifications about ids. I fully support Heath's interpretation (see mail link above) what 'system_id' represents. Perhaps git-people might be confused by "where the change was committed" as that is not the same as the 'repository', but I have no idea how can we formulate that part differently - perhaps "Identity of the system (repository) where the change ..." ?

This issue is also related to discussions we had in SEC during Aug-Sep 2017 about what do we understand when we talk about SYSTEMs and their ids. Perhaps what we are missing is a formal definition of this SYSTEM type, that 'owns' the EHRs or the VERSIONED_PARTYs in Demographics.

In practice, the way we have this implemented is that our SYSTEMs have (short) unique ids, something like '9EEYOUEBAKWS8SK1', which are used in AUDIT_DETAILS.system_id, OBJECT_VERSION_ID.creating_system_id, EHR.system_id, VERSIONED_OBJECT.owner_id, VERSION.
Perhaps we should mention in specification that these 'system_id' values should be the same as they all normally refer to the same things (if you agree with my interpretation).

Reporter

Pablo Pazos

Components

Affects versions

Priority

Minor
Configure