HI Tim, no need to apologise -this is part of our purpoase so i think we area a logical and sensible particpant to be invited in. jon Quoting Tim Churches <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote: > > I have been standing aside on this proposal as I have some operational > > concerns about it. However I see Tim has dragged me into the firing > line > > so I had better respond. > > Sorry for dragging you in - I was just trying to point out that there > may be alternative models for funding and developing a FOSS primary care > EHR, and that such alternative models depend on having suitable human > and organisational environments and settings, and that those too exist. > > > My experience with getting take up for NEW > > software is that it is extremely difficult, whether you are selling it > or > > giving it away ( I have done both). Hence I have no faith in a small > group > > devleoping its own slant on a solution, hence I believe the project > needs > > large scale buy-in to begin with. However that can take 2 forms either > > with the client community throwing its weight behind the project or > > alternatively a funding body. > > Yes, buy-in, or at least acknowledgement of to the process by Colleges > and professional bodies, other academic depts of medicine and health > sciences govt agencies, interested NGOs (eg NPS) etc are all vital - not > just the handful of enthusiasts on this list. And at least one large > organisation willing to bankroll it for philanthropic reasons (but with > a self-promotional/public relations subtext). > > > Secondly I think the limitation of time > > availability for a small band of volunteers is impractical for getting > a > > large project properly established so I would favour a model of funded > > staff to do the development. I think all of these criteria fall in > line > > with Tim's model. Our Centre would be prepared to be a home for such a > > project, but the initiation of the project has to be with the > commitment > > of one of the two drivers mentioned above, preferably with a > philanthropic > > funder. We would not be able to fund the project thorugh our own > resources > > and if the community cannot raise the money to support the needed > staff > > then the project is not a goer, IMHO. > > Yup, it would take at least $1m, maybe twice that, and no-one pretends > that any university has that sort of money just lying around. But large > corporate entities do have that sort of money, often just lying around > looking for ways to enhance the image or brand of the organisation. > > Anyway, I am prepared to invest a measured amount of time in pursuing > this idea (of seeking corporate funding for a FOSS primary care EHR) in > 2007, if any others are interested. But also quite resigned to giving up > after the first few refusals - but strange things can and do sometimes > happen (I'm sure a saw a sticker on the bumper bar of a car about > something like this... some mention of magic, I think. Now, where's my > crystal?). > > Tim C > > > Quoting Tim Churches <[EMAIL PROTECTED]>: > > > >> 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 > >> > > > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > > 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 > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
