Re: [Gnumed-devel] patient object - backend listener

[Karsten Hilbert]

> I think this is the only viable solution.
Certainly.

> That said, such condition is extremely unlikely to arise
Not really.

> virtually all 
> health record related data is write-once and read-only thereafter.
Write-once read-only does not always help here.

Your surname example isn't particularly good, I guess. Let me
give you one from daily practice:

Suppose that all of the anamnestic data of *one* encounter (one
day, usually) is stored in one text field.

Rambling about in our practice I happen to wander into our
small septic surgery room with the intent to pick up some item
or other. There I am helloed at by Mrs Jones whom I see
regularly but who is seeing another doctor today for a right
hand knife cut at lunch time. Her record ist called up on
screen. I verify with her from my memory that her Tet shot is
up to date. I don't look at her record, I don't make a note
about that in her on-screen record but rather pick up what I
needed and wander back to my room. The reason for my asking in
the first place was that a) she usually is my patient and b)
the tet shots are stored in a fridge the consultation room I
am in today so that - if need be - I can send down my nurse to
the sep OR with a tet shot. Which, thankfully, isn't needed
here. I don't know if her doctor-for-the-day checked up on
Tet.

Anyways, back in my room I decide to do leave a note in her
anamnesis for today. I do so and this is the root of the evil:
I type "had Tet shot in 1999". This is in the database now.
Meanwhile the other doc has returned and is typing some other
stuff about how and when it happened - more anamnestic data,
that is. The sep OR does not show the note, however, until I
commit my note. AT THAT POINT it becomes unclear as to what to
do. The three-line salute mentioned before is not sufficient.

We can't discard either note. We must store both of them...

Well, upon further thinking, this particular case is solvable,
too: Since the information was entered by different providers
(me and the other doc) we would create two anamenstic record
rows with a different provider ID that are merged on display.
In this particular case reduncancy may or may not arrive
depending on whether the other doc also checks Mrs. Jones' Tet
status and records that.

So, mainly it boils down to the *same provider* recording
conflicting data of the same type within the same timeframe.
Not that's a bit unlikely, agreed. But it can happen, e.g. if
I (improperly) seize the other doc's ID for the moment.

Anyone still see any flaws here ?

This still leaves us with the question of HOW to detect this
situation. Shall we add timestamps or some other identifier to
the rows via the audit parent ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346