Ian Haywood wrote: > > Elizabeth Dodd wrote: > >>>> Option 2. Work on the Au fork of Gnumed to get that operational instead >>> I don't know what this means. What's the objective of the Au fork? > Basically an EHR project which focusses on Australian requirements, and in > its design keeps > itself within the meagre intellectual capacities of the programmers. > I hope to have something to show at 1280cc. > > For others to help we first need to lock down and document not so much the > external requirements, but the > internal ones: database design policy, middleware and how data moves around, > and GUI design policy, > so different people can write compatible modules. > It was the inability to make these decisions that paralysed gnumed for so > long. (and we > finally ended up with a (personally) rather daunting 'neither-fish-nor-fowl' > solution) > > This technical decisionmaking is what I tried to get started on the > ozdocit.org wiki, but we have heaps of wildly different > solutions with no clear way of choosing a single one. Also, many people are > indifferent to the > amount of programmatic work their favourite solution represents. Richard and > I are doing what we *can* > do, which certainly isn't the best solution, but IMHO would still be better > than most of the commerical offerings > (mainly because we are like two little gnomes standing on the PostgreSQL > giant's head) > > That still doesn't help the students: we're at least 6 months away from the > above, I would advise looking at Wagtail > as the requirements domain is much smaller and so it's easier to specify a > doable project (such as a nice GUI, for example)
GNUmed-au or any other kind of EHR is much, much too large a project for students to take on, unless they have several years to commit to it (which they don't). WagTail seems like the right size, but even then a degree of selectivity about what is tackled is needed. Everything is more complicated, more tedious and takes longer in real life than it does when just idly thinking about it. >> The backend wouldn't get ported; it is stable although written in MUMPS. An >> Australian front end? > VistA doesn't need to be 'ported' or'emulated': an open-source MUMPS engine > already exists. The backend does need to be modified (storing provider > numbers, > medicare numbers instead of "Social Security Numbers' etc. > This is hard as a lot of the VistA code isn't well commented etc. > > The frontend is *not* open-source and Windows-only, which (IMHO) is the big > show-stopper for VistA: we can't modify it. Apparently there was a push to > write a java frontend > at one stage, does anyone know about this? The thing to remember about VistA is that it is intended for *hospitals*. Big, full-blown, thousand-bed-plus hospitals. Not for GPs and primary practice. As such, VistA can never fly without the sort of IT infrastructure that you expect in a hospital with an annual budget of many hundreds of millions per annum (or a regional or state health authority with a budget of billions per annum). That said, the resources it needs seem to be a lot less than those required by the dominant commercial hospital information systems. There is a project to create a cut-down, simplified version of VistA for use in primary care in the US, to be called "VistA-Office". My understanding is that this pruning project is proving to be far more difficult and time-consuming than first thought, and as a result, VistA-Office has not yet been made available. It is also still unclear whether VistA-Office will be available under and open source or public domain license. Because VistA is public domain, there is no obligation to release derivatives as open source, and several companies already sell their own VistA derivatives on a commercial basis. So I would just keep a watching brief on VistA at this stage. Unless you really like the MUMPS programming language... Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
