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

[Carlos Moro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Richard Terry wrote:

| I would urge you to actually put gnuMed stuff you are developing to
| the test in the clinical real-time, and I emphasise real-time,
| situation. But do so with a Zen 'beginners mind' - ie don't
| approach it with the attitude that what you have developed will
| work.

That will be a great moment and another development cycle will arise.
But, at the current moment i think the most  important tenet is
getting  (asap) some ui functional enough (not final) that can pass to
some pilote-testing deployment enviroments. We'll get then enough (a
lot, surely) feedback and we'll have time and testing experiences to
fix and pulish all needs...

| Note that I frequently do that - the tabbed mutliple SOAP concept
| being a classic. My gut reaction, because I think the sashed SOAP
| stuff sucks so much because it is so inelegant, was that it was a
| waste of time - yet I gave it a little thought - and an hours
| fiddling to write the code in between patients, and hey, I was
| impressed. Multiple SOAPs are really good - it is just how you
| implement them

It hasn't been implemented nothing but a first draft at the moment...
Let's give a try. Really, it's not so much time , and  it's not a
waste of time at all (trying new paths like the present is always
healthy), and it's sure a great part of the code and ideas can be
straightforward applied to other approaches (controller main window -
current leaft/future tabs... not so much design different), like multi
tab. I myself will write the multi-tabbed version after multi-sash
would be mostly done, there's not problem at all. But, just let us
give enough time, help and trust to code and improve... Don't doubt
we'll finally find satisfaction for all ideas... and will provide
final users with all and the most suitable solutions...


Best regards,
Carlos

| I'll forward to the list.It may be fantastic - but integrating
| Carlos' design into screen real-estate on monitors most people are
| running (15") won't leave much space for anything else. I could be
| wrong - prove it to me by the integrated picture.
|
| Regarding the linking of SOAP with multiple problems to a
| diagnosis. Why do you need to cleanly separate the thread. That is
| not what happens in the paper record. When you wish to review a
| thread - you scan back over multiple entries and your eye catches
| the words you want to link. Similarly, you can link any number of
| diagnoses to a single SOAP entry, and when you are reviewing this
| in a summary form, simply each consultation will be shown, just as
| it is on paper.
|
|>> I personally still like the the idea of the user actively
|>> linking the consutation to an existing or new problem at the
|>> bottom of the SOAP area and having the multiple threads present
|>> in the same SOAP, which is much more workable in actual use.
|>
|> But then one has no way of cleanly separating which thread
|> belongs to which problem (which isn't obvious in some cases, yes)
|> and this is very undesirable.
|>
| On Tue, 23 Nov 2004 07:02 am, Karsten Hilbert wrote:
|
|>> The suggestion of the 1.2.3 below is UNWORKABLE.
|>
|> Well, it may be for you. It may be for the rest of the world. But
|> is it not unworkable for me. I don't see a reason why GnuMed
|> should not support this mode and if it is just for me (of course,
|> I'll have to write the code myself then) - as long as it does not
|> affect those parts of GnuMed that work for other people. Right ?
|> Please don't think we are catching ideas out of thin air ! The
|> numbering thing DOES work. I do it daily. On paper.
|>
|
|> Also, the multisash-split soap idea didn't come out of nothing. A
|> couple weeks ago I met Marc Verbeke, one of the authors of the
|> Belgian EMR spec and and associate professor for Family Medicine
|> at University of Gent, Belgium. He showed me an application he
|> and a group of Belgian doctors use to record their episode
|> related encounter data. It had that exact
|> split-off-new-soap-widget functionality and it worked just fine.
|> So there :-)
|>
|>> Before reading my criticism please remember that there is a
|>> vast difference between half a dozen enthusiasts using a
|>> program and REAL LIFE DOCTORS, many of whom cannot type
|>> properly, and don't think in an ordered manner when it comes to
|>> data entry.
|>
|> Sure, I don't have any grudge giving them something they *can*
|> work with, too.
|>
|>> 1. It doesn't work in practice (I tried it for an hour -
|>> confusion)
|>
|> you forgot "doesn't work ... *for me*"
|>
|>> I wish you guys would actually try this in your day to day
|>> clinical practice ie as you are working with real patients in
|>> real time.
|>
|> I don't just *try* the numbering. I *do* it. Albeit on paper. And
|> tell you what my notes are far better than the other doctors'
|> ones at that practice.
|>
|>> It is also useful to have gnumed running on your puter next to
|>> your actual clinical software - that way you can duck and have
|>> a quick look at it as you are actually using your existing
|>> clinical software - then keeping all these new ideas in mind -
|>> just have a quick think about 'would this actually work now' -
|>> good example being Carlos's multiple soap thingy - which I
|>> don't think is practical in its current format
|>
|> It is lilkely not the most practical but it doesn't conceptually
|> involve any more switching between areas than the notebook. It's
|> perhaps a bit less polished visually. But it should do the job
|> somehow, for 0.1 at least.
|>
|>> - cause you lose everything else that is important that you
|>> need to orient you to the patient.
|>
|> That is surely true. Your designs are usually nicely integrated.
|>
|
|>> Just as an aside - continuation of interrupted consultations.
|>> This one struck me as I had a kid with quite severe tachpnoea
|>> and chest recession which I wasn't sure was due to asthma or
|>> nasty infection. I opted for asthma  and gave the kid a hefty
|>> dose of bronchodilator, but then had to throw him out into the
|>> waiting room for it to work or not, and keep going on with the
|>> consultation. A couple of patients later I reviewed the child -
|>> tachpnoea dramatically settled etc - ie responded well - this
|>> consultation should in fact be still active in gnumed - but put
|>> on hold. Do we have such a mechanism in place?
|>
|> Yes. One might either just leave open one client waiting for the
|> patient to be reassessed.
|>
|> Or else we do have some heuristics in place when loading a new
|> patient. Eg. below a certain timespan we assume it's still the
|> same encounter (4 hours). Above a threshold we assume a new
|> encounter (6 hours). Inbetween we ask the user. We don't have a
|> knob yet to allow the user to activate an older encounter as
|> still being current (although the backend/middleware sure support
|> that). Defaults kindly provided by Liz derived from service
|> charge requirements.
|>
|> Karsten
|
|
|
|
| _______________________________________________ Gnumed-devel
| mailing list address@hidden
| http://lists.gnu.org/mailman/listinfo/gnumed-devel
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBonpM5BCD+/pQ4WIRAt+gAKC6aLV2bWgEcdOWy7YHJhp44B1DmgCdE1eG
4atZ3aqRxhj5k+/uVqv3lEA=
=gB2w
-----END PGP SIGNATURE-----