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 openehr-technical-requ...@lists.openehr.org het > volgende geschreven: > > Send openEHR-technical mailing list submissions to > openehr-technical@lists.openehr.org > > 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 > openehr-technical-requ...@lists.openehr.org > > You can reach the person managing the list at > openehr-technical-ow...@lists.openehr.org > > 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 <grah...@healthintersections.com.au> > To: For openEHR technical discussions > <openehr-technical@lists.openehr.org> > Cc: For openEHR clinical discussions > <openehr-clini...@lists.openehr.org> > 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 < > heather.les...@oceanhealthsystems.com> 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- >> boun...@lists.openehr.org] *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 <gf...@luna.nl> 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> >> gf...@luna.nl >> >> >> >> On 31 May 2017, at 06:54, Pablo Pazos <pablo.pa...@cabolabs.com> 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 >> openEHR-technical@lists.openehr.org >> 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 >> pablo.pa...@cabolabs.com >> Subscribe to our newsletter <http://eepurl.com/b_w_tj> >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> technical_lists.openehr.org >> > > > > -- > ----- > http://www.healthintersections.com.au / grah...@healthintersections.com.au > / +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 <heather.les...@oceanhealthsystems.com> > To: For openEHR clinical discussions > <openehr-clini...@lists.openehr.org>, "For openEHR technical > discussions" <openehr-technical@lists.openehr.org> > 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:openehr-clinical-boun...@lists.openehr.org] On > Behalf Of Grahame Grieve > Sent: Monday, 5 June 2017 3:59 PM > To: For openEHR technical discussions <openehr-technical@lists.openehr.org> > Cc: For openEHR clinical discussions <openehr-clini...@lists.openehr.org> > 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 > <heather.les...@oceanhealthsystems.com<mailto:heather.les...@oceanhealthsystems.com>> > 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-boun...@lists.openehr.org<mailto:openehr-technical-boun...@lists.openehr.org>] > On Behalf Of Pablo Pazos > Sent: Thursday, 1 June 2017 12:58 AM > To: For openEHR technical discussions > <openehr-technical@lists.openehr.org<mailto: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 <gf...@luna.nl<mailto:gf...@luna.nl>> > 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> > gf...@luna.nl<mailto:gf...@luna.nl> > > On 31 May 2017, at 06:54, Pablo Pazos > <pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com>> 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 > openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> > 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/> > pablo.pa...@cabolabs.com<mailto:pablo.pa...@cabolabs.com> > Subscribe to our newsletter<http://eepurl.com/b_w_tj> > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > ----- > http://www.healthintersections.com.au / > grah...@healthintersections.com.au<mailto:grah...@healthintersections.com.au> > / +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 > openEHR-technical@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ------------------------------ > > End of openEHR-technical Digest, Vol 64, Issue 4 > ************************************************ _______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
