Re: [Gnumed-devel] problem with UI/logic separation

[Karsten Hilbert]

> > - decompose into __init__ and init_encounter() which can
> >   return error codes (cumbersome, undesirable)

> why undesirable ? IMHO you are trying to do too much magic in
> init. If you want the user to choose the active encounter (or
> at least be able to do so) this should definitely be done
> outside __init__.
I wonder why you think that. Probably because you haven't been
in that specific situation yet. I am just modelling real world
use cases. Let me give you an example:

At our surgery the nurses write the current date on the chart
where I am supposed to write my notes. THEY THUS DECIDE THAT
THIS IS A NEW ENCOUNTER. They then hand me the chart. *I*
don't have to make that decision. Of course, they may be wrong
because: patient hand-over was insufficient at change of shift
AND the patient was sent for a 60 minute walk between two of
the oral glucose tolerance blood sample drawing AND they haven't
noticed that todays date is already in the chart...

Now, maybe the did notice and they DIDN'T make that mistake of
starting a new encounter. They just handed me the notes AGAIN
for seeing the patient again.

I can handle this situation with a timeout.

The difficulty comes in when I've seen this little guy at 8am
with painful/putride otitis media. The single mom tells me
they had planned to leave for a one-week Egypt holiday tonight
at 2am which they've both been looking forward too and saving
the money for. And now this. So I decide to take a look at him
again at 10pm tonight for the final advice on flying. Now this
is ambiguous whether this is considered a new encounter or
merely a delayed continuation of the first one. The nurses ask
me. The computer must, too.

How do we handle this situation ? The solution that comes to
mind is a soft timeout (below which all re-pulls of a chart
are continuations) vs. a hard timeout (above which all are new
encounters). This is what I need the dialog for.

Why is it undesirable to split into __init__ and
initiate_encounter ?  Because it would be desirable to not
require the programmers to think about whether they need to
call initiate_encounter() after getting a handle on a patient
chart object. I expect of my staff to not only do what they
are told the way they were told to but rather to also think
about what needs to be done !

Due to the fact that we use lazy instantiation of the EMR
object (upon first access to it via the patient object) any
access can be the one needing to initialize an encounter.
Hence any access would need to be followed by
initiate_encounter(). Of course, we could write a wrapper
get_emr() and by threat of beheading mandate it's use but that
ain't really any cleaner and adds overhead.

Some may think this is arguing over rather petty a point but
this sort of problem is going to come up every once in a while
in various places so I'd rather come to an acceptable solution
now.

> > - provide __init__ with a callback function for asking
> >   questions at the UI level (doesn't feel clean)
> It might not feel clean because having user interaction in __init__ can never 
> be clean.
It doesn't. It happens in GUI space. It just so happens to be
initiated from non-GUI space.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346