Questionnaires

Pablo Pazos pablo.pazos at cabolabs.com
Thu Jul 6 04:01:15 EDT 2017


Hi Heather,

See between your lines.

On Thu, Jul 6, 2017 at 1:40 AM, Heather Leslie <
heather.leslie at oceanhealthsystems.com> wrote:

> Hi Pablo,
>
>
>
> From my POV the critical words in your email are “(defined on templates)”.
> If we have to define the semantics of each questionnaire in the templates,
> why not just archetype it and lock it down at that level.
>

I was considering what you said about not modeling questionnaires at all on
your blog post, and making my mind around the need of some level of
modeling, considering that most questionnaires are not general purpose and
very heterogeneous, also have a great number of them (also mentioned on
your post).

Since archetypes are general purpose, my proposal was to have on archetypes
just the basic building block that allow us to create specific templates,
as it seems to be most questionnaires might be context-specific.

So in my propose "model" archetypes are not even generic questionnaires,
but abstract question definitions.


>
>
> In a generic questionnaire every data element will have to be an ‘Any’,
> defined in the template; the questions will need to be added, the relevant
> values defined etc.
>

I agree that Any should be the ELEMENT.value for a generic question. My
focus was on the 80% of the types I saw on real questionnaires that are
boolean, text or coded text.
But we should also follow common sense. For example I don't thing parsable,
multimedia, ehr uri, ... should be valid types for this. But I can see
count, identifier, date, and even interval<date> to be valid on some
contexts.


>
>
> AND the biggest problem for me is defining the pattern for the generic
> questionnaire – every time I’ve tried to design a flexible pattern that
> allows various levels of nesting under cluster headings for questionnaire
> groupings etc I get tied up in knots. There is no one single solution that
> will cover all questionairres – simple tree structures will not provide the
> solutions we need.
>

That is tricky. Most if not all the questionnaires I saw are not nested,
that is why I mentioned just ELEMENTs, what I was saying implicitly is to
have just ITEM_LIST.


>
>
> We could use a generic OBSERVATION container and a simple CLUSTER that
> allows multiple instances of a question with an ‘Any’ data type and a SLOT
> for nesting further instances.
>

I think OBSERVATION and ADMIN_ENTRY should be valid "question" containers,
it gives a little more semantics that can be used for querying, and some
times questionnaires are 100% administrative. A possible model would be:

OBSERVATION (Obs. Quest.)
|_ITEM_LIST
  |_SLOT (Question) occur. 1..*

ADMIN_ENTRY (Obs. Quest.)
|_ITEM_LIST
  |_SLOT (Question) occur. 1..*

ELEMENT(Question)
|_DV_CODED_TEXT (name - defines the question and allows querying by code)
|_ANY (value)

COMPO (Questionnaire)
|_SLOT (Obs. Quest.)
|_SLOT (Admin Quest.)


Template
|_COMPO
  |_OBSERVATION
    |_ITEM_LIST
      |_ELEMENT
        |_Cancer history in family? (code=1234)
        |_Boolean
...
... more questions, even mixing OBS and ADMIN containers
...


One thing I'm not sure on that model is how to represent multi-valuated
answers (e.g. if you have any chronic disease, please specify which one(s):
asthma, food allergy, hypertension).
Maybe repeating the ELEMENT with the same name is a good solution, and GUI
can show just one question with many answers.

Another thing is if we really need to allow nesting, maybe define two
archetypes: ITEM_TREE and ITEM_LIST, so we have some flexibility on
templates, who needs nesting will use TREE, simple mortals like me will use
LIST :)



> But the modelling overheads are onerous and I’m still struggling to see
> the value in pushing the work to the template design rather than just
> archetyping it. I’ve attached an example to show a possible pattern – but
> it is SO MESSY with renaming of every data point, constraining every aspect
> of each question (just as you would in a de novo archetype) and the
> overheads of explaining how to build a template from a generic pattern and
> define every single part of it in the template seem not worth the benefit.
>

I prefer to have just the basics on archetypes, we need that either way to
create templates, and do the rest on templates because there is not much to
reuse or define in a generic and globally valid way. IMO this follows the
design principles of archetypes vs. templates.


>
>
> Maybe I’m missing something…
>

We all miss something, still this is a good exercise. I don't think anyone
here has this figured out, not me for sure :)


>
>
> Heather
>
>
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> bounces at lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Thursday, 6 July 2017 12:05 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,
>
> 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.leslie@
> 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 <099%20043%20145>
> 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
>
>
>
>
> --
>
> Ing. Pablo Pazos Gutiérrez
> Cel:(00598) 99 043 145 <099%20043%20145>
> 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
>



-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170706/4ec688cf/attachment-0002.html>


More information about the openEHR-clinical mailing list