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[1]. Their FAQ[2] > is probably the best place to start. The project doesn't look > particularly active, but I could be wrong. > > [1] http://www.gnumed.org/ > [2] 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. David -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
