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
...@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
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
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-boun...@lists.openehr.org]
On Behalf Of pablo pazos
Sent: Thursday, 31 January 2013 10:03 AM
To: openeh technical
Subject: RE: Questions about
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
Op 29-1-2013 21:48, Thomas Beale schreef:
I would be interested in Pablo Bert's ideas...
For my idea it serves to help identify the machine were the committer
committed the dataset. It is hard to identify a machine absolutely, but
combined with other facts, it can be a helpful hint.
In a
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.
On 30/01/2013 08:07, Erik Sundvall wrote:
Hi!
On Tue, Jan 29, 2013 at 9:48 PM, Thomas Beale
thomas.beale at oceaninformatics.com
mailto: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
On 01/30/2013 09:07 AM, Erik Sundvall wrote:
Maybe we need to contemplate capturing both the user device
network id and the server id.
My opinion is to leave that to the organization which uses the Kernel.
Laws and organization-requirements can differ, and I think it is not for
the
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
Hi all, this question is related t oa previous thread:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012-November/007392.html
I just want to check a couple of things to validate my implementation of an
openEHR Server.
The definition of AUDIT_DETAILS.system_id is:
On 01/23/2013 06:11 AM, pablo pazos wrote:
The definition of AUDIT_DETAILS.system_id is: Identity of the system
where the change was committed. Ideally this is a machine- and
human-processable identifier, but it may not be..
Let's say I have a CLIENT where COMPOSITIONS are created, and a
[mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Bert Verhees
Sent: Wednesday, 23 January 2013 8:50 PM
To: openehr-technical at lists.openehr.org
Subject: Re: Questions about commit and AUDIT_DETAILS
On 01/23/2013 06:11 AM, pablo pazos wrote:
The definition
On 01/23/2013 02:05 PM, Sam Heard wrote:
The commit time is the time that the author committed it to the system.
I think, when this is the case, that the system-ID must be the system on
which the author is working/committing, normally not the server.
The server would not make sense.
What one
On 23/01/2013 05:11, pablo pazos wrote:
Hi all, this question is related t oa previous thread:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2012-November/007392.html
I just want to check a couple of things to validate my implementation
of an openEHR Server.
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
Hi Thomas,
The original idea was that a logical EHR service id would be used. A
'client id' is likely to be meaningless and untrackable. The id is
only useful if it is relatively permanent, and future information
requests can be made to that logical EHR system. It would also be
17 matches
Mail list logo
