Concept Overload Caution
Hi everyone There are a lot of technical people who have volunteered as reviewers on CKM and we have had major input from a number of them. There will be more issues that arise when we have the first set of archetypes for publication to ensure consistency. There is no doubt that we all benefit from people speaking up about what their systems do and why. This helps ensure archetypes are suitable to support existing systems. Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Stef Verlinden Sent: Tuesday, 23 June 2009 4:02 PM To: For openEHR technical discussions Subject: Re: Concept Overload Caution Hi Heath, I complety agree with you. Let's all do what we're best at. What I would like to add to your proposal is some feedback (both ways) so doctors and technicians can learn from eachother. Rather than de- empowering the one or the other I think we should team up to create a properly working system that really adds value for the citizens/ patient who are the subject of this all. Also as I clinician I really would like an understandable (at technical lay-mans level) manual with clear examples who things can work and why some solutions shoudl be avoided. Maybe some best- practices of whatever you like to call that Cheers, Stef Op 23 jun 2009, om 02:15 heeft Heath Frankel het volgende geschreven: Hi Tim, Thank you for your post, I complete agree. Like you I am not a clinician and feel that I am rocking the establishment of openEHR and the principles of Archetypes by saying this, but I strongly believe that we need to have a technical review process of archetypes before they are published. What I am looking to review is not related to the clinical content, but the patterns used to represent that clinical content. In particular, I would looking to ensure that we have single concept representation, loose coupling, reusability, appropriate use of specialisation, and most importantly I believe, appropriate structures to support querying. These are all good object-oriented (or general software) design principles that technicians are trained to be better at then clinicians. As part of the archetype governance and publishing process, I would like to see a technical review process. I realise I am writing to a group of technicians on this list and this is probably a topic for the clinical list, but I think there probably are enough clinicians on this technical list to knock me around if they feel that I am rocking it too hard. Please understand that I not trying to re-empower the technician, I am simply looking for good quality knowledge artefacts and believe this a process that is missing in the current archetype development process. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Wednesday, 3 June 2009 9:59 AM To: For openEHR technical discussions Subject: Concept Overload Caution Hi All, The past 3 or 4 subjects on this list takes me back to conversations that we had before (maybe several years ago?) when we were discussing slots and links. Maybe they were here maybe they were on the ARB list. I do not recall now. But my feeling in both of these areas are that there is a tendency for archetype developers to create archetypes that are more than one clinical concept. IIRC, that is about the time that templates were being thought of/designed to alleviate the pressure on archetypes to serve everyone, everywhere. As Heath has just mentioned, templates are the better place for this type of grouping. They tend to provide that ability to be more localized. Remember that when you are creating or reusing archetypes that they should be universally reusable. If they are not, then they do not meet the basic requirement of being a single clinical concept. This is fundamental to openEHR being future proof. The misuse of slots and probably any use of links in a particular archetype; IMHO is a very bad thing and will lead us down the road that we see with data model centric systems as opposed to our information model. While I am not a clinician nor a lab tech I do ask those of you creating archetypes to review the fundamental principles of archetypes and templates. Then think twice before publishing an artifact. From what I am reading I think that there is becoming a tendency to put too much runtime functionality into what is supposed to be singular data items. My 2 cents/pence/centavos --Tim -- Timothy Cook, MSc Health Informatics Research Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook
Concept Overload Caution
Hi Heath, I complety agree with you. Let's all do what we're best at. What I would like to add to your proposal is some feedback (both ways) so doctors and technicians can learn from eachother. Rather than de- empowering the one or the other I think we should team up to create a properly working system that really adds value for the citizens/ patient who are the subject of this all. Also as I clinician I really would like an understandable (at technical lay-mans level) manual with clear examples who things can work and why some solutions shoudl be avoided. Maybe some best- practices of whatever you like to call that Cheers, Stef Op 23 jun 2009, om 02:15 heeft Heath Frankel het volgende geschreven: Hi Tim, Thank you for your post, I complete agree. Like you I am not a clinician and feel that I am rocking the establishment of openEHR and the principles of Archetypes by saying this, but I strongly believe that we need to have a technical review process of archetypes before they are published. What I am looking to review is not related to the clinical content, but the patterns used to represent that clinical content. In particular, I would looking to ensure that we have single concept representation, loose coupling, reusability, appropriate use of specialisation, and most importantly I believe, appropriate structures to support querying. These are all good object-oriented (or general software) design principles that technicians are trained to be better at then clinicians. As part of the archetype governance and publishing process, I would like to see a technical review process. I realise I am writing to a group of technicians on this list and this is probably a topic for the clinical list, but I think there probably are enough clinicians on this technical list to knock me around if they feel that I am rocking it too hard. Please understand that I not trying to re-empower the technician, I am simply looking for good quality knowledge artefacts and believe this a process that is missing in the current archetype development process. Regards Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr- technical- bounces at openehr.org] On Behalf Of Tim Cook Sent: Wednesday, 3 June 2009 9:59 AM To: For openEHR technical discussions Subject: Concept Overload Caution Hi All, The past 3 or 4 subjects on this list takes me back to conversations that we had before (maybe several years ago?) when we were discussing slots and links. Maybe they were here maybe they were on the ARB list. I do not recall now. But my feeling in both of these areas are that there is a tendency for archetype developers to create archetypes that are more than one clinical concept. IIRC, that is about the time that templates were being thought of/designed to alleviate the pressure on archetypes to serve everyone, everywhere. As Heath has just mentioned, templates are the better place for this type of grouping. They tend to provide that ability to be more localized. Remember that when you are creating or reusing archetypes that they should be universally reusable. If they are not, then they do not meet the basic requirement of being a single clinical concept. This is fundamental to openEHR being future proof. The misuse of slots and probably any use of links in a particular archetype; IMHO is a very bad thing and will lead us down the road that we see with data model centric systems as opposed to our information model. While I am not a clinician nor a lab tech I do ask those of you creating archetypes to review the fundamental principles of archetypes and templates. Then think twice before publishing an artifact. From what I am reading I think that there is becoming a tendency to put too much runtime functionality into what is supposed to be singular data items. My 2 cents/pence/centavos --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
Concept Overload Caution
Hi Heath and Peter Peter Gummer wrote: Heath Frankel wrote: I strongly believe that we need to have a technical review process of archetypes before they are published. ... Please understand that I not trying to re-empower the technician, I am simply looking for good quality knowledge artefacts and believe this a process that is missing in the current archetype development process. I agree. Technical input is essential. We have the validation report in CKM and this captures some errors, but many of the issues Heath mentioned require a manual review of the archetype. I think it behoves us tech-heads to get involved. I (and others) have been invited six months ago to help the CKM publishing process by adopting an archetype. It would be very good to have a couple of technicians on there. Adopting is a good means for individual archetypes and as a rule everybody who adopts an archetype in CKM will always be invited to review the archetype. For consistency etc, I believe it would be even more benefitial if we have more or less the same couple of technical reviewers for each archetype. I am not sure if this should be a totally separate process from the clinical review process or part of it. If it is one process, it makes the handling of it a lot easier and more streamlined, but on the other hand you wouldn't want too many technical comments as part of the clinical review process and technicians may not be satisfied with the more clinically oriented view of the archetype presented during the review. I think we should test drive adding some volunteer technicians to the review round of an archetype that is currently under review and see how we go with this. Cheers Sebastian
CKM reviews (Was Re: Concept Overload Caution)
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090623/bf0d5aee/attachment.html
Concept Overload Caution
Hi Tim et al, Interesting comments. Certainly it is very common for newcomers to openEHR to model end-point datasets e.g. 'Diabetes consultation' as a single archetype, rather than as a set of archetypes , aggregated into a template. Sometimes this is due to a misunderstanding of the openEHR principles, in other cases, it arises from a pragmatic decision to generate a 'quick and dirty' data model to satisfy a local requirement. There is a particular difficulty with questionnaire type constructs where this kind of single-archetype per dataset construct is sometimes the best approach. I'd be interested to know if you feel that any of the current CKM archetypes break the 'single-concept' per archetype rule as I could see that you might feel that some of the recent histopathology clusters for e.g melanoma, might fall into this category. These are 'my babies' to feel free to let fly!! I was not sure what you meant by 'misuse of slots' - can you give some examples? At present , I see using slots for 2 distinct purposes: 1) To allow us to reuse structured content e.g. 'Lymph node metastases' that appears at different points within parent structures or in different archetypes 2) To provide an open-ended means of expansion of a clinical concept where it is simply not possible to fully define the concept e.g some aspects of physical examination which are horribly fractal, or where below a certain level, there is no clinical consensus e.g. wide variation in the microscopic reporting of breast cancer. Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian at mcmi.co.uk Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com BCS Primary Health Care Specialist Group www.phcsg.org 2009/6/3 Tim Cook timothywayne.cook at gmail.com Hi All, The past 3 or 4 subjects on this list takes me back to conversations that we had before (maybe several years ago?) when we were discussing slots and links. Maybe they were here maybe they were on the ARB list. I do not recall now. But my feeling in both of these areas are that there is a tendency for archetype developers to create archetypes that are more than one clinical concept. IIRC, that is about the time that templates were being thought of/designed to alleviate the pressure on archetypes to serve everyone, everywhere. As Heath has just mentioned, templates are the better place for this type of grouping. They tend to provide that ability to be more localized. Remember that when you are creating or reusing archetypes that they should be universally reusable. If they are not, then they do not meet the basic requirement of being a single clinical concept. This is fundamental to openEHR being future proof. The misuse of slots and probably any use of links in a particular archetype; IMHO is a very bad thing and will lead us down the road that we see with data model centric systems as opposed to our information model. While I am not a clinician nor a lab tech I do ask those of you creating archetypes to review the fundamental principles of archetypes and templates. Then think twice before publishing an artifact. From what I am reading I think that there is becoming a tendency to put too much runtime functionality into what is supposed to be singular data items. My 2 cents/pence/centavos --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/20090623/230a3c8c/attachment.html
Concept Overload Caution
Hi All, The past 3 or 4 subjects on this list takes me back to conversations that we had before (maybe several years ago?) when we were discussing slots and links. Maybe they were here maybe they were on the ARB list. I do not recall now. But my feeling in both of these areas are that there is a tendency for archetype developers to create archetypes that are more than one clinical concept. IIRC, that is about the time that templates were being thought of/designed to alleviate the pressure on archetypes to serve everyone, everywhere. As Heath has just mentioned, templates are the better place for this type of grouping. They tend to provide that ability to be more localized. Remember that when you are creating or reusing archetypes that they should be universally reusable. If they are not, then they do not meet the basic requirement of being a single clinical concept. This is fundamental to openEHR being future proof. The misuse of slots and probably any use of links in a particular archetype; IMHO is a very bad thing and will lead us down the road that we see with data model centric systems as opposed to our information model. While I am not a clinician nor a lab tech I do ask those of you creating archetypes to review the fundamental principles of archetypes and templates. Then think twice before publishing an artifact.
