Why? What are the arguments? Gerard Freriks +31 620347088 [email protected]
Kattensingel 20 2801 CA Gouda the Netherlands > On 5 Jun 2017, at 08:44, William Goossen <[email protected]> wrote: > > The examples given as Glasgow Coma Scale and Barthel index are definitely NOT > questionnaires. These are assessment scales and require quite a different > approach than the also extremely useful questions and answers. > > Vriendelijke groet, > > Dr. William Goossen > > Directeur Results 4 Care BV > +31654614458 > >> Op 5 jun. 2017 om 08:25 heeft [email protected] >> het volgende geschreven: >> >> Send openEHR-technical mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openEHR-technical digest..." >> >> >> Today's Topics: >> >> 1. Re: Questionnaires (Grahame Grieve) >> 2. RE: Questionnaires (Heather Leslie) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 5 Jun 2017 15:59:26 +1000 >> From: Grahame Grieve <[email protected]> >> To: For openEHR technical discussions >> <[email protected]> >> Cc: For openEHR clinical discussions >> <[email protected]> >> Subject: Re: Questionnaires >> Message-ID: >> <cag47hgypmsi1u1znhheoh_ymz841m7mlvwd6hgccufsy-vq...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> hi Heather >> >>> A generic question/answer pattern is next to useless - interoperability >> is really not helped >> >> I think you should rather say "A generic question/answer pattern is only >> useful for exchanging the questions and answers, and does not allow re-use >> of data". This is not 'next to useless for interoperability', just not fit >> for any wider purpose >> >> Grahame >> >> >> On Mon, Jun 5, 2017 at 3:51 PM, Heather Leslie < >> [email protected]> wrote: >> >>> Following Thomas? suggestion re a separate thread: >>> >>> >>> >>> I wrote a blog post in 2014 which still reflects our current thinking re >>> questionnaires: https://omowizard.wordpress.com/2014/02/21/the- >>> questionnaire-challenge/ >>> >>> >>> >>> Our experience is that the data is the priority and so we want to focus on >>> questionnaires to support capture of good quality data. >>> >>> >>> >>> If you want to try to capture data from the majority of existing >>> questionnaires then good luck ? questionnaires notoriously ask questions >>> badly, conflating multiple concepts into one question, Boolean True/False >>> when there are other ?shades of gray? etc. They work variably as far as >>> human interpretation but usually very badly wrt computer interpretation. >>> >>> >>> >>> We do have experience in taking previous paper questionnaires, analysing >>> the data requirements sought in terms of what we want to persist and then >>> we design the UI/questions to match the data desired and/or suggesting the >>> UI might show a questionnaire but each question the clinical data is >>> actually recorded using core archetypes ? for example ?Do you have >>> diabetes?? ? ?Yes?, is recorded using the value ?Diabetes? in the >>> EVAL.problem_diagnosis and ?No? is recorded in the matching exclusion >>> archetype. This creates real clinical data that can be used as part of a >>> health record rather than create an electronic checkbox version of the >>> original paper questionnaire which will never be used again, but capture >>> dust in our EHR?s virtual archives. >>> >>> >>> >>> In summary: >>> >>> - A generic question/answer pattern is next to useless - >>> interoperability is really not helped, especially if both the question and >>> answer has to be managed in the template. We have tried many variations of >>> this in the past, some of which were uploaded into CKM and subsequently >>> rejected. >>> - Lock in those questionnaires that are ubiquitous, evidence based, >>> validated as OBSERVATION archetypes and share them in the international CKM >>> ? eg AUDIT, Glasgow coma scale, Barthel index, Edinburgh post natal >>> depression scale ? there are many examples in CKM. >>> - Lock in local questionnaires that are going to be reused in your >>> organisation, region or jurisdiction even though they may not be reusable >>> elsewhere. They will provide some interoperability even if might only be >>> appropriate within one clinical system or national CKM. An example is the >>> Modified Early Warning Score/National Early Warning Score ? there are a few >>> different variations used in different locations and whether they should >>> all be in the international CKM is still not clear. >>> >>> >>> >>> BTW Questionnaires should be modelled as OBSERVATIONs (ie evidence that >>> can be collected over and over again using the same protocol) not >>> EVALUATIONS (as they are not meta-analysis nor summaries). >>> >>> >>> >>> Regards >>> >>> >>> >>> Heather >>> >>> >>> >>> *From:* openEHR-technical [mailto:openehr-technical- >>> [email protected]] *On Behalf Of *Pablo Pazos >>> *Sent:* Thursday, 1 June 2017 12:58 AM >>> *To:* For openEHR technical discussions <openehr-technical@lists. >>> openehr.org> >>> *Subject:* Re: Reports - a new openEHR RM type? >>> >>> >>> >>> Besides specific ways to model questionnaires, my questions is if our >>> openEHR clinical modelers have a pattern to represent questionnaires using >>> the openEHR information model. >>> >>> >>> >>> On Wed, May 31, 2017 at 3:37 AM, GF <[email protected]> wrote: >>> >>> There are several kinds of context archetypes/templates and their >>> meta-data are used for: >>> >>> - de novo data - re-used data >>> >>> - step in the clinical treatment model (observation, assessment/inference, >>> planning, ordering, execution) >>> >>> - kind of interface it is designed for (data presentation on a screen, >>> data capture, database store/retrieve, CDSS, ? >>> >>> >>> >>> Each Template needs to capture all this and is a Composition. >>> >>> All these contexts are characteristics of a Composition in the end. >>> >>> >>> >>> Questionnaires are in essence a tool that classifies information. >>> >>> And sometimes it transforms a set of responses into an aggregated >>> value/code >>> >>> The questionnaire can be treated as any classification, meaning we need to >>> de fine inclusion and exclusion criteria, >>> >>> and possible results per question can be a quantitative result (number, >>> PQ, code), or a semi-quantitative result (high, low), or a qualitative >>> result (present/ not present). >>> >>> Semi-Qualitative results need, inclusion/exclusion criteria and a >>> definition of what the norm/population is is about (females, children, etc.) >>> >>> >>> >>> >>> Gerard Freriks >>> +31 620347088 <+31%206%2020347088> >>> [email protected] >>> >>> >>> >>> On 31 May 2017, at 06:54, Pablo Pazos <[email protected]> wrote: >>> >>> >>> >>> Hi Thomas, >>> >>> Thinking about the hierarchy, at which level will be a Report be? Below >>> compo? Below entry? Structure? Representation? >>> >>> OT: many asked me this and didn't had a good answer. Do we have a pattern >>> to model questionnaires? Some require to define questions, and the answer >>> type in most cases is boolean, or coded text (multiple choice), and answers >>> might be 0..* (more than one answer for the same question is valid). >>> >>> Cheers, >>> >>> Pablo. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> http://lists.openehr.org/mailman/listinfo/openehr- >>> technical_lists.openehr.org >>> >>> >>> >>> >>> -- >>> >>> Ing. Pablo Pazos Guti?rrez >>> Cel:(00598) 99 043 145 >>> Skype: cabolabs >>> >>> <http://cabolabs.com/> >>> http://www.cabolabs.com >>> [email protected] >>> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> http://lists.openehr.org/mailman/listinfo/openehr- >>> technical_lists.openehr.org >>> >> >> >> >> -- >> ----- >> http://www.healthintersections.com.au / [email protected] >> / +61 411 867 065 >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170605/1cd4c49e/attachment-0001.html> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 5 Jun 2017 06:24:50 +0000 >> From: Heather Leslie <[email protected]> >> To: For openEHR clinical discussions >> <[email protected]>, "For openEHR technical >> discussions" <[email protected]> >> Subject: RE: Questionnaires >> Message-ID: >> >> <sy3pr01mb19131a7c8e2e230285779c6eea...@sy3pr01mb1913.ausprd01.prod.outlook.com> >> >> Content-Type: text/plain; charset="utf-8" >> >> Thanks Grahame, but I disagree. >> >> ?? A generic question/answer pattern is next to useless - >> interoperability is really not helped, especially if both the question and >> answer has to be managed in the template.? >> >> The complete sentence qualifies that the dependence on template modelling is >> the issue wrt interoperability. This is where a generic pattern is made >> specific for a given questionnaire or data set. Also that we have found >> there are multiple generic patterns, none of which is universally applicable >> and so to create multiple generic patterns becomes nonsensical. >> >> In the templating scenario it is only if the exact same template is shared >> (where every question has been renamed and associated value sets inserted) >> that can we get any value. In our experience it is of higher value to create >> an archetype that can at least be shared locally and explicitly models the >> precise question/answer combo in order to achieve better reuse. >> >> Heather >> >> From: openEHR-clinical [mailto:[email protected]] >> On Behalf Of Grahame Grieve >> Sent: Monday, 5 June 2017 3:59 PM >> To: For openEHR technical discussions <[email protected]> >> Cc: For openEHR clinical discussions <[email protected]> >> Subject: Re: Questionnaires >> >> hi Heather >> >>> A generic question/answer pattern is next to useless - interoperability is >>> really not helped >> >> I think you should rather say "A generic question/answer pattern is only >> useful for exchanging the questions and answers, and does not allow re-use >> of data". This is not 'next to useless for interoperability', just not fit >> for any wider purpose >> >> Grahame >> >> >> On Mon, Jun 5, 2017 at 3:51 PM, Heather Leslie >> <[email protected]<mailto:[email protected]>> >> wrote: >> Following Thomas? suggestion re a separate thread: >> >> I wrote a blog post in 2014 which still reflects our current thinking re >> questionnaires: >> https://omowizard.wordpress.com/2014/02/21/the-questionnaire-challenge/ >> >> Our experience is that the data is the priority and so we want to focus on >> questionnaires to support capture of good quality data. >> >> If you want to try to capture data from the majority of existing >> questionnaires then good luck ? questionnaires notoriously ask questions >> badly, conflating multiple concepts into one question, Boolean True/False >> when there are other ?shades of gray? etc. They work variably as far as >> human interpretation but usually very badly wrt computer interpretation. >> >> We do have experience in taking previous paper questionnaires, analysing the >> data requirements sought in terms of what we want to persist and then we >> design the UI/questions to match the data desired and/or suggesting the UI >> might show a questionnaire but each question the clinical data is actually >> recorded using core archetypes ? for example ?Do you have diabetes?? ? >> ?Yes?, is recorded using the value ?Diabetes? in the EVAL.problem_diagnosis >> and ?No? is recorded in the matching exclusion archetype. This creates real >> clinical data that can be used as part of a health record rather than create >> an electronic checkbox version of the original paper questionnaire which >> will never be used again, but capture dust in our EHR?s virtual archives. >> >> In summary: >> >> * A generic question/answer pattern is next to useless - interoperability >> is really not helped, especially if both the question and answer has to be >> managed in the template. We have tried many variations of this in the past, >> some of which were uploaded into CKM and subsequently rejected. >> * Lock in those questionnaires that are ubiquitous, evidence based, >> validated as OBSERVATION archetypes and share them in the international CKM >> ? eg AUDIT, Glasgow coma scale, Barthel index, Edinburgh post natal >> depression scale ? there are many examples in CKM. >> * Lock in local questionnaires that are going to be reused in your >> organisation, region or jurisdiction even though they may not be reusable >> elsewhere. They will provide some interoperability even if might only be >> appropriate within one clinical system or national CKM. An example is the >> Modified Early Warning Score/National Early Warning Score ? there are a few >> different variations used in different locations and whether they should all >> be in the international CKM is still not clear. >> >> BTW Questionnaires should be modelled as OBSERVATIONs (ie evidence that can >> be collected over and over again using the same protocol) not EVALUATIONS >> (as they are not meta-analysis nor summaries). >> >> Regards >> >> Heather >> >> From: openEHR-technical >> [mailto:[email protected]<mailto:[email protected]>] >> On Behalf Of Pablo Pazos >> Sent: Thursday, 1 June 2017 12:58 AM >> To: For openEHR technical discussions >> <[email protected]<mailto:[email protected]>> >> Subject: Re: Reports - a new openEHR RM type? >> >> Besides specific ways to model questionnaires, my questions is if our >> openEHR clinical modelers have a pattern to represent questionnaires using >> the openEHR information model. >> >> On Wed, May 31, 2017 at 3:37 AM, GF <[email protected]<mailto:[email protected]>> >> wrote: >> There are several kinds of context archetypes/templates and their meta-data >> are used for: >> - de novo data - re-used data >> - step in the clinical treatment model (observation, assessment/inference, >> planning, ordering, execution) >> - kind of interface it is designed for (data presentation on a screen, data >> capture, database store/retrieve, CDSS, ? >> >> Each Template needs to capture all this and is a Composition. >> All these contexts are characteristics of a Composition in the end. >> >> Questionnaires are in essence a tool that classifies information. >> And sometimes it transforms a set of responses into an aggregated value/code >> The questionnaire can be treated as any classification, meaning we need to >> de fine inclusion and exclusion criteria, >> and possible results per question can be a quantitative result (number, PQ, >> code), or a semi-quantitative result (high, low), or a qualitative result >> (present/ not present). >> Semi-Qualitative results need, inclusion/exclusion criteria and a definition >> of what the norm/population is is about (females, children, etc.) >> >> >> Gerard Freriks >> +31 620347088<tel:+31%206%2020347088> >> [email protected]<mailto:[email protected]> >> >> On 31 May 2017, at 06:54, Pablo Pazos >> <[email protected]<mailto:[email protected]>> wrote: >> >> Hi Thomas, >> Thinking about the hierarchy, at which level will be a Report be? Below >> compo? Below entry? Structure? Representation? >> OT: many asked me this and didn't had a good answer. Do we have a pattern to >> model questionnaires? Some require to define questions, and the answer type >> in most cases is boolean, or coded text (multiple choice), and answers might >> be 0..* (more than one answer for the same question is valid). >> Cheers, >> Pablo. >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected]<mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> -- >> Ing. Pablo Pazos Guti?rrez >> Cel:(00598) 99 043 145 >> Skype: cabolabs >> >> [https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UTZuZlU&revid=0B27lX-sxkymfcUwzT0N2RUs3bGU2UUovakc4VXBxWFZ6OXNnPQ]<http://cabolabs.com/> >> http://www.cabolabs.com<http://www.cabolabs.com/> >> [email protected]<mailto:[email protected]> >> Subscribe to our newsletter<http://eepurl.com/b_w_tj> >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected]<mailto:[email protected]> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> -- >> ----- >> http://www.healthintersections.com.au / >> [email protected]<mailto:[email protected]> >> / +61 411 867 065 >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170605/27a46f0d/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> ------------------------------ >> >> End of openEHR-technical Digest, Vol 64, Issue 4 >> ************************************************ > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
