Re: Questionnaires
Hi Heather, I read your post and your answer. Got two clear ideas: 1. generic approach / pattern is not clear or valuable. 2. current questionnaires might need a semantic review / corrections to check if a. questions are correctly asked, b. possible answers correspond to the question, c. the goal of the questions is clinical or has other goal, and that can determine if that question/answer should or not be part of the EHR In my specific case, the scope might be narrower: + consider all questions are correctly modeled and answers correspond to questions + need the content to be archetyped and the data to be in the openEHR IM + most answer types will be boolean, coded text, text, and their null flavours Since no generic approach might be possible, it might not be so bad to have a generic archetype for the questionnaire definition, just as a framework, and do the custom work on templates. I thought about this for some time: 1. questions are elements with value alternatives for boolean, coded text, text 2. those elements have coded text names, that is where the question is specified, and codes can be custom (defined on templates) 3. of course, question occurrence is 1..* 4. on templates, specific occurrences are modeled, with specific codes for the element name, and those should have occurrence 1..1 (this should be possible in terms of the AOM/TOM but I doubt it is currently supported by modeling tools, I think TD doesn't have this) I know this is more an implementation idea, using standard modeling artifacts. But since there is no generic modeling for this, and the implementation needs to use the standard artifacts, I find this to be a not so bad solution. Opinions? :) On Mon, Jun 5, 2017 at 2:51 AM, 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- >
Re: Questionnaires
Hi all, First of all, I largely agree with Heather re the current approach. At freshEHR, we generally try to maximise the use of international 'semantic' archetypes, including scales, scores etc but accept that this is often not necessary and that there is place for simply modelling aspects of the questionnaire as-is. Commercially, I am interested in how we might make use of , or at worst, play nicely with the FHIR Questionnaire resources. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 5 June 2017 at 10:05, GF <gf...@luna.nl> wrote: > Hi, > > A few of generic ideas around the question-answer pair. > > There are several kinds of question-answer pairs: > - The general generic pattern is the pair: question - answer; > - The questionnaire can be one or more question-answer pairs; > - The questions can be locally defined or regionally, nationally, > internationally used; > - Answers can be* free text*, *quantitative* (number, code), > *semi-quantitative* (derived from a categorised set of possible answers > using inclusion and exclusion criteria) or *qualitative* (present, not > present); > - Answers can be aggregated by means of category, mathematical formula. > > This list of kinds of questionnaires ranges from simple to very complex > patterns. > Some are simple statements others are very complex scales and > questionnaires in between. > They are all variations on a theme. > Any answer can expressed in the in-line local form and/or with a reference > to an external source. > > > Gerard Freriks > +31 620347088 <+31%206%2020347088> > gf...@luna.nl > > Kattensingel 20 > 2801 CA Gouda > the Netherlands > > On 5 Jun 2017, at 07:59, Grahame Grieve <grahame@healthintersections. > com.au> wrote: > > 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 > > > > ___ > openEHR-technical mailing list > openehr-techni...@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org > ___ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
RE: Questionnaires
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-techni...@lists.openehr.org> Cc: For openEHR clinical discussions <openehr-clinical@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-techni...@lists.openehr.org<mailto:openehr-techni...@lists.openehr.org>> Subject: Re: Reports - a new openEHR RM type? Besides spe
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> 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 classifica
Questionnaires
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-techni...@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
