Re: [Gnumed-devel] re: sourceforge ldap

[Karsten Hilbert]

On Thu, May 20, 2004 at 09:33:12PM +1000, Horst Herb wrote:
> 
> On Thu, 20 May 2004 18:57, Ian Haywood wrote:
> > (there is no way to access demographics without automatically creating an
> > entry in the clinical database) A separate standalone client for
> > contacts/demographics in general seems the way to go.
> 
> This is horrible. What happened to our modular design? What is this nonsense 
> about not being able to access demographics without creating an entry in the 
> clinical database?
That's plain untrue and hearsay.

The gmDemographicRecord.py module does not even have a mention
of the term "clin" anywhere and it still runs it's tests just
fine.

Instantiating a gmPerson does not in any way touch the
clinical "service". Except if you say
person.get_clinical_record(). Doh. (Or export_data() for
that matter.)

Not even setting gmCurrentPatient() (*Patient !) to some
person does in any way force any entries into the clinical
record. Only if you start *accessing* the clinical record is it
touched at all.

So please check your facts.

> 1.) The gnumed client as such is foremost a GUI framework for pluggable 
> modules
Nope. There is no "gnumed client". There is a "GnuMed medical
office client". The purpose of which is decidedly clinical.
Henceforth it very centrally operates on the concept of an
active patient. By selection of which the chart is
automatically opened and readied for accepting notes etc.

> 2.) Module design aims for independent functionality; in fact, most modules 
> should run as standalone programs with few dependencies if invoked outside 
> the gnumed client framework
Have you ever tried to keep code in sync to run inside and
outside the framework ? We have. I suggest you take a stab at it.
Where do options come from ? Is database access available ?
There's a few things to ponder before success.

> 3.) The concept of "Services" only makes sense if these are really totally 
> independent;
which is why it's post-0.1

> this is especially valid for the "demographic" service for which 
> we must not assume the same confidentiality constraint as for the other 
> services.
And there you said it. "Clinical" data has other constraints
than address data. And for users "patient" demographics *is*
clinical data as opposed to mere address book entries. Not
that I agree, though.

All in all easier said than done. I'd like to see your code
on this.

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