Hi, 'Questionnaires’ is a problem.
The spectrum ranges from - simple lists of questions and answers to - questions and answers that depend on other input from previous question/answers or data in the database and questionnaire answers that can be aggregated in one result. Answers to questions sometimes will be queried and others are not. Sometimes one question allows one answer, sometimes more than 1, sometimes questions are optional, sometimes not. Sometimes these answers and questions play a role within the questionnaire, sometimes they are used on their own outside. Sometimes the aggregated results will be queried. Sometimes questionnaires are used locally for administrative reasons, sometimes they act like any other clinical test. All these give rise to requirements for possible solutions. ‘Intelligent’ questionnaires I consider out of scope, for the moment. And - I think- the problem is tractable on the condition that the questionnaire is modelled as CLUSTERs. With one CLUSTER/pattern to allow the optional aggregated result and define the components of the questionnaire. This organising CLUSTER/pattern makes use of CLUSTERs/patterns for each question/answer pair. These CLUSTERs are topics that can be queried. One must allow that queries start at the CLUSTER level. It must be possible to query the aggregated result and the individual topics. The same problem is encountered with Lab. Panels. So the quetionnaire nut meeds to be cracked. Gerard Freriks +31 620347088 [email protected] Kattensingel 20 2801 CA Gouda the Netherlands > On 6 Jul 2017, at 06:40, Heather Leslie > <[email protected]> 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. > > 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. > > 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. > > 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. 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. > <> > Maybe I’m missing something… > > Heather >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
