back in 1999 , the choice of using Eiffel as the first demonstration language to implement openehr , was interesting;
Eiffel was being in used in business programming then, and it's design by contract, where the interface of classes
are constrained by preconditions and postconditions ( preconditions are the constraints published that are explicitly
defined , that must exist upon the global variables and the parameter variables of functions , before a function
will execute, and postconditions are the guaranteed constraints that will be met, when a function returns ) ,
sounded academically rigorous . Unfortunately, Eiffel was largely a proprietary language of Bertrand Myers , who wrote
a book about "design by contract" in the early 90s, and one couldn't really get an Eiffel compiler for free , so
openehr essentially lost its "openness" on its first attempt at self propogation ; if the choice had been pascal ( delphi),
C or C++ ( microsoft , borland, gnu-gcc ) , geeks might have helped propogate openehr, especially if it had the mozilla license
then as it does now .
Rather than spiel emr shoppers with how rigorous openehr is, why not try to inform e.g. what's the advantage of openehr's ADL
over say XML XSD, or even a SQL database schema declaration ? Archetypes sounds like a constrained datatype definition language ,
so how are archetypes different from xsd instances , or even SQL database declarations with "before update", "before insert" and "before delete" triggers and rules ( the later being around for 25 years, and even being freely available in the last 10 years ).
How does openehr propose , if it is that flexible , to overcome the same problem that sql, and xml applications have, that the syntax
of a storage record , its datatype structure, doesn't equate with its semantics, so one can have similiar semantics in two syntactically
different EMRs , and there still is a requirement for a human programmer to write a 2 way importer/exporter in order to get
just 2 different emrs to interoperate, and we're back to square one, as with relational databases ?
On Mon Jan 2 11:38 , Ian Haywood sent:
Tim Churches wrote:
>
> It is a bootstrapping problem. Relatively few individuals or
> organisations are willing to put time, effort and resources into openEHR
> until they see that the whole thing works as promised, at least for a
> few proof-of-concept examples. Currently, the lack of a publicly
> available (eithe open source or commercial) openEHR storage/retrieval
> engine (aka kernel) is a showstopper - it is the hurdle between openEHR
> and a seeing-is-believing "tipping point". The thing that amazes and
> worries me is that I had exactly this same (email) exchange with Tom
> Beale in 2003. Now it is 2006 and still no generally available
[snip]
The parallels with gnumed are striking, Although OpenEHR is well-planned
(one might say over-planned) it hasn't saved them from the same difficulty
of getting "over the hump", that is, a basic working system that people can look
at, play with, and generates interest which then snowballs into a community and
further development.
Fundamentally the problem is the ratio of development complexity
to programmer resources.
In the medical open-source world developer resources are very limited, so we
need to set our inital sights to a system that can actually get built.
Fortunately end-users are much more forgiving than informatics academics,
as David pointed out at the beginning of this thread: it simply isn't that hard.
Eye on the ball, people.
Ian
_______________________________________________
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
