I believe that the client application/machine should be recorded in a separate level audit log, something like the ihe atna. The contribution audit is intended to support thr versioning control in a distributed environment of eHR systems do when compositions are exchanged between systems we know were it was originally committed. There are many auditable event that occur in an eHR system that are not supported by thr contribution audit such as reads which require a separate audit log anyway, this is more at the service layer than in the EHR. Heath On Jan 30, 2013 7:18 AM, "Thomas Beale" <thomas.beale at oceaninformatics.com> wrote:
> On 23/01/2013 15:59, pablo pazos wrote: > > Hi Bert / Sam, > > Thanks for your answers. > > The idea is that the new COMPOSITION will be available to the EHR SYSTEM > when it arrives to the SERVER. I understand the difference between > finishing a COMPOSITION (e.g. signing and setting the end time) and > committing it to be available to the system (e.g. other CLIENTs could > access the new COMPOSITION). > > I agree with Bert that AUDIT_DETAILS.system_id should be "the system on > which the author is working/committing, normally not the server.", but IMO > this is the opposite to the current definition of that field. > > Moreover, if that field is set to the SERVER's ID it will be redundant, > because the SERVER knows that the COMPOSITION was committed to itself, but > what doesn't knows is the ID of the system where the COMSPOTION was > authored (e.g. the SERVER could identify the CLIENT by it's IP, but 1. IP's > change, 2. there could be a middleware so the IP received by the SERVER > could not be the IP of the CLIENT). > > What do you think? > > > 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. If this information is not available, then that data, > when sent to another place doesn't indicate where it was committed. If the > audit trail includes some machine name of a client device, it's no help on > its own. Maybe we need to contemplate capturing both the user device > network id and the server id. > > It depends on what we think these ids are needed for. The server id is > easy - when informatoin is shared, you want to know where it was originally > committed (which might not be the same as the machine or service you got it > from today) so that further requests could be made there. The utility of > the client device id is probably only inside the original environment, but > I am not sure how it would be used. I would be interested in Pablo & Bert's > ideas... > > - thomas > > > _______________________________________________ > 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/20130130/aa62590d/attachment.html>
