gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] diagnosis tables


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] diagnosis tables
Date: Wed, 28 Apr 2004 14:06:29 +0200
User-agent: Mutt/1.3.22.1i

> > -- ============================================
> > -- diagnosis tables
> > -- --------------------------------------------

> > create table clin_diag (
> Consider
>       laterality char default '?' check (laterality in 'l', 'r', '?'),
OK, I wasn't sure whether to include this in clin_diag.

> Also, which of these fields is the foreign key to lnk_diag2code?
None of them. I don't think we need to force a code upon a
diagnosis. Coding (or classifying) for that matter is a matter
of requirements in addition to recording a diagnosis. May that
be for billing (mind you, also here we *have* to code for
billing), may that be because the user or the MPH wants to do
statistics. There will, of course, be background processes
scanning for missing diagnosis <-> code associations IF that
happens to be necessary. Missing associations will be reported
in housekeeping_todo.

IF one would REALLY want to force associations at
update/insert time triggers can be added locally.

> > -- "working set" of diagnoses
> > create table lnk_diag2code (
> >     pk serial primary key,
> >     description text
> >             not null,
> >     code text
> >             not null,
> unique, surely.
Nope, see the unique constraint below. Different codesets just
may happen to have the exact same code for a given description
(think upgrades to a coding system where it is required to
keep the previous one around).



> gmPG derives the timezone from Python's time.timezone, by the docs
> | timezone
> |    The offset of the local (non-DST) timezone, in seconds west of 
> UTC..........
>                                                     ^^^^^^^
> In AU, this number gets rather large, this is what's killing the mxDateTime 
> parser.
Or rather the fact that seconds aren't a supported ISO format
for time zones in the first place, apparently.

> I've added a conversion to hours in gmPG, this seems to fix things.
Excellent.

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]