Re: [Gnumed-devel] on meaningfully signing off reviewed items

[Karsten Hilbert]

On Sun, Jan 29, 2006 at 12:05:21AM -0800, Jim Busser wrote:

> Sorry to ask (again) what is actually "done" with a 
> letter/document/file when it arrives,
No problem. This hasn't perhaps been spelt out clearly in
the recent past.

Documents in GNUmed are a collection of "objects" and some
metadata both at the document and at the object level. What
those objects are is of no concern to our document
management system. They can be movies, scans, picture, audio
recordings, emails, a *.doc, a PDF, whatever, also mixed in
type freely among each other. Think of them as the "files"
which make up the document as a whole. At one time they most
likely were real files for a moment. But eventually they are
stored *inside* the database, as the content of the field
doc_obj.data, to be precise.

Here is the workflow:

Incoming documents are scanned and the file(s) imported
into PostgreSQL. The paper original could be disposed of
depending on jurisdiction.

Newly imported documents have a reviewed status of "not
reviewed". The intended reviewer is set to the "primary"
doctor of the patient unless overriden. The GUI may allow to
immediately set the status to "reviewed", for example if the
doctor is handed a document by the patient and she discusses,
scans, and imports it right away during the encounter.

For unreviewed documents the intended reviewer is notified
via her inbox which will say "patient XY has unreviewed
documents". Double-clicking that message will take the
reviewer to the patient's document tree (or a widget better
suited for reviewing) where unreviewed documents can then be
reviewed.

Assuming a followup letter arrives with histology details it
is most likely prudent to create a new document "discharge
letter" with a comment along the lines of

 "histology follow-up for 12/05 St.James Hpt: high-grade dysplasia !"

However, inevitably, for inscrutable reasons a page will be
lost in the rumble when scanning a document only to
re-emerge later. The missing page may even go unnoticed
initally. In that case the natural tendency would be to
attach an additional object - the scan of the missing page -
to the existing document. This is certainly technically
supported by the backend. We can even re-order the pages
explicitely.

Does that clear up the fog ?

> Supposing it were a digital file, would a copy of this file be 
> imported to live "inside" a Postgres table row presumably as data 
> type "blob", permitting the EMR to archive or delete the original 
> however they choose,
yes

> or will GNUmed instead write into a table row 
> only a "link" (file specification) for the file?
no

> I suspect *not* the latter though it be how documents are handled in some 
> EMRs!
We don't try to emulate Bad Things if we can help it ;-)

> So if, after the initial import of a document into a row, an entire 
> replacement copy or an extra page later arrives, there can only be 
> two options(?). Modify the original row, or create a new row purely 
> to hold the newer corrected & complete version of a document or the 
> additional page, however the case may be.
There is a third option which is what can happen in GNUmed
(for legit or illegit (?) reasons):

A row is added to the objects table and is then *linked* to
the documents table just like all the other object rows
making up the document.

> So if a row becomes modified, it becomes subject to the audit trail
Well, that's part of the problem: We don't currently audit
the raw object data table because the feeling was we would
not want to audit large blobs. These can be up to several MB
each. However, they are rarely changed, perhaps slightly
less rarely deleted.

So perhaps we *should* audit them ?

Ian, Richard, Horst, others, what do you think ?

Nevertheless, even without audit trailing the blobs
themselves we can detect tampering by signed timestamping of
database export backups (the GNotary concept).

> which would make it clear that it had been altered, potentially by 
> someone other than the person who signed it. So the only remaining 
> problem is our contention that the doctor carries the responsibility 
> to view and acknowledge the alteration.
Well, the workflow support tool (IOW the GUI) must then make
sure the intended reviewer is, again, notified of the
addition or change.

> While the record would carry 
> the modified_by value that pertains to the user who did it, any 
> existing value for "signed by" would no longer have clinical meaning. 
Exactly -- if we had signed off the *document*. But we sign
off (implicitely) on the individual objects such that an
added object does not automatically acquire signed-offness.
So, additions are safe.

> So we should specify "on update, signed_by is NULL" which would 
> require the widget to write a "null" for signed_by?
That's a pretty cool idea. We can do this in an "on update"
trigger.

on update to doc_obj
        if new.data != old.data
                invalidate "reviewed" records for this doc_obj row

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