Re: [Gnumed-devel] Better-structured narrative output

[Busser, Jim]

On 2011-12-01, at 1:46 PM, Karsten Hilbert wrote:

> the rules for determining start/length/string/mode
> are fully arbitrary and entirely depend on the goal.
> 
>> where, beginning with position 1 in string X, you would get
>> 
>>      1, 27, X, match <--- X can only (either) match Y or inform an insertion
> ...
> What about ambiguity ?  (the simplest form of which would be
> two potentially detected changes according to the above
> rules would overlap)

The easiest algorithm would identify (at most) a single block of difference, 
wherein the paired strings are compared:

        from their beginnings, yielding an anterograde breakpoint
        from their ends, yielding a retrograde breakpoint

and everything in between those points becomes treated as the 'delta'. 

I cannot overemphasize the importance of this. IMO the biggest source of 
medical error is when doctors were not aware that new information had entered 
the chart, or that it had been changed, because the fact of new or changed 
information was dispersed in multiple areas within the record which, even if 
visited, may not have made themselves apparent.

Even just the fact that GNUmed *provides* the Journal is great but I am mindful 
that we should make it better (more efficiently usable).

Sorting all of the rows by modified_when (with the ability to visually scan up 
from the bottom, to determine the last point in time of your *own* entries, if 
any) makes it easy to determine the point at which to then visually scan 
"forward in time".

In a left-to-right (occidental) paradigm, it is least confusing if the column 
on which things are being sorted (i.e. modified_when) would be left-most.

I suggest that the next Journal column label be

        'Entries in'
        --------------

below which to list an alias for the table-source of the displayed rows:

        Encounters
        Episodes
        Notes
        Past history
        Social history
        Hospitalizations
        Procedures
        Medications
        Allergy_state
        Allergy_details
        Waitlist?

and the next one the

        User (or daemon)
        ------

and the next one

        Altered
        ---------
             *

denoting whether or not the row represents a modification (*) and the final one

        Information
        ---------------

thus we would have:

        Entry (modification) date, In, By, Altered, Information
        

Lastly, where a row has been modified and if we would NOT assist the user by 
showing them the content of the change, that is (a) potentially clinically 
stressful and (b) putting the user in a position where even if they *wanted* to 
lookup the original, the data is only poorly accessible from the audit log 
which maybe needs the schema to relax at least read access to the audit table.

-- JIm