[Gnumed-devel] Re: lab data/blobs/tracking (was offlist Re: further work - vacc popup)

[Karsten Hilbert]

On Sat, Oct 22, 2005 at 02:54:10PM -0700, Jim Busser wrote:
> Subject: lab data/blobs/tracking (was offlist Re: further work - vacc
>  popup)

> >I think the sanest thing to do
> >for now is to require the blobs schema to exist in the same
> >database as the clinical schema thereby making it much safer
> >to use a linked tracking table. I'll try to keep the
> >tracking table(s) completely generic such that any kind of
> >information can be tracked if desired.

> The discussion dates back to some of the following
> http://lists.gnu.org/archive/html/gnumed-devel/2005-02/msg00282.html
> http://lists.gnu.org/archive/html/gnumed-devel/2005-03/msg00057.html
> http://lists.gnu.org/archive/html/gnumed-devel/2005-03/msg00112.html

> are we clear enough on how new 
> information (and within that, new patient information) will come into 
> GNUmed?
>
> methods/sources:
> 
> - fetcher/importers connect to lab data clearinghouses to pull down 
> results, these are only ever patient-related, although it could be 
> possible to receive results for a patient who is not yet in GNUmed, 
> either because we were misidentified or because the patient has yet 
> to make their first contact
Either the patient is automatically identifiable or she is
not. In the first case the importer can auto-import and
alert the user of the availability of new results. In the
latter case the data would go into a holding area. For test
results we already have test_results_unmatched. For files it
can be a the incoming/ folder and a notification to the user.

> - electronic messages that were not fetched above but, rather, had 
> been sent as secure messages, either by email or downloaded through a 
> web interface. Might these messages contain a mix of text (maybe a 
> private email concerning a patient) and an attachment (maybe a set of 
> granular results or an image) and
> - - if the message body was correspondence, do we want this copied
>       into a "received correspondence" are of gnumed
> - - if the message contained anything else in the body or attachment,
>      it is run through an importer which determines if it is parsable or a 
>      blob
>      and if it can match the patient, attaches it to a patient record?
For the latter see above.

I would have incoming blobs end up in incoming/. A process
would then decide whether they are
 a) immediately parseable hl7/pit/...
 b) of type a) but wrapped in a simple message envelope (=email)
 b) of complex type, eg email with several parts

Anything that is matchable and importable without residue
would be imported and matched (a and b). Some things will be
imported into *_unmatched (a and b). Most complex things may
need to stay in incoming/ with a notification of
availability until the user decides how to dispose of them
at which point parts can be imported while other parts can
be moved into the narrative etc. Some complex parts may just
have to be imported as a blob on the whole to be handed back
out to an appropriate viewer (say, a full-fledged mail reader
or AbiWord) when the need for displaying arises.

None of this changes much of the seen/unseen tracking.

- incoming/ is unseen by definition
- _unmatched is unseen by definition

Tracking only relates to "properly" imported data since
patient matching and technical import can conceivably be
done by non-medical personnel.

> - incoming letters/faxes are received as (or automatically converted 
> into) images.
They would end up in incoming/ or subdirs thereof.

> These could include:
> - a cover page to identify the intended recipient
> - the cover page (or an inside page) might also identify patients
> - it is possible that more than one patient could be identified on 
> the cover or an inside page, for example a listing of all patients in 
> the communication, each of whom has one or more reports (accounting 
> for one or more pages) deeper in the stack. In this case, do we split 
> off the pages that are not unique to distinct patients, and link this 
> "cover set" to each of the patients, or do we link it to none of the 
> patients, only to the recipient as non-patient (well, non-unique 
> patient) correspondence? In the latter case we would have:
> i. a tracking record for the cover pages linked to the doctor
>      but not to any patients *plus*
No, the cover pages are workflow debris. At the end of the
day what matters is whether a given *patient-related result*
has been reviewed by a clinician or not. We don't really
attempt to do administration level workflow quality
assurance just yet which IMHO is overkill for the average GP
practice.

The only thing we currently attempt to track is the
seen/unseen status of incoming data along with what
importance the reviewing clinician assigned to it.

> - if the incoming correspondence is purely professional or business, 
> not to do with a patient, would this prompt creation of a tracking 
> table record
No, not of any type.

> or is it proposed that the tracking table be 
> used *purely* for clinical items?
yes, no general workflow modelling

> - archival records (paper that gets scanned) - does this also require 
> a per patient tracking record for clinical management
yes, but again only to indiciate "reviewed by clinician"


> I suppose that 
> *somewhere* in an EMR it needs to be indicated whether or not a 
> legacy paper chart exists,
That would be the job of blobs.doc_med.ext_ref.

> So that may as well appear among the various other documents, it 
> simply does not require to be cued up for signing?
Well, the scanning/archival frontend may allow the tagging
of arbitrary ranges of the incoming data to be tagged as
"seen" as appropriate.

> - I am not sure if there will be other ways to get a test result into 
> GNUmed, but now I think if the front desk staff receive a critical 
> abnormal result by phone, where in GNUmed does that get inserted?
I'd have the front desk staff manually enter it into the lab
sheet of the corresponding patient and cause a notification
to be sent to the relevant doctor with the appropriate
urgency.

> Is 
> it just a "message" until the doctor chooses to create a sOap note 
> around it?
That might work just as well. If local workflow rules permit
this staff could send an email to the doc detailing the
newly obtained result.

> And so for other messages created internally within the office, will 
> it be desired for clinicians to decide which messages remain external 
> to the patient record:
...
> which you may judge should become part of the official record?
Well, we are talking about messaging here which is not yet
part of the discussion, actually.

> So an 
> internal message only becomes part of a patient's "clinical" chart 
> when it is decided by the clinician to put it into the clinical (as 
> opposed to the administrative) record? In a medicolegal case, is it 
> permitted to open and offer up only the 'clinical' chart and hold 
> back the "administrative (including messages and financial)" chart?
Well, as I see it, GNUmed does not yet try to create a
complete all-encompassing chart of clinical, admin,
financial etc etc chart of a patient. For the time being we
concentrate on the clinical aspect (which most OSS EMRs lack
severely). It may well occurr to someone to link the GNUmed
clinical chart with the FreeMed clinical billing system or
some such. For the time being we mostly discard the
administrative bits and pieces that may temporarily get
created in the database.

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