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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130129/0e36336f/attachment.html>
