Hi Ian,
SECTION.Questionnaire
OBSERVATION.PreopQuestionnaire.v1
Relevant medication (DV_CODEDTEXT)
Atenolol Y/N
Furosemide Y/N
Aspirin Y/N
How this would be implemented?
Just by setting Occurrences to Repeating-Limited 3-3 for Relevant
medication (DV_CODEDTEXT) can I have those three Y/N options? How
would that be reflected in the GUI? what I can see now is just one
time of this drop down list in the GUI represented in the Archetype
Editor
-Regards
Pariya
On Jun 1, 2009, at 11:57 AM, Ian McNicoll wrote:
> Hi Pariya,
>
> If I have understood correctly, you are suggesting something like
> this...
>
> Relevant medication
>
> Atenolol Y/N
> Furosemide Y/N
> Aspirin Y/N
>
> This is a typical instance of a 'Questionnaire-type' question. In
> contrast, all of the current major health information
> representations use a 'Clinical Statement' pattern. e.g openEHR,
> HL7v3, Snomed-CT
>
> Relevant medication
>
> Medication = Atenolol
> Medication = Furosemide
> Medication = Aspirin
>
> i.e the list is created as a series of assertions, rather than being
> a set of Y/N answers to a fixed list.
>
> For interoperable queryability, it is important that the clinical
> statement pattern is maintained when the data is persisted e.g
> Asprin= Y must be mapped to Mediation=Aspirin.
>
> Handling the negative e.g. Aspirin=N, is more problematic. In
> general, clinicians do not need to record negatives for long-term
> queryability but some negatives need to be recorded for medico-legal
> purposes and are more common in research questionnaires.
>
> Part of the difficulty here is that the use and purpose of
> questionnaires is often highly localised and the mapping
> requirements for each Question to an equivalent 'clinical
> statement' have to be analysed on a case-by-case basis. Just be
> clear that this is a feature of Questionnaires and not of openEHR -
> a recent HL7-CDA paper describes an identical problem.
>
> Our current working practice is to dual-model a Questionairre within
> a template, using a single archetype to represent all of the
> question-type nodes (often within section for clarity) and to model
> any equivalent clinical statement archetypes in a separate section.
>
> e.g.
>
> SECTION.Questionnaire
> OBSERVATION.PreopQuestionnaire.v1
> Relevant medication (DV_CODEDTEXT)
> Atenolol Y/N
> Furosemide Y/N
> Aspirin Y/N
>
> Relevant diagnoses (DV_CODEDTEXT)
> Heart disease Y/N
> Diabetes Y/N
>
> SECTION Clinical Statements
>
> ACTION.Medication.v1
> EVALUATION.problem-diagnosis.v1
>
>
> Unfortunately, this means that we have to specify how and when each
> Y/N answer resolves (or not) to a clinical statement.
>
> In general questionnaires are horrible but they are a reality in
> modern clinical recording practice which we have to deal with. I
> think in future years we will find ways to automate the process a
> little better.
>
>
> Ian
>
>
>
> Dr Ian McNicoll
> office / fax +44(0)141 560 4657
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian at mcmi.co.uk
>
> Clinical Analyst Ocean Informatics ian.mcnicoll at oceaninformatics.com
> BCS Primary Health Care Specialist Group www.phcsg.org
>
>
> 2009/6/1 Pariya Kashfi <hajar.kashfi at chalmers.se>
> Dear All,
> I have encountered a question regarding knowledge representation
> during archetype designing.
> Let's say a list of some special drugs that patient has used is
> important for Evaluation. I have two options here: First, to apply
> one external rule during the data entry, and mark the patient as e.g
> X-affected. Secondly, to represent this knowledge in Templates/
> Archetypes I am designing. It can be in the form of an Item-Tree-
> Medication-List using internal codes ( to specify medications that
> may be selected in the drug list). And to check this node at runtime
> or during evaluation of EHR for storage.
> It may even be a third option that I have not been considers so far
> i.d using internal rules (First Order Logic) within archetypes.
> The first option, sounds more general to me, and the benefit is that
> whenever I want to update rules, I don't need to change the
> arcehtypes/templates. And the second option sounds more natural to
> me in that I express the knowledge in archetypes directly, makes it
> more understandable for clinicians and can be modeled by themselves.
> Which one is more acceptable based on openEHR concepts?Do you see
> any flaws in these solutions?Is there any better idea?
>
> Regards
> Pariya
>
> MSc; PhD Candidate
> Department of Computing Science and Engineering
> Chalmers University of Technology
> http://www.chalmers.se/cse/EN/people/kashfi-hajar
>
>
>
>
>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Regards
Pariya
MSc; PhD Candidate
Department of Computing Science and Engineering
Chalmers University of Technology
http://www.chalmers.se/cse/EN/people/kashfi-hajar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090601/ac456502/attachment.html>
