gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] diagnosis tables


From: Ian Haywood
Subject: Re: [Gnumed-devel] diagnosis tables
Date: Wed, 28 Apr 2004 13:27:58 +1000

On Tue, 27 Apr 2004 16:32:06 +0200
Karsten Hilbert <address@hidden> wrote:

> Please consider the enclosed tables for storing diagnoses.
> 
> Discussion, comments, criticism solicited.
> 
> -- ============================================
> -- diagnosis tables
> -- --------------------------------------------
> -- patient attached diagnosis
> create table clin_diag (
>       pk serial primary key,
[snip]
>               default true
>               check ((is_active = true) and (is_significant = true))
Consider
        laterality char default '?' check (laterality in 'l', 'r', '?'),

Also, which of these fields is the foreign key to lnk_diag2code?

> -- "working set" of diagnoses
> create table lnk_diag2code (
>       pk serial primary key,
>       description text
>               not null,
>       code text
>               not null,
unique, surely.
>       xfk_coding_system text
>               not null,
>       unique (description, code, xfk_coding_system)
> ) inherits (audit_fields);

> select dob from v_basic_person
> yields "+01" results.
Same here using psql. Only connections via gnumed give insane timezones.

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.
I've added a conversion to hours in gmPG, this seems to fix things.

Ian


-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E


Attachment: pgpW2OoauIYWw.pgp
Description: PGP signature


reply via email to

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