Instead of waiting an indeterminate length of time for the 'Acode implementation' (which has been donated to openEHR as far as I know) to finish, anybody interested in getting the job done faster could of course also consider to contribute to it instead of writing an entirely new kernel? Take a lot and give a little bit back where you can. The java reference parser for example is very usable in the state it is in now, we use it all the time. I agree with Bert that the emphasis of openEHR is on the specifications, and that the reference implementations are a means of evaluating the specifications. It is thus essential for the specifications to be open source and the source code of the ref implementation is great to have - but you cannot expect 'download, install, and completed is my EHR project' ;-)
Sebastian > -----Original Message----- > From: Tim Churches [mailto:tchur at optushome.com.au] > Sent: Tuesday, 7 August 2007 6:38 AM > To: For openEHR technical discussions > Subject: Re: Open Sorce Database > > Bert Verhees wrote: > >> Dear group > >> > >> I've a question about ? what is the experience > implementing openEHR > >> in opensource database like mysql or progreSQL in a > hospital of 500 beds? > > > > I don't think there will be much difference as long as it > comes to an > > SQL-based implementation. The benchmarks for > ANSI-SQL-handling MYSQL > > of SQL-server or Oracle are more or less comparable. > > It is very easy to test, you can also take a look at > TPC-benchmarks, > > because you can regard the OpenEhr database-use as a rather complex > > use with 50 to 100 tables (depending on the architecture-specifics) > > > > But when you look to other ways, f.e. object-oriented > databases, like > > Matisse or Cache, or XML-features of databases, then you > bind yourself > > to vendor specific features, then it is another story, and > not easy to > > determine what is a good choice. > > > > There is not much discussion on this subject, good that you > bring it > > up. I hope others will say something about this subject. > > The key issue is no so much what database back-end to use, > but rather what to use or write as the openEHR layer (kernel > and query system). I'm told that there are various > closed-source, proprietary implementations of openEHR (e.g. > by Ocean Informatics) which can use an SQL back-end, but only > one open-source implementation, by ACode in Sweden, which is > on the openEHR.org web site. But what is the current status > of this implementation - it is rather hard to determine > exactly what bit work, what bits have been fully tested and > what is left to be done, short of installing it, looking > through its source code and writing one's own tests. > > The latest release notes for it at > http://svn.openehr.org/ref_impl_java/TRUNK/readme.txt say: > > ########## > Java openEHR Implementation project > ----------------------------------- > VERSION Release-1.0.1 RC > > STATUS Based on openEHR release 1.0.1 RC and implemented > Reference Model > - EHR, EHR Extract, Demographics, Common, Data Structures, > Data Types and Support, and Archetype Object Model, openEHR > Archetype Profile. > Besides, support for archetypes based object creation has > been added into Archetype Object Model classes. > The work is still in progress. The intention is to have > complete implementation of openEHR Reference Model and > Archetype Object Model, with support for archetype based > object creation and validation. > ########### > > I'm not sure whether that means it supports queries or not - > I suspect not. > > So for an open-source implementation of openEHR, it looks > like, as at August 2007, one has to either wait an > indeterminate length of time for the ACode implementation to > be completed or one has to write an entire openEHR kernel > (and test and validate it, which is the more time-consuming > part) oneself. > > Is that correct? I must save this email for re-use because I > have been asking this same question for over three years now... > > Tim C > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
