gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Synopsis (AOE?) attaches to the prior encounter?


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Synopsis (AOE?) attaches to the prior encounter?
Date: Fri, 30 Nov 2012 23:39:31 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Nov 29, 2012 at 02:13:53AM +0000, Jim Busser wrote:

> >> 3. Why is it that despite that I inputted the synopsis "Angina resolved…" 
> >> today, it shows up in the EMR browser under the encounter from 6 days ago)?
> > 
> > That's the start timestamp (2012-11-22 18:22) of the
> > encounter within which the episode (containing the synopsis)
> > was created. It also shows that you last modified the
> > episode entry on 2012-11-28 11:18 (it doesn't show _what_
> > thereof you modified:
> > 
> >> .------------------------------------------------------------------------------------------------------
> >> |   Happened |       Doc |     | Narrative
> >> |------------------------------------------------------------------------------------------------------
> >> | 2012-11-22 |      JaBu |   … | Encounter: review chart 2012-11-22 18:22 
> >> - 18:22 (2012-11-22 18:22)
> >> |            |           |   A | Episode (open): Angina;
> >> |            |           |     | Angina resolved on atenolol 50/d but 
> >> intolerant thereof (hr 40/min).;
> >> |            |           |     | (2012-11-28 11:18)
> >> | 2012-11-28 |      JaBu |   … | Encounter: phone w/ provider 2012-11-28 
> >> 10:40 - 10:55
> >> |            |           |     |  RFE: MIBI Dec 7, 2012 @ 0715 (2012-11-28 
> >> 11:34)
> >> |            |           |   S | called by GP (patient in office), 
> >> reported to her absence
> >> <snip>
> >> |       None |      JaBu |   O | Allergy state: unknown, unasked 
> >> (2012-11-22 18:22)
> >> `------------------------------------------------------------------------------------------------------
> 
> So if I have this correct, the (episode) synopsis remains
> a property of the episode, across its encountlets themselves
> spread across possibly multiple encounters,

That's correct.

> and its sequencing within the EMR journal so that it
> appears up with the oldest encounter-for-episode is a
> design choice ?

A nitpick: the episode appears with the encounter within
which it was *created* inside the database, not the
oldest-within-episode one.

> Is it a property of (or dependent on) a stored reference
> to the oldest encounter-for-episode, or is it a "visually
> floating" property of having its date_clin set to match the
> oldest encounter?

                                        Tabelle »clin.episode«
               Spalte                |           Typ            |               
             Beschreibung
-------------------------------------+--------------------------+--------------------------------------------------------------------
...
 pk                                  | integer                  | 
 fk_health_issue                     | integer                  | health issue 
this episode belongs to
 description                         | text                     | 
description/name of this episode
 is_open                             | boolean                  | whether the 
episode is open (eg. there is activity for it),       +
                                     |                          |          
means open in a temporal sense as in "not closed yet";   +
                                     |                          |          only 
one episode can be open per health issue
 fk_encounter                        | integer                  | The encounter 
during which this episode was added (begun).
 diagnostic_certainty_classification | text                     | The certainty 
at which this problem is believed to be a diagnosis:+
                                     |                          | A: sign 
(Symptom)                                                 +
                                     |                          | B: cluster of 
signs (Symptomkomplex)                              +
                                     |                          | C: syndromic 
diagnosis (Bild einer Diagnose)                      +
                                     |                          | D: proven 
diagnosis (diagnostisch gesichert)
 summary                             | text                     | Used for 
tracking the summary of this episode.

Indexe:
    "episode_pkey" PRIMARY KEY, btree (pk)
    "idx_uniq_open_epi_per_issue" UNIQUE, btree (is_open, fk_health_issue) 
WHERE fk_health_issue IS NOT NULL AND is_open
    "idx_episode_issue" btree (fk_health_issue)
    "idx_episode_modified_by" btree (modified_by)
    "idx_episode_with_issue" btree (fk_health_issue) WHERE fk_health_issue IS 
NOT NULL
    "idx_episode_without_issue" btree (fk_health_issue) WHERE fk_health_issue 
IS NULL
Fremdschlüssel-Constraints:
    "episode_fk_encounter_fkey" FOREIGN KEY (fk_encounter) REFERENCES 
clin.encounter(pk) ON UPDATE CASCADE ON DELETE RESTRICT

=> Glad you asked because we are lacking an index on .fk_encounter ;-)


> One reason that I am finding this unnatural is because I
> had thought that the EMR journal overall structures its
> output, within the current patient, according to a truly
> chronologic sequence

It does but not ...

> based on last_modified

:-)

(If it did it would be a forensic rather than clinical way
of displaying the EMR.)

>       YYYY-MM-DD (date_modified, not date_clin)
> 
>               time_modified (from the datetime_stamp)
> 
>                       within time_modified, by row_type (soap u)
> 
> and if this is true then we should revert the synopsis so
> that it falls naturally among when it was last modified and
> not with (earlier) encounters.
> 
> Or is there something that I am misunderstanding?

Would that mean you would want the _entire_ episode journal
entry to float towards .modified_when ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]