Re: [Gnumed-devel] may help

[Karsten Hilbert]

> Karsten's  schema allows an encounter to be a container for an unordered 
> list of clinical root items.  The clinical entry
> is done by selecting  a health issue ( or default health issue),   
Or no health issue at all which would amount to an unlinked
episode. Which we now allow to account for minor non-recurring
afflictions such as "minor cold" more conveniently.

> Once a new issue is started, no more clinical items can
> be attached to the previous health issue.
That strikes me as odd. It's certainly not intended that way.
Health issues are (logically) independant of each other as
regards entry of data.

> In practice, this is a disadvantage, because one could forget to attach 
> a P clinical item, and be unable to add medications
> under a previous health issue.
Precisely. The disadvantage does not exist in the backend.

> re-prescribing old  medications  has not been done;
> the traditional way is just to have checkboxes or other select mechanism 
> against the current medication list,  but
> this would not link to episode/health issues in the encounter.
It sure could, why not ?

> With respect to business logic in python, I didn't think of that. There 
> is already a moderately constrained SQL schema written by Karsten,
> and I was expecting that any invalid data will turn up as  constraint 
> violation error, and achieving the right validation
> amounts to getting the constraint violation to go away, without changing 
> the backend schema.
This is what is intended by the schema, yes. It may have holes
here and there, however.

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