On Fri, Sep 05, 2008 at 01:48:23AM -0700, Jim Busser wrote:
> Encounter groups chronologically by date & time of the encounter,
yes
> which means according to the date and time of the changes being
> written into the EMR.
No. There's explicit start/end modelling.
> This permits a chronologically later encounter to
> record information about things that happened even before the previous
> encounter,
Sure. Just like in a book where the character says: "Oh, way
back in 1893, I did this and that".
> and so while the *record* is chronological,
techically, yes
> the storyline of
> the patient illness becomes disrupted. This is what I meant when I
> indicated that encounters may need some second dimension of time
> (clinical "attributed" time) to permit a clinically-meaningful sort.
We do have some clinical items which have explicit clinical
times modelled into them. Witness clin.health_issue:
age_noted
this stores what the patient said at what age the health_issue became
known first,
this is an interval and can thus be used in actual date-based ordering,
this may be subject to correction and is audited
fk_encounter
this stores during which encounter the recording clinician first
entered the health issue (that is, when did it become known to her),
this is taken from the current_encounter at the time of insertion,
it is not intended to change later but it can, technically, which
is, of course, audited
modified_when
this stored when the encounter information was actually technically
entered into the database or when it was later changed,
this IS part of the auditing metadata
Or look at clin.test_result. It too has:
- modified_when (see above)
- clin_when, the comment says:
the time when this result was *actually* obtained,
if this is a lab result this should be between lab_request.clin_when and
lab_request.results_reported_when,
HL7: OBR.observation_date_time
- fk_encounter (see above)
Or else look at clin.allergy:
- modified_when
- clin_when
- fk_encounter
In fact, any clinical item has *at least* modified_when and
fk_encounter catering for "when inserted" and "belonging to
which medical encounter start-time interval". Some feature
the third "actually happened when". In many others the third
timestamp may either be not knowable, not known, not
relevant (there I said it ;-) or else textually contained in
the narrative.
OpenEHR also models those three types of times.
> - the timeline of the patient's illness, which is sometimes only figured
> out and pieced together after-the-fact
That is the clin_when order.
> - the timeline of any findings, which are sometimes only entered
> after-the-fact
That is - pretty much - the chronological order of
fk_encounter. Some (such as test results) do not *quite* fit
because they are often entered after obtained in the lab.~
> - the timeline of the recording of information, and of signing, and of
> any edits to these, in the EMR
The modified_when side of things.
We explicitely model time of signing as well, because the
review root table(s) are audited, too, of course ;-)
> Episodes, in addition to their top-level semantic grouping, also have
> (within their top-level) a chronologic order among episode which I
> expect is mangeable.
Sure. Under any given issues there's a bunch of past closed
episodes. Then there can be one open episode on that issue.
All those can be chronologically ordered by their
fk_encounter foreign key :-) That tells us when they were
first inserted. Each episode's change history can *also* be
gotten chronologically courtesy of modified_when and the
appropriate audit entries.
I think we are pretty well covered here :-)) (Not that
there will need to be changes here and there - I just
recently discovered that we do need fk_encounter on each of
health_issue and episode :-o )
> The challenge may be to display entries within episodes in clinical
> chronological order as opposed to when-entered-and-audited chronological
> order.
It's always a challenge to know precisely what one wants
displayed how and why. And then there's the challenge what
the things that *are* displayed *really* mean. That's part
of why I like this whole project.
> Does this well-capture the conundrum?
It does.
Karsten
--
GPG key ID E4071346 @
wwwkeys.pgp.netE167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
_______________________________________________