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.
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).