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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090601/36cac38d/attachment.html>
