Re: [Gnumed-devel] help on encounters

[Karsten Hilbert]

> - in the schema (as it exists, or as it is yet to be updated) are the 
> RFE and AOE each clin_narrative rows with a value for soap_cat other 
> than {s,o,a,p} or is this value left null so that we will have is_rfe 
> and is_aoe?
RFE - clin_narrative row with soap_cat = S and is_rfe = true
AOE - clin_narrative row with soap_cat = A and is_aoe = true

> - we have resolved that an encounter need not have ALL the above 
> elements
ACK

> (for example a phone call may have no "O" unless the doctor 
> wishes to note something about the patient's affect, speech or sounds),
ACK

> but do we wish to assert any to be REQUIRED i.e. as a precondition for 
> creating an encounter, must we have at least an RFE?
Not really. If there was a way to say at the database level
"there must be at least one row linked to the encounter" we
could do that. But we can't since PostgreSQL doesn't have
ASSERTs to my knowledget - and even then it'd be hairy. It is
surely solvable by programmatic logic (trigger, stored proc,
even app level logic) but not purely at the DDL level.

> - supposing at the end of the visit, or even a week after the visit is 
> done, there is a plan or request by the patient or doctor for followup.
New encounter, clearly.

> I can understand that there is now a new RFE but I do not understand an 
> attachment to the visit that has already concluded.
A new encounter should be created.

> The RFE will relate 
> to the next visit, i.e. to the next encounter for this health issue.
Exactly (the next encounter * for the next episode * of this
health issue).

> We 
> are not proposing for a single software "encounter" to refer to 
> multiple visits, are we(?)
No.

> for I thought that was a functional aspect of the "episode".
Exactly. Probably THE functional aspect of an episode.

> - supposing before this next visit (which may not even be scheduled 
> yet), the doctor wishes to record a discussion with a consultant. I can 
> see how the discussion could lead to a modification of the Assessment 
> and/or of the Plan but how to handle this?
Either create a new encounter recording what you want to
record. Or add on to the last encounters' data directly. Or
link new clin_narrative rows to the last encounter. I can see
merit in either approach. The decision needs to be taken by
the frontend and the user.

> After all, if we bother to create encounter types of "chart review",
Chart review is mainly intended as the default, eg. when we
just *access* the chart for looking up something or other.

> then we should create a new encounter to capture the discussion with 
> the consultant, along with any resulting modification to the assessment 
> and plan.
Sure, why not ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346