gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] LabJournal


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] LabJournal
Date: Thu, 30 Sep 2004 19:45:16 +0200
User-agent: Mutt/1.3.22.1i

OK, I am looking at the lab journal right now.

Here is an idea for the Wiki: add a page per plugin where we
can keep record of change requests

> Under the first tab, where you enter the id for each request, the 
> Journal is for all patients that are having tests ordered?
Yes. The first tab has the concept "pending request" so it
offers a view on all pending requests and a way to enter a new
request which would then be pending, too.

> Can it 
> limit the view to a single patient (so that you can see what has been 
> ordered for the one patient)
No it cannot currently but can be made to if need be. Talk to
Sebastian about that.

> or would this information have to be 
> accessed through a different plug-in after activating a single 
> patient?
Not a good solution IMO.


> Maybe if a patient is active, and you then go to LabJournal, 
> it would be useful to show ONLY testst that have been (or are being) 
> requested for the active patient, and by use of a button or menu or 
> keystroke to expand the view to all patients?
Sounds reasonable - Sebastian ?

> Is there also now, or would it in future be useful to present, 
> alongside what has been ordered, whether the result has yet come 
> back, or if it is still pending?
status is displayed already, currently status cannot be
"completed", however

> Requested but unresulted labs will 
> presumably not show in the PathLab plugin, because the results will 
> not yet exist.
correct

> In the second tab, shown are those results which have not been 
> successfully matched to a request id
well, any kind of errors that happened during automatic
processing of lab data is aggregated here, errors that were
directly presented to a user are not found here

eg. when the importer notes a situation it cannot handle it
will report in as much detail as necessary what is the matter,
the user will then find those error reports in this second tab
of the lab journal and must do something about them, there is
no way yet, to delete handled reports from here but that can
also be done manually as they are saved in a backend table, of
course, and that table is a general table for such reporting -
the lab journal error tab is just a *view* on that table ...

>, for example if the lab sent you 
> data that was garbled or miscoded or from some doctor outside the 
> practice who ordered the test, but directed that you be sent a copy.
like that, yeah

> For such results, is it agreed useful to to offer alongside them a 
> list of default matches on a formula like
...
> Would it permit the matches that are offered to be accepted singly or 
> in any manually-clicked combination?
sure, just that someone needs to implement that

> I am thinking the acceptance/ linking of the 
> result to the patient needs to capture the responsible clinician or 
> is this limited to the "review" step?
well, whoever writes data into test_result will be recorded by
way of the auditing

> What happens if someone copies you the result on a patient that does 
> not yet exist in your system, but that someone else (maybe a doctor 
> outside your practice whose patient you may be willing to see, but no 
> record has not yet been created for them, maybe your colleague has 
> not even had a chance to discuss this with you yet). It would be 
> helpful to see details of the test information including which doctor 
> requested the test, and once you decide if you wish to keep this 
> result you can create a new patient and put in however much 
> information will help the soft match to occur most easily.
if there is a need this seems useful

> What do you do when you decide a result does not belong to your 
> practice for example if you were sent it in error. In Canada, even if 
> you received it by mistake, there is a responsibility to make sure 
> the patient is looked after so it can involve contacting the lab or 
> the ordering doctor or whoever was supposed to have received it, and 
> to get the lab to re-issue it or to forward it yourself. The fact 
> that this has been taken care of also needs to be documented - should 
> I/we pre-empt the use of the field test_result.note_provider or do we 
> need some additional field or does this fall to a workflow table to 
> show what action has arisen from the result?
not pre-empt but *use* for that purpose. sounds like a perfect
match to me - for test_result.narrative (eg. v_test_results.comment)

> Also even when it was not your patient but you are now (as in my 
> case) "stuck" with that result, it is going to be difficult to find 
> if there should later be a complaint, for example "Dr Busser you were 
> sent a copy of a result on Missy Jones, verify this, and identify 
> what was done". Therefore I should have to create Missy Jones as a 
> patient if I am later to find this record.
if that is necessary in a given jurisdiction - sure, why not ?

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]