openEHR Querying specifications
Hi Gerard, I 'm afraid I agree with Tim on this one. The difference between 'breaking' Version changes and non-breaking Revisions is clearly documented in the specification. The reason for confusion and non-use within the NHS is simply that the current tools do not support Revisions. Now that the Template Model has been produced, I would hope that we can properly support Revisions in both Archetype Editor and Template Designer. I appreciate that at first, Version / Revision is confusing because of the similarity in English, but I think it is too late now to change these terms, which at least have clear technical definitions. I was interested to see Thomas's comment that a future version of the parser will offer guidance on whether an altered archetype needs to be re-versioned. BTW What would be the equivalents in Dutch for Revision and Version? Ian 2008/6/4 Tim Cook timothywayne.cook at gmail.com: On Wed, 2008-06-04 at 21:56 +0200, Gerard Freriks wrote: Dear all, The text below by Thomas warrants a conclusion: - openEHR needs a (place in a) document that defines the correct wording and meaning of: version and revision. To my mind these words are to much similar and can generate confusions. Alternatives: Package (new Archetype that breaks the previous package archetype) plus conversion script from the Old to the New Archetype) Version (new Archetype as the result of some editorial changes, only, not breaking the previous version) Hmmm, seems to me that you are introducing a new term AND omitting a term that is in use. While not clarifying the previous terms which Tom did quite well. I believe that Tom very well defined a version change as a change that substantially modified a previous version in such a manner as to render it incompatible with previous versions. A Revision (which you omitted) is a change that may further constrain or otherwise modify an archetype but does not render the expressed information unusable. This is also the same information that can be found in the relevant documents. But I see no reference to 'Package' as far as archetypes are concerned. Package implies a grouping of some type. An archetype is (AFAIK) considered to be the expression of a single clinical concept. Regards, Tim ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org
Decision Support was: MIE-2008
Hi Gerard, I agree with most of your comments and in principle that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, this amounts to heresy in a UK context and I think we should be prepared to regard David Markwell's Grey Zone as a contested area for some time. I think we could waste a lot of energy in trying to reduce the grey zone and might be better served by allowing dual-representation in both openEHR paths and Snomed post-coordination, and concentrating our efforts on the clearer areaswhere one approach is obviously better than the other. I would rather present Snomed-openEHR as the productive marriage of 2 noble families, whose sum is greater than the parts, whilst accepting that there will remain on-going jockeying for position in the 'border lands'. Ian (joyfully mixing his metaphors) 2008/6/3 Gerard Freriks gfrer at luna.nl: Hi, Free text versus structured data and information debate: - Like Ian said: Archetypes and templates take away problems from the IT-domain and leave them for those in healthcare. When those in health need, want decision support they will have to use more structured info. In the end they will solve their own problems. - We, in the archetype world, will have to show the way. Timo's thoughts are providing ways to think. Archetypes used must be able to serve many purposes: recording, retrieval, exchange, archiving and re-use for among others decision support. - The boundary problem has to be solved. Davids 'grey zone' must be reduced to a manageable small zone. We can not change the past and must find ways to deal with pre-historic (pre-archetype) data. In order to solve it we must look forward and reduce the 'grey zone' by acknowledging that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end. Gerard On Jun 3, 2008, at 7:43 AM, Sam Heard wrote: Terminology A final part of the equation is the area that David Markwell has been working on in the NHS in the UK. He is investigating how to generate computable terminology code phrases from an archetype: that is, how to post-coordinate information captured in an archetype for inferencing in the terminology space. This has benefit in linking with the pre-archetype data and may allow complex research to be undertaken in the future using ontological tools and engines. So we need to keep the balance between freedom and structure, recognising (as Ian McNicoll says) that good archetypes take the problem out of the technical space to where it becomes a human (and potentially soluble) issue. Cheers, Sam -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org
openEHR Querying specifications
Heath Frankel wrote: [openEHR-EHR-COMPOSITION.encounter.v1*] (or perhaps more correctly [openEHR-EHR-COMPOSITION.encounter.v1.*], where the dot means any character not the version delimiter) and [openEHR-EHR-COMPOSITION.encounter.v\d+] are different. The first allows all revisions of .v1 (e.g. v1.1, v1.2, ..) Close, but not quite! [openEHR-EHR-COMPOSITION.encounter.v1.*] allows all revisions of .v1, .v10, .v11, ... .v100, .v101, etc. To allow all revisions of .v1, we would need this: [openEHR-EHR-COMPOSITION.encounter.v1\..*] But what about .v1draft? This regex wouldn't catch it. Does this matter? Or is that old draft convention going to be phased out? - Peter
openEHR Querying specifications
The v1draft convention is already deprecated. The BNF for AQL doesn't support it deliberately, to ensure only non-draft archetypes are used when committing/retrieving data. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Peter Gummer Sent: Thursday, 5 June 2008 11:14 AM To: For openEHR technical discussions Subject: Re: openEHR Querying specifications Heath Frankel wrote: [openEHR-EHR-COMPOSITION.encounter.v1*] (or perhaps more correctly [openEHR-EHR-COMPOSITION.encounter.v1.*], where the dot means any character not the version delimiter) and [openEHR-EHR-COMPOSITION.encounter.v\d+] are different. The first allows all revisions of .v1 (e.g. v1.1, v1.2, ..) Close, but not quite! [openEHR-EHR-COMPOSITION.encounter.v1.*] allows all revisions of .v1, .v10, .v11, ... .v100, .v101, etc. To allow all revisions of .v1, we would need this: [openEHR-EHR-COMPOSITION.encounter.v1\..*] But what about .v1draft? This regex wouldn't catch it. Does this matter? Or is that old draft convention going to be phased out? - Peter ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
Hi Ian and Gerard, Could you please explain what post-coordination is and maybe provide an example of post- (and pre-?) coordination? Cheers, Stef Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven: most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/4d21b3e3/attachment.html
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/725c0b1f/attachment.html
openEHR Querying specifications
at gmail.com: -- Message: 2 Date: Tue, 03 Jun 2008 16:39:37 +0100 From: Thomas Beale thomas.beale at oceaninformatics.com Subject: openEHR Querying specifications To: Openehr-Technical openehr-technical at openehr.org Message-ID: 484565B9.6030805 at oceaninformatics.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed The current material is therefore intended as a resource for discussion and definition of a query language for openEHR. A team can be defined after sufficient time for the community to react to this material and determine if it makes sense to use AQL as the basis or to seek other solutions or candidates. - thomas beale Perhaps this has been answered but as the archetypes change version is it expected that the AQL will need to keep up with that - I assume our historic data would be specific to the archetype version - not 'upgraded' ? i.e. after v1: FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 after v2: FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1] CONTAINS OBSERVATION obs2 [openEHR-EHR-OBSERVATION.blood_pressure.v2] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 OR obs2/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 ) not sure if that is exactly right. thanks! Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Dr Ian McNicoll office +44(0)141 560 4657 fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll Consultant - Ocean Informatics ian.mcnicoll at oceaninformatics.com Consultant - IRIS GP Accounts Member of BCS Primary Health Care Specialist Group ? http://www.phcsg.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/61feb9cf/attachment.html
Parsing archetype xml with JAXB
Hi Greg, Have you tried XMLBeans? I have good experience in RM XML data binding using XMLBeans, http://www.openehr.org/svn/ref_impl_java/SANDBOX/xml-binding/ Haven't tried it with AOM XML binding, but it shouldn't be too different I suppose. Regards, Rong On Thu, Jun 5, 2008 at 3:03 PM, Greg Caulton caultonpos at gmail.com wrote: Hi, I used JAXB to generate java files from the XSD files but I am not getting very far with the unmarshalling, currently I get: javax.xml.bind.UnmarshalException: Unable to create an instance of test123.COBJECT: Unable to create an instance of test123.COBJECT when executing the following code: JAXBContext jc = JAXBContext.newInstance(ARCHETYPE.class); Unmarshaller unmarshaller = jc.createUnmarshaller(); JAXBElementARCHETYPE root = unmarshaller.unmarshal(new StreamSource(new File(filename)), ARCHETYPE.class); I've tried both XML from subversion and XML freshly generated from the Ocean Archetype Editor. the test123 is just the package I put the JAXB generated java files into, not related to the problem. I don't suppose anyone has run in this issue...? thanks! Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/ee3d4a0f/attachment.html
Parsing archetype xml with JAXB
Greg - I think this question would be better on the implementers list - to avoid causing too many heart attacks among the readers of this list on seeing actual code ;-) - thomas beale Greg Caulton wrote: Hi, I used JAXB to generate java files from the XSD files but I am not getting very far with the unmarshalling, currently I get: javax.xml.bind.UnmarshalException: Unable to create an instance of test123.COBJECT: Unable to create an instance of test123.COBJECT when executing the following code: JAXBContext jc = JAXBContext.newInstance(ARCHETYPE.class); Unmarshaller unmarshaller = jc.createUnmarshaller(); JAXBElementARCHETYPE root = unmarshaller.unmarshal(new StreamSource(new File(filename)), ARCHETYPE.class); I've tried both XML from subversion and XML freshly generated from the Ocean Archetype Editor. the test123 is just the package I put the JAXB generated java files into, not related to the problem. I don't suppose anyone has run in this issue...? thanks! Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * *
Parsing archetype xml with JAXB
On Thu, Jun 5, 2008 at 4:10 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: Greg - I think this question would be better on the implementers list - to avoid causing too many heart attacks among the readers of this list on seeing actual code ;-) Good point, Tom! =) It could be even posted on the Java-list. /Rong - thomas beale Greg Caulton wrote: Hi, I used JAXB to generate java files from the XSD files but I am not getting very far with the unmarshalling, currently I get: javax.xml.bind.UnmarshalException: Unable to create an instance of test123.COBJECT: Unable to create an instance of test123.COBJECT when executing the following code: JAXBContext jc = JAXBContext.newInstance(ARCHETYPE.class); Unmarshaller unmarshaller = jc.createUnmarshaller(); JAXBElementARCHETYPE root = unmarshaller.unmarshal(new StreamSource(new File(filename)), ARCHETYPE.class); I've tried both XML from subversion and XML freshly generated from the Ocean Archetype Editor. the test123 is just the package I put the JAXB generated java files into, not related to the problem. I don't suppose anyone has run in this issue...? thanks! Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ * * ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/ffa989a3/attachment.html
Parsing archetype xml with JAXB
Hi Greg, Have you tried XMLBeans? I have good experience in RM XML data binding using XMLBeans, http://www.openehr.org/svn/ref_impl_java/SANDBOX/xml-binding/ Haven't tried it with AOM XML binding, but it shouldn't be too different I suppose. Regards, Rong Hmm, well perhaps I should just use the ref_impl_java jar files to parse the ADL ? Either way is fine - I just want to have the archetype in a java object I can navigate and pull out the information I need to create the data elements and forms. This must be an old link to a single jar: http://www.openehr.org/svn/ref_impl_java/TRUNK/docs/download.htm Is there somewhere else I can download a single all in one openehr jar ? Multiple is fine too of course. thanks! Greg
Parsing archetype xml with JAXB
On Thu, Jun 5, 2008 at 4:51 PM, Greg Caulton caultonpos at gmail.com wrote: Hi Greg, Have you tried XMLBeans? I have good experience in RM XML data binding using XMLBeans, http://www.openehr.org/svn/ref_impl_java/SANDBOX/xml-binding/ Haven't tried it with AOM XML binding, but it shouldn't be too different I suppose. Regards, Rong Hmm, well perhaps I should just use the ref_impl_java jar files to parse the ADL ? Either way is fine - I just want to have the archetype in a java object I can navigate and pull out the information I need to create the data elements and forms. This must be an old link to a single jar: http://www.openehr.org/svn/ref_impl_java/TRUNK/docs/download.htm Is there somewhere else I can download a single all in one openehr jar ? Multiple is fine too of course. If you are familiar with Maven, the best way is to check out the latest version from the trunk and build from source. You could also download jars from the continuous integration server from here http://openehr.cambiosys.org/continuum. Just click the component and follow the link working copy and pick up the jar files form the sub-directory target. Cheers, Rong thanks! Greg ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/5e197a7d/attachment.html
Parsing archetype xml with JAXB
If you are familiar with Maven, the best way is to check out the latest version from the trunk and build from source. You could also download jars from the continuous integration server from here http://openehr.cambiosys.org/continuum. Just click the component and follow the link working copy and pick up the jar files form the sub-directory target. Cheers, Rong Awesome, one jar and one line of code and I have the Archetype object from the source ADL - sweet. I'll thank you in person next week :-) Greg - I think this question would be better on the implementers list - to avoid causing too many heart attacks among the readers of this list on seeing actual code ;-) - thomas beale Don't worry, I won't show the one line of code :-) thanks! Greg http://www.patientos.org
Decision Support was: MIE-2008
Ian, I agree. But my wished outcome is clear. And of course we have to deal with the past. But the sooner we, ... Gerard On Jun 5, 2008, at 12:48 AM, Ian McNicoll wrote: Hi Gerard, I agree with most of your comments and in principle that most post-coordination (using modifiers in Snomed-space instead of Archetype/Template space) must end, this amounts to heresy in a UK context and I think we should be prepared to regard David Markwell's Grey Zone as a contested area for some time. I think we could waste a lot of energy in trying to reduce the grey zone and might be better served by allowing dual-representation in both openEHR paths and Snomed post-coordination, and concentrating our efforts on the clearer areaswhere one approach is obviously better than the other. I would rather present Snomed-openEHR as the productive marriage of 2 noble families, whose sum is greater than the parts, whilst accepting that there will remain on-going jockeying for position in the 'border lands'. Ian (joyfully mixing his metaphors) -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/38e85b5f/attachment.html
