Hi Pablo Sent from my iPad
On 06/02/2013, at 7:55 AM, "pablo pazos" <pazospablo at hotmail.com> wrote: > Hi Sam, reading more about this, it seems FEEDER_AUDIT_DETAILS is more for > copying stuff from non-openEHR systems, > but from your words I tend to think it can be used also as an audit to copy > stuff from openEHR systems. In both cases, > the use case for creating FEEDER_AUDIT_DETAILS might be when importing > records from legacy systems. Is that correct? Yes...if you are importing complete compositions from another EHR system you do not need this as the Audit and contribution details capture all that is required. > > In the other hand, I haven't still a clear idea of what is considered the > *same system* or *same domain* and > what should be the criteria to set a limit for the commit use case. As I > stated on my previous email (maybe it's not so clear), > one system could be considered inside or outside the same domain of the EHR > Server (where stuff sould be committed), > so the AUDIT_DETAILS.system_id could vary depending just on what I consider > to be on the same domain or not. The system ID in audit details is the one that is committing the new composition. Simple, straight forward. > > BTW, I don't know if this is correct, but I consider importing or copying > records from another system a different use case > than commiting compositions for record sharing. May be FEEDER_AUDIT_DETAILS > should be only used for copying/importing > and AUDIT_DETAILS for committing. What do you think? Yes, but if you look for sharing data between openEHR systems on the Wiki it will show how to preserve the information from the original commit. Cheers Sam > > > -- > Kind regards, > Ing. Pablo Pazos Guti?rrez > http://cabolabs.com > > From: sam.heard at oceaninformatics.com > To: openehr-technical at lists.openehr.org > Subject: RE: Questions about commit and AUDIT_DETAILS > Date: Thu, 31 Jan 2013 10:24:27 +0930 > > 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:openehr-technical-bounces at > lists.openehr.org] 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? > > _______________________________________________ > 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/20130206/af96c9bf/attachment-0001.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
