Hi All,
If you want some requirements for GP Practice to work from there are these:
gpcg.org/publications/docs/IBMFinal.pdf
gpcg.org/publications/docs/IBMTech.pdf
gpcg.org/publications/docs/IBMScope.pdf
A bit old now - but still looked close the last time I browsed.
This also might be useful
gpcg.org/publications/docs/data_model/Final_Project_Report.pdf
Sorry if I am teaching anyone to suck eggs!
Cheers
David
---- Dr David G More MB, PhD, FACHI E-mail: [EMAIL PROTECTED] On Wed, 28 Dec 2005 07:22:38 +0800, Richard Hosking wrote: > I have been toying around the edges of Gnumed, but uneasy about > committing a lot of effort, because progress appears to be stalled at > present. Also I am still climbing the long learning curve to be able to > contribute. It is probably the nearest to a viable FOSS app around, and > could form the core of further development. > Having studied the characteristics of "successful open source" on Google > it seems that you need something tangible to gather a core of volunteer > developers around. > > However the big problems with Gnumed appear to me to be lack of coherent > up front requirements analysis, and the sheer technical feasibility of a > full medical software suite. In my view a medical app would have to be > able to deliver waiting room management/scheduling and a financial > package with billing as well as the clinical side. Of all the FOSS > projects studied on Google, requirements were implicit - though not > actually canvassed, the developer had a clear idea what he wanted. > I dont think this is the case with Gnumed and needs more work > > The other aspect of feasibility is the requirement for ongoing > maintenance of data in prescribing, billing, vaccinations, travel etc. > This would require a major effort and I dont think could be done on a > voluntary basis - maybe this would be the basis for a commercial model, > as well as technical support > > OTOH the cost of all the Windows based infrastructure should give a leg > up to any commercial competitor based on Linux and FOSS. > > What do list members see as the requirements for a medical app in Australia? > > Richard > > David Guest wrote: > >>Ian Haywood wrote: >> >> >>>>David Guest wrote: >>>> >>>> >>>>>It was >>>>>a very simple package. It recorded notes, wrote scripts and could import >>>>>and export text and binary data. It allowed others direct access to its >>>>>database. It's simple structure, >>>>> >>>>> >>>David, I don't know if you are one of the few who can dream at will, >>> >>> >>Yep, pretty much, sometimes recurrently. I particularly like the one >>where you become Professor of General Practice at Melbourne Uni and a >>coterie of doctors and programmers committed to the promise of open >>source in health forms and becomes a world centre for this activity. >> >> >>>but if you are, can you dream a little more around this concept. >>>IOW, what are the *bare minimum* features of an EHR that will get it taken >>>seriously? >>> >>>For my own part, I have been using MDW2 for 4 months. I use notes, scripts, letters, path/radiol requests, >>>path results (PIT only), and that's it. >>> >>> >>I think we agree on the basics, Ian. It's keyboard, ins and outs and a >>scripts database. >> >> >>>I use immunisations too in accordance with practice policy but IMHO it's worse than useless (90% of our >>>vaccinations are catch-up) I once fired up the Travel module: must have taken the programmer all of 5 minutes, >>>and s/he must have been drunk, >>> >>> >>I had a bit of time over the Xmas break, and did the Ruby on Rails >>tutorial (dead easy Windows tute at onlamp) and then started on the Ajax >>on Rails. The upshot of all this is that we will have to rethink about >>the way we handle web data and interactions and hence all medical >>communications. I now know what you, Tim and Horst were referring to >>earlier. Unfortunately only a few others do. >> >> >>>>It was at that point that I woke up >>>>so I never found out whether the company accepted those modules and >>>>devised a mutually acceptable system for licensing them. >>>> >>>> >>>This is difficult. In general the following are true of the IT world: >>>- people won't make free contributions to someone else's proprietary product. Argus is a good demonstration here. >>>- you can't run a FOSS outfit where your product is based on a proprietary core. This is why GNOME exists, for example. >>> >>>If the hypothetical company wants a serious community around it, it needs to make the core free, and >>>run off support or other tricks (i.e. Trolltech: free linux version for hackers, charge $$$ for Windows) >>>Although theoretically possible (even Horst pays for support, for example) this model runs strongly counter to >>>the ideology of IT in this country. >>> >>> >>Yes you certainly need a free core or nobody will come. I would >>recommend GPLing the program and charging for add ons like MIMS and for >>the packaging and support. No commercial company can come near your code >>and its doubtful that more a handful of GPs have the time and expertise >>to put it together themselves. >> >>Ian notes a GPLed medical software program has been on the dream list >>for a while. Richard King came within a few hours of it but he, or more >>particularly his wife, were too battle scarred by the medical IT >>industry to return to the front. It's an opportunity for a startup but >>would require a reasonably rare combination of skills to make it happen. >> >>David >> >> > _______________________________________________ > Gpcg_talk mailing list >[EMAIL PROTECTED] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > __________ NOD32 1.1340 (20051226) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com |
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
