Hi
I have no doubt others will add to this but here are my thoughts... in
line
[EMAIL PROTECTED] wrote:
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.
SAM> As David More has said - this has all been going on for a
while - and Eiffel was the best tool for the job in the early 1990s. It
has also meant that we could compile the model and ensure its
correctness. UML tools still do not provide a means of doing this.
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 .
We are aware that Eiffel poses barriers from this point of view - but
we have persisted for now. The reference model is now also represented
in C# and Java - the latter being open source.
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 ).
The approach is different in that there are really two schemas or more
accurately rules about how to represent data. The information model
schema is the only one that the database or XML tools knows about -
this guarantees that all implementations can receive and persist all
data in openEHR format. The second schema or set of rules is
the archetype - which specifies how to represent specific information
in the information model. So it is a layer on top of the normal schema
used in IT today. ADL therefore can specify how to represent something
within a base schema - it is not specific to the openEHR
reference model but works generically.
The openEHR XML schema is the schema of the reference model -
archetypes specify how to record a diagnosis, for instance, using the
reference model. I think you can understand why this is not possible
using another schema (in fact a number of research groups in Australia
and Europe tried to find alternate approaches using standard tools for
sometime before we even contemplated ADL).
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 ?
This is the role of ADL - it specifies the semantics over and above the
reference model. One is then only faced with the import and export of
the far simpler reference model to the standard openEHR XML schema for
instance.
Is this helpful....
Cheers, Sam
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
|
