Re: [Gnumed-bugs] <bug>: tryed to merge patients

[Karsten Hilbert]

Hi Marc,

> client version: 1.5.9

helps us a lot more when

> user comment  : tryed to merge patients

fails because it creates a script

> 2015-12-20 13:11:30  WARNING   gmPerson.py::assimilate_identity(): identity 
> [3965] is about to assimilate identity [1672], SQL script 
> [/tmp/gnumed/marc/gm-lfd6u0/gm-assimilate-1672-into-3965-OuJLIY.sql]

containing the SQL it runs to do so each time it is run.

That script lives in the instance temp dir and is only valid
for a very limited amount of time (it contains hardcoded
primary keys).

If you feel you exactly understand what each command in that
file does you can run it with "psql" against your database.
Also, we can use it to analyze potential problems.

In your case GNUmed was trying to coalesce the allergy states
of the two patients to be merged:

        UPDATE clin.allergy_state SET
                has_allergy = greatest (
                        (SELECT has_allergy FROM clin.v_pat_allergy_state WHERE 
pk_patient = 1672),
                        (SELECT has_allergy FROM clin.v_pat_allergy_state WHERE 
pk_patient = 3965)
                )
        WHERE
                pk = (SELECT pk_allergy_state FROM clin.v_pat_allergy_state 
WHERE pk_patient = 3965)

Given the fact that the merged row is to contain a 1 for the
actual .has_allergy (meaning "does have allergies"):

        DETAIL:  Failing row contains (225038, 1, 2015-12-20 
13:11:30.405087+01, gm-dbo, 3965, >>>1<<<, null, null, 16153)

but a NULL for .last_confirmed

        DETAIL:  Failing row contains (225038, 1, 2015-12-20 
13:11:30.405087+01, gm-dbo, 3965, 1, null, >>>null<<<, 16153)

a check constraint violation is reported

        IntegrityError: new row for relation "allergy_state" violates check 
constraint "allergy_state_check"

Since the above SQL

a) updates the existing row belonging to the patient being merged INTO
b) does NOT update the existing .last_confirmed
c) uses greatest(has_allergy) from among both patients

it will end up setting .has_allergy to 1 from the patient
being merged FROM but leaves .last_confirmed at NULL courtesy
of the patient being merged INTO.

That fails. The update will have to take that into account
and I have changed it to (for 1.5.next):

        UPDATE clin.allergy_state SET
                has_allergy = greatest (
                        (SELECT has_allergy FROM clin.v_pat_allergy_state WHERE 
pk_patient = %(pat2del)s),
                        (SELECT has_allergy FROM clin.v_pat_allergy_state WHERE 
pk_patient = %(pat2keep)s)
                ),
                -- perhaps use least() to play it safe and make it appear 
longer ago than it might have been, actually ?
                last_confirmed = greatest (
                        (SELECT last_confirmed FROM clin.v_pat_allergy_state 
WHERE pk_patient = %(pat2del)s),
                        (SELECT last_confirmed FROM clin.v_pat_allergy_state 
WHERE pk_patient = %(pat2keep)s)
                )
        WHERE
                pk = (SELECT pk_allergy_state FROM clin.v_pat_allergy_state 
WHERE pk_patient = %(pat2keep)s)

There's a few options for you right now:

- wait for 1.5.10
- use the attached gmPerson.py
- manually edit the SQL script in the temp dir
- manually reconcile the allergy states of both patients
- use the client to reconcile the allergy states of the patients

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

gmPerson.py
Description: Text Data