[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Inf
Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info
Thu, 2 Dec 2004 21:10:47 +0100
> Ah, I really get the passion in your reply, or perhaps irritation or both.
Passion. At times a bit of wondrous disbelief mixed in.
> I've discussed this ad-nauseum with malcolm Ireland (BTW I attatch a quick
> reply he sent to me last week - which is equally equivocal about what to do
> because of lack of any recognised good solution). Malcom''s considered
> opinion is that it is impossible to transfer the paper paradigm to the
> electronic medium. He made the interesting comment to me on the phone the
> other night when we discussed it at lengh again, that he beleives that once
> we have a generation who have been brought up entirely paperless, then some
> bright spark will (not constrained by the paper paradigm cemented in their
> brain) come up with a good way of doing it electronically. Until then,
> anything is better than the current crop of abysmal software.
He's probably right. Also, for 0.1 let's concentrate on that
"anything" being better than what exists. Let's keep your even
better designs for 0.2.
> Sorry, but maybe I've just totally mis-understood, as I'm not involved with
> the backend stuff. Do you mean that the SOAP (or whatever) doesn't matter if
> there are 4 lines or 10 different types of lines, that the existing code will
> save them appropriatley to the database?
Precisely. Any narrative row will be saved under one of the
SOAP types. Any such row can be adorned with more types if
wanted. For the "SOAP" widget it is going to be configurable
by the user along the lines:
'OK, give me one input field with the label "Patient Request",
make the basic type of that be "S" but also attach the types
"RFE", "unsolicited history", "patient problem" to that row
The label would be chosen freely by the user. The number of
thusly defined fields could be chosen freely by the user. The
types to be attached to said fields can be freely chosen by
the user from the available types (which are, again,
configurable with reasonable defaults). The user would thus
configure "her" SOAP widget once and use that without worrying
anymore about type-ing the data later when using the widget.
All fields would have one of SOAP, however. There may be more
than one field of any of SOAP per widget.
The Save-parser would need to be taught
a) how to save any of type SOAP
b) how to parse out and handle data from popup edit areas
c) how to attach additional types to the rows in the DB
Does that make sense ?
> Nothing about the consultation is 'objective' anyway.
I know :-)
> The importance I think of separating the patients dialog from the doctors
> dialog, is that it keeps in the forefront of the doctors mind what the
> patient wants.
I do see why your way of separating things is useful. I am
just being strict on the technical implementation thereof.
> I think to look at the Patient Request is interesting. I've been actively in
> clinical practice now for (shudder) 28 years. I've found over the years that
> despite 'sorting out' the history I had obtained from the patient, come to a
> diagnoses, implemented management, that at the end of the consultation I
> often got a sense of 'incompleteness'
Sometimes even us younger docs get that feeling... :)
> As the years rolled by I realised (I'm a slow learner) that what I wasn't
> doing despite all my training, was really finding out at the beginning what
> the patient wanted to get out of the consultation - which was often very
> different from their presenting complaint as we all know.
Likely this is due to the perception of our "mission". Is it
to do "the Right Thing for the patient's afflictions" ? Is it
"the Right Thing for the patient"? Or is it "what the patient
wants" ? Likely it's a difficult balance between all three,
Malcolm Ireland's notes are spot on !
> Then came SOAP - where the notes
> were divided into subjective, objective, assessment and plan. This was an
> improvement for GPs,
> but still only fits a proportion of visits, and there is argument as to what
> fits where (eg, when a detailed history
> is "extracted" with some difficulty from the patient, is that S or O?
Does it matter that much ? Go by the feeling of it at the time
of consultation. In GnuMed all narrative is searchable
regardless of attached types anyways.
> It also fails with brief consultations
> such as BP check wth repeat prescription, or when the patient's presentation
> and the GP's reason for seeing them
> are different.
> It does not fit well with current preventive strategies.
Why ? There's an RFE and an outcome. There's also a "problem".
Which is what Malcolm says below:
> I did a small study of GP notes some years ago, and learned that GPs recorded
> fairly consistently why the patient came (?S),
> and what was done (?P).
> The processing in the middle (O and A) was very inconsistent. Whether
> this is good or bad is not the question - it is reality.
And hence we don't force the user to input something there.
> Can I describe a generic consultation?
> What was I thinking (A) - do I actually record this? Am I thinking I
> don't have a clue,
> but I don't think its serious and will see what happens over the next few
> days. Do I record my ignorance?
I sure do. I try to note down WHY I think I don't know, too,
eg: consult! read! lack of data!
> I haven't discussed the problem oriented medical record. We're supposed to
> allocate a problem (or more)
> to every visit), and know if they're curent, resolved, continuing etc.
But we can conveniently use catch-alls for when we don't know.
> Anyone who has tried to do
> this knows haw difficult it is. What do you do with the patient who doesn't
> seem to know why they
> came, who you can't work out why they came, but who leaves happy with the
> consultation and
> appears to have had some need satisfied?
I record precisely that ! Yeah, I know this type of patient... :-)
Best served at 3am which let's you hit the sack bedazzled
I think the worse case is when that happens but the patient
leaves dissatisfied. I then try to have the guts to tell them
that I don't have a clue what I can do for them but that they
appear to have *some* problem or other and that I'd advise
them to either come back or see someone else. I also document
that fact (unless I forget).
> In summary, any structured format works much of the time, but there are many
> exceptions when it
> fails. The tendency is to "fill in the boxes", even though its not exactly
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346