Hi Pablo
One simple thing ? the FEEDER_AUDIT_DETAILS is there to let you record when something in this composition came from somewhere else. The AUDIT_DETAILs are what happened here. You do not need to record FEEDER_AUDIT but it can be helpful. You can log it if you want but then it is not clear to others where this came from. You need more technical input on the rest. Cheers, Sam From: openEHR-technical [mailto:[email protected]] On Behalf Of pablo pazos Sent: Thursday, 31 January 2013 10:03 AM To: openeh technical Subject: RE: Questions about commit and AUDIT_DETAILS Hi guys, thanks fo your answers, Now it is more clear for me: what openEHR defines is an inter-system audit, and what I tried to do is to have an intra-system audit (between subsystems of the same system). There's only one confusion I need to clarify: isn't the FEEDER_AUDIT_DETAILS designed to record information of the source for record copying between EHR domains/environments? e.g. having FEEDER_AUDIT_DETAILS.system_id == system where the composition was first committed. If so, why the AUDIT_DETAILS.system_id is meant to record the same information? Or better said, is there any difference between FEEDER_AUDIT_DETAILS.system_id and AUDIT_DETAILS.system_id? The problem I see is we could use the word "system" for many purposes, and other words like "domain" or "environment" could descrive better what is "inter" or "intra". In my case the EHR Server and the EMR apps are each one an independend system, but together they also are a system. If the communication is intra or inter system only depends of who controls each subsystem (EHR Server or the EMR apps). In any case, I need to record an audit of the commit to the EHR Server. Consider this: * If there is a monolitic EMR App that has it's own composition repo (commits data to itself), it could send a copy of the compositions to the EHR Server to share the records with other systems. * If the Org1 owns the EMR and the Org2 owns the EHR Server, then the system_id == EMR, but if Org2 owns an EMR2 system that commits records to the EHR Server, then for commits from EMR2 the system_id == Org2 (an environment or domain id). * Is this correct from the openEHR purpose for the AUDIT_DETAILS.system_id? About the question asked by Thomas, I don't think we need to record a "device id". In my case a client (i.e. an EMR App) is also a Client/Server system (my apps are all web apps). So, we have a communication architecture like this: EHR Server (server) <=> EHR Server (client), EMR (server) <=> EMR (client) * EHR Server (server): server side of the EHR Server web app * EHR Server (client): client side of the EHR Server, where admins manage stuff using a web GUI (web browser, device) * EMR (server): server side of the EMR, storage, logic, etc. * EMR (client): client side of the EMR, where end users inupt and visualize data (web browser, device) * <=>: HTTP communication (the EHR Server (server) has communication with the EMR (server) for commit and query) I don't think the EMR (client) id (the device where the end user is accessing the EMR(server) from a browser) it's needed for audit at the application level (maybe it's needed as a low level audit for sys admins). In my case I need the id of the EMR (server) because it commits stuff to the EHR Server (server), it doesn't matter if the EMR is part of the same domain of the EHR Server or not. Also consider that both of those XXX (server) has fixed IPs, but the EMR (client) could run from any device, using dynamic IPs, but what is really needed is the id of the logged user instead of the device id. In the case above, do you think openEHR audit structures should support the record of the EMR (server) id when commiting stuff to the server or I should create my own audit structures to record that information? Thanks a lot! -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com <http://cabolabs.com/es/home> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130131/9710cab6/attachment-0001.html>
