Small question about commits and AUDIT_DETAILS.system_id
Hi Pablo, No I don't agree. The point I tried to explain was that the system is the EHR repository, not an application. So if there is one or more applications using a repository at one or more organisations the is just one system id. In an Australian jurisdiction I have a repository that is used by multiple instances of 5 applications at 100 diff healthcare facilities managed by gov't and non gov't organisations. There is only one system id for the repository. Heath Original Message Subject: RE: Small question about commits and AUDIT_DETAILS.system_id From: pablo pazos pazospa...@hotmail.com To: openeh technical openehr-technical at lists.openehr.org CC: Hi! Thanks for your answers. It is a little tricky but from Thomas comments, I think that the system is not a technical term, but is more related to an organizational term. For example, if I use the same system / service to hold EHRs from 2 different hospitals, I really have 2 system ids instead of one. So the system_id doesn't depend on the technical architecture, but depends on how the business is organized. Is that correct? Again, the description from the specs doesn't help to understand this (Identity of the system where the change was committed, so it depends on what a system is for us). For the next version of the specs I think we can update that description and maybe give a couple of examples. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos Date: Thu, 21 Aug 2014 09:47:35 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: Small question about commits and AUDIT_DETAILS.system_id Heath, this is correct, you were not wrong for 10 y ;-) We don't record the name or type or id of the application, and I am not sure even now if that would be of any use. I can't see that it would be. The system_id is for exactly the purpose that Heath as explained here. - thomas On 21/08/2014 00:27, Heath Frankel wrote: Hi Thomas Pablo, I am finding the words in the this discussion ambiguous, and the specification does help to clarify. Here is my interpretation of AUDIT_DETAILS.system_id. I have an EHR service, which is used by two different application, one is a hospital system and another a mobile application that may not be related to the hospital system but share the same EHR service. When the hospital system and mobile application commits something they are using the same system_id, the system_id of the EHR service. If there is an exchange of data between this EHR service and another organisations EHR service via an EHR extract, the system ID will be used in the other organisations EHR service to identify that the commit was performed in the original organisations system_id. Therefore, the system_id identifies the system that is assigning version identifiers in the EHR repository, i.e. the AUDIT_DETAILS.system_id matches the system_id component of the version.uid. This is important for distributed versioning. So in Pablo?s scenario, it is one system of multiple components with multiple components sharing the same EHR service, the mobile and the EMR would use the same system_id. Has my interpretation been wrong for 10 years? If so, then we need clarity added to the specification. ___ 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/20140907/cbf0d0ed/attachment.html
Commits and Contributions
The commit uid is generated by the ocean EHR client, this is consistent with a git commit. All this is is a GUID so easy to do. Although I set the commit time on the client, I override this on server. Heath Original Message Subject: Commits and Contributions From: pablo pazos pazospa...@hotmail.com To: openeh technical openehr-technical at lists.openehr.org CC: Hi, I'm working on EHRServer, trying to improve how the XML is committed and processed to simplify querying. Right now I have a web app that commits a list of VERSIONs to the EHRServer. That service is based on the Ocean's commitContribution service http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface The CONTRIBUTION instance for the committed VERSIONs is created by the EHRServer, but the VERSIONs come in XML format. Looking at the openEHR XSDs, each VERSION needs an OBJECT_REF to a CONTRIBUTION. Since the CONTRIBUTION is created by the EHRServer, the VERSION XML doesn't have the OBJECT_REF, so it's invalid against the openEHR XSDs. What can I do? 1. Create the CONTRIBUTION at the client side and commit both, CONTRIBUTION and VERSIONs. 2. Add dummy XML to each VERSION just to pass the XSD validation. 3. Modify the openEHR schemas to add minOccurs=0 to the version.contribution element. 4. Other? Why I think these solutions are not so good: 1. IMO the role of the server is to create the CONTRIBUTION, because it's like a log for the commit, also the Ocean's service doesn't receive a CONTRIBUTION object. 2. I don't like adding stuff I will not use but seems the less problematic solution. 3. For me this is terrible, I want to play with the openEHR rules, not make my own, but it is just for the commit, so if I want to send compositions to an external system, that will be valid against the original openEHR XSDs because in the EHRServer I have the CONTRIBUTION. What do you think? Do you have a better solution? Thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.comhttp://cabolabs.com/es/homehttp://twitter.com/ppazos -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140907/fde4523a/attachment.html
Small question about commits and AUDIT_DETAILS.system_id
Thanks Heath. Can others comment on this to have a unified view and specific definition of the system id? I think i have 3 different definitions right now, and one contradicts the other :) Maybe the system_id hasn't a specific definition so might be used differently by different implementations. (?) In the end is just an id, does it matter if it's attached to a system or service or if it's something related to an organization or if it's a host domain? What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: heath.fran...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: RE: Small question about commits and AUDIT_DETAILS.system_id Date: Sun, 7 Sep 2014 23:25:43 + Hi Pablo, No I don't agree. The point I tried to explain was that the system is the EHR repository, not an application. So if there is one or more applications using a repository at one or more organisations the is just one system id. In an Australian jurisdiction I have a repository that is used by multiple instances of 5 applications at 100 diff healthcare facilities managed by gov't and non gov't organisations. There is only one system id for the repository. Heath Original Message Subject: RE: Small question about commits and AUDIT_DETAILS.system_id From: pablo pazos pazospa...@hotmail.com To: openeh technical openehr-technical at lists.openehr.org CC: Hi! Thanks for your answers. It is a little tricky but from Thomas comments, I think that the system is not a technical term, but is more related to an organizational term. For example, if I use the same system / service to hold EHRs from 2 different hospitals, I really have 2 system ids instead of one. So the system_id doesn't depend on the technical architecture, but depends on how the business is organized. Is that correct? Again, the description from the specs doesn't help to understand this (Identity of the system where the change was committed, so it depends on what a system is for us). For the next version of the specs I think we can update that description and maybe give a couple of examples. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Thu, 21 Aug 2014 09:47:35 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: Small question about commits and AUDIT_DETAILS.system_id Heath, this is correct, you were not wrong for 10 y ;-) We don't record the name or type or id of the application, and I am not sure even now if that would be of any use. I can't see that it would be. The system_id is for exactly the purpose that Heath as explained here. - thomas On 21/08/2014 00:27, Heath Frankel wrote: Hi Thomas Pablo, I am finding the words in the this discussion ambiguous, and the specification does help to clarify. Here is my interpretation of AUDIT_DETAILS.system_id. I have an EHR service, which is used by two different application, one is a hospital system and another a mobile application that may not be related to the hospital system but share the same EHR service. When the hospital system and mobile application commits something they are using the same system_id, the system_id of the EHR service. If there is an exchange of data between this EHR service and another organisations EHR service via an EHR extract, the system ID will be used in the other organisations EHR service to identify that the commit was performed in the original organisations system_id. Therefore, the system_id identifies the system that is assigning version identifiers in the EHR repository, i.e. the AUDIT_DETAILS.system_id matches the system_id component of the version.uid. This is important for distributed versioning. So in Pablo?s scenario, it is one system of multiple components with multiple components sharing the same EHR service, the mobile and the EMR would use the same system_id. Has my interpretation been wrong for 10 years? If so, then we need clarity added to the specification. ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ 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/20140908/655d1448/attachment.html
Small question about commits and AUDIT_DETAILS.system_id
at lists.openehr.orgmailto:openEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto:openEHR-technical at lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ___ openEHR-technical mailing list openEHR-technical at lists.openehr.orgmailto:openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org # Scanned by MailMarshal - M86 Security's comprehensive email content security solution. # IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140908/130562fc/attachment-0001.html