[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-bugs] <bug>: on saving scanned document
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-bugs] <bug>: on saving scanned document |
Date: |
Mon, 25 Nov 2013 18:44:55 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Mon, Nov 25, 2013 at 12:19:28AM +0100, Karsten Hilbert wrote:
> > user comment : on saving scanned document
> >
> > client version: 1.4.0
>
> You've been inserting a document but GNUmed did not
> like that idea:
>
> > 2013-11-24 17:52:41 ERROR gm.db
> > (/usr/share/gnumed/Gnumed/pycommon/gmPG2.py::run_rw_queries() #1334): RW
> > query failed: [INSERT INTO blobs.doc_med (fk_type, fk_encounter,
> > fk_episode) VALUES (27, 7819, 1539) RETURNING pk]
>
> In particular it thought that both the episode and
> the encounter that are being linked to the document
> better belong to one and the same patient. And they
> did not seem to. And that's what the database tells
> us about:
>
> > 2013-11-24 17:52:41 ERROR gm.db
> > (/usr/share/gnumed/Gnumed/pycommon/gmPG2.py::run_rw_queries() #1339): PG
> > error message: ERROR: INSERT into blobs.doc_med: Sanity check failed.
> > Encounter 7819 patient = 1913. Episode 1539 patient = 768.
>
> I had a look at the code of the sanity check which
> raises this concern and it did seem correct. So, let's
> double-check your data. Please report the output of
> the following:
>
> select * from clin.encounter where pk = 7819;
>
> select * from clin.episode where pk = 1539;
>
> select * from clin.encounter where pk = (select fk_encounter from
> clin.episode where pk = 1539);
>
> That should shed some light.
I have been able to replicate this behaviour. It happens under certain
circumstances only. A workaround is to explicitely select an episode
for new documents rather than accept the default...
Off to fixing ...
Karsten
--
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346