gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] the sweeping changes


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] the sweeping changes
Date: Wed, 2 Feb 2005 16:53:13 +0100
User-agent: Mutt/1.3.22.1i

> It's a bigger change than I would have liked, I promise I will stick to 
> smaller patches in future.
If all your big changes work out like this things are quite fine.

> >Will have to fine-tune/check a couple files in HorstSpace.
> >Also, in all actuality occurrences of "demographic_record"
> >might actually be better named "identity" ??
> Yes.
I'll take care of that then.

> >cIdentity might perhaps be moved to gmPerson.py ? Would that
> >make sense ?
> Then what is gmDemographicRecord.py?
Nothing, really, apart from being a bad name for whatever it
*is* that should have been named "identity" :-)

> IMHO PersonSearcher_SQL should move to gmDemographicRecord.py
No. Not even if we kept gmDemographicRecord.
gmDemographicRecord used to be the "folder" holding the
administrative/demographic data of *a* patient (much like
clinical_record is for clinical data, we are just more used to
that). cPatientSearcher_SQL is something outside the scope of
one given patient. You can think of it as being a "smart
handle for the filing cabinet": When pulling open a file
drawer it reads your mind and pops up the file you were
thinking of, eg. it finds the patient for you.

Eventually, we might want to create a super-super-class
representing the practice we are running GnuMed for. *That*
object might conceptually "contain" the patient searcher
(along the lines of logic that connectors might be defined
towards *other* practices that might require a different
searcher).

> My rationale is this: when (if) we ever write an LDAP demographics layer,
> gmDemographics.py is what gets re-written,
We'll just write another searcher and go from there. Don't
worry too much, I guess.

> gmPerson.py is the higher
> conceptual layer (binding clinical, demographics, docs, etc.) which
> stays the same.
I fully agree with this assessment !

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]