It seems unclear to me also
Some major questions in my mind
Is the project commercial - ie is there the intent to make money (either
only to sustain the effort or for someone to actually make real money)?
If this was the case presumably it would be
Are we aiming to produce just a clinical system or a whole suite?
In practice however, many if not most projects are affected more or less
by the platform/tools they choose. This applies to proprietary ones
also. It may not be a bad thing that RoR determines many design
decisions, if that is what is chosen.
It seems that a web based system to allow the system to have distibuted
components is a good idea and that that this decision is already made
R
Tim Churches wrote:
Ian Haywood <[EMAIL PROTECTED]> wrote:
Tim Churches wrote:
So, I am not asserting that Django or Turbogears are better than
Ruby-on-Rails, or that RoR is not the framework/language of choice for
an open primary care EMR/ER project. I am just saying that it might
not
be wise to just take Horst's word for it.
I have also had a look at all 3 and the NASA video.
All are very good and I suspect advantages/disadvantages
may outweigh each other over the course of a large project
such as ours. Again making the decision
is more important than the actual decision.
Python is a plus, but as yet I can't find any libraries or bindings
which Ruby lacks, and the learning curve from Python is very smooth.
Ruby is more like 90% Python and 10% Perl (the good 10%)
True, Rails is more 'constraining': it clearly maps out how certain
things
are done, this is a disadvantage where there is a single hacker or
project governance is otherwise good (such as with NetEpi), but in our
situation it's a big plus: if Rails is chosen, there are fewer things to
argue about,
so things move faster. With Turbogears we then have to then decide which
templater,
which ORM [SQLObject/SQLAlchemy, I find RoR's ActiveRecord better than
either], and so on.
Relying on the Web application framework to address project governance issues
may be a mistake...
Personnally I am dubious that a volunteer-only, "traditional" open source
project, as GNUmed has been, can succeed in creating a production-readyhigh-quality
primary care EHR/EMR in a reasonable timeframe (or any timeframe). All of the extant,
in-production open source EHR/EMR systems have been funded projects with a core of
full-time developers, aided and abetted by volumteers and supporters.
I suppose I am a bit unclear what "our situation", as you put it, actually is. Of course,
there doesn't have to be just one "situation" - there is room for several initiatives to
create an open source primary care EHR/EMR, perhaps one unfunded and resourced by volunteers, and
one with a funded core team of paid developers. The latter depends on funding, of course, and that
has to be found. The former may be helpful in securing the latter.
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
