gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Anticoagulation project and larger planning issues


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Anticoagulation project and larger planning issues
Date: Mon, 7 Feb 2005 15:16:23 +0100
User-agent: Mutt/1.3.22.1i

> I now have a computer (Windows XP) set up for the nurses.
Good. XP does run PostgreSQL.

> The local district strategic planning committee believes that a set 
> of very basic modules
> - patient identification (even if just "fed" from an appointment 
>   manager / biller)
> - lab results handling
> - medication management
> 
> would be a very good starting point for many people
Are we still in the game if we focus on "just"
  - patient identification
  - lab results handling
leaving
  - medication management
out of the loop for now ?

(Apart from anti coag handling which may suffice to be done
through soap rows for the time being.)

> @ Karsten & others, would it take a full-time programmer more than a 
> month to develop gnumed to the extent I need?
Likely, yes.

> Should a programmer 
> from a developed country cost much more than $50 Can/Aus (30 euros) 
> per hour? (Not twice that, I hope!!!)
I have no idea.

> EMR needs for an anticoagulation clinic:
> ========================================
Jim, can you put those somewhere permanent, eg the Wiki ?

> input new patient from the keyboard
> detect / warn if duplicate patient about to be created
> edit current demographic information
needs to be done ASAP, "primitive" version possible within a
week (3 days full-time)

> find patient
done

> input health issue(s)
>       indication for anticoagulation
>       target intensity (INR 2.5-3.5)
Eg. you want to be able to call up patient X and enter a
health issue "Post-MI 6/2004" and enter a target intensity for
the INR. The latter might be put into a soaP row. A day or so.

> input medications (warfarin & maybe a low molecular weight heparin 
> (LMWH) e.g. tinzaparin)
This needs work. 3 weeks (1 week full-time)

> input soaP
>       set date for next lab_request
>       identify lab_request status (needed/printed/submitted vs 
> standing order)
1 week (3 days full-time).

> establish connection to lab to fetch lab data
> fetch data (LOINC)
3 weeks full-time. Outside work.

> populate gnumed test_type table with any "new" combinations of
>       organisation/code/coding_system
1 week (3 days full-time)

> notify users that new lab data is available
How ? 3 days full-time.

> import data into staging table
>       match to patients (since Canada uses no lab_request id) :-(
>       if lab_request originated from the clinic
>               offer that encounter/episode as the one to link
>       elif originated from some other provider
>               create dummy encounter/episode "unrequested test results"
"unrequested" might be put into the comment. I would then
link the results to the *current* encounter/episode.

>       update the following for actual requests +- unrequested test results
>               update lab_request_id (internal to the lab)
>               update lab_rxd_when (specimen date/time received)
>               update results_reported_when (was the report generated)
>               update request_status (final, preliminary, partial)
>               update is_pending
> transfer data into test_results
> assign fk_reviewer
5 weeks (1 week full-time)

> permit manual entry of lab results that did not arrive by way of the 
> electronic interface
1 week full-time

> next, the following must be identifiable and must support a good work flow:
> - for test results outside of range
>       instruction obtained from doctor
>       input medication change (including "no change")
>       - capture the change as "as nurse user xx" for "authorizing Doctor yy"
>       soaP entry references medication change and next lab_request
>       patient notified & notification status is captured
>       (might we want notification_status in test_results?)
>       test results outside of range are marked as having been dealt with
>       for all these, set reviewed_by_clinician boolean "TRUE"
> - for test results within range
>       soaP entry specifies per-protocol next lab_request
>       patient notified & notification status is captured
>       test results within range are marked as having been dealt with
>       for all these, set reviewed_by_clinician boolean "TRUE"
> - for overdue requests having lab_rxd_when is NULL
>       patient is contacted / reminded / SoaP captured
>       existing lab_request is CANCELLED
>       new lab_request is entered (or should existing be modified?)
>       overdue requests are marked as having been dealt with
Hard to tell.

Jim, starting from this can you separate out what needs to be
done first to be able to show "something" to the nurses, what
needs to be at the very minimum to offer them "something
useful" and what can be done after that ?

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]