[Top][All Lists]
[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