Questionnaires

Grahame Grieve grahame at healthintersections.com.au
Mon Jun 5 01:59:26 EDT 2017


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.leslie at 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-
> bounces at lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Thursday, 1 June 2017 12:58 AM
> *To:* For openEHR technical discussions <openehr-technical at 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 <gfrer at 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>
> gfrer at luna.nl
>
>
>
> On 31 May 2017, at 06:54, Pablo Pazos <pablo.pazos at 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 at 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.pazos at cabolabs.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>



-- 
-----
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170605/1cd4c49e/attachment-0002.html>


More information about the openEHR-clinical mailing list