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
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
