[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Test results imports, and encounters
From: |
James Busser |
Subject: |
Re: [Gnumed-devel] Test results imports, and encounters |
Date: |
Wed, 24 Jun 2009 14:21:11 -0700 (PDT) |
> > ...how would this be recorded in the database in terms
> > of encounters
> Again, this question doesn't really exist. The encounter
> just is. The Zen Of Encounter. Something is done to an EMR -
> a better word for this encounter may be "session".
Well, there exists a table clin.encounter, so the table "just is", and the
table *does* get populated by "encounters". In the same way that every episode
that would be created must have a non-NULL encounter, so it is with every
health issue and narrative (soap) item and test_result. All depend on an
associated non-NULL encounter.
So maybe what we are resolving is that while it is required that each imported
item must be associated with a encounter... one that is keyed to an exiting (or
newly-created) person / patient, there exists the possibility ... if we would
so-decide ... to key *every* imported patient result to a single encounter
record. But any way you "cut" it, a per-patient-keyed encounter is needed.
Not that keying every result import (over the life of a patient) to a single
encounter is a good idea... it may be wise to key all of the tests which were
created in any one batch (session?) to an encounter that was specific to that
event, in case somethign will have gone wrong?
So maybe we are now only talking whether to key results creation -- when
originated by an importer -- to a single encounter per import session per
patient (instead of re-using a generic encounter per patient across all
imports).
> The type would probably be "administrational" I'd think
> off-hand.
>
> Should it be shown ? I think so.
> > - would each import process create a single per-patient encounter which
> > may be of type "results <importer>" and could this encounter be
> > permitted to have a start datetime and an end datetime
I had mistakenly thought encounters to require and support an end-time, but I
see in the schema only "started" and "last affirmed" timestamps, nothing to
require or support either an "ended" timestamp, nor a status of "closed".
> - "auto-close" would mean "place chronologically older than"
> - there is no explicit closure
as I stood corrected above.
> > ... allow test results import to be entered (stored) under a special
> > encounter type that simply adds more and more datetime stamped
> > administrative soap rows although maybe there is a downside to doing
> > this?
>
> Sure, I wouldn't generate a new episode for each import.
> Just use one "imported test results" or some such under
> "unattributed".
I will have us revisit & ocnfirm or clarify this as a lab importer gets closer
to fruition :-)