Re: [Gnumed-devel] Gnumed Value Objects dev guide, draft 1

[Karsten Hilbert]

> Conceptually what is the difference between this and a health issue?

car accident 9/2000

 vs

Aitken II fracture

metabolic syndrom
 vs
hyperlipidema type II
hypertension
glaucoma
IDDM

I should think we would want a diagnosis to be a hard and fast
scientific fact (if we don't have that fact as we do in many
GP patients we simply don't have a *clinical* diagnosis --
this doesn't concern billing in the least as for that "billing
diagnoses" should and will be attached to billed item groups).

A health issue is more of a soft, encompassing, over-arching
issue with one's health.

> > > >     cDrug
> > Yep, sort of. Note that we probably already have it somewhere
> > in Hilmar's gmDrug* code. Perhaps just not as nicely singled
> > out.
> Do you mean, "a drug in the drug database", which is not a clinical VO.
Ah, quite true !

> AFAIK the plan is to have a separate API for this. Draft spec is in drugref 
> CVS.
> Because this API is meant to be accessible across XML-RPC, it can't look like 
> a VO
> (which otherwise would be nice)
It can still be a "VO", eg a class that has some of the get_fields,
__getitem__ properties etc. But it won't inherit from
cClinItem but rather implement XML-RPC calls.

> Having 2 clinical drug objects is overkill: can we just have currently 
> prescribed drugs,
Yes.

> and rely on the auditing mechanism to generate a list of past scripts?
No (if you are referring to the database level auditing).

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