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.open
ehr.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.or
g/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.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-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-tec
hnical-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-techni...@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 <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-techni...@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.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-techni...@lists.ope
nehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
ehr.org
--
-----
http://www.healthintersections.com.au /
grah...@healthintersections.com.au<mailto:grahame@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@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
ehr.org
------------------------------
End of openEHR-technical Digest, Vol 64, Issue 4
************************************************
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-
boun...@lists.openehr.org] On Behalf Of William Goossen
Sent: Monday, 5 June 2017 4:45 PM
To: openehr-technical@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@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-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.or
g/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.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-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.leslie@
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-tec
hnical-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-techni...@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 <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-techni...@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.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-techni...@lists.ope
nehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open
ehr.org
--
-----
http://www.healthintersections.com.au /
grah...@healthintersections.com.au<mailto:grahame@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@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@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-
technical_lists.openehr.org
