[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major r
From: |
Thilo Schuler |
Subject: |
Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005) |
Date: |
Thu, 27 Jan 2005 02:24:26 +1100 |
User-agent: |
Mozilla Thunderbird 0.7.3 (Windows/20040803) |
J Busser wrote:
What would gnumed require to gain doctors' interest, and possibly excite
them?
In descending order:
1. can fully serve their clinical and administrative (billing etc) EMR
needs
2. can serve a partial solution, able to be integrated with other EMRs
for the
other parts (billing, scheduling)
3. partial solution that integrates *incompletely* (or not at all) i.e.
requires some double-entry, or has other limitations (e.g. client
configuration
demands limits remote access), however gnumed's value is worth it
4. demonstrable potential ("within reach") to achieve some or all of the
above
5. {philosophical /proof of concept/ hobby} participation
Of course there is the issue of how *well* gnumed does the above, but
let that
be "understood". So, working up from the bottom:
- at #5, people are already participating
- at #4, some people are confident but others are not
- at #3, gnumed may be close to providing a partial solution, but this
will not
really "count" until it is in place and working. We will probably only
achieve "excitement" once several demonstration/installation sites achieve
Level 2-3 function and this should include non-developer consultants and
support people who can get an installation up and running without having
to ask
for help.
Agree, especially the easy installation is considered crucial IMO
To better get us "up" the ladder, from #5 toward #1:
- Might it help to solicit third-party assessments of gnumed's
potential? For
example, if a clinical group (or groups) retained a consultant to assess
one or
more EMR candidates and in the process evaluated/identified gnumed's design
as "sound", and could identify the cost to a group to get additional needed
code written and deployed, might that not be a help? Obviously the "gnumed"
people probably think that "gnumed" is good, but an outsider would ask
"does anyone else"?
A positive assessment (including some back and white cost figures) would
be a great argument.
But probably not many consultancies can assess medical OSS properly.
- Might web-enabling be a helpful stepping stone? I recognize that the
*long-
term* gnumed plan is to provide a GUI client that will be far more
nimble and
effective than a browser-based client. However, there are sizeable
groups of
doctors already invested in a paper practice, for whom a stepped approach
(moving through a hybrid system) will be more manageable. For these
people, the
ability to access/view/manage patient contact details, lab results and
prescriptions will be **huge**, even if they continue (for a while) to make
their entries on paper, and continue to use fax machines. The ability to
*not*
have to install and configure Python/wxWindows/GnuMed on every client could
remove a **huge** impediment to people **trying** gnumed. Right now, it
is EASY
for people to LOOK at OSCAR. That is not possible with gnumed. I am still
trying to figure out how my anticoagulation clinic project could be
achieved as
the easiest possible "win" but at the same time helping as much as
possible to
advance gnumed. My project funds would go further, and could do more, if I
could align/pool them with any resources, projects and plans (for example)
Carlos may know to be possible, and which (for example) Syan might also
like to
help to guide. So now I ask, what do people think of a strategy of
achieving
the "basics" via web while very much still building the GUI client for
the more
ambitious functions?
I think a web client is good intermediate solution since as you said it
is a lot more convincing to look at an even only partly functinal program.
I am trying to get into a project course for the next and last term at
an Aussie uni (happened to be very unlucky with my choice -> has been a
waste of time only justified to get a visa).
I will propose to write a web client (at least for some functions) for
GNUmed in those 2 days per week.
Planned to do this in XUL (Example: Open
http://www.faser.net/mab/remote.cfm with Firefox or Mozilla 1.7)
Mentioned XUL a couple of weeks ago. Would try to interface it with
GNUmed's python middleware objects through PyXPCOM.
Tim had responded sceptically. I tried to reach him to ask about his
experience. (@Tim: if you read this, I would like to contact you. I
think we both live in SYD, so I could call you or even meet you)
To figure out what is possible I will do some preliminary exploring (+
documenting). I started today with adding some info on the DB structure
to the wiki. I will keep on amending this. Other topics I want to look
into is health issue/episode/encounter (@Jim: Did I remember correctly
that you want to write something up) and use of the GNUmed API ie the
middleware objects
good night
-thilo
- And on the matter of a GUI client, which I know some will want to see
stay "front and centre", can the client software be more portable? Would
it be
possible to have all of the "client" dependencies (application files and
configgurations etc.) stored on a USB Flash drive? You could be at the
hospital
or at a friend's house, you could be on-call or even just remember
something
that you have to check or "do", and you could just pop in the USB Flash
drive
and "go". No more having to have your laptop with you just to access
your EMR.
You could even have the drive set up with multiple-OS versions! How
would that
be?
_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel
- Re: [Gnumed-devel] Re: web frontend/patient singleton, (continued)
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/30
- [Gnumed-devel] Forms layer (was: Re: web frontend/patient singleton), Ian Haywood, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, J Busser, 2005/01/30
- Re: [Gnumed-devel] Re: web frontend/patient singleton, Karsten Hilbert, 2005/01/31
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), catmat, 2005/01/28
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), catmat, 2005/01/28
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Karsten Hilbert, 2005/01/28
- Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Karsten Hilbert, 2005/01/28
Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005), Karsten Hilbert, 2005/01/26
Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005),
Thilo Schuler <=