gnumed-devel
[Top][All Lists]
Advanced

[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





reply via email to

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