Richard Terry wrote: > Australia desperately needs an open source solution. The problem with GP's > not > getting the software they need from the MSI is a grumbling continuing problem > which will never go away. > > The state of all the major players (except Profile which I think is > conceptually light years ahead of anything on the market - but has enough > deficiencies to make using it difficult in Australia) is woefull. > > We are now stuck with MDW for at least the next decade. Most of the available > software is 'kindergarten software', with a long history of 'bolt on > solutions', because they programs lack conceptual vision. I take my hat off > to paperless practices using MDW, but then I guess you get used to anything - > sort of like a bad marriage which you can't leave. BP despite some advantages > I think has major conceptual design flaws and is little more than nextgen MDW > with new clothes. > > Despite the availability of web 2 toolkits for rich web client interfaces > running on thin clients, I'm yet to be convinced of their maturity, utility, > reliability given the fact that the interent is not 100% reliable nor > available everywhere. Others will of course violently disagree, and yes I'm > aware they have been used for many years with java based rich web clients. > I've looked at many fromqooxdoo, backbase, dojo, heaps of other ajax ones, > ruby on rails etc. Ultimately I guess the way to go. > > Based on my experience with gnuMed which I consider a failed (relatively) > open > source project, going open source not easy. Many of the major open source > projects which have succeeded are supported in some way or other by > companies. > > Such a pity the MSI wouldn't band together, create a unified open source > project, then let them continue to charge for support. Who cares. Personally > I wouldn't mind paying for support, as long as the solution is open source > and I can modify the bits I want to for me and have free access to the > database to import/export as I need. > > As to an open source project, developing software, let alone open source > software is often not easy, > > In my experience it is difficult to get a group of people together who can > agree on a fundamental design -everyone tends to think their idea's are > better. > > To run such a project you would need proper planning and then an autocratic > dictator (like me!!!!!!!!!) who basically says 'No, we will do it this way > and it will look and function this way, and allocate the tasks. > > Done that way I'd estimate it would take about 6 months if everyone pulled > out all stops to get a basic proof of concept functioning client. Ask Tim > Churches his opinion as he has huge experience in this area.
Here is what I opined about these topics about 5 months ago, on this list: -------- Original Message -------- Subject: Re: [GPCG_TALK] hypothetical Date: Thu, 21 Sep 2006 09:12:04 +1000 From: Tim Churches <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: No, totally disorganised To: General Practice Computing Group Talk <[email protected]> CC: Jon Patrick <[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 _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
