[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] patient object - backend listener
From: |
Horst Herb |
Subject: |
Re: [Gnumed-devel] patient object - backend listener |
Date: |
Thu, 06 Feb 2003 16:02:29 +1100 |
User-agent: |
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021212 |
Karsten Hilbert wrote:
Or will we display a three line salute and let the user make
up her mind ?
1) _original_content_of_item____
2) _current_content_in_database_
3) _our_changes_to_content______
"Please select the version you want to keep !"
I think this is the only viable solution.
That said, such condition is extremely unlikely to arise: virtually all
health record related data is write-once and read-only thereafter.
Not very likely that two people in the same system clash very often
editing the little data that makes sense editing (like a person's
current address: but even there, there is little likelihood of a clash:
you never actually *edit* a name or an address, you jsut create a new
record and the you *link* this information. This is one of the better
reasons why data should be highly normalized.
Example:
You change Mr Smithe's surname to Mrs Jones, since she just married:
- in a denormalized unversioned system, you overwrite Smith with Jones
- in a normalized versioned system, you create a new surname "Jones" and
link it up in a one to many relationship with the identity bearing this
name, and only then you tag is as the "current surname". The only
information that can possibly clash is the change of the tag, one single
internal ID. Not likely to clash, and if it ever clashes, there can
only be one right information, the other information must be wrong. Will
not take long to figure out which information is right and which is wrong.
Our system is not denormalized and versioned just for fun: we trade our
complexity for this utmost comfortable feeling of having literally
uncorruptable records.
HOrst