|
| From: | Syan Tan |
| Subject: | Re: [Gnumed-devel] When & where to present GNUmed e.g. IEEE Symposium? Role of 'Papers'? |
| Date: | Sun, 27 Nov 2005 18:43:54 +0800 |
What is the requirement details for prescribing ?
- the most superficial is sufficient detail when outputting a prescription print on script paper.
e.g. where i work, what seems to be minimal detail is prescriber name, prescriber locatiion, prescriber identification number,
script number - q ? what is this and how is it generated - the drug name and drug strength, package description, amount
prescribed and repeats, and dosing instruction, which might as well be free text, although some would like to "atomize" this further.
- next level is the ability to record and recall prescriptions, and to remember cancelled or changed historical prescriptions
- next level is to search for drug interactions
- next level then for drug - disease / condition interactions
In the past, prescription module attempts seem to be poo-poohed as being oversimplified, not general enough, not international enough
not meeting legal obligations, etc.... when the above level one would seem fairly simple to do. happy to hear from anyone
who would think there are some justified complexities that need to be added to the above requirement statement.
On Sat Nov 26 4:23 , J Busser sent:
>The major barriers between Gnumed and widespread use (at least in
>Australia) are the lack of a prescribing module and the lack of an
>integrated appointments/accounting system
All of this is very do-able, it really comes down to what amount of
collaborative effort can be assembled by the "GNUmed community". I am
happy to help with defining some needs and functional design, but it
is the area of coding that I imagine that we need the most help, and
that will only come from growing the community.
And unless it is possible to pull donors and investors out of the
woodwork, the way forward could be to coax people to use GNUmed as a
partial solution, postponing the other big pieces until a critical
mass of *actual* users is developed.
For example if you already register patients in a satisfactory
scheduling and billing program it is possible to "push" the patient's
registration information into GNUmed (or to switch to GNUmed and
"pull" it in) and then conduct your clinical work inside GNUmed.
So I would suggest the supporters of GNUmed, inside each country,
identify a commercial vendor that is willing to let its own partial
solution (scheduling and billing) inter-operate with GNUmed.
re prescribing:
A proven approach has been taken by OSCAR McMaster which, for
prescribing, deployed an instance (correct term?) of drugref and
after populating it with a Canadian inventory of drugs, wrote hooks
from OSCAR for prescription-writing.
So with a suitable prescribing module, installations of GNUmed in
Canada could share access to that same server. One drugref server per
country might serve the needs of multiple clinics using different OSS
EMRs. Load, rather than distance, may be the determining factor
because I know an OSCAR site in my province of British Columbia that
accesses a drugref server at distance of two thousand miles without
usability complaints.
For Australia, Richard Terry had reported on-list (see the archive)
special permission having been obtained from an Australian company
(or branch) to allow their drug inventory to reside in drugref, at
least for the GNUmed project, on at least a trial basis. But I do not
know where it stands.
re appointments:
I know someone working on another OSS project (not OSCAR) who knows
David Chan, and who is interested to determine from David what are
his views about that code being borrowed and redeployed inside other
GPLd projects.
re accounting:
This is maybe usefully divisible into patient service (medical
services)-based accounting which can involve the electronic
submission of claims to paying organizations, versus more
general-purpose accounting for the medical practice that can inform
the tracking and ordering of supplies in addition to managing the
office expenses and payroll. Maybe also invoicing for clinical work
or consulting that is not accessible through electronic claims
submission. For the first area, there had been discussion of trying
to use freeb but I believe freeb may have (at least its originator
has) been absorbed into a commercial company. I had assembled some
background notes that reside on the wiki. For the second area people
have proposed SQL-Ledger but they could certainly use an off the
shelf package.
_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel
| [Prev in Thread] | Current Thread | [Next in Thread] |