[Gnumed-devel] gnumed ideas 0.1 and post-0.1 (was Time for a major re-think in 2005)

[J Busser]

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.

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"?

- 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?

- 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?