Re: [Gnumed-devel] Movve to Qt (was: Conference)

[Karsten Hilbert]

Roberto,

> I'm going to start contributing to gnumed so we can use it in my mom's
> clinic in Brazil.
Excellent. I think it'd be worthwhile to collect your mom's
clinic's requirements into
CVS:client/doc/TODO/GP-practice-reqs-brazil.txt.

> Especifically, I would like to work on the scheduling
> facility (schedule patient appointments) and
Ian has done some fairly extensive schema work in that area. I
haven't looked at it (not that I'd have to for it to be
worthwhile ;-).  There's some code from Horst and probably
some more code buried somewhere in Horst's machines.

> adaptation to Brazil's medical reality, of course.
See above. Any news on the nationwide smart card project ?
(Christian ?)

> I have lots of experience with databases (especially PostgreSQL) and
> relational data modelling. I'd like to help with that as well, if that's
Excellent !

> needed (if so, can someone point me to where I should start poking
> please?)
You might take a look a clinical/demographics to see how we
did things so far, offer some suggestions and then maybe
embark on the scheduling stuff ?  I also have one very
specific question that hasn't been answered on the pgsql list
so far:

Can a good case be made *against* using NOT NULL constraints
on table attributes in audit trail tables where the
corresponding attributes in the audited table also have a NOT
NULL constraint ? OR is it (and for what reason) important to
not have ANY constraints on audit trail tables ? We are doing
the NOT NULL in audit trail tables currently as I feel the
need to be as strict as possible about the data BUT i'd
love to drop that if I have good reason as that would make it
vastly easier to auto-create audit trail tables... Which is
desirable ...  Well, writing this it occurs to me that when
the audit trail table is missing for a table that is marked
for auditing I should just log that as a warning and happily
create the audit trail table assuming the user knew what she
was doing, shouldn't I ? :-))

> > 7/ Generalisation of clinical history API from the Allergies functions
> > to avoid separate functions for allergies, immunisations, etc:
> > viz. a thinner layer around updateable views.  Exact arrangement of
> > these views depends on outcome of design process.
> I'm interested in (7).
I'd be right on with you there. Please post your ideas and
feel free to ask if clarification is needed. I am to blame for
some of that stuff in CVS.

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