Thanks Heath.
Can others comment on this to have a unified view and specific definition of 
the system id?
I think i have 3 different definitions right now, and one contradicts the other 
:)
Maybe the system_id hasn't a specific definition so might be used differently 
by different implementations. (?)
In the end is just an id, does it matter if it's attached to a system or 
service or if it's something related to an organization or if it's a host 
domain?
What do you think?

-- 
Kind regards,
Eng. Pablo Pazos Guti?rrez
http://cabolabs.com

From: heath.fran...@oceaninformatics.com
To: openehr-technical at lists.openehr.org
Subject: RE: Small question about commits and AUDIT_DETAILS.system_id
Date: Sun, 7 Sep 2014 23:25:43 +0000








Hi Pablo,

No I don't agree. The point I tried to explain was that the system is the EHR 
repository, not an application. So if there is one or more applications using a 
repository at one or more organisations the is just one system id.



In an Australian jurisdiction I have a repository that is used by multiple 
instances of 5 applications at 100 diff healthcare facilities managed by gov't 
and non gov't organisations. There is only one system id for the repository.



Heath








-------- Original Message --------

Subject: RE: Small question about commits and AUDIT_DETAILS.system_id

From: pablo pazos <pazospa...@hotmail.com>

To: openeh technical <openehr-technical at lists.openehr.org>

CC: 




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?



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





Date: Thu, 21 Aug 2014 09:47:35 +0100

From: thomas.be...@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/20140908/655d1448/attachment.html>

Reply via email to