openEHR-technical Digest, Vol 64, Issue 4

Pablo Pazos pablo.pazos at cabolabs.com
Mon Jun 5 03:54:46 EDT 2017


I'm not so sure about this s but here we go:

I don't think that the question/answer format of a record really defined
that is indeed a questionnaire. Sometimes that is just due user interface
design.
If the record needs modeling question definitions and their possible answer
types or answer alternatives, that might be indeed a questionnaire.
In the other hand, if the records don't need the question definitions, just
the content definition e.g. entries, that mighty be a normal clinical
record.

If we don't consider this, anything can be defined as a questionnaire, and
that would be a useless generalization for both software development and
Interoperability. And in some cases would be incorrect, for example
questionnaires AFAIK don't contain time series data or maintain state of
ongoing talks (both examples are related with time related data).

This topic is a good conceptualization exercise!

On Jun 5, 2017 3:52 AM, "Heather Leslie" <
heather.leslie at oceanhealthsystems.com> wrote:

> 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:openehr-technical-
> bounces at lists.openehr.org] On Behalf Of William Goossen
> Sent: Monday, 5 June 2017 4:45 PM
> To: openehr-technical at lists.openehr.org
> 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 openehr-technical-request@
> lists.openehr.org het volgende geschreven:
> >
> > Send openEHR-technical mailing list submissions to
> >    openehr-technical at lists.openehr.org
> >
> > 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
> >    openehr-technical-request at lists.openehr.org
> >
> > You can reach the person managing the list at
> >    openehr-technical-owner at 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 <grahame at healthintersections.com.au>
> > To: For openEHR technical discussions
> >    <openehr-technical at lists.openehr.org>
> > Cc: For openEHR clinical discussions
> >    <openehr-clinical at lists.openehr.org>
> > Subject: Re: Questionnaires
> > Message-ID:
> >
> > <CAG47hGYpmSi1U1Znhheoh_YMZ841m7MLVWd6hGccUfsy-vQmHw at 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.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-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 <heather.leslie at oceanhealthsystems.com>
> > To: For openEHR clinical discussions
> >    <openehr-clinical at lists.openehr.org>,    "For openEHR technical
> >    discussions" <openehr-technical at lists.openehr.org>
> > Subject: RE: Questionnaires
> > Message-ID:
> >
> > <SY3PR01MB19131A7C8E2E230285779C6EEACA0 at 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:openehr-clinical-bounces at lists.openehr.org] On Behalf Of
> > Grahame Grieve
> > Sent: Monday, 5 June 2017 3:59 PM
> > To: For openEHR technical discussions
> > <openehr-technical at lists.openehr.org>
> > Cc: For openEHR clinical discussions
> > <openehr-clinical at 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.leslie@
> oceanhealthsystems.com<mailto: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<mailto:openehr-tec
> > hnical-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<mailto:openehr-technical at lists.op
> > 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 <gfrer at luna.nl<mailto: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<tel:+31%206%2020347088>
> > gfrer at luna.nl<mailto:gfrer at luna.nl>
> >
> > On 31 May 2017, at 06:54, Pablo Pazos <pablo.pazos at cabolabs.com<mailto:
> 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<mailto:openEHR-technical at lists.ope
> > 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/>
> > pablo.pazos at cabolabs.com<mailto: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<mailto:openEHR-technical at lists.ope
> > nehr.org>
> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
> > ehr.org
> >
> >
> >
> > --
> > -----
> > http://www.healthintersections.com.au /
> > grahame at healthintersections.com.au<mailto:grahame at 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
> > openEHR-technical at lists.openehr.org
> > 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
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> technical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20170605/01123ee5/attachment-0002.html>


More information about the openEHR-technical mailing list