Decision Support was: MIE-2008
, for which I'd love to exchange ideas with others in a list created for this particular subject. All the best Seref On Sat, May 31, 2008 at 1:43 PM, Thilo Schuler thilo.schuler at gmail.com wrote: 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 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 -- ___ openEHR-technical mailing listopenEHR-technical at openehr.orghttp://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 ___ 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/20080602/dfc70538/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/20080602/dfc70538/attachment.JPG
MIE-2008
Rong, The only limit on attachments I have found is the default maximum number of attachments per page, however this is configurable (not sure if there is any limits to the configuration). Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Rong Chen Sent: Friday, 30 May 2008 7:34 PM To: For openEHR technical discussions Subject: Re: MIE-2008 On Fri, May 30, 2008 at 11:48 AM, Thomas Beale thomas.beale at oceaninformatics.com 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. It sounds like a good idea to me. Is there any limit on the type/size of file that can be uploaded to the wiki page? Cheers, Rong - thomas beale * ___ 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/20080602/093470ac/attachment.html
MIE-2008
Due to the limit of attachments per page I suggest the opposite approach, upload to a conference specific page an then link to it from other index pages. Obviously we will need another page for papers not related to a conference, such as publications. I would also expect in future that we might even have papers (blogs) written on the openEHR wiki that might be indexed as well. I agree with Heath - papers and presentations attached to their relevant conference page, and other 'index' pages that link into those conference page attachments. That way the index pages can link to specific papers in a way that tells a coherent story, rather than being an overwhelming list of papers - i.e. an 'introductory' index that links to the latest 'archetype 101' paper, the latest introductory technical paper etc. Obviously other index pages can deal with other topics, and from other perspectives (a clinicians view of openEHR etc). Andrew
ANN:openEHR Python Implementation
On Sun, 2008-06-01 at 22:22 +0100, Sam Heard wrote: Congratulations Tim - you are really getting your hands dirty now! Welcome to level 3 (or is it 4?) Sam Well, right now I feel like that 'I' am at level ZERO! :-) But thanks! This has been one of those projects rolling around in my head for several years. Many things conspired to keep it suppressed but it feels good for it to actually becoming reality. It is currently frozen at Revision 19 since I am starting a major refactoring to solve the circular import issues. This may take up to 2 weeks. If anyone wants to help you don't even have to know anything about Python. I could use lots of copy/paste work and the instructions are posted in the development mailing list archives: http://sourceforge.net/mailarchive/forum.php?forum_name=oship-devel Cheers, 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* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/bb282625/attachment.asc
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* ** -- next part -- A non-text attachment was scrubbed... Name: Displayemail.gif Type: image/gif Size: 4274 bytes Desc: not available URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/3b76342e/attachment.gif -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/3b76342e/attachment.asc
Decision Support was: MIE-2008
On Mon, 2008-06-02 at 00:41 +0300, Seref Arikan wrote: In case any member of this group have a candidate app for a trial like this, I'd be delighted to get some pointers for future work. I was going to save this for the decision support mailing list. But since you asked ... :-) The EVIDENCE-BASED GUIDELINES AND DECISION SUPPORT SYSTEM (EGADSS) [Yeah we thought it was a cool acronym too!] Is a project that I worked on up until we came to some obvious disagreements over implementation. But the concepts are valid and proven. See: http://egadss.sourceforge.net/ The basic concept is that an EMR sends a basic known set of information about a patient to the DSS. The DSS processes whatever clinical guidelines it knows about using the CLIPS Inference Engine http://clipsrules.sourceforge.net/ and if it finds something applicable to this patient it processes the guideline. If it needs more information (lab results etc.) it sends a request back to the EMR. The guideline analysis is completed and instructions returned to the EMR. A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding and using an openEHR EHR Extract instead of the CDA for messaging is certainly in my future plans. Cheers, 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* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/63ba55d1/attachment.asc
Decision Support was: MIE-2008
On Mon, 2008-06-02 at 09:45 -0300, Tim Cook wrote: A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding BTW: I am not including/excluding other possibilities here. PROforma is a prime candidate but even after reading John Fox's book Safe and Sound: Artificial Intelligence in Hazardous Applications, http://mitpress.mit.edu/book-home.tcl?isbn=0262062119 I was still confused but very interested. :-) --Tim -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/feae05e0/attachment.asc
Decision Support was: MIE-2008
On Mon, Jun 02, 2008 at 09:48:17AM -0300, Tim Cook wrote: I'd really like to see the outcomes of a little project which would be about porting a simple existing decision support system to an OpenEHR based infrastructure. Warning against adverse drug events for patient safety would be a good target for example. (mostly) rewriting this kind of app would give valuable feedback to archetype designers and also standard developers. Doing adverse drug reactions isn't too tough of a technical problem. It is however a MASSIVE knowledge problem. Using clinical guidelines to determine things like immunization adherence etc is a much butter place to start IMHO. Full ACK. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Decision Support was: MIE-2008
On Mon, Jun 02, 2008 at 09:45:08AM -0300, Tim Cook wrote: The EVIDENCE-BASED GUIDELINES AND DECISION SUPPORT SYSTEM (EGADSS) The basic concept is that an EMR sends a basic known set of information about a patient to the DSS. The DSS processes whatever clinical guidelines it knows about using the CLIPS Inference Engine http://clipsrules.sourceforge.net/ and if it finds something applicable to this patient it processes the guideline. If it needs more information (lab results etc.) it sends a request back to the EMR. The guideline analysis is completed and instructions returned to the EMR. That's precisely how I would want a DSS to work for interfacing it with GNUmed. When I last looked at EGADSS (a year or so ago) it looked like they wanted me to use their own GUI not just for defining guidelines but also make the user use their GUI to check for guideline adherence of patients handed over from an EMR. IOW, I couldn't find any documentation on how to get instructions back into GNUmed. Any pointers ? A re-implementation of this engine using GLIF instead of Arden Syntax guideline encoding and using an openEHR EHR Extract instead of the CDA for messaging is certainly in my future plans. Looking forward to that. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
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! 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 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Decision Support was: MIE-2008
On Mon, 2008-06-02 at 15:14 +0200, Karsten Hilbert wrote: That's precisely how I would want a DSS to work for interfacing it with GNUmed. When I last looked at EGADSS (a year or so ago) it looked like they wanted me to use their own GUI not just for defining guidelines but also make the user use their GUI to check for guideline adherence of patients handed over from an EMR. IOW, I couldn't find any documentation on how to get instructions back into GNUmed. Any pointers ? once upon a time there was a pretty good demo online and it appeared to adhere to the initial concepts. As I said; I left the project due to the chosen implementation strategy. I am therefore not 100% certain how it works in implementation now. I don't hold out much hope for a collaborative open source community around this project though. ** In full disclosure though; for those thinking about using EGADSS. I was recently asked (a few weeks ago) to facilitate a conference call with EGADSS people and the FreeMED Foundation in order for the Foundation to gain some open source project management position and move the project forward. In my investigation of the status of EGADSS I found that it is only being used as a tool in Dr. Jankhe's computer science courses at this time. Dr. Jankhe is the one that took over my position as project technical lead and drove the implementation in it's current direction. I was never able to build any real open source mindset within the group and left in frustration. Dr. Jankhe had told me in one of our first meetings that he could never promote open source because Microsoft was a major contributor to his computer science program. You can take all this for what it is worth and maybe the FreeMED Foundation will be able to rekindle some open source energy in the project? Either way, I believe a re-implementation is the best way to go. As Paul Harvey ( http://www.paulharvey.com/ )would say; Now you know, the rest of the story. :-) Cheers, 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* ** -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080602/daa61a4f/attachment.asc
ANN:openEHR Python Implementation
On Mon, Jun 2, 2008 at 1:45 PM, Tim Cook timothywayne.cook at gmail.com wrote: On Sun, 2008-06-01 at 22:22 +0100, Sam Heard wrote: Congratulations Tim - you are really getting your hands dirty now! Welcome to level 3 (or is it 4?) Sam Well, right now I feel like that 'I' am at level ZERO! :-) But thanks! This has been one of those projects rolling around in my head for several years. Many things conspired to keep it suppressed but it feels good for it to actually becoming reality. Congratulations, Tim! =) It is currently frozen at Revision 19 since I am starting a major refactoring to solve the circular import issues. This may take up to 2 weeks. If anyone wants to help you don't even have to know anything I had to fight the circular import (dependence) issues in the Java implementation from time to time. The last time was that I wanted to use the minimum terminology service component inside the test code of RM core component (all RM classes except EHR and Demographics), but had to give up due to circular dependency. Where do you have the issue in your implementation? Cheers, Rong about Python. I could use lots of copy/paste work and the instructions are posted in the development mailing list archives: http://sourceforge.net/mailarchive/forum.php?forum_name=oship-devel Cheers, 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-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/20080602/a1378378/attachment.html
