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 17:30:53 +0100
User-agent: Mutt/1.3.22.1i

> As I said on the list a few days ago, having actually used the editing areas
> in multiple consultations, my preference is for starting with the undefined,
> soap, and adding tabs as needed, either as a review of old problems, or new
> problems (ie the multiple soap tabs) a la firefox browser approach, as per
> the png's I showed on the list.
As I said, I am fine with this and can imagine myself using
it, too.

> This works really well. Having a pre-defined
> number of SOAP's as per carolos's current implementation
It doesn't. You are getting something wrong there.

> Again I'd urge to to try this in an actual SOAP control in real-time over
> several days without prejudice. Karsten may be disciplined enough and capable
> enought to number each episode but no other mere mortal doctors will be. Also
> attatching an unnumbered SOAP episode to the last episode seems strange to
> me.  Surely, the consultation contents just become part of the progress
> notes. Why link it to a known problem when it hasn't been actively linked by
> the doctor?
Because no data *is* unrelated to a problem. Whether I know
that problem or not is a different matter. If I am the lazy
type of doctor not caring about problems/episodes and such
stuff I'll just use catch-all variants thereof. I can even
have a frontend written for me that does not even bother
giving me any choice anymore if I so desire.

> The major difficulty with your concepts of numbering problems is as I've
> alluded to, how are you going to ensure the user conforms?
I am not going to and I am not even interested in trying. I
won't be hiding the way of the warrior from you either. But
do I care whether you walk it ? It's you who's going to get
killed.

> Parsing will beome
> a nightmare. Ordinary people just don't do that. On paper yes - we do it
> every day because paper is well suited to that - but not electronically.
Tell you what I fail to see the difference. However, as I
said, I am fine with more structured approaches.

> By the way, I'm having a focus group next week with our local GP on 'data
> input paradigms in medical records', where I'm going to see what they think
> works (won't tell them about gnuMed and SOAP until after they do all the
> talking - and describe how they currently do it in their computer systems and
> what the problems are).
Sounds good.

> A further question - have members moved any further to looking at SOAP vs the
> other options I presented which seem to be more workable ie Patient History,
> Doctor History, Clinical Findings, Assessment, Plan + link to diagnosis.
For $Deity's sake, Richard ! We've re-hashed that just
recently. It doesn't matter one friggin' bit how you LABEL
your input fields !! The SOAP input widget doesn't care in the
least. It'll accept input and hand that input with some
formatting applied to the parser that's being invoked on Save.

1) I am fine with Carlos labelling the fields any way you see
   fit even in the very first release.
2) Of course, in Germany those fields won't be called
   "Subjective" or anything stupid like that.
3) The label/type-per-label of the input fields is going to be
   configurable to anyone's personal whims in v0.2.

> I know I keep labouring this point but I think it is really vital to move on
> from a basic SOAP control to something that will actually work in clinical
> practice - when consensus of those who have studied the SOAP method seems to
> be that it hasn't proved practical in clinical experience.
Please do explain the difference between the following. I am
simply to stupid to figure it out:

Subjective:     Patient Complaint:
Subjective:     History Taken:
Objective:      Clinical Findings:
Asessment:      Assessment:
Plan:           Plan:

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.

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]