Decision Support was: MIE-2008
Hi Thilo, See my comments inline below... -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Monday, June 02, 2008 11:12 PM To: heath.frankel at oceaninformatics.com; For openEHR technical discussions Cc: timothywayne.cook at gmail.com Subject: Re: Decision Support was: MIE-2008 Yes, agree on the querying ... and for querying we need structured content! As Sam and I noticed before this has to be considered when designing archetypes. This doesn't mean there shouldn't be free-text fields, this is a very valid requirement in clinical medicine! [Chunlan Ma] Agree with this requirement. However, we have to be very careful when we allow free text in archetypes because more free-text fields would have less control over data quality. Currently, data quality is an issue and I believe that archetypes will play a very important role in resolving this issue. However, if we provide more free-text fields than necessary, then we may loss one of the advantages of using archetypes. Even though all text fields can be either free-text or coded text, there should be some rules/guidelines suggesting what kinds of fields can be free-text, coded-text or both. Whether a text field is defined appropriately should be assessed during archetype governance process. What I am saying is that carefully defining a text field is not only for the purpose of DSS, it is also for data quality control. Chunlan Thus, when designing archtypes the art is to find the balance between free-text (max. flexibility) and structured content. In my mind we often have to offer *both* in an archetype. If I want to create a local application with lots of DSS I create a template that uses mostly the structured parts of the archetype. If I want maximum freedom I use mostly the free-text parts. Another scenario is that I receive information from another archetype-enabled system: The receiving system doesn't know whether the sending system had used the archtype in a flexible (free-text) or in a structured way. To allow the receiving system to decide whether it can use DSS with this information I see two options: 1) We have a root archetype that optionally offers both (free-text and structured) and we specialise a DSS optimised archetype from it. So only if the DSS optimised archetype was used, much DSS is can be offered. 2) Or we create generic archetype design patterns with switch-like constructs (i.e. if this option option was chosen I can rely on these other attributes to be available as well) so the receiving system's DSS engine can do a kind of archetype-introspection to decide what it can use and what not. Just early thoughts. What do others think? On Mon, Jun 2, 2008 at 9:55 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Thilo, I think the key thing that needs to be considered in Archetype design to support Decision Support is querying. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Thilo Schuler Sent: Saturday, 31 May 2008 8:13 PM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: Decision Support was: MIE-2008 I am also interested. I wonder how much decision support has to be considered when designing archetypes. In the near and midterm future decision support will probably mostly happen on a local (i.e. template) level, but I still assume that there should be design patterns of the underlying archetypes that make local decision support feasible. -Thilo On Sat, May 31, 2008 at 1:38 AM, Tim Cook timothywayne.cook at gmail.com wrote: On Fri, 2008-05-30 at 15:19 +0100, Sam Heard wrote: I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? I am certainly interested. It is the core of my interest semantic information management in healthcare and my primary driver for being involved in the EGADSS project http://egadss.sourceforge.net/ Though I was out voted by HL7v3 and Arden Syntax MLM proponents so I left the project. -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* ** ___ openEHR-technical mailing list
MIE-2008
Thanks Sam, Yes I?d be interested to join this list as well. Workflow, decision-support and EHRs such a huge space to work in! Be great to get those interested to share their thoughts in the one spot. I do agree with you about the importance of context for such applications to gain widespread usability and acceptance, and from my past research til now, I still believe openEHR provides the best model for capturing a person?s entire heath context and a framework that enable other technologies like workflow management systems and guideline engines to interact with it in a meaningful way. Cheers, Sistine From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Sam Heard Sent: Friday, 30 May 2008 11:50 PM To: For openEHR technical discussions Cc: Barretto, Sistine Subject: Re: MIE-2008 I wonder if we should have a particular list for people who are interested in working with openEHR from a decision support point of view. This may not be appropriate just yet but I believe it will generate a considerably different intellectual space. I wonder what others think? Sam P?ria Kashfi wrote: Hi all, As you may find in my signature, I'm a PhD student at Chalmers University of Technology, Sweden. The idea of having a conference related wiki page would be great for me, but not in entering related papers yet! MIE2008 was an amazing opportunity for me to get more familiar with openEHR and I've just starting investigating it for our projects. As a part of Pragmatic Pattern project, I'll design and develop an Evidence Based Clinicla Decision Support System You may find more information about our projects here: http://www.cs.chalmers.se/proj/medview/website/medview/omMedView.html http://www.his.se/templates/vanligwebbsida1.aspx?id=29549 I hope discussing issues on this mailing list, or getting access to resources in the Wiki will help me find the best way of utilizing this standard. Finally, It was so nice to meet you- Rong,Beatriz,Ian and Heather - in MIE2008 :) Regards paria On May 30, 2008, at 11:48 AM, Thomas Beale wrote: Lisa Thurston wrote: Andrew Patterson wrote: Actually, is it possible to have a conferences page on the wiki that is a bit of a one-stop shop for documenting openEHR related contributions to conferences. Somewhere where authors could attach their presentations from last years Medinfo, the MIE 2008 etc - and maybe also lists of future conferences of interest to openEHR folks. I know I can create pages myself on the wiki but I'm still a bit unsure where things are supposed to go in the wiki tree. Andrew, I think this is a really good idea. A link from the homepage or static part of the website into a place on the wiki where users can upload papers and continue the discussion has potential as both a reference and a way to provide feedback and/or engage in discussion on each paper in one location. *I am fine with that - I don't think we had the wiki running when we did the MedInfo pages. Probably we should move that to the wiki as well and make a small web page. How do others feel about this. Note, if we go this way, I am likely to leav it up to conference paper-writers to put their own entries up in the relevant pages! Can we have reactions from a few more people - if the response is positive, I will organise the conference material onto the wiki. - thomas beale * ___ 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 -- Dr Sam Heard Chief Executive Officer Director, openEHR Foundation Senior Visiting Research Fellow, University College London 214 Victoria Avenue Chatswood, NSW, 2067 Phone: +61 2 9415 4994 Mobile: +61 4 1783 8808 21 Chester Cres London E8 2PH Phone: +44 20 7249 7085 Mobile: +44 77 9871 0980 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/a8e0a160/attachment.html -- next part -- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/a8e0a160/attachment.jpg
Decision Support was: MIE-2008
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/5d6ab130/attachment.html -- next part -- A non-text attachment was scrubbed... Name: OceanInformaticsl.JPG Type: image/jpeg Size: 5828 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/5d6ab130/attachment.JPG
MIE-2008
Sounds good to me. I think the sub-page for the paper could be an optional thing but the link from the conference page can either go to a sub page or directly to the paper. The sub-page approach also assists with the attachment limit issue (which will need to be administered by someone) and allow comments to be made about the paper or presentation. Heath -Original Message- From: Tim Cook [mailto:timothywayne.cook at gmail.com] Sent: Monday, 2 June 2008 9:49 PM To: heath.frankel at oceaninformatics.com Cc: 'For openEHR technical discussions' Subject: RE: MIE-2008 On Mon, 2008-06-02 at 17:16 +0930, Heath Frankel wrote: Labels only work on pages, not on attachments. Are we looking at a page per paper or page per conference? If the former then this suggest could work, but I don't think is as good as an index, however much more automated. My full thoughts on this were: A main conference index page linked to a single page about the individual conferences. On the individual conference page there could be a brief description as well as dates/times and location of the conference. Each paper, presentation, poster, etc. is attached to a child page of this conference where the author could add the abstract or a brief description. This page carries the Labels for the attachment. This way only the main conference index has to be maintained by a single person and future conferences can be added as soon as we know of a planned openEHR event. This gives us everything linked to a specific conference as well as being able to search for specifically labeled subject matter across the site. --Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **
openEHR Querying specifications
As part of the ongoing specification work this year, we have started to build some resource pages for the various specifications. One of them concerns a querying solution for openEHR - see the wiki page at: http://www.openehr.org/wiki/display/spec/openEHR+Query+Specifications I have uploaded the Ocean Informatics developed 'Archetype Query Language' (AQL) as a candidate solution for querying archetype-based data. As explained in the query specification home page, AQL can be treated as a starting point for defining a normative openEHR querying language, or it may be considered to be one candidate amongst several, if there are others available. Ocean Informatics undertakes to continue the development of this language in the openEHR space, so that if the openEHR community wishes to use AQL, the most recent modifications will be available. The timetable we have initially suggested for openEHR is to have a solid development draft ready in Q3 2008, i.e. before end September. See the roadmap for the current delivery plan - http://www.openehr.org/specifications/spec_roadmap_2008.html . A stable release should probably be available by mid 2009. 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
Decision Support was: MIE-2008
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/d583d302/attachment.html
MIE-2008
Hi! Using the wiki as first entry for the publications is great for speed and update/correction capabilities. - - - The stuff below is a non urgent suggestion for people interested in long term persistence of openEHR-related publications, others could stop reading here... - - - For real long time storage and permanent links (possibly having longer life than a wiki or CMS installation) I'd suggest that we _also_ sooner or later add the publications (papers, phd thesis etc) to a nomal web server directory as done before. Doing this is a bit tedious and requires special permissions, so the poor soul (webmaster) that would need to do this now and then probably would prefer doing batch uploads. Now the resources directory is divided into topics, having paths such as http://www.openehr.org/publications/workflow/Eric_Browne_WF_thesis_2005.pdf If we have the wiki for navigation and context, then maybe a time-indexed web directory would be easier to maintain, such as http://www.openehr.org/publications/2008/ (and make directory listings allowed on those parts of the server, to make life easier for search robots and url-hacking people). To make it easier to know what to upload where, one could set up a wiki page per publication year and ask authors (and other helpful people) to add a link to already wiki-uploaded papers (e.g. the specific MIE2008 page file attachment). The webmaster could then go through those pages and do the uploads now and then (and move uploaded document pointers from a To upload subheading to a Uploaded heading on that page). Best regards, Erik Sundvall erisu at imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579 On Fri, May 30, 2008 at 1:03 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: I have created a new wiki space called 'resource', and a root page 'conferences' beneath it. I have also created more or less a copy of the MedInfo 2007 page in the wiki. See http://www.openehr.org/wiki/display/resources/Conferences . On a whim, I chose a left-menu navigation style, just to see if we would like it better. I should be able to change it back if we don't like it. One thing to note: in the MedInfo 2007 page, all the links point back to the openEHR.org website, whereas in future conference webpages, we will usually upload attachments. The problem we have to tackle is that conferences is only one way to view material; after a while you want a proper index of the papers etc, and you no longer care that much about what conference they came from. I addressed this on the openEHR website with a 'publications' set of pages (currently workflow, Health ICT and archetypes). The conference-independent view of things is obviously teh more long term one. Would anyone like to propose how we do this on the wiki? Clearly an agreed discipline is needed, e.g. we might say that you have to upload to a page for papers, and then put an entry in the conference page that just points to that. thoughts? - thomas beale
openEHR Querying specifications
Hi Tom, On Tue, 2008-06-03 at 16:39 +0100, Thomas Beale wrote: I have uploaded the Ocean Informatics developed 'Archetype Query Language' (AQL) as a candidate solution for querying archetype-based data. As explained in the query specification home page, AQL can be treated as a starting point for defining a normative openEHR querying language, or it may be considered to be one candidate amongst several, if there are others available. Ocean Informatics undertakes to continue the development of this language in the openEHR space, so that if the openEHR community wishes to use AQL, the most recent modifications will be available. This certainly 'looks' functional. I assume that Ocean Informatics has done a fair amount of testing it to get to this point.
openEHR Querying specifications
-- Message: 2 Date: Tue, 03 Jun 2008 16:39:37 +0100 From: Thomas Beale thomas.be...@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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/4281de30/attachment.html
openEHR Querying specifications
Fair point. Perhaps AQL should support ranges of version numbers to simplify the query as in many cases the query will not be affected by a structrural change to the archetype e.g. FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND 2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[=1] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 Versions and revisions would need to be handled. Ian 2008/6/3 Greg Caulton caultonpos 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 Querying specifications
I suspect changes between version could potentially break the paths in WHERE clause. So maybe the version information isn't significant here since either the path works and the criteria are checked or the path doesn't work and fails silently. /Rong On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: Fair point. Perhaps AQL should support ranges of version numbers to simplify the query as in many cases the query will not be affected by a structrural change to the archetype e.g. FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN 1.5 AND 2] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v[=1] WHERE ( obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value = 140 Versions and revisions would need to be handled. Ian 2008/6/3 Greg Caulton caultonpos 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/455d222f/attachment.html
