ADLs documentation?
Hello everyone, I have been trying to found information about ADLs, but there is no information on current (1.4) ADL document. Searching the wiki for 'ADLs' doesn't work as returns all 'ADL' results. Do you know where the documentation about ADLs can be found? Regards
CKM progress and RE: Archetype versioning on CKM
the community more active in the openEHR CKM - make it yours! Take the initiative. Volunteer as an Editor. Send us candidate archetypes. Tell your colleagues. Translate the published archetypes from inside CKM - simply select 'Translate archetypes' from within the 'Archetypes' menu. Interestingly one member has been busy translating archetypes into Arabic (Syrian) - both the draft and published. I did email them to advise they prioritise the published archetypes to ensure they realised that if the draft archetypes change, the translation will potentially need to be re-done, yet they keep coming;-) I'm still excited. the more I'm involved, the more I'm convinced that this work has great potential to make a real difference. Please join in. Cheers Heather From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 16 June 2011 6:25 PM To: For openEHR clinical discussions; Openehr-Technical Subject: Re: Archetype versioning on CKM Erik, thanks for the pointer. I like this set of rules. It is not too different from the current draft identification spec http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/k nowledge_id_system.pdf , and it would be easy to upgrade it to reflect the SemVer rules more faithfully. In the openEHR spec, major.minor.patch is referred to as version.revision.build. I seem to remember a discussion where we thought about renaming these. Do people think we should just stop mentioning version/revision/build with respect to archetypes? Or is it helpful to think of an openEHR 'revision' as being the same as a 'minor' version (personally I think yes)? The only thing I don't like that much is going back to putting 'draft' etc on the end of the version string, but I guess it is so common, that we should just go with the flow. If we can get a bit of consensus here, I can update this draft proposal to reflect it pretty quickly. - t On 14/06/2011 09:24, Erik Sundvall wrote: Hi! I came to think of this openEHR versioning discussion thread when I read about the Semantic Versioning initiative at http://semver.org/ I think the reasoning there is very appropriate also for openEHR artifacts. The problem for openEHR might be that there are so many seemingly usable archetypes in the openEHR-hosted CKM that are neither modified for a long time nor officially tagged as published. It is understandable if it's tempting to start using them in real systems already now. After all the alternative is to reinvent the wheel locally and is that really better? Perhaps there should be a time limit on how long artifacts in the CKM can stay at a version below 1.0.0? Perhaps things would become easier if we break the link between an artifact having published status (as in being CRB approved) and the fact that an artifact has a version over 1.0.0. That way systems can start using archetypes past 1.0.0 knowing that non-compatible changes will have new major version numbers (irrespective of if they are published or not). Keeping approval badges like ARB published, NHS approved or WHO 2011 Certified separate from technical version numbers might be a good idea anyway... (Example: the first ARB published version of Archetype X might be 2.4.2 and the next time it's awarded an ARB published badge again might be when the ARB has time to get around to looking at version 2.8.4 or 7.8.9). Likely, agencies will want to approve sets of artifacts on a regular basis like tagging a number of mutually compatible archetypes and templates as NHS 2012-Q1 approved. The reasoning under #3 at http://semver.org/ (regarding 1.0.0beta1 1.0.0beta2 1.0.0.) might solve the draft problem discussed in this openEHR thread previously. (Provided that beta versions etc. don't get used/abused in live EHR systems.) The Semantic Versioning specification formalism is also machine processable in a nice way. 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/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/ce9e00c3/attachment.html -- next part -- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 1189 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/ce9e00c3/attachment.jpg
ADLs documentation?
Diego, if you mean the ADL 1.5 format, see the specs at the bottom of http://www.openehr.org/svn/specification/TRUNK/publishing/roadmap.html - thomas On 21/06/2011 09:57, Diego Bosc? wrote: Hello everyone, I have been trying to found information about ADLs, but there is no information on current (1.4) ADL document. Searching the wiki for 'ADLs' doesn't work as returns all 'ADL' results. Do you know where the documentation about ADLs can be found? Regards ___ 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/20110621/d67338b5/attachment.html
ADLs documentation?
I mean ADLs as referenced here http://www.openehr.org/224-OE.html .adls, for 'ADL source' files, allowing specialised archetypes to be represented 'differentially' (like object-oriented subclasses) 2011/6/21 Thomas Beale thomas.beale at oceaninformatics.com: Diego, if you mean the ADL 1.5 format, see the specs at the bottom of http://www.openehr.org/svn/specification/TRUNK/publishing/roadmap.html - thomas On 21/06/2011 09:57, Diego Bosc? wrote: Hello everyone, I have been trying to found information about ADLs, but there is no information on current (1.4) ADL document. Searching the wiki for 'ADLs' doesn't work as returns all 'ADL' results. Do you know where the documentation about ADLs can be found? Regards ___ 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
on the possibility of 'one information model' in e-health
, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/8489a985/attachment.html -- next part -- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/8489a985/attachment.jpg
ADLs documentation?
For the tool, see http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html For the wiki page see here http://www.openehr.org/wiki/display/spec/openEHR+Templates+and+Specialised+Archetypes - you can see a lot of examples here. otherwise see the links on the page I mentioned below for the syntax (see sectoin 10 of the ADL 1.5 doc). Note that .adls files are just .adl files for most archetypes, but for specialised archetypes, the format is 'differential', meaning that only changes with respect to the parent are indicated, not the whole content. hope this helps, - thomas On 21/06/2011 10:30, Diego Bosc? wrote: I mean ADLs as referenced here http://www.openehr.org/224-OE.html .adls, for 'ADL source' files, allowing specialised archetypes to be represented 'differentially' (like object-oriented subclasses) 2011/6/21 Thomas Bealethomas.beale at oceaninformatics.com: Diego, if you mean the ADL 1.5 format, see the specs at the bottom of http://www.openehr.org/svn/specification/TRUNK/publishing/roadmap.html - thomas On 21/06/2011 09:57, Diego Bosc? wrote: * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/877f944a/attachment.html
ADLs documentation?
Thanks, that is what I was looking for 2011/6/21 Thomas Beale thomas.beale at oceaninformatics.com: For the tool, see http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html For the wiki page see here - you can see a lot of examples here. otherwise see the links on the page I mentioned below for the syntax (see sectoin 10 of the ADL 1.5 doc). Note that .adls files are just .adl files for most archetypes, but for specialised archetypes, the format is 'differential', meaning that only changes with respect to the parent are indicated, not the whole content. hope this helps, - thomas On 21/06/2011 10:30, Diego Bosc? wrote: I mean ADLs as referenced here http://www.openehr.org/224-OE.html .adls, for 'ADL source' files, allowing specialised archetypes to be represented 'differentially' (like object-oriented subclasses) 2011/6/21 Thomas Beale thomas.beale at oceaninformatics.com: Diego, if you mean the ADL 1.5 format, see the specs at the bottom of http://www.openehr.org/svn/specification/TRUNK/publishing/roadmap.html - thomas On 21/06/2011 09:57, Diego Bosc? wrote: ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
on the possibility of 'one information model' in e-health
Hello Thomas Thank you very much for your response. One of the motives for what i am outlining in my last message has been the recurring discussions in the list about the suitability of this or that model (or approach) in e-health. So, an objective metric (a relative or ideally, an absolute one) of the suitability of a model to describe a domain could drive improvement and consensus. It would be the quantification of the suitability of ...[a thoery] that is as simple as possible for the most comprehensive explanatory power. Anyway, i might put together something more specific about this and share it with the list sometime later, although i admit that there are still some gray areas especially when trying to provide some practical examples on established models. All the best Athanasios Anastasiou On 21/06/2011 10:37, Thomas Beale wrote: Hi Athanasios, I doubt if mathematically measuring model complexity would be a good way to determine utility of information models for use in archetype modelling, and therefore in e-health more generally. The only way to do that is to see which ones support more / better archetypes. In this sense, the information model is like a 'theory' - the idea is to get one that is as simple as possible for the most comprehensive explanatory power. - thomas On 10/06/2011 13:55, Athanasios Anastasiou wrote: Hello everyone It has been very interesting to read the post and follow the subsequent discussion about [the quest for] one information model in e-health and especially the patterns part. I am not sure if there can be one information model in e-health but what i think that can be done is a ranking of available models according to how expressive they are and patterns (patterns of data structures and types) would be key to this. For example, at the low end of the spectrum, we could have some really simple models which are able to describe hierarchical information up to a certain depth. For example, you can describe the data about a document as a sequence of element where element can be simple (only one data entry of some supported type) XOR complex (an entry composed of many simple supported types). This would be less expressive than a list of element where element can be simple OR complex. In the latter case complex elements can also be nested. Something more expressive than this would be a [structure] of element where [structure] could be a list, a tree, a graph or other of complex OR simple elements. The table PATTERN / EXPLANATION in Thomas' blog post is a good start but i think that it is mixing types with some familiar class names. These can be broken down even further: The data/state/protocol/reasoning is a Dictionary. The History of events is essentially the same but the type of the index is now different. An order state machine is a directed graph (with loops). A composition document is a Set and participations could also be sets or dictionaries. Could we have defined the COMPOSITION as a special case of a set archetype with specific constraints? Could we have done the same for a state machine? Simply counting the supported patterns would not provide a comprehensive picture though. I trust that terms are used consistently. So, a mathematical model provides constraints over a domain. But there is nothing stopping someone to create an overly complex model to fit complex data with minimal error (reminds me of feature creep). You could have two models, one with 5 parameters and one with 50 parameters that seem to be fitting experimental data (observations from the domain) perfectly, which one do you choose? Obviously, the one with the 5 parameters because it is _simpler_. Mathematics does have tools to estimate model complexity versus how well the model describes the observations and i am sure that some parallels can be drawn here. In computer science, there are probably additional markers that need to be taken into account...It's not only a matter of how expressive a model is but also how easy it is to be used or how cheap it is to implement...These are probably more difficult to quantify but key factors for adopting a particular model. In this way, the model(s) that rank first would be the easiest and cheapest model(s) that can describe a domain most effectively. We don't have a golden standard for a domain of course, but something like this would be irrelevant. Even if we could pull all the workflows and documents from all the healthcare systems in the world, they would be a snapshot of what is required today** and with the exponential pace of progress would quickly become surpassed. This means that the ranking (without taking into account the shape of the domain) would only be useful amongst two or more models. All the best Athanasios Anastasiou **: But a very good indication of the patterns that are actually used out there...maybe Google is already doing it. On
on the possibility of 'one information model' in e-health
On 21/06/2011 13:09, Athanasios Anastasiou wrote: Hello Thomas Thank you very much for your response. One of the motives for what i am outlining in my last message has been the recurring discussions in the list about the suitability of this or that model (or approach) in e-health. So, an objective metric (a relative or ideally, an absolute one) of the suitability of a model to describe a domain could drive improvement and consensus. certainly I agree with that - it is just that using a 'white-box' method is unlikely to work in my view; a 'black-box' method is more useful because it tests the information model(s) against their ability to support real world content models like archetypes. I am not saying that the openEHR model is perfect by any means, only that much of it was elaborated by direct archetype modelling; this provided far more feedback for changes than any standard IT modelling methods or metrics could ever ave done. As I think I mentioned in the blog post, one of the best tests for an information model in e-health is to see how you would model Glucose Tolerance Test based on it. With some it is exceedingly difficult, with some it is easy. - thomas It would be the quantification of the suitability of ...[a thoery] that is as simple as possible for the most comprehensive explanatory power. Anyway, i might put together something more specific about this and share it with the list sometime later, although i admit that there are still some gray areas especially when trying to provide some practical examples on established models. All the best Athanasios Anastasiou * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110621/c0888796/attachment.html
