On 05-09-14 19:06, pablo pazos wrote:
> Hi! Thanks for your answers.
>
> It is a little tricky but from Thomas comments, I think that the
> "system" is not a technical term, but is more related to an
> organizational term. For example, if I use the same system / service
> to hold EHRs from 2 different hospitals, I really have 2 system ids
> instead of one. So the system_id doesn't depend on the technical
> architecture, but depends on how the business is organized. Is that
> correct?
I must admit, that this is confusing to me too.
And I have some more confusing.
That is the ID of a VERSION, which is:
Unique identifier of this version, containing owner_id,
creating_system_id and version_tree_id.
So, if you don't know the creating_system_id of a specific version, you
are not able to find it.
And can there be more same-versions of the same dataset with the same ID
but on different environments?
It would be branching, wouldn't it?
That would be the right solution, the same as with sourcecode, if two
people work on the same checkout they need to go branching.
So I put the Kernel_ID (which is in the config file) in the
creating_system_id, so it stays the same, even if it is clustered, or
moved to another machine.
I can understand if there is a client systemId in the Contribution, or
in the Audit, but it seems, there isn't.
You want to know who put the data there, you want to know when it
happened, so, why should not you want to know where it happened?
I therefor understood the System_id as the machine where the commit
happened, maybe a cell-phone, maybe a device, whatever.
Bert
>
> Again, the description from the specs doesn't help to understand this
> ("Identity of the system where the change was committed", so it
> depends on what a "system" is for us).
>
> For the next version of the specs I think we can update that
> description and maybe give a couple of examples.
>
> What do you think?
>
> --
> Kind regards,
> Eng. Pablo Pazos Guti?rrez
> http://cabolabs.com <http://cabolabs.com/es/home>
>
> ------------------------------------------------------------------------
> Date: Thu, 21 Aug 2014 09:47:35 +0100
> From: thomas.beale at oceaninformatics.com
> To: openehr-technical at lists.openehr.org
> Subject: Re: Small question about commits and AUDIT_DETAILS.system_id
>
>
> Heath,
>
> this is correct, you were not wrong for 10 y ;-)
>
> We don't record the name or type or id of the application, and I am
> not sure even now if that would be of any use. I can't see that it
> would be. The system_id is for exactly the purpose that Heath as
> explained here.
>
> - thomas
>
>
> On 21/08/2014 00:27, Heath Frankel wrote:
>
> Hi Thomas & Pablo,
>
> I am finding the words in the this discussion ambiguous, and the
> specification does help to clarify. Here is my interpretation of
> AUDIT_DETAILS.system_id.
>
> I have an EHR service, which is used by two different application,
> one is a hospital system and another a mobile application that may
> not be related to the hospital system but share the same EHR
> service. When the hospital system and mobile application commits
> something they are using the same system_id, the system_id of the
> EHR service. If there is an exchange of data between this EHR
> service and another organisations EHR service via an EHR extract,
> the system ID will be used in the other organisations EHR service
> to identify that the commit was performed in the original
> organisations system_id.
>
> Therefore, the system_id identifies the system that is assigning
> version identifiers in the EHR repository, i.e. the
> AUDIT_DETAILS.system_id matches the system_id component of the
> version.uid. This is important for distributed versioning.
>
> So in Pablo?s scenario, it is one system of multiple components
> with multiple components sharing the same EHR service, the mobile
> and the EMR would use the same system_id.
>
> Has my interpretation been wrong for 10 years? If so, then we need
> clarity added to the specification.
>
>
>
> _______________________________________________ openEHR-technical
> mailing list openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140905/9e6ddc33/attachment.html>
