Dear David,
Thanks for your comments, but I would just like to make the following
points:
* openEHR is a long-term effort, and is designed to provide a lasting
legacy into the future of health computing internationally. It is designed
as a paradigm change to the way things are done now. As with all paradigm
changes, much of the reaction has been caution, and even resistance.
* the group working on openEHR has chosen to stay connected to the
standards community rather then go off on its own like say openEMR, openHRE,
openEMED, Freemed, Gnumed etc etc. Never heard of them? Google them. They're
all there. The Australian government is not thinking about any of them, nor
is any other government. That's because they are not engaged in the
international standards community, they just produce software. Some of them
are now thinking of re-engineering their product based on openEHR (we had an
email from the FreeMed people to that effect last week).
* the openEHR archetype approach has been adopted into the CEN EN13606
standard. Has anybody else's approach? No. Why? Because a) the archetype
approach is technically sound and b) because openEHR people took the time to
educate CEN people to the point where they realised they needed it. This
took some years. The outcome is that archetypes (and hence archetype-based
software products) will be used around Europe in the coming years.
* openEHR archetypes have been used by the Clinical Information
Project and now NeHTA as the basis for expressing clinical and demographic
content models. Why is it not some other mechanism? Clearly openEHR
archeytpes have something to offer in this space.
* there are basic problems of information modelling, workflow
modelling and many other aspects of the EHR that are seriously difficult. It
takes time to properly get to grips with the domain, previous research, and
synthesise new ideas. Ever wonder why there is no other EHR solution on the
horizon? Why are there not a dozen other solutions? Why are we even having
this conversation? Because it still has not been solved. Ergo, the fact that
openEHR is still going and is known by most national e-Health programmes
indicates that it has something to offer.
* It also takes time to set up an international community, change
management plan, open source licenses, legal protection, architectural
review board, and actually make it all work. This has now all been done.
* there has been absolutely minimal funding from the Australian
government (via the GPCG), about $450k to the main group (outside of the $3m
given to the DSTC to do the Qld trial; try comparing this to the main IT
budgets of Qld or NSW Health...). All of the work done on this minimal
budget has provided useful results. If people wanted something five years
ago, then they should have helped to lobby the government rather than
sitting around. Instead, a small department in UCL and Ocean Informatics has
funded most of the work.
* Rather than just producing paper, like the standards organisations,
openEHR actually takes account of implementation experience. Thus, the
forthcoming Release 1.0 includes changes resulting from 2 years' experience
around the world with openEHR. Ignoring that might have made it earlier, but
it would have been of significantly lower quality.
openEHR Release 1.0 is due in Feb 2006. We know of about 25 projects around
the world working with it(see the openEHR webite). We expect a kernel in
every major programming language by the end of 2006. Basic versions already
exist in Java and C#. That's not bad progress, given all the obstacles and
lack of manpower and financial support.
hope this helps.
__________________________________
Dr Hugh Leslie
MBBS, Dip. Obs. RACOG, FRACGP, FACHI
M: 0404 033 767 E: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of David More
Sent: Monday, 2 January 2006 7:25 PM
To: General Practice Computing Group Talk; [email protected]
Cc: Clarke, Paul; David Rowed
Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming
Hi Hugh,
A list of the live working "real" implementations that one can see touch and
feel today would be very useful. - Indeed after watching since 1992 with the
initial GEHR material I am seriously wondering if it will happen - we are
now talking well over a decade.
Frankly - I am no longer interested in excuses - some real tangible results
would be useful - indeed it has become essential!
If you have them - where are they - who is using them and where are their
testimonials its wonderful - or even works for a full range of the illnesses
in general practice?
I really am beginning to wonder whether our suggestion that openEHR be
adopted in 1997 was massively premature given the absence of publicly useful
progress.
Really - its 2006 - the time has come to put up or shut up..Sorry but I am
basically sick of the lack of some concrete progress. Are there the
archetypes needed and a mechanism to mange, versions and support them into
the indefinite future?
openEHR is meant to be medicolegally safe - it is not if these mechanisms
and infrastructure are not in place - are they? If so where? Or is all this
a great idea with no practicality and no operational implementations?
Enquiring minds are sick of spin - would like some facts..is it too hard to
tell us?
(Note: where is the evidence the DSTC Kernel - and does DSTC even now exist?
- actually do a full range of GP related care?)
Cheers
David
----
Dr David G More MB, PhD, FACHI
Phone +61-2-9438-2851 Fax +61-2-9906-7038
Skype Username : davidgmore
E-mail: [EMAIL PROTECTED]
On Mon, 2 Jan 2006 18:43:31 +1100, Hugh Leslie wrote:
> Hi All
>
>> Tim Churches wrote:
>> Richard Hosking wrote:
>>> Reading the OpenEHR site again - they are progressing and seem to be
>>> the best candidates for an information model. There is 20 years of
>>> research behind the concepts. Unfortunately they are using Java,
>>> Eiffel, and C#, but the info is open (Mozilla license - is this a
>>> problem?)
>
> There is a lot of openEHR development going on in a lot of different
> development environments. Indeed on the openEHR website you can find a
> mixture of Java, Eiffel and C# and some MySQL db schemas. openEHR is
> completely development environment agnostic and the only requirement is
that
> all the software conforms to the open source specification.
>
>> The currenly available openEHR tools are all for creating and
>> validating Archetype definitions. The choice of languages is not
>> really a problem for such support tools. Mozilla license is fully open
>> source, and rather less restrictive than the GPL. No problem at all.
>
> There are now more than just archetype creation tools available. There is
> now an early Java reference openEHR engine which comprises a number of
> components, probably the most important of which is the kernel - "a small
> but sophisticated component which implements the reference model (RM) and
> archetype model (AM) in order to actually use archetypes at runtime to
build
> and validate data. It is the key component in many openEHR services, and
> central to the archetype method."
> OceanInformatics have a C# based kernel is likely to be opensourced in the
> near future.
>
>>> How could we translate Archetypes into SQL tables in a database?
>>> I guess it could be done by hand - better would be some sort of parser.
>>> This is a separate issue to the user interface of course
>
> There are two parts to the openEHR specification - the archetype model and
> the reference model. The archetype model allows you to describe and
> constrain a clinical idea such as blood pressure. The reference model
> allows you to build concrete examples of these archetypes and in the
openEHR
> world, a database is full of reference model components that are described
> by archetypes. One of the main advantages of this design is that the
> underlying database schema can be designed once and as long as the
reference
> model doesn't change, ANY new archetyped data can be included even if it's
a
> new concept or hasn't been seen before. The clinical concepts are
> completely separate from the database schema. This also makes it possible
> to exchange data much more easily i.e. a discharge summary can be received
> and a blood pressure contained in some part of that discharge summary can
be
> understood and included in any list of blood pressures that the software
> provides.
>
>> The idea is that Archetypes are the storage mechanism - just text
>> files
>> - but this implies the existence of openEHR storage engines which can
>> make use of them. This is the missing part of the puzzle - not such
>> engines are generally available, either as open source or
>> commercially, althought there is a Swedish one which is very poorly
>> documented at present. A few companies have built their own engines
>> for use in specifica products, but openEHR Arcetypes won't fly until
>> there is a range of open source and commercial data storage and
>> retrieval engines for it.
>
>> Tim C
>
> There are a number of projects around the world that have built systems
that
> utilise this structure and in Australia there are at least three working
> examples of openEHR kernels including a commercial offering that is being
> used by QLD Health.
> Its true that for openEHR to work, we will need some open source and
> commercial engines - this is happening now and support is growing all
around
> the world.
>
> Hugh Leslie
>
> __________________________________
> Dr Hugh Leslie
> MBBS, Dip. Obs. RACOG, FRACGP, FACHI
>
> Ocean Informatics Pty Ltd
> M: 0404 033 767 E: [EMAIL PROTECTED]
> _______________________________________________
> Gpcg_talk mailing list
> [email protected]
> http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
>
> __________ NOD32 1.1347 (20051230) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
