[Top][All Lists]

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

Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 55, Issue 19

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Re: Gnumed-devel Digest, Vol 55, Issue 19
Date: Sat, 30 Jun 2007 11:27:01 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Fri, Jun 29, 2007 at 09:34:21AM +0200, Ruthard Baudach wrote:

> Open MRS is breaking the concept dictionary approach at many places in  
> there data structure. Look e.g. at the personal data - all data to the  
> patient's name is stored in one table, all address data and so on.
Horrible, I know.

> A conceptual approach for personal data wouldn't make sense as naming  
> conventions or the way locations are addressed don't change very often.
Well, but they *are* hugely variable across nationalities.

Also, particularly with names, I'd like to eventually change
the GNUmed schema to something like:

create table dem.name_part_type (
        pk serial primary key,
        value text
                not null
                check <not empty>

create table (
        pk serial primary key,
        fk_identity integer
                references dem.identity(pk),
        active boolean
                not null
                default true,
        unique (fk_identity, active)
) inherits (audit.audit_parent);

create table dem.name_part (
        pk serial primary key,
        fk_name integer
                references name(pk),
        fk_type integer
                references name_part_type(pk),
        value text
                not null
                check <not empty>,
        unique (fk_name, fk_type)
) inherits (audit.audit_parent);

The table name_part_type would hold data such as

        maiden name
        warrior name
        artist name

A few name formatting rules would then allow displaying the
correct name based on nationality or country of letter
target or GNUmed deployment locality.   

> On the other hand, as far as I understood the database scheme of GNUmed,  
> FNUmed seems to use a concept dictionary approach where it is sensibel -  
> for storage of encounters for exyample, but without making a lot of fuzz  
> about it.
Sort of but only to the first degree. We don't directly
*facilitate* concept reuse, either. However, there's also a
camp which warns against the evils of the OTLT syndrom -
"One True Lookup Table" which AFAIU the concept dictionary
needs, EAV-on-steroids, so to speak.

> OpenMRS would habve been handy in 2000, as you started work

> - If I'm not  
> mistaken, it would be "only" necessary to write a GUI for OpenMSR (and  
> billing modules, and national form handling modules, and letter modules  
> and and and)
Yep :-)

> Now, OpenMRS might give some good ideas, and help to polish the database  
> structure.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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