On 30/01/2013 08:07, Erik Sundvall wrote: > Hi! > > > On Tue, Jan 29, 2013 at 9:48 PM, Thomas Beale > <thomas.beale at oceaninformatics.com > <mailto:thomas.beale at oceaninformatics.com>> wrote: > > The point isn't for the server to know what is committed to > itself, but for other systems to know where data that they are > sent copies of, was originally committed. > > > That was my understanding too. I think of the system id as an > identifying logical "domain" for versioning where there is a guarantee > that the same version_tree_id (e.g. 3 in 1298745::my.system::3) will > never be reused for another commit. In such a domain there should be > some mechanism to get the latest version and to assign new > non-conflicting version_tree_id's committs in the domain thus has to > be synchronized one way or another so that additional writes with same > ID get detected and stopped.
yes - this is crucial functionality in an openEHR EHR server/service. > > If those conditions are fulfilled it matters less if things are done > on client or server side, but I would guess that it in many cased will > be far easer to implement on the server side than to have a > distributed sync for clients. > > Maybe we need to contemplate capturing both the user device > network id and the server id. > > > In the LiU EEE implementation of the REST architecture described in my > thesis (http://www.imt.liu.se/~erisu/2013/phd/ > <http://www.imt.liu.se/%7Eerisu/2013/phd/>) we use the normal > http-server log to record user agent (device and browser/agent) and > originating IP. The URIs and HTTP redirections are designed in a way > that makes it easy to identify the HTTP-log entry associated with a > certain commit, so if you have a VERSION of an object and have access > to the HTTP-logs you can easily track this for system audit purposes. > Since the dates are included in the audit_details of every openEHR > VERSION it is also easy to figure out which log file to look in if you > happen to have an ordinary log rotation and archiving system. > > I am not sure that it would always be a too good idea to cram > user-agent, IP etc into the CONTRIBUTION or audit_details that are > persisted in the EHR and SOMETIMES transferred in EHR extracts. 1) > Those details may give away unwanted or unneccearily detailed info to > other organisations that you are sharing EHR extracts with. 2) > that would be my concern as well. On the other hand, if you want to track down a doctor who has outsourced his/her job to China <http://www.bbc.co.uk/news/technology-21043693> and EHR modifications are coming from an IP address waaaay outside the intended source domain, we might need some way to do it ;-) - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130130/bd58461a/attachment-0001.html>
