Re: [Gnumed-devel] SOAP widget navigation

[Karsten Hilbert]

> So far Richard has suggested that within an encounter, multiple draft 
> RFEs with draft SOAP/AOE elements could co-exist as a list with each 
> ideally expressed in a condensed, single-line format:
Yes, just below the edit area.

> Is this 
> multi-problem functionality targeted for 0.1, or should the plan for 
> 0.1 be constrained to single-problem encounters?
Single or multiple problem encounters aren't really that much
different in handling so I would think multiple problems is
OK for 0.1.

> After we have support for multi-problem encounters, an elegant function 
> (post 0.1) would support drag-and-drop where the content in one note, 
   ^^^^^^^^
   most definitely

> I don't know whether during creation of the SOAP notes, and while they 
> are being worked on, the rows will exist only in memory, or will have
*That* is a useful pre-/post-0.1 consideration. I would for
now write them notes to the backend as soon as the user
decides to be done with one and work on another problem. I
know this will incur extraneous audit records but, frankly, I
take the liberty to not care :-)

> their content written immediately, or cached at intervals decided by 
> postgres, into table records?
Eventually cached at intervals, client-side.

> Are they then immediately subject to 
> audit requirements?
Yes.

> If we are willing to tolerate this limitation for 0.1
> -- choosing to delay until post 0.1 Horst's limbo proposal
I am.

>  -- will audit functions be invisible to the user?
In what sense ? They are certainly invisible in that the user
doesn't have to do a thing to enjoy their benefits.

> I did not see in the schema an an audit_explanation/comment/annotation 
> field into which the user can be permitted or forced to annotate a 
> source or reason.
There is none. I believe I remember I asked about this on the
list once (might be linked from the Wiki) but got no real
feedback. Right now our audit scheme does not support
annotations. I wonder how useful it is, eventually. I fear
it'd amount to a lot of work for little gain, no ? Your
parsing suggestion if surely doable, though. The backend code
for this is not *entirely* trivial as it involves a bit of
special trickery to pass parameters to trigger functions.

> so that the user (maybe a covering doctor) can know whether
> it might have changed since they last viewed it.
That's already possible. One can display who changed the row
when. That's already audited.

IMO a post-0.1 consideration. Not hard but a bit laborious, I
suppose.

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