Richard Hosking wrote:
> One of the problems that has been mentioned is the need to interact with
> other systems.
> If this is necessary than may of the problems that Andrew Shrosbee has
> mentioned will arise.
> To avoid this I think it will be necessary top create a complete suite
> of software including downloader, financials and front desk as well as
> the clinical part.
> {Presumably there are OSS programs that could form the basis for these -
> or will it be necessary to completely build something from scratch?Yes, there are many mature OSS projects which can be used as starting points or complete solutions for these components - eg ArgusConnect for comms, and/or Mirth, which looks very, very promising (see http://www.mirthproject.org/ ) - no time to list others but they are available, at least as departure points. Tim C > Tim Churches wrote: > >> Andrew Patterson wrote: >> >> >>>> All I can tell you is that FOSS deployment does not work that way. >>>> >>> The big question then is GP/specialist desktop software in >>> Australia amenable to the way FOSS deployment normally >>> works? I would contend that from what I have seen of the GP >>> world in the last few years, it is the _least_ amenable >>> industry to FOSS deployed software. >>> >> >> I think that you may be almost correct in that assertion - the >> GP/specialist practice/clinic/rooms information system domain may well >> be unsuited to the traditional FOSS development strategy of lots of >> people volunteering their time to progress a project. The GNUmed open >> source GP info system project, which is run on those lines, has not >> succeeded after 5 or 6 years or constant effort (although it has not >> completely failed either). That "bazaar" model works where the "market" >> for the resulting software is large, with potential users numbered in >> the hundreds of thousands or more, and/or when the "market" for the >> software is programmers, because they like to scratch their own itches. >> The health software market, even for GP systems where the total number >> of deployed systems nationally might number 8 or 10 thousand, is still a >> pretty small "market". Thus other FOSS development strategies are >> needed, and I would argue that the dominant one is not actually the >> "bazaar" model in which hundreds of volunteer hackers collaborate to >> magically produce a bit a of software - that is in fact very rare. >> Rather, the dominant model is a smallish team of professional software >> developers funded - by a single party (eg a large company or a >> philanthropist), by a consortium or by a donation pool, and sometimes >> even by government - who work full-time or nearly full-time on one or >> more FOSS projects, engaging with a wider community (not necessarily all >> programmers: engaged and enthusiastic end-users also play a huge role) >> which debates and informs the design and future directions of the >> software, and helps with testing, documentation and marketing, and may >> contribute code patches or enhancements. The small core team can't do >> without the project community, but nor can the project community do >> without the funded core team. Open source licensing makes this model >> work because it allows the community to work with the core team in an >> intimate manner, running its collective fingers through the hair of the >> project's programme code, providing innovations and inspiration for the >> core team and constantly challenging them to do better. For the core >> team, this represents a real challenge, and it takes a certain sort of >> person with not just the right technical skills but also the right sort >> of personality to be a member of a FOSS project core team, and although >> such work is often rewarding, people often burn out. But that's OK, >> because open source licensing all means there can never be an absolute >> monopoly on membership of that core team, and people come forward from >> the community to replace the burnt out or the merely singed, and >> sometimes entire core teams are transplanted or duplicated elsewhere. >> All good, healthy stuff. >> >> *That's* the model which needs to be followed for an open source GP >> system (and that's what Tony and others basically propose, I think). My >> guess is that between $1m and $3m funding and 18 months is needed to >> create a core GP system (but one with advanced features and design) >> which would be ready for widespread use. In the big scheme of things, a >> few million is a drop in the ocean. Govt could easily fund it, and >> stranger things have happened so this should not be entirely dismissed - >> even a State govt, or consortium of State govts might fund it if it made >> a shared EHR and/or community health and "hospital-in-the-home" and >> similar initiatives easier or possible. But more likely sources are >> commercial sponsors, with drug companies being the obvious sources - but >> clearly drug company advertising could never be inserted in such a >> system because immediately someone would and could (and should) strip >> out the code which implements such advertising - but discrete >> acknowledgement of the funding source would be acceptable to everyone, I >> think - and the funding agency could even hold copyright on the most or >> all of the code - but not monopoly control of that copyrighted code >> because it would be licensed as open source. Others sources might be >> investment companies, banks or other large organisations. Macquarie Bank >> already sponsors Australian public health research projects to the tune >> of several millions per annum. An open source GP system sponsored by, >> say, the Commonwealth Bank or NAB would be a rather good way to promote >> themselves - a discrete logo in the corner of patient-facing screens >> would probably be acceptable, or perhaps better a discrete poster for >> the wall of the waiting room: "This practice uses XYZ open source >> information system proudly sponsored by the Commonwealth Bank." >> Difficult to object to that. Then there's the private health insurers. >> "Sponsored by Medicare Private" or "Sponsored by HCF". For any of these >> organisations, investment of a few million, or even partial funding to >> the tune of a few hundred thousand each would not cause them the >> slightest financial embarrassment. >> >> To make such funding work though, there needs to be a "plausible >> promise" that after 12-18 months a working systems will emerge. That's >> why it is important to secure such a project a home in a Centre for >> Health Informatics R&D located in a shiny glass-and-steel School of IT >> building on the campus of a sandstone uni, with a governing board >> populated by eminent medical academics with Orders of Australia etc, and >> run by people with track records in managing and succeeding with similar >> projects (albeit in different domains), and with a pool of really bright >> and enthusiastic students who act as a multiply for any money invested, >> and backed by an engaged and very cluey community of GPs (primarily >> people on this list). And the aim must also be to push the envelope. Not >> just build an open source clone of Medical Director, but something which >> shows up the the design and thinking behind Medical Director as >> something out of the 20th Century. Let's build something for the 21st >> Century instead. In other words, a research component is necessary, I >> think, rather than being problem. And the resulting system could be seen >> as a research platform, not just for IT and software engineering >> techniques, but also for decision support systems, population health >> data aggregation and analysis and so on. But to be effective as a >> research platform, it also needs to be competent production system for >> everyday use in general practices. That's the direction that Geoff Sayer >> seem to be trying to lead Medical Director prior to his departure from >> HCN- as a research platform for decision support and >> pharmaco-epidemiology built on top of the dominant production GP info >> system. The flaw was, in my opinion, that he was trying to do that in >> the context of a commercial, proprietary environment of a >> publicly-traded company where the fiduciary imperative to make as big a >> profit as possible creates a constant double-bind. An open source >> project in a university R&D centre sustained by a community of GPs seems >> like a better way to progress such goals in the long-term. >> >> What organisation could resist investing in all that? (Plenty, probably, >> but it seems like it is worth a shot.) Step one: develop a prospectus >> for the project, covering not just the benefits, funding model, >> implementers, community etc but also outlining the functional >> requirements and the technical approaches. I'm happy to help with such a >> prospectus over the next few months. Step two: dust off the business >> suit and start trotting the prospectus around to potential funders, as >> outlined above. I'll need a few more months to lose enough weight to >> squeeze into my one and only suit, but again, I'd be happy to be part of >> the team which makes the pitch to various organisations. At the very >> least, I always enjoy taking in the (usually spectacular) views from the >> board rooms of the head offices of large corporations. >> >> >> >>> Other then a very small subset (who incidentally >>> I imagine are all subscribed to this list), GP's have had to >>> be dragged kicking and screaming to use computers >>> in the first place - to think that they are going to be >>> going to source forge and downloading nightly builds >>> of their clinical software is a bit far fetched. And where as >>> in other industries, commercial companies could foster >>> the open source project and work off support contracts >>> - lo and behold, it turns out that GP's >>> don't like paying any money for support either. Don't get me >>> wrong - I'd love to see good free opensource clinical system. >>> I just don't think you'll get anything like that with $50000 >>> in seed funding - and even if you get it up and running it >>> would require a lot of work to get GP's to actually use it. >>> >> >> Absolutely agree that the end product to be deployed must be slick and >> easy to install and administer - CVS downloads are only for the core >> team and highly engaged community members, not for end users. But think >> how easy Firefox is to install (or even OpenOffice) - those are the >> targets in that respect. >> >> Also agree that several million dollars are needed to build a system, >> not several tens of thousands of dollars. >> >> I do think that there is a living to be made by people like Peter >> Machell in providing paid support for such systems, or paid help-desk >> facilities via a modest annual subscription, but the costs need to be >> low (as general practice is a very low-margin business) and no-one will >> get rich doing such support work. >> >> 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
