gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] guidline routed diagnostic in GNUmed


From: Richard Terry
Subject: Re: [Gnumed-devel] guidline routed diagnostic in GNUmed
Date: Wed, 20 Sep 2006 08:41:14 +1000
User-agent: KMail/1.9

Philipp,

snip.....

I'd be interested in who you are - age - quals - what you do, so I can pitch 
my reply to you.

However:

> A guidline-programm for that purpose needs a data input mode, which does
> not disturbe the doctor/patient contact.
>
> The quickest way of data input in medicine is via keyboard, without mouse.
> But this means: both hands on the keyboard, concentrated on tipping into
> the keyboard. That is OK after having done my diagnostic chat with the
> patient. The patient does accept this interruption for administrative
> means.

Perhaps this is cultural, perhaps not. This has been well studied many times, 
and it is generally thought that doctor typing on the keyboard is not 
necessarily problematic for the patient if done in certain ways.

Office should be setup so that the patient sits side -by side with the 
doctor/desk, and patient can see the screen which the doctor is accessing. 
Patients in computerised practices soon get used to the concept (after all 
they all use them in their work/homes anyway). They quickly see the 
advantages of clearly entered information, provision of printed material etc.

If you spend time with the patient first, and when using the keyboard actually 
let them know that you will now be doing that, it seems not to be a problem.


>
> But hacking into the keyboard  while speaking to the patient, with both
> hands on the keyboard, having a glimps over the shoulder to the patient
> is'nt what Balint would have done when speaking to the patient.
>
> So I think, for that part of dhe docter-patient-contact the better way of
> entering datas from the diagnostic chat into GNUmed would be to only (or
> predominantly) use the mouse.

using the mouse is grossly inefficient, and  programs designed to enter 
clincial information by point and click at check boxes, option buttons etc, 
quickly become a dogs breakfast of gui design.
>
> Do we need to enter data while doing the diagnostc/therapeutic chat?

Often not! see above

>
> If we want our diagnostic chat beeing guided through a program, we have to
> enter data direct in front of the patient.
> This has to be done in a way, which does not or very few disturb the chat.
>
> How can we use the mouse to move thum-nail images of the symptoms of the
> patient's request on to an image of the human? It is not possibel in that
> simple way. But if we could divide and organize that process I have the
> idea, that we could manage it.

Interesting idea.  See my previous post about html/richedit control + embedded 
images
>
> This is, what I would like to test.
>
> The next question is: how can we provide guidance through the diagnostic
> process without a steep and inflexible sequence of question?
>
> How could it be that GNUmed knows now which filds I need to enter now?
> Which question have to be asked?
>
> When we are able to enter data while speaking to the patient, in a way,
> that does not disturbe the doctor-patient-contact, the Gnumed-programm
> could be able to think with us. Gnumed could be able to acompanay us in
> this diagnostic process (=Guidline). Gnumed should be able to offer fields
> to take up data whenever we need them. Like a good nurse during operation,
> knowing which instrument the docter will need now.
>
> A huge database would be necessary to save these diagnostic gatewayes.
> A self-learning programm would be necessary to learn these informations.
>
> Certenly this is a future project.
>
> But what I would like to start with now is to test, if the first approach
> is possible.
>
> As I am new in python and object oriented programming, I am not able to
> start this project on my own. Not now. But may be later :-)
>
> My question is: Does anyone know python source-code, that has realized to
> put graphical thum-nail-objects (could be the graphical sign for pain in
> our example) to some graphical surfice (could be  the image of human beeing
> in our project). By positioning this object at a given position the
> following programmflow will depend on what is spicified on that position
> point. That means: The object "pain" will behave different on different
> locations.
>
> I would like to play with such a initial test-programm to see, if we can
> find a way of concentrating the many possible question at the beginning of
> a diagnostic chat to some few symboles.
>
> And I would like to learn object oriented programming with this example.
>
> Is this how the pink panther is thinking? Unrealistic? May be.
> But I am a phantast. And optimist. :-)

Keep un the enthusiam. 

You may not be that well versed in this list. I've bashed my head against the 
wall trying to get far simpler and more universal concepts incorporated into 
gnuMed without success. As such I cannot see gnuMed ever getting anywhere 
much. It is still essentially unusable in its current state, but good luck.

If you are interested, have a look at the stuff I wrote starting back in 1995, 
completed around 1997 - donated to gnuMed and not used: see 
www.gnumed.net/rterry/Index.htm. Had this been taken up gnuMed would have 
been well and truly usable and in many thousands of offices right now.

Richard Terry 
GP NSW Australia.
>
> Philipp Walderdorff
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel




reply via email to

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