SLUG Mailing List Archives
Re: [SLUG] Open Source Medical Practice Management Software
- To: Slug <slug@xxxxxxxxxxx>
- Subject: Re: [SLUG] Open Source Medical Practice Management Software
- From: David Guest <dguest@xxxxxxxxxxxxxxx>
- Date: Wed, 05 Mar 2008 22:06:06 +1100
- User-agent: Thunderbird 22.214.171.124 (X11/20071031)
Sridhar Dhanapalan wrote:
> In this case it's much more than billing data - we're talking about
> sensitive medical records that meed to be managed and interchanged in
> ways strictly defined by guidelines and legislation set by governments
> and various other authorities.
Actually, despite their reputed mercenary nature, most doctors don't
really care about their billing data. They set their fees as they see
fit and as long as most of the columns add up and they are happy with
the numbers, they are content. If they want to swap to a new billing
package they usually just run out the old one and start the new.
Managing their medical data is much more important to them and having a
core but movable dataset is the holy grail. The functional requirements
are actually pretty limited. In brief they are demographics, recording
notes (efficiently), generating outgoing correspondence, accepting and
"processing" incoming correspondence (including pathology and radiology)
and generating prescriptions.
Medicare Australia requires billing software to pass their compliance
testing. This mainly involves responding with the correct codes to their
on-line batch processing facility. Medicare Australia was formerly known
as the Health Insurance Commission. This best describes its function and
in reality it does not give a rat's about medical data. Ultimate
responsibility for clinical decisions rests with the doctor and they are
free to choose whichever tools they like to to assist them. This,
unfortunately, is all too often pen and paper.
> Imagine the difficulties associated with designing a business-ready
> FOSS accounting package, and multiplying all the complexities tenfold.
> I've been involved in a number of deployments of medical software in
> Australia, and I've quite frankly been shocked at the poor design and
> implementation decisions made. In one system still widely used in
> regional Australia, it is expected that interaction be made over RDP
> (Windows remote desktop). Considering the WAN links are satellite with
> an ISDN uplink, the results aren't fantastic. If the ISDN goes down
> (which isn't uncommon), the system becomes unbearable to use as the
> satellite takes over the uplink too. Imagine running an interactive
> desktop session over a link that has latencies (pings) in the order of
> one second.
The most successful electronic medical record (EMR) packages in primary
care have been written by doctor programmers. To date non-programmer
doctors have been unable to articulate their requirements or have
misunderstood the technology. Most EMR packages use MS SQL as their
backend. A few use firebird and one uses 4G.
Since moving data from one medical package to another is very difficult,
vendor lock in has stifled innovation and most of the products are over
ten years old. Most are designed for use only over the LAN. (I regard
RDP as LAN technology which becomes progressively more painful the
further you stretch it.)
> In terms of FOSS alternatives, take a look at Gnumed. Their FAQ
> is probably the best place to start. The project doesn't look
> particularly active, but I could be wrong.
>  http://www.gnumed.org/
>  http://www.gnumed.org/faqs.html
Gnumed started as a joint German-Australian venture in 2000. As Ken
Wilson has noted, the practice of medicine varies country to country and
gnumed has demonstrated, despite the best endeavours of the core
developers, that the universal EMR is not possible. He who codes wins
and gnumed is quite successful in providing certain supplementary
components to commercial software packages in the German market. It is
no longer of much use in Australia.
The way forward is to define a subset of medical data as used in the
Australia. Unique identifiers for disease codes, pathology tests and
requests and prescription data is probably the minimal subset to get
something functioning. After ten years and millions of dollars spent by
the Feds this is yet to occur. This is a serious issue that
unfortunately plays out as farce.