[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 dem.name (
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
lastname
firstname
nickname
maiden name
warrior name
artist name
pseudonym
alias
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
Yep.
> - 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.
Absolutely.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346