Re: [Gnumed-devel] Test results imports, and encounters

[James Busser]

> > ...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 :-)