Questions about commit and AUDIT_DETAILS
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
Questions about commit and AUDIT_DETAILS
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? In the other hand, I haven't still a clear idea of what is considered the *same system* or *same domain* andwhat 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. BTW, I don't know if this is correct, but I consider importing or copying records from another system a different use casethan commiting compositions for record sharing. May be FEEDER_AUDIT_DETAILS should be only used for copying/importingand AUDIT_DETAILS for committing. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com From: sam.he...@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 appEHR 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
Questions about commit and AUDIT_DETAILS
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 reinvent this in openEHR other than defining some event IDs and profiling the required data and it'd format for common events such as contributions, extracts and queries. Heath On Jan 30, 2013 7:05 PM, Erik Sundvall erik.sundvall at liu.se wrote: Ooops, accidentally sent unfinished mail... see additions below. On Wed, Jan 30, 2013 at 9:07 AM, Erik Sundvall erik.sundvall at liu.sewrote: 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. I think of the system id as an identifying logical domain for versioning where there is a guarantee that the same version_tree_id (e.g. 3 in 1298745::my.system::3) will never be reused for another commit. In such a domain there should be some mechanism to get the latest version and to assign new non-conflicting version_tree_id's committs in the domain thus has to be synchronized one way or another so that additional writes with same ID get detected and stopped. If those conditions are fulfilled it matters less if things are done on client or server side, but I would guess that it in many cased will be far easer to implement on the server side than to have a distributed sync for clients. Maybe we need to contemplate capturing both the user device network id and the server id. In the LiU EEE implementation of the REST architecture described in my thesis (http://www.imt.liu.se/~erisu/2013/phd/) we use the normal http-server log to record user agent (device and browser/agent) and originating IP. The URIs and HTTP redirections are designed in a way that makes it easy to identify the HTTP-log entry associated with a certain commit, so if you have a VERSION of an object and have access to the HTTP-logs you can easily track this for system audit purposes. Since the dates are included in the audit_details of every openEHR VERSION it is also easy to figure out which log file to look in if you happen to have an ordinary log rotation and archiving system. I am not sure that it would always be a too good idea to cram user-agent, IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR and SOMETIMES transferred in EHR extracts. 1) Those details may give away unwanted or unneccearily detailed info to other organisations that you are sharing EHR extracts with. 2) Here is a more complete version of the last part: I am not sure that it would always be a too good idea to cram user-agent, IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR and SOMETIMES transferred in EHR extracts: 1) Those details may give away unwanted or unnecessarily detailed info to other organisations that you are sharing EHR extracts with (for example hints about your internal ip network structure, operating systems and hardware devices) 2) If we would be sharing detailed log data outside originating systems, then we would need to agree on format and what to record. That could be _very_ different for different systems. I don't say providing slots for such things in the RM would be terribly bad, I just want to say that we should think twice and first have good use case descriptions pointing out why existing mechanisms (including possible uses of feeder_audit) combined with other system logs would not be sufficient. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-28673 ___ 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/20130131/ea334fc6/attachment-0001.html
Questions about commit and AUDIT_DETAILS
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-boun...@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? 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
Questions about commit and AUDIT_DETAILS
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
Questions about commit and AUDIT_DETAILS
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 Microsoft environment it is possible to identify a machine, but only if the kernel communicates with the Microsoft-server-services. Some UNIX/Linux configurations offer similar identification-services. It is not a service, the kernel processes this without interaction to the user. Querying these data only happens in case of a inspection/inquiry. Querying should be implemented as a service. I have implemented the audit-details-storage. The kernel retrieves the information, and as kernel maintainer, I have a simple dataset structure to store it in. I leave the discussion what it should be to others. It is stored in a separate database-pointer, but I haven't yet implemented the query-service for this. It is on the TO-DO list. --- Thinking about this, I was in discussion with a American physician, a few weeks ago, and I explained to them the audit-details, and the versioning of datasets. She was shocked, became a bit angry, she could not understand why a physician should invest for system-functionality which could serve to get them sued in case of malfunctioning. My argument that it could save them, it could also be used to proof that a complainer is wrong, did not make any difference. It was not only that she had a strong opinion, she became emotional. I hadn't expected that, because in the Netherlands every physician thinks that is completely normal to store audit-information. Maybe a good thing to remember when doing business with Americans :-) Bert
Questions about commit and AUDIT_DETAILS
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. I think of the system id as an identifying logical domain for versioning where there is a guarantee that the same version_tree_id (e.g. 3 in 1298745::my.system::3) will never be reused for another commit. In such a domain there should be some mechanism to get the latest version and to assign new non-conflicting version_tree_id's committs in the domain thus has to be synchronized one way or another so that additional writes with same ID get detected and stopped. If those conditions are fulfilled it matters less if things are done on client or server side, but I would guess that it in many cased will be far easer to implement on the server side than to have a distributed sync for clients. Maybe we need to contemplate capturing both the user device network id and the server id. In the LiU EEE implementation of the REST architecture described in my thesis (http://www.imt.liu.se/~erisu/2013/phd/) we use the normal http-server log to record user agent (device and browser/agent) and originating IP. The URIs and HTTP redirections are designed in a way that makes it easy to identify the HTTP-log entry associated with a certain commit, so if you have a VERSION of an object and have access to the HTTP-logs you can easily track this for system audit purposes. Since the dates are included in the audit_details of every openEHR VERSION it is also easy to figure out which log file to look in if you happen to have an ordinary log rotation and archiving system. I am not sure that it would always be a too good idea to cram user-agent, IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR and SOMETIMES transferred in EHR extracts. 1) Those details may give away unwanted or unneccearily detailed info to other organisations that you are sharing EHR extracts with. 2) Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130130/c5fecf9b/attachment.html
Questions about commit and AUDIT_DETAILS
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 where data that they are sent copies of, was originally committed. That was my understanding too. I think of the system id as an identifying logical domain for versioning where there is a guarantee that the same version_tree_id (e.g. 3 in 1298745::my.system::3) will never be reused for another commit. In such a domain there should be some mechanism to get the latest version and to assign new non-conflicting version_tree_id's committs in the domain thus has to be synchronized one way or another so that additional writes with same ID get detected and stopped. yes - this is crucial functionality in an openEHR EHR server/service. If those conditions are fulfilled it matters less if things are done on client or server side, but I would guess that it in many cased will be far easer to implement on the server side than to have a distributed sync for clients. Maybe we need to contemplate capturing both the user device network id and the server id. In the LiU EEE implementation of the REST architecture described in my thesis (http://www.imt.liu.se/~erisu/2013/phd/ http://www.imt.liu.se/%7Eerisu/2013/phd/) we use the normal http-server log to record user agent (device and browser/agent) and originating IP. The URIs and HTTP redirections are designed in a way that makes it easy to identify the HTTP-log entry associated with a certain commit, so if you have a VERSION of an object and have access to the HTTP-logs you can easily track this for system audit purposes. Since the dates are included in the audit_details of every openEHR VERSION it is also easy to figure out which log file to look in if you happen to have an ordinary log rotation and archiving system. I am not sure that it would always be a too good idea to cram user-agent, IP etc into the CONTRIBUTION or audit_details that are persisted in the EHR and SOMETIMES transferred in EHR extracts. 1) Those details may give away unwanted or unneccearily detailed info to other organisations that you are sharing EHR extracts with. 2) that would be my concern as well. On the other hand, if you want to track down a doctor who has outsourced his/her job to China http://www.bbc.co.uk/news/technology-21043693 and EHR modifications are coming from an IP address wy outside the intended source domain, we might need some way to do it ;-) - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130130/bd58461a/attachment-0001.html
Questions about commit and AUDIT_DETAILS
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 kernel-builder, or the OpenEHR-specification to impose ideas which will not work in all situations. That is why I thought of that American physician with whom I had that bit heated discussion. If you want a wide acceptance of OpenEHR, you should take care of making it wide acceptable and always take care not to get isolated on an ivory tower. What needs to be specified is a generic, general usable space/datastructure to leave the audit-data. t should have some required minimum set, if used, f.e. timestamps, but I leave this for further contemplation. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130130/abc33d5e/attachment.html
Questions about commit and AUDIT_DETAILS
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
Questions about commit and AUDIT_DETAILS
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: 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 SERVER where COMPOSITIONS are committed by the CLIENT.If I understand this correctly, AUDIT_DETAILS.system_id would be the SERVER ID. If so, where can I specify the CLIENT's ID (the system that committed the COMPOSITION). This information is needed to have the complete log of the commit. In the other hand, where COMPOSITIONs are imported from the CLIENT, the FEEDER_AUDIT_DETAILS.system_id is the Identifier of the system which handled the information item, so it is the CLIENT's ID. If this is right, why do we have different definitions for X.system_id for different scenarios of sending information from a CLIENT to a SERVER (e.g. the 1st case is the SERVER's ID, on the 2nd is the CLIENT's ID). Thanks a lot. BTW, after the validation of my implementation, I'll release the code under Apache 2.0 License. so everyone will be welcome to contribute. -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/856d02d7/attachment.html
Questions about commit and AUDIT_DETAILS
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 SERVER where COMPOSITIONS are committed by the CLIENT. I understood this as not technically committed (that is the database-server) but conceptually committed, and that is the machine on which the client-user is typing/clicking. The client-user gives order to commit a dataset. This is different if there is an automatic feed of data, in that case, the feeder-audit is used. regards Bert Verhees -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/d14a64cb/attachment.html
Questions about commit and AUDIT_DETAILS
Hi Bert I am sure the technical people will respond but it is a good question. The commit time is the time that the author committed it to the system. I believe this is usually generated on the server to ensure accuracy. When there is a system with considerable delay between the clinician saving to the record and the record being stored in the EHR repository, I would use the Finish Time of the event context for the clinical commit time and leave the commit time to show when this information became visible as part of the health record. Cheers, Sam From: openEHR-technical [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 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 SERVER where COMPOSITIONS are committed by the CLIENT. I understood this as not technically committed (that is the database-server) but conceptually committed, and that is the machine on which the client-user is typing/clicking. The client-user gives order to commit a dataset. This is different if there is an automatic feed of data, in that case, the feeder-audit is used. regards Bert Verhees -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/b06dd73d/attachment.html
Questions about commit and AUDIT_DETAILS
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 wants to know is where the author was, when he committed the dataset, and the client-machine, if possible together with IP-address (+NAT-network) he was working on can be a good indication. If it is in his study at home, or on the airport, the patient is probably not present. Bert -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/51664ce8/attachment.html
Questions about commit and AUDIT_DETAILS
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. 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 SERVER where COMPOSITIONS are committed by the CLIENT. If I understand this correctly, AUDIT_DETAILS.system_id would be the SERVER ID. If so, where can I specify the CLIENT's ID (the system that committed the COMPOSITION). This information is needed to have the complete log of the commit. In the other hand, where COMPOSITIONs are imported from the CLIENT, the FEEDER_AUDIT_DETAILS.system_id is the Identifier of the system which handled the information item, so it is the CLIENT's ID. If this is right, why do we have different definitions for X.system_id for different scenarios of sending information from a CLIENT to a SERVER (e.g. the 1st case is the SERVER's ID, on the 2nd is the CLIENT's ID). Hi Pablo, 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 the id of the system that other users who could see this information were using, and where medico-legal investigations take place. In a more cloud-based world, it might not seem so clear, because numerous organisations might be committing to a physical service that supports multi-tenanting. However, in either case, it should be something like a domain name of an EHR service that is understood to be the legal EHR repository facility of the organisation in which the clinician works. There might be an argument for having another field for 'client device type' (e.g. phone, iPad etc). - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/deb339a5/attachment-0001.html
Questions about commit and AUDIT_DETAILS
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? -- Kind regards, Ing. Pablo Pazos Guti?rrez http://cabolabs.com -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/8885e0bd/attachment.html
Questions about commit and AUDIT_DETAILS
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 the id of the system that other users who could see this information were using, and where medico-legal investigations take place. I think that depends on the architecture of each system. Let me explain my architecture design: One EHR Server: handles composition persistence, has commit and query services.Many EMR Systems/Apps: handles data input, commit client, query client. Functionality:The new COMPOSITIONs are available to the EHR SYSTEM when an EMR System commits it to the EHR Server.Each EMR System has a unique ID that is permanent, at least for data input. (I want to know who changes the EHR).For data visualization, a unique ID or a permanent one is not required. (login information would suffice to know who is accessing the EHR). If there is a Paediatric EMR (PEMR) and an Emergency EMR (EEMR), from the PEMR a clinician could see records committed from the EEMR, and he/she may want to know that a record was created on the Emergency System. I know this can be addressd by using EVENT_CONTEXT.location setting, but for medico-legal issues it will be necessary to have track of the record from the authoring system to the persistent storage, IMO that should be done using audit trail data from AUDIT_DETAILS (I think that's the role of AUDIT_DETAILS in the IM). What do you think? In a more cloud-based world, it might not seem so clear, because numerous organisations might be committing to a physical service that supports multi-tenanting. I'm thinking this to be a mini cloud, but only for one organization. However, in either case, it should be something like a domain name of an EHR service that is understood to be the legal EHR repository facility of the organisation in which the clinician works. Considering the architecture and funcionalities (services) above, you understand as domain name of an EHR service as the EHR SERVER, the EMR CLIENTs, or the whole system (one EHR SERVER, many EMR Systems)? There might be an argument for having another field for 'client device type' (e.g. phone, iPad etc). I'm not on device area yet :) Thanks,Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130123/4ffeeaa7/attachment.html
