[Top][All Lists]

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

Re: [Gnumed-devel] LabJournal

From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] LabJournal
Date: Sun, 3 Oct 2004 22:49:00 +0200
User-agent: KMail/1.7

On Thursday 30 September 2004 19:45, Karsten Hilbert wrote:
> 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.
Yes, talk to me :-). Well I am back physically from Brazil.  
I can implement this. How exactly would you like it ?
I am talking GUI here. I could place a button anywhere but maybe this is not 
the best solution.
> > 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

Sebastian Hilbert 
Leipzig / Germany
[]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice

reply via email to

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