i would have preferred less infrastructure re-write, and more adhoc scripting,
e.g. I don't like the wrapper for dbapi, but I think it is necessary in order
for future separation of document/image management and clinical stuff onto
more than one computing node , but I still think it made a shambles of python dbapi unnecessarily.
However, end-users don't really care about that stuff anyway. they just want
it to work similiarly with the essential functions , and cost less, and be readily
modifiable by another hired programmer / customizer , and that, gnumed does have and do.
On Mon Sep 25 23:22 , Tim Churches
[EMAIL PROTECTED] wrote:
> I am not quite sure why Tim has to consistently bag gnumed ;
> it's not that bad, and not much different from the rest of the commonly
> used ehr stuff in gp land.
Sorry, I didn't mean to bag GNUmed - it incorporates some really good
and innovative ideas and some daring software engineering, and I admire
its commitment to (or perhaps obsession with) sound computer science
principles. It is just that after 6 or 7 years of effort, it is still
far from sufficiently complete or stable enough for everyday use
(although the German side of the project differs on that point - they
seem to be using it in some fashion). And when I look at the underlying
code, my brain hurts - but that probably reflects a problem with my
brain more than a problem with the programme code.
Tim C
> On Mon Sep 25 22:25 , Tim Churches sent:
>
> Richard Hosking wrote:
> >
> > I agree Tim.
> > IF this project were to take off (and it appears to have evolved from a
> > few casual comments a week ago - clearly there is a mood to do such a
> > thing) then the basic parameters need to be right.
> > I have the greatest respect for Horst's abilities.
> > However we are not all industry professionals and are possibly easier to
> > impress than they would be :) A second opinion would be useful.
> > It is clearly a large undertaking and it is likely that it will founder
> > fairly quickly.
> > I think we are at the stage in the design process of "feasibility"
> > assessment - can/should we do it?
>
> It seems that Horst is self-financing a RoR-based initiative, and I
> suspect that others such as Ian may assist with this if it looks
> promising. I wish them well and am really interested to see what comes
> of it - we may all be pleasantly surprised.
>
> However, I still think that there is a need and role for a GP
> information system which meets immediate needs and thus can act as a
> practical test-bed for the development and refinement of the next-gen
> things which Jon Patrick has mentioned - terminology servers, analytics
> and so on.
>
> > It probably doesnt pass the feasibility test in several areas
> > Financial/economic
> > on the plus side there is no doubt in my mind that the cost savings
> > could be significant to practices if a viable system could be delivered.
> > Some of the list members couild be beneficiaries of this. However, on
> > the minus side there is no direct link between beneficiaries and those
> > who are proposing to do the coding/management. In other words we dont
> > have a group of clinicians looking for a better way with money to do so.
> > Some money may be available, but it is likely to be well short of what
> > is required. Much of the work will be gratis.
>
> My take is that substantial private-sector philanthropic funding is
> required - where "philanthropic" may mean "good for public relations and
> the corporate image".
>
> > Technical
> > Given enough resources the actual coding is probably not that hard -
> > several industry players have delivered systems written by small groups
> > of developers.
>
> It is harder than it looks to create a really flexible but really sound
> system - and tedious - no-one likes writing thousands of unit test
> fixtures, but that is what is needed for a quality system.
>
> > There is a code and experience base in Gnumed and
> > previous projects.
>
> Many lessons to be learnt and ideas to be gleened from GNUmed, but don't
> count on being able to re-use the code.
>
> > Open source systems have advanced a lot in recent
> > years. To deliver a basic clinical system without any research level
> > addons should be technically feasible (there that was easy :))
> > However I think there should be a complete practice suite of software
>
> Certainly the open source infrastructure components are now very, very
> sound.
>
> > Operational
> > Will the system solve the business problem (what is the business
> > problem? Is there a business problem?) I have a vague frustration withe
> > current systems, but I guess I can live with them as I am a contractor
> > and there is no significant financial penalty to me.
> > I guess I would like to do it to scratch an itch and to move things
> > forward in the standards area and public health area. I would also learn
> > a lot about IT if I was heavily involved. Is that a good enough reason?
>
> Yes, if combined with other good reasons.
>
> > Schedule
> > Will we get it done in a reasonable timeframe? What is the timeframe?
>
> Needs to deliver within two years, max.
>
> > Legal
> > Are there legal barriers to such a project? I cant see any
>
> Nor I.
>
> > Political
> > What will the political effect be? Are there any political
> > showstoppers? Will others try to sabotage the project? Could it force
> > proprietary vendors to change their approach? Would it open up standards?
>
> Would certainly ginger up the local health IT marketplace.
>
> > Having said all that I still like the idea
>
> Me too, and I'm prepared to invest some time, starting in Dec, to try to
> progress a funding sales pitch. In the meantime, we look to the
> Horst-on-Rails locomotive.
>
> Tim C
>
> > Tim Churches wrote:
> >
> > > [EMAIL PROTECTED]
> <_javascript_:top.opencompose (="">[EMAIL PROTECTED]','','','')> wrote:
> > >
> > >
> > >> Quoting Tim Churches <[EMAIL PROTECTED]
> <_javascript_:top.opencompose (="">[EMAIL PROTECTED]','','','')>>:
> > >>
> > >>> Horst Herb <[EMAIL PROTECTED]
> <_javascript_:top.opencompose (="">[EMAIL PROTECTED]','','','')>> wrote:
> > >>>
> > >>>> Minix and Linux to me illustrate the battle between academia and
> > >>>> pragmatic engineering. Of course the pragmatic engineer will take
> > >>>> a leaf
> > >>>> out of the academic book and benefit from teachings and research,
> > >>>> but what they
> > >>>> do and how they do it is very, very different from academic
> > >>>> "solutions".
> > >>>>
> > >>> I suppose we are most interested here in solutions which see the
> > >>> light of day
> > >>> and can thus be used by many people, not just their genius progenitor -
> > >>> regardless of where such solutions come from.
> > >>>
> > >> Gentlemen, please! ;-)
> > >>
> > >
> > > Sorry, but frankly I am still smarting from being accused by Horst of
> > > spreading unfounded FUD, just because I dared suggest that it might be
> > > worth double checking Horst's take on RoR as the ant's pant's of Web
> > > application frameworks.
> > >
> > >
> > >
> > >
> > >
> > >
> > _______________________________________________
> > Gpcg_talk mailing list
> > [email protected]
> <_javascript_:top.opencompose (="">[email protected]','','','')>
> > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
> >
>
> _______________________________________________
> Gpcg_talk mailing list
> [email protected]
> <_javascript_:top.opencompose (="">[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
_______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
