gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] A Proposal for Gnumed: Rites of Passage


From: David Guest
Subject: [Gnumed-devel] A Proposal for Gnumed: Rites of Passage
Date: Sun, 13 Mar 2005 15:28:42 +1100
User-agent: Debian Thunderbird 1.0 (X11/20050116)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks Horst, Mark, Ian, Tim, Syan, Prashanth and Richard (and per cc
Karsten)

I was present at the birth of gnumed in a back alley off Dixon Street
on a hot summer's night in February 2000. Since that time, I have
watched it grow and mature. As a friend of the family, I now see it as
a restless teenager, loosed from its parental strings, full of
attitude and chutzpah. It has plenty of potential. It might even
change the world. But there is this nagging fear that it's just going
to lounge about on the sofa all day playing the latest video games. It
needs a job.

Let me cast myself as everydoc, a general practitioner interested in
computers and using them daily for the benefit of my patients and
myself. Commercial software has made this possible. However, the
limitations of the closed source software model with each new player
in the field having to implement their electronic health record
software from scratch has been obvious to me for over six years.

The same inefficiencies have seen open source replace proprietary
software firstly on the internet and in universities, then in the
servers of large companies and now slowly, but increasingly, in
embedded appliances and on the desktop. New technologies start off
with proprietary products in niche areas.  Rivals come in and a market
develops placing downward pressure on prices and upward pressure on
features. Eventually, however, one recognises that this once new area
has become part of the infrastructure and needs replacing with a more
economically efficient model. Routers on the net run BSD, GNU/Linux
replaces commercial *nix in companies and universities and even
commercial companies like Apple replace the core of their operating
system with solid stable open source software. The initial developers
having enjoyed the fruits of their copyright and commercial oligopoly
move on to greener pastures.

Let me suggest that an electronic health record is now a core
component of our national health infrastructure. Certainly that is the
view of the Australian government, which has established NEHTA
(http://www.nehta.gov.au/) to allow us to cross over to computer based
actions and transactions.

So who should fund this infrastructure development? The obvious answer
is the Federal government. They will reap huge savings by the more
efficient use of health care resources and this is why they have
finally funded NEHTA and put it on the fast track. Besides, as long as
it does not interfere with the market, the Federal government loves
funding infrastructure ... but there's the rub.

It is rumoured that HealthConnect or NSW Health.Net will produce a
?free client for HealthConnect, but there is a dearth of detail. NEHTA
itself is strangely silent on this topic and leaves this as an area to
explore in the next financial year
(http://www.nehta.gov.au/index.php?option=com_docman&task=doc_download&gid=4&Itemid=53).
(For those starving GPs who cannot afford MS Office try the OOo
version, http://ozdoc.mine.nu/nehta/NEHTA-HEALTH-E-NATION2005.sxi, or
plain pdf,
http://ozdoc.mine.nu/nehta/NEHTA-HEALTH-E-NATION2005.pdf.)

GPs could fund the client. As one of the major beneficiaries this
seems one sensible option. It would also give them some control over
the priorities particularly focussing on the core functionality it
will require to replace the paper or the current electronic EHR on the
GP's desktop.

Mark and others suggest organisations like ADGP, NPS and others may be
interested in funding components that would address their special
areas of interest. This would be welcome but we need a core EHR first.

What should this core EHR do? I would suggest the following:-

   1. record keeping
   2. outputting data in a number of specified formats - prescribing,
      letters, email, summaries, etc.
   3. inputting data from other sources - pathology, radiology,
      letters, discharge summaries, etc.

I would suggest that this is sufficient to start but a possibly
separate possibly commercial program for patient and doctor scheduling
and billing is also essential if we are serious about real world take
up of this software.

What would it take to get an EHR up and running. From my observations
it took Richard King and Frank Pyefinch, people who knew what they
were doing, about 8 to 12 months. As a guesstimate a release version
of "Gnumed Professional" should be about the same length of time given
the wealth of experience and existence of core components that are
already available in gnumed. Obviously it also depends on the
experience and skills of the developer.

How much would this cost? Maybe we should ask Prashanth? $200,000?

I believe that the EHR we are proposing for Australian doctors would
be equally useful to any doctor in any other country. The truth of
this statement can be seen from the gnumed experience where much
(?most) of the code has been contributed by people from outside
Australia. Customisation and internationalisation would be necessary
but again this has already been done by gnumed.

What software should we use to build Gnumed Professional? Unlike Tim,
I believe it is essential that we use open source software as the
prime tools. The cost of entry to the project must be essentially zero
for developers in Australia and less developed countries.

Which tools in particular should we use? I will defer to those more
experienced than I, but Horst seems to have made the correct choice
those five years ago. Solid reliable postgresql as the backend, with
python middle layer business object code that is portable to other
databases (while at the same time allowing "easy" access from a GUI or
web interface) was a good choice.

The code should be developed as an open source project with a dev
mailing list, CVS and documentation wiki. Once again gnumed has shown
the way. In fact creating Gnumed Professional as a fork to gnumed dev
may well be the best way to go.

I have not addressed some other design issues like roles, ACLs,
encryption, schema and coding systems. Some of these areas seem to be
coming to a resolution under the NEHTA and other open source
initiatives and we should ride on their coat tails.

I note Horst's very generous offer to take a month off to do some core
work. I would even be prepared to do a week of locum work for him but
this does not seem the right way to go to me. Supporting medical
software is a commercial undertaking and we should take a commercial
approach even if we are using open source software. The best model for
funding Gnumed Professional is not clear but the ideas put forward by
Brendan Scott and Tim are stimulating. It might even be possible to
attract funding from such other diverse sources as Ausaid
(http://www.ausaid.gov.au/) or the Shuttleworth Foundation
(http://www.shuttleworthfoundation.org/).

What form would the governance of Gnumed Professional take? I would
suggest that the majority of the "Board" should be doctors and medical
informaticians with an interest and expertise in open source.
Representation from funding bodies if any would be necessary. I have a
list of potential candidates in my head but others with different
skills may be more appropriate to this enterprise.

What's next? If two hundred GPs each with a thousand dollars each
thought this was worthwhile, we could make a start on developing a
structure and a business plan. If we cannot find them we need to hunt
around for some money. I'm in for $1000. Anyone else?

David




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCM8F5U4kit4I95MkRAuKqAJ4uPaAitBwyeHqeVM36oOY4kfPqeACeOv+J
gL0ccykVCAHKiA/sGxJ6tfM=
=BIgl
-----END PGP SIGNATURE-----





reply via email to

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