Hi Erik, I agree and I intended to say in my other response that I think this level of audit trail could be left to individual systems just like you use http-server log and I use an IHE ATNA implementation. Although it may be desirable to standardise the data model of the logs I see no reason to reinvent this in openEHR other than defining some event IDs and profiling the required data and it'd format for common events such as contributions, extracts and queries. Heath On Jan 30, 2013 7:05 PM, "Erik Sundvall" <erik.sundvall at liu.se> wrote:
> Ooops, accidentally sent unfinished mail... see additions below. > > On Wed, Jan 30, 2013 at 9:07 AM, Erik Sundvall <erik.sundvall at liu.se>wrote: > >> Hi! >> >> On Tue, Jan 29, 2013 at 9:48 PM, Thomas Beale < >> 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. >> >> 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/) 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) >> > > Here is a more complete version of the last part: > > 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 unnecessarily detailed info to > other organisations that you are sharing EHR extracts with (for example > hints about your internal ip network structure, operating systems and > hardware devices) > > 2) If we would be sharing detailed log data outside originating systems, > then we would need to agree on format and what to record. That could be > _very_ different for different systems. > > I don't say providing slots for such things in the RM would be terribly > bad, I just want to say that we should think twice and first have good use > case descriptions pointing out why existing mechanisms (including possible > uses of feeder_audit) combined with other system logs would not be > sufficient. > > Best regards, > Erik Sundvall > erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-28673 > >> >> > > _______________________________________________ > 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/20130131/ea334fc6/attachment-0001.html>
