Re: [Gnumed-devel] Re: Cannot change the dates of the encounters

[Karsten Hilbert]

> I am entirely happy with the (Chronological) EMR Journal displaying  
> its content organized according to the datetimes of the *encounters*,  
> meaning this display is sequenced from the datetime of the encounter  
> *entries* and not of the clinically historical dates being referred- 
> to as having happened.

Currently, the journal is retrieved like so:

  select
        to_char(vemrj.clin_when, 'YYYY-MM-DD') as date,
        vemrj.*,
        (select rank from clin.soap_cat_ranks where soap_cat=vemrj.soap_cat) as 
scr
  from clin.v_emr_journal vemrj
  where pk_patient = %s
  order by date, pk_episode, scr, src_table

IOW, items are ordered by their date of clinical occurrence. This will often 
but not
always be the original modified_when. So this is sequenced as to when things are
thought to clinically have happened. Encounters are not taking into account at 
all there.

If you think we *should* - first and foremost - sequence by encounter we'd have 
to
rework that.

The following two definitions may be useful in the Wiki:

> I suppose we can think of
> 
>       EMR Journal == the *literally* chronological journal, within which  
> any soapLets (optionally attributed to a variety of different  
> episodes) would be clustered together.

I have a feeling this definition is what we can agree on but I think it might 
need
some pinning down. What exactly should we regard as the "literally" 
chronological
journal ?

Literally as in time-of-insertion or time-of-clinical-occurrence ?

>       EMR tree == the representation of health issues, each defined by  
> (and displaying) zero [1], one, or more *clinically*-ordered episodes  
> unique to this issue, where -- inside each episode -- there will have  
> been attached at least one entry, and there may have been attached a  
> variety of entries (progress notes, lab results, imported documents).


> 1) we had identified that the representation of the health issues  
> (i.e. the sort order) could be governed by whatever combination of  
> pre-pended ( * , - ) and alpha characters was desired to be the  
> operand of a simple sort on clin.health_issue.description

This is how it currently sorts. I do believe it was fixed somewhere in the 0.2 
series.

> 2) clin.episode apparently (in the EMR tree) shows the same encounter  
> multiple times
Each episode is only show once in the EMR tree, namely under the corresponding
(pseudo) issue. And each episode lists each encounter it was mentioned in only
once, too.

> but maybe within each episode we only want to see the  
> clin_narrative rows that pertain to the episode,
We, of course, do !?

> sorted by clin_when  
> instead of modified_when.
Yes, SOAP entries under their encounter under an episode are sorted
by clin_when, currently.

> [1] Health issues can have zero episodes, think "past Hx"  items.  
correct

> Even so, the health issue could only have been created through some  
> form of encounter,
yes, one of the reasons that made me discover the need
to have clin.health_issue.fk_encounter

Karsten
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer