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
