Hi William, I can concede that for those examples.
Honestly I'm not particularly fussed about categorisation of the examples and there are plenty of examples which use a question/answer format with a total score at the end, so it is not clear if we should call it a questionnaire or a scale. The principles that I've laid out remain the same. Regards Heather -----Original Message----- From: openEHR-technical [mailto:[email protected]] On Behalf Of William Goossen Sent: Monday, 5 June 2017 4:45 PM To: [email protected] Subject: Re: openEHR-technical Digest, Vol 64, Issue 4 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.open > ehr.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.or > g/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.ou > tlook.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:openehr-tec > [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] > enehr.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]<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] > nehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org > > > > -- > Ing. Pablo Pazos Guti?rrez > Cel:(00598) 99 043 145 > Skype: cabolabs > > [https://docs.google.com/uc?export=download&id=0B27lX-sxkymfdEdPLVI5UT > ZuZlU&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] > nehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.org > > > > -- > ----- > http://www.healthintersections.com.au / > [email protected]<mailto:grahame@healthintersections. > com.au> / +61 411 867 065 > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.or > g/attachments/20170605/27a46f0d/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > ehr.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
