Re: [Gnumed-devel] database schema, was Re: LinuDent and tk_fp and odontolinux

[Horst Herb]

On Wed, 17 Apr 2002 10:33, Andrew Ho wrote:
> Sharing the DB is a good idea. However, is the DB schema easy to extend
> and manage over time? For example, if I take the GNUmed DB and modify a
> few of its tables (e.g. for psychiatry), how do I make sure that I don't
> break compatibility with the Internal Medicine modules? How do I make
> sure what I added will work with other people's ideas for describing the
> psychiatry domain?

Easy. We broke up our database design into independend "services". That is, 
one set of tables and relationship focuses on demographics - and nothing 
else. One set of tables and relationship focuses on pharmaceutic 
reference, and so forth.
For psychiatry, you just add another psychiatry centric "service", but you 
don't modify existing tables.
Our design is highly (though not completely) normalized. In your own added 
tables, you just add references to whatever other existing information you 
need to incorporate into your own design.

The main GUI client software allows plugins; You can take the 
off-the-shelve user interface and write a few plugins adding dialogs for 
your domain-specific problems. The design is dead-easy: all your plugin 
does is 
1.) suggest where to be placed on the user interface (you can enforce a 
placement on the GUI too if you need)
2.) register itself with a variety of "broker" objects that give the plugin 
- access to user interface elements 
- access existing database connections
- access to callback function registers that notify the plugin on data 
changes (like when a different patient is selected by the user)

When you write your plugin, you just focus on your domain specific needs. 
Chances are, that the features common to any domain (like patients 
demographics, pathology results etc) are already working and need no 
modification. As most user interaction happens through "notebook" alike 
widgets, you can expand existing ones by letting your plugin simply add 
"pages".

You can reach such autonomy of information only with highly normalized 
data; otherwise, there would be too much artificial interdependence of 
information preventing you from adding information in a "black box" style. 
Thus, I see the lack of normalization a great weakness in other projects.

Horst