Re: [Gnumed-devel] Formatting of SOAP row and metadata

[Jim Busser]

On 2011-07-21, at 10:34 AM, Karsten Hilbert wrote:

> I think we need more opinions on this.

I will be glad for more thoughts.

I am only having trouble to follow the argument to leave it per current state.

What we are talking about is:

        what to display in the right pane of narrative content plus 
notices-of-import, depending on a selection in the left EMR tree when the left 
EMR tree has, in the case of an example:

        Congestive heart failure  (<-- Health issue)
                First episode (<-- episode with one to many encounters)
                Hospitalized ABC (<-- episode with one to many encounters)
                With atrial fibrillation (<-- episode with one to many 
encounters)

****************************
At the episode level:
****************************

When the clinician desires to see "the chart" (notes etc) that is associated 
with a particular episode

                Hospitalized ABC

then that is what you select at left.

With that now in focus on the left, the argument is on what to show at right in 
terms of this same "Hospitalized ABC " labelling information. Presently, this 
information may be shown at right multiple times (up to once per encountlet) 
meaning if this episode had 8 encounters containing clinical narrative, or 
measurements, or imported documents, you might see several instances among the 
right-sided output:

                Episode "Hospitalized ABC" in health
                issue "Congestive heart failure"

Possible opinions on what to do with the above two lines are:

        (1) yes, continue to show them even if multiple times

        (2) show them, but only once as follows:
                incorporated into the
                header that sits already at the *top* of the
                right-sided output:

                "Clinical data generated during encounters
                        within this episode:"

        (3) do not show it at all; it is implicit in the at-left selection

My own opinion is that (3) is cleanest (minimalist) but (2) has merit by 
providing context to the user of what is currently (already) selected at left. 
This has additional value if this right-sided text would be copy-pasted into a 
document, encrypted email etc.

It is the current state (1) that I have been having trouble to understand its 
value. It seems to me to just clutter things up.

****************************
At the health issue level:
****************************

The same question is magnified because if we imagined a pooling of several 
encountlets (even if only 5 per episode, across 3 episodes we are talking in 
this simple case around 15 instances of

                Episode "<name of episode>" in health
                issue "Congestive heart failure"

or 30 lines of text interspersed among the clinical narrative.

I do agree that there is value in the current non-null tagging of notes 
by-episode:
- makes it possible to filter by episode
- makes it possible to *aggregate* by episode

… but this need not mean the episode info is valuable to display multiple times 
in the view.

My suggestion would be to (instead) incorporate the episode information into 
the header that sits already at the *top* of the right-sided output. Where it 
currently says:

        Clinical data generated during encounters under this health issue:

I would replace with

        Clinical data generated during encounters under selected health issue:
                Congestive heart failure
        episodes:
                First episode (09/2000 - 07/2010)
                Hospitalized ABC (10/2010 - 11/2010)
                With atrial fibrillation (03/2011 - 04/2011)

What this would do is:

- allow the list of episodes to be easily seen at right *independently* of the 
state of expansion under the left-side EMR health issue

- provide whoever is browsing with episode date span information, pointing them 
to potential clin_when dates of interest to which they may wish to scroll down

- provide episode information that can be copy-pasted

-- Jim