gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] The 1,2,3's of SOAP for multiple problems-2


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] The 1,2,3's of SOAP for multiple problems-2
Date: Wed, 24 Nov 2004 11:59:14 +0100
User-agent: Mutt/1.3.22.1i

> I am referred a patient with (or GP receives a patient newly-moved to 
> the area bringing to attention their) hypertension and hypokalemia. 
> Their known issues/history , in order of interest to me, are:
> 
> 1995 hypertension
> Hx asthma
> arthritis L knee
> on hormonal replacement (post-menopausal)
> 1994 s/p Nissen fundoplication (GE reflux)
> 1956 s/p sinus surgery
> 1989 s/p foot surgery
> - note hypokalemia had not, in the referral, been expressed as "past 
> history"
IMO it likely isn't a past history item per se but rather
feels like a symptom of an underlying health issue. Mind you,
that issue may not be known yet. Also, it can truly go
unexplained for longer in which case one would enter a
"temporary" (eg. expected to be replaced/merged later) issue
such as "hypokalemia OUO" or "idiopathic hypokalemia ?cause".
As long as it can't be attributed it does warrant being
entered as an issue even if it will turn out not to *be* the
core issue.

> I would be tempted to input as health_issues
> - hypertension (maybe 'hypertension with hypokalemia')
> - asthma (pertinent to drug choices for BP)
> - arthritis L knee (pertinent to ?NSAID use affecting BP)
> A GP being likely to have to refill the HRT may want that issue to 
> stay in view.
Sounds fair.

> The other items however I am less inclined to make as "issues" 
> because I may not want them in my "field of view" at each visit 
> unless I am prompted by some clinical uncertainty or review to expand 
> that view. So if they are to be added as issues, it would be nice to 
> make them inactive or otherwise filterable.
Well, just mark them inactive, then ? And they are, likely.

> But if later her asthma flares and it turns out GE reflux has 
> reactivated, the issue "GE reflux" could be created, but I would feel 
> stupid if I lose sight of (and the patient must remind me, because it 
> was out of view) that theirs was a well-known prior problem. Easily 
> avoidable if it was just a matter of "show all" among the patient's 
> total listing of issues.
That's the intent of is_active.

> But harder if for every symptom that "seems" 
> new (at least to us), we must manually check a lot of areas *in case* 
> there is something there:
Well, that can easily be avoided: Issues that feel like issues
get entered as issues (with or without attached narrative).
Mark active/inactive as needed. Issues that don't really feel
like issues and which the doctor does want to keep recorded
could always be stored as either episodes or narrative under a
dedicated issue "further past history". So, two (IMO logical)
places to check for seemingly new items.

> - filtered issues
> - unfiltered issues (in case something needs to be resurrected)
That's your "show all".

> - episodes that did not get attached to an issue
Well, "our" "problem list" is intended to include unattached
episodes (but show them only depending on is_open - "show all"
would bring them into view alongside inactive issues). Ian,
I'll explain that "problem list" in a minute. Please ask back
if I forget.

> - diagnoses (sorry, not sure if they are part of a composite view)
> - soap notes for anything that was put there but neither made an 
> issue nor linked to a diagnosis (depending on the answer to my prior 
> email about other tags in soap notes)
> - medications
> - anywhere else?
Well, the user can't be forced to put data in particular
places. If one doctor of all things wants to put important
data into vaccination comment fields he can, but hey.

> To Richard's point, non-developer doctors may have a harder time than 
> us to make instinctive (or to reason out by force of will) gnumed's 
> data-constructs for the various places that have to be looked at.
I trust that if we distill that properly on the list we can
make intuitive GUI widgets that guide the user where to put
what.

> Anything to make it easier for them to not "miss" key info when in 
> "re-think" mode (composite view on-demand?, maybe a suitable tree 
> could do this?) could be helpful.
suitable tree ... sounds like an attractive idea, actually ...
for v0.x ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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