Re: [Gnumed-devel] Fwd: Lab data support in OSCAR

[Karsten Hilbert]

Jim,

thanks for your probing into OSCAR. Here is what we support
(and to various levels of completeness already do):

> One other functional design element not included below is the need to 
> "flag" new results as having to be looked at by a doc in the clinic, 
> perhaps flagging abnormal results as even more important, and to 
> capture the fact once these have been viewed (i.e. by which doctor). Is 
> it felt that such functionality, and some items listed below, should be 
> targets for GNUMed?
On any test result record we support the following fields:

technically_abnormal
 - this is what the lab thinks about the value obtained from
   the sample, usually whether it's outside the range found in
   "normal" patients when using this method of measuring,
   however, if the lab has background info on the patient this
   may have very well been taken into account

reviewed_by_clinician
 - whether or not a clinician at the practice (usually one of
   the docs) has reviewed this result

fk_reviewer
 - points to who reviewed the result

clinically_relevant
 - whether or not the reviewing clinician flagged this result
   as clinically relevant, this must not coincide with
   technically_abnormal

Now, we also have some logical constraints on what
combinations of the above can occur.

1) only if reviewed_by_clinician is false may
   technically_abnormal be null

2) reviewed_by_clinician may only be true or false, default
   false

3) fk_reviewer may only be null if reviewed_by_clinician is
   false, default null

4) clinically_relevant may only be null if
   reviewed_by_clinician is false, default null

This enforces quite some data quality *right on the backend*
regardless of how crappy an application is interfacing with
the database. Things such as this are one of the reasons why
we don't even attempt to support MySQL. It simply doesn't
deliver.

> >the future.  This addition would probably require separate database 
> >tables,
> >as our lab system is built strictly to handle HL7 lab data.
Ah, what a cardinal mistake !  Transferred to looking at the
human race this is the same as saying: "Nah, you are
Jewish/Black/Native American/... you can't have lunch at this
restaurant." And, of course, when adding this functionality
one would NOT by any means want to introduce additional tables
but rather generalize the tables that are there. This is my
biggest criticism with OSCAR. It is worse with Care2x.

> > > - batch download and processing of resulted tests (automated via
> > > schedule) which I expect is a given basic minimum for an EMR
> >Yes - the lab module downloads and processes test results automatically
> >every 10-20 minutes (this value is easily configurable).
We (that is, at my parents' GP practice) download once per
night. This is run by cron so it is easily changeable.

> >Missing a lab "pickup" shouldn't cause any problems, as the lab 
> >results sit
> >in a queue on PathNET's servers until they are downloaded.
True, but we need the result *now*. That matters more to us since
we only download once daily.

> >We could
> >probably give the user the option to trigger PathNET downloads 
> >manually.
> >However, PathNET has a minimum delay between downloads (10 minutes).  
Sounds reasonable. Believe it or not or lab has the weirdest
download rules ever: At midnight available results are
archived if any download was attempted during the preceding 24
hours no matter whether that failed or succeeded. Before
midnight you can download as many times as you wish. You will
always get all the results available up to that point in time
including the ones you had downloaded previously on that day.
There's no error handling whatsoever. So what we are doing is
parsing the data in-flight on the wire making sure we receive
a valid structure and detect the last line of the file
(thankfully, that's doable without ambiguity).

> >Our lab module automatically matches Lab data to OSCAR patients based 
> >on PHN numbers.
We auto-match data when either the lab request ID (that
barcode sticker number) is unambiguously associated with a
patient or the patient demographics (first, last, dob, gender)
obtained from the result match *one* patient.

> >However, users must verify the matched data before it is 
> >"Linked" to the patient's EMR.
We don't require verification for auto-matches. That can be
added, however.

> >As well, users must manually link any lab results
> >that are not matched automatically.  Undo functionality is provided.
Unmatched results are put back into the import queue and a
note regarding their status (eg, couldn't match incoming
request ... to any patient) is put into the housekeeping todo
for the user to handle. This todo log is found in the lab
journal tab of the main notebook. Undo is as easy as saying
"link this result to that patient" - which isn't implemented,
however.

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