GUI-directives/hints again (Was: Developing usable GUIs)
of specifying another mechanism for GUI-concerns. You'd still get layers (if you sensibly use specialisation) but more flexible boundaries during the needed upcoming period of collaborative experimentation and real use. On Mon, Dec 6, 2010 at 22:06, Koray Atalag k.atalag at auckland.ac.nz wrote: I think having these discussions is a great start. But it'd be great if someone from the core group 'owns' this thread and puts some pressure on us. Koray, what makes you exclude yourself from the core group? Shouldn't openEHR be a community with peers trying to solve common problems, where people like you with specific implementation experience can help collaboratively lead a specific exploration tangents at least as well as some official core that is busy prioritizing other important explorations. Whatever that core is I believe it will be actively involved in, and appreciate, the discussions. You already own the problem together with others owning the same problem. I think openEHR should be a platform to facilitate collective ownership of problem solving processes and solutions. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/http://www.imt.liu.se/%7Eerisu/ Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Thilo Schuler +61 404 030 143 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101211/6cb40e99/attachment.html
HL7 modelling approach
Greetings, I am interested in the details of some of the statements below. We've been working on generic methods of electronic healthcare standards implementation at CHIME. We have different teams focusing on different standards, and developing common tools and methods is an attractive goal for us. So your comments may provide us some interesting cases to work on. Please see comments/questions below In my experiences HL7 matches up to 98% of ability to represent clinical concepts and behavior and OpenEHR archetypes have several limits, making it maximum of 50% of representing clinical concept characteristics. Could you please provide an example where openEHR displays some or ideally more of the several limits you mention? I am interested in hearing about clinical concepts which are easily modelled in HL7 and hard to model in openEHR. In particular in OpenEHR it is too hard to have relationships with coding systems, e.g. Snomed CT (HL7 code attribute and OID systems is almost perfect and widely implemented for this), I have seen no proper archetype allowing to do the same. Could you please tell why do you find the term/terminology binding mechanics of archetypes too hard? Again, do you have an example of a clinical model which is easily bound to Snomed CT in HL7 and is problematic in openEHR? It is difficult to express relationships between data elements in archetypes, e.g. which data elements are organized in what structure with each other (such as the HL7 component relationship) and e.g. define the algorithm to create a sum score (such as the HL7 attribute of derivation method). I must be missing something here, but there are multiple views of Archetypes, from trees in GUI to even mindmaps, (to me) quite clearly displaying the structure. Again, could you provide me a link to an HL7 example which makes use of the relationship you find hard to express in openEHR? The option to model workflow or behaviour of concepts (e.g. the HL7 mood code for an observation) has no equivalent in OpenEHR archetypes. Again, do you have an example where INSTRUCTION, ACTION and ACTIVITY fail to deliver what you want to do? Could you kindly provide a clinical use case? Your mail is interesting for me at a personal level too, since I've always seen people having different approaches to the problem, and discussion is mostly around the efficiency or elegance of achieving the goal. You clearly point towards cases where you have observed failure, and I'd really like to hear specifics of these. Best Regards Seref -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101211/bf15003b/attachment.html
HL7 modelling approach
Apologies for forgetting to address William Goossen in the mail below. It appears I've deleted a little bit too much from the original message. Best Regards S On Sat, Dec 11, 2010 at 9:55 PM, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: Greetings, I am interested in the details of some of the statements below. We've been working on generic methods of electronic healthcare standards implementation at CHIME. We have different teams focusing on different standards, and developing common tools and methods is an attractive goal for us. So your comments may provide us some interesting cases to work on. Please see comments/questions below In my experiences HL7 matches up to 98% of ability to represent clinical concepts and behavior and OpenEHR archetypes have several limits, making it maximum of 50% of representing clinical concept characteristics. Could you please provide an example where openEHR displays some or ideally more of the several limits you mention? I am interested in hearing about clinical concepts which are easily modelled in HL7 and hard to model in openEHR. In particular in OpenEHR it is too hard to have relationships with coding systems, e.g. Snomed CT (HL7 code attribute and OID systems is almost perfect and widely implemented for this), I have seen no proper archetype allowing to do the same. Could you please tell why do you find the term/terminology binding mechanics of archetypes too hard? Again, do you have an example of a clinical model which is easily bound to Snomed CT in HL7 and is problematic in openEHR? It is difficult to express relationships between data elements in archetypes, e.g. which data elements are organized in what structure with each other (such as the HL7 component relationship) and e.g. define the algorithm to create a sum score (such as the HL7 attribute of derivation method). I must be missing something here, but there are multiple views of Archetypes, from trees in GUI to even mindmaps, (to me) quite clearly displaying the structure. Again, could you provide me a link to an HL7 example which makes use of the relationship you find hard to express in openEHR? The option to model workflow or behaviour of concepts (e.g. the HL7 mood code for an observation) has no equivalent in OpenEHR archetypes. Again, do you have an example where INSTRUCTION, ACTION and ACTIVITY fail to deliver what you want to do? Could you kindly provide a clinical use case? Your mail is interesting for me at a personal level too, since I've always seen people having different approaches to the problem, and discussion is mostly around the efficiency or elegance of achieving the goal. You clearly point towards cases where you have observed failure, and I'd really like to hear specifics of these. Best Regards Seref -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101211/d2152467/attachment.html
