gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Inf


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info
Date: Wed, 1 Dec 2004 21:56:43 +0100
User-agent: Mutt/1.3.22.1i

> > Ian, can we simply add a "type" field to the soap2 __init__
> > args that types the labels the user supplies ? Eg. If I wanted
> > to name a field "what ran on TV while I didn't listen to the
> > patient's boring account of his presenting complaint" - so be
> > it - but let me attach a type "S" to that field. The type can
> > be used to constrain phrasewheel matches, popup edit areas,
> > and available codes, too, and it should be handed out with the
> > dict entries from GetData(). The post-processor for saving the
> > stuff will/should build on that.

> Certainly, however (I assume) Richard would like these labels
> also used when displaying the notes
Ah, I didn't think of that. But also I don't see a problem.
Below is why.

> if two labels map to type 'S', how are those clin_narratives separated
They are not separated by SOAP type. Remember how I tried to
explain that I see SOAP as a data type, not a data source
identifier or comment on the quality of the data stored. Both
of "Patient Request" and "History Taken" will end up under
"S"oap. However, if one wants to keep them discernible one
would need to employ *additional* typing via lnk_type2item. In
there one could attach any type including "presenting
complaint" and "history as taken by the clinician pertinent to
the presenting complaint" to the SOAP rows. Now, Richard is of
course right to tell us that no user is ever going to be
manually inputting such typing. We would need to find a way to
tell the SOAP widget any additional types that should be
passed on to GetData() to be attached to the rows in question.
I don't see this as a problem, technically, though. Those
types would then automatically be attached to the rows and could
be used in filtering (and display) later. Appropriately
crafted types would allow to reconstruct the labels Richard
might want.

Anyways, I still hold the belief that the "SOAP" types are of
sufficient fundamentality to be included in clin_root_item
(and hence clin_narrative) directly. I do admit that
is_rfe/is_aoe might be moved to being "just another linked
type" if that's what people think is necessary.

> (IOW, we need five clin_root_item types, not four)
Hm. If we start doing that where are we going to stop ? Also,
where's the fundamental difference in quality between "Patient
Complaint" and "History Taken" ? Both are narrative of
*subjective* quality. Which is the only thing separating them
from sOap (eg. Clinical Findings) which are *objective* items.

> Personally I think we should add a fifth type ("H"?),
> after all, you don't have to use it if you don't want to.
I understand you are getting me here with my own argument :-))

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]