Re: [Gnumed-devel] Aggregating health issues on screen. - Contextual Info

[Karsten Hilbert]

> Do we envision ONE i.e. a *single* SOAP editing area
Both approaches are possible.

Carlos and me decided to implement *multiple* SOAP editing
areas in a sashed split window approach for a first.

Richard argues for a *single* SOAP area being attached to a
list of problems regardless of which problems the individual
items really belong to.

Richard also seems fine with *multiple* SOAP editing areas if
they are put on a tabbed notebook. I would also be fine with
that approach. It is likely we will implement this as a second
approach after split sash.

I also argued for a "numbered" *single* SOAP editing areas that
allows to "mark" bits of data for specific problems by
"numbering" them - much like your higlighting suggested below.
Richard chimed in saying this would not work.

> a) if it relates to only a single problem-episode, requires no 
> division into encountlets *but*
This would work correctly in all of the above scenarios.

> b) if, in the judgement of the doctor, the content is meaningfully / 
> usefully separable into encountlets --- each such "bit" able to be 
> "attached" to the pertinent problem --- this is *not mandatory* 
> however *is recommended (the only sensible way)* for any doctor who 
> desires to later assemble the pieces specific to such a "thread" to 
> be able to do so
I do think we shouldn't have a vision lesser thatn this.

> Alternatively some might think or favor that multiple SOAPlets be 
> created concurrently, in some combination of full or collapsed views, 
Which provides the same outcome in a different way.

> with the doctor jumping back and forth among these SOAPlets as the 
> patient jumps around, but I worry this forces premature choices of 
> where the information "belongs".
Well, any bit of data can be re-attached later if so desired.

> Moreover there could be 2 new 
> problems happening but if the problems had not yet been created there 
> is a risk of circularity to the process. Lastly if I am busy I might 
> rather end the visit having captured my SOAP content but preferring a 
> while later (maybe after a few phone calls and a few patients) to 
> come back and further process what I was thinking.
Sure, why not ?

> So I would rather 
> have the option of collecting and caching content in a single area to 
> be able to attach pieces to problems as time and reason permit.
If your mode of operation is thusly have the frontdesk staff
create a new episode "today: <RFE>" at each and every
encounter. Then write your SOAP notes attached to that
episode. Whenever you feel like detailing further you can go
back and sort into different episodes as wanted perhaps
deleting the catch-all episode at the end. Some widgets might
need to be written to efficiently support that but the backend
doesn't have a problem with it.

> - suppose we have within a SOAP  editing area several bullet points 
> and/or a few paragraphs
My suggestion was numbering with the episode numbering
order arbitrarily created for this encounter. Richard
denounced that as unworkable. Decide for yourself.

> - suppose portions are highlighted, or demarcated (whatever is the 
> method) thus denoting "encountlets" to be attached to each of 
> multiple specified problems (episodes)
A different possible way of attaching within one SOAP widget.

> -- what happens to any text that was *not* thus highlighted or 
> demarcated,
Well, numbering wouldn't have any such amiguity. Entirely
unnumbered soap widgets would belong to the "last active"
problem. All other data can be traced to a number.

> i.e. was the SOAP content being held only in memory, and 
> after the encountlet(s) are parsed off and processed, any other text 
> gets "dumped"?
It would IMO get attached to the "last active" problem.

> Or are we talking about *preserving* everything that 
> was in the SOAP editing area,
Why of course.

> and simply supporting the additional 
> functionality of *copying* bits into various problems
If we so decide.

> -- can the same bit of text be multipurposed into two separate problems?
What for ? Technically it sure could.

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