gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] emrjounalplugin.py comments further html work


From: Ian Haywood
Subject: Re: [Gnumed-devel] emrjounalplugin.py comments further html work
Date: Tue, 20 Sep 2005 08:10:54 +1000
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050912)


Karsten Hilbert wrote:
-----
>>The pros and cons of *partitioning* the data contained within any one 
>>visit (encounter) into parts each attached to the "owning" issue. 
>>There may be a *design tension* here between what's advocated by 
>>technically correct designers, who strive to maximize the exactness 
>>or precision of a data relationship versus what is "good enough" and 
>>much more satisfactory to get the "work" done.
I disagree.

Ulimately, why are we linking notes to episodes, to organise the
clinical history for convience, not a pure pharmodynamic statement
about what systems are effected by the drug. So, the clinician
has to choose the "main" problem for the given comment,
if they really can't, IMHO it is better to have no linked
porblem than multiple linkages.


>>So if at a visit a patient was initiated on an angiotensin converting 
>>enzyme inhibitor at a visit where diabetes, hypertension and heart 
>>failure were pertinent, does it matter which one (or more) problems 
>>were the "indication". Even if we care (because we might) is there 
>>some way to capture this other than by partitioning the contents of 
>>the note into separate problems? After all, maybe the drug is 
>>selected to treat all three (supposing they have proteinuria [setting 
>>aside if that should be separate]) but we certainly don't want to 
>>have to repeat the drug three times, once in each partition.
This is an edge-case, if the clinician found the patient had 3 simultaneous
and equally-compelling indications for ACEI.

In reality one indication is usually "first", either in time or in importance, 
usually hypertension in this case.
To keep the backend (and the UI sane) edge-cases must sometimes be sacrificed 
on the altar
of simplicity.

> - have a table clin_aux_narr2epi which allows for additional
>   episodes/problems to be linked to this clin_root_item
>   (eg clin_medication)
The linktable should be used *instead* of clin_root_item.fk_episode if we are 
going to do that.
Firstly, the concept of a "primary" linked episode and "secondary" links
is too complex by half, and secondly it confirms my points above.

> - make the prescription widget allow to select further
>   episodes/problems to be attached
If we have multiple tabls and popup script widgets, then we already know which
episode to link to.
Why select again for scripts? (my current software does this,
it gts annoying vry quickly)


Ian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]