Richard Hosking wrote: > Absolutely agree Tim > Unfortunately it would probably not return commercially to the developer > - ie it would make most sense for health funders ie govt.
Agreed - with open source there is no money to be made from the actual software and thus unless the development team also wanted run a GP software support business on an ongoing basis, there would be no financial return to them. That is unlikely - a really good developers (be they project managers, programmers, technical writers etc) want to do development, not deployment and support. Thus the $2m needed to fund them would need to be a grant - from govt, or from the private sector - and not a financial investment made in the expectation of direct financial return. There would be enormous returns to the funding agency or company in terms of goodwill and positive publicity, of course, as well as returns in terms of improved health, but not direct revenues. However, I dare say that people like Peter Machell could make a reasonable living supporting the mooted open source system. > They dont seem > ready for such ideas. Even if it were a total failure I suspect it would > be worth doing as it might make the commercial providers play ball with > interoperability. People need to be convinced that it is sensible and feasible. Also agree that one way for, say, NEHTA, to view the funding of such an initiative would be as a risk-management strategy against possible market-failure to implement all the standards they are issuing. > It would also require a maintenance infrastructure > which would need to be funded. Yes, I mentioned the need for perhaps $1m p.a. ongoing funding for a non-profit foundation to oversee ongoing maintenance and development. Tim C > Tim Churches wrote: > >> syan tan <[EMAIL PROTECTED]> wrote: >> >> >>> oops, wrong here as well. It's not bad ; it is probably strongly bound >>> to the underlying middleware zope and plone, but the organization is >>> not clueless. It's a little different from gnumed . For instance, it >>> has a consultation and a progress note, and a >>> procedural report section ( eg echo, stress test). the consultation >>> and progress note section look identical, single text box entry >>> but associated with a date field and a doctor field. The procedural >>> report section looks like what the consultation section should look >>> like, e.g. with free text boxes for every aspect of a medical report >>> with the option of importing existing information in each section >>> e.g. past history, medications, allergies . >>> The script section does look like a database row entry, but is as >>> simplified as what is normally usable, e.g. free text drug name, >>> free text script instructions, with boxes for quantity and repeats, >>> and script validity date. It also adds some script mx functions such >>> as retirement of medication and reason for retirement. >>> The immunization and allergy sections look not done. >>> The results and documents section look like file upload screens >>> with metadata entry, but the results section gives the hint that an >>> attempt will be made to parse the file uploaded for metadata >>> information, such as which patient, and category of result. >>> There is a section for entry of vital signs; >>> recalls are called health maintenances , with three fields , recall >>> date, type of recall, and reason for recall / eh .. health maintenance. >>> The appointments section is adequate too - it has 3 views, >>> month by hour, giving rapid overview of available appointments, >>> multiple doctors view for the secretaries, and single doctor's view >>> for doctors, pretty much basically what we get in oz. >>> So it is better than openemr, and it looks like several months work, >>> given it might have gone over one iteration, unless the guy >>> who did it worked it out on paper first, and worked within the >>> limitations of his platform, which is what it looks like, so it >>> could have been several weeks work. >>> >> >> Yes, yes, fine, OK, whatever, but the political point that I am trying >> to make is that building a capable and very sound open-source primary >> care EMR for Australia is *not* a few afternoons work, not even for >> Horst, but *nor* is it a $100 million exercise. It is, instead, about >> 8 to 10 person-years effort by half a dozen smart people working >> full-time on the project over the course of 12-18 months of calendar >> time, at a total cost of $1.5 to $2 million. I can think of no more >> cost-effective investment to improve of our nation's health than that, >> because it would save hundreds of millions by simplifying the creation >> of shared EHRs and other initiatives, and it would provide an open >> platform for a whole range of decision-support, quality assurance and >> public health program plug-ins. And much more. >> >> Tim C >> >> >> >>> On Tue, 2007-04-03 at 07:01 +1000, Tim Churches wrote: >>> >>>> Well, that's its name. It is a new, open source, Web-based EMR for the >>>> US market, based on Zope and Plone, which are intriguing but probably >>>> quite sound choices for infrastructure (uses an object database, not a >>>> relational database - makes much sense for clinical data). See >>>> http://www.uemr.com/index.html >>>> >>>> Probably not usable as-is in the Oz setting, but yet another >>>> demonstration that it *is* possible to create viable open source >>>> clinical apps with very modest investment. They mention "four years of >>>> effort", probably by one to three people - thus around 10 person-years >>>> of effort. That's around $1.5-2.0 million of investment. Would be >>> money >>> >>>> well spent by a govt agency or even a private philanthropic concern in >>>> the Australian setting (or even sponsorship by a private health >>>> insurance company - what better way to promote yourself but to have >>>> posters in GPs' waiting rooms say "the computer software used by this >>>> practice is proudly sponsored by...". No need to wait 4 years: half a >>>> dozen smart people could do it in 12-18 months, with increasingly >>>> polished prototypes to show off and get active feedback at monthly >>>> intervals along the way. That's what Australian patients and health >>>> professionals deserve. >>>> >>>> Tim C >>>> _______________________________________________ >>>> Gpcg_talk mailing list >>>> [email protected] >>>> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >>>> >>>> >>> _______________________________________________ >>> Gpcg_talk mailing list >>> [email protected] >>> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >>> >> _______________________________________________ >> Gpcg_talk mailing list >> [email protected] >> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk >> >> >> > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
