Re: Questionnaires

2017-07-05 Thread Pablo Pazos
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.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.org>
> *Subject:* Re: Reports - a new openEHR RM type?
>

Re: Using aql for data set in DV_CODED_TEXT

2017-07-05 Thread Pablo Pazos
Hi Dileep,

You are mixing modeling/design with implementation/runtime. Archetypes can
define terminology bindings at design time. Those should be resolved at
runtime.

You can just create other files with AQLs, and another file that maps
archetype paths to the AQL files. Your app will be able to load the
archetype, load the AQL and execute AQL to resolve the term subset for each
DV_CODED_TEXT in your archetype, and use that on a GUI.

Of course files are just examples, implementation can be at a database
level.


Hope that helps :)

On Wed, Jul 5, 2017 at 9:23 AM, Dileep V S  wrote:

> HI,
>
> I am just wondering if it is possible to embed an AQL into the archetype
> so that the data set for a DV_CODED_TEXT is formed out of existing
> compositions.
>
> For example, a hospital registration form that asks for a person's
> allergies. Instead of an empty field, it can be populated from existing
> data through a query so that the front desk can just validate the data. Can
> this be modeled into the archetype? Or should it be an implementation
> detail?
>
> regards
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113 <+91%2096328%2088113>
> a: 103, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> ___
> 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://www.cabolabs.com
pablo.pa...@cabolabs.com
Subscribe to our newsletter 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: Using aql for data set in DV_CODED_TEXT

2017-07-05 Thread Bjørn Næss
Hi 
We have implemented this in the form based on the operational template. 
Then we put reuse information with AQL to query structures to be reused for 
different purposes. 
Works perfectly well :-) 

Regards
Bjørn Næss
Product owner Arena EHR 
DIPS ASA

Mobil +47 93 43 29 10

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Pieter Bos
Sent: onsdag 5. juli 2017 16:01
To: For openEHR technical discussions 
Subject: Re: Using aql for data set in DV_CODED_TEXT

It could be an application detail.

Or in ADL 2 it can be a query function in the rules section, as defined in the 
specs. Not sure if you want this in basic archetypes, but you can certainly do 
this in adl 2 templates.

I'm not sure what you can do in GDL.

Regards,

Pieter Bos
Nedap Healthcare

Op 5 jul. 2017 om 15:16 heeft Bakke, Silje Ljosland 
>
 het volgende geschreven:

Hi Dileep!

Functionality like you describe should be part of the application 
implementation, not the archetype.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes Nasjonal IKT HF, Norway 
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: Wednesday, July 5, 2017 2:23 PM
To: For openEHR technical discussions 
>
Subject: Using aql for data set in DV_CODED_TEXT

HI,
I am just wondering if it is possible to embed an AQL into the archetype so 
that the data set for a DV_CODED_TEXT is formed out of existing compositions.
For example, a hospital registration form that asks for a person's allergies. 
Instead of an empty field, it can be populated from existing data through a 
query so that the front desk can just validate the data. Can this be modeled 
into the archetype? Or should it be an implementation detail?
regards
[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

Dileep V S

Founder

HealtheLife Ventures LLP

m:

+91 9632888113

a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100

w:

healthelife.in  e: 
dil...@healthelife.in


___
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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org


RE: Using aql for data set in DV_CODED_TEXT

2017-07-05 Thread Bakke, Silje Ljosland
Hi Dileep!

Functionality like you describe should be part of the application 
implementation, not the archetype.

Kind regards,
Silje Ljosland Bakke

Information Architect, RN
Coordinator, National Editorial Board for Archetypes
Nasjonal IKT HF, Norway
Tel. +47 40203298
Web: http://arketyper.no / Twitter: 
@arketyper_no

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Dileep V S
Sent: Wednesday, July 5, 2017 2:23 PM
To: For openEHR technical discussions 
Subject: Using aql for data set in DV_CODED_TEXT

HI,
I am just wondering if it is possible to embed an AQL into the archetype so 
that the data set for a DV_CODED_TEXT is formed out of existing compositions.
For example, a hospital registration form that asks for a person's allergies. 
Instead of an empty field, it can be populated from existing data through a 
query so that the front desk can just validate the data. Can this be modeled 
into the archetype? Or should it be an implementation detail?
regards
[https://drive.google.com/uc?id=0BxQc41y9yqs6bkE5a1JQQVBjZG8]

Dileep V S

Founder

HealtheLife Ventures LLP

m:

+91 9632888113

a:

103, Innovation Centre, IIIT, Electronics City, Bangalore 560100

w:

healthelife.in  e: 
dil...@healthelife.in


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org