On 8/6/07, Tim Churches <tchur at optushome.com.au> wrote: > > 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.
Tim, Adding support for EHR Query is definitely on the road-map of the Java Reference Implementation project. A draft of the road-map can be accessed from http://svn.openehr.org/ref_impl_java/TRUNK/docs/roadmap.htm. But one has to wait until the Query specification is released. 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. When we at ACODE donated the Java source code to openEHR, we hoped the implementation was good enough to serve as a good starting point for others to contribute to so they don't have to start from scratch. It was certainly not completed and would require lots of man-hours to keep it healthy and grow. The last three years journey proves to be very fruitful (considering how scarce the resources have been allocated to the project) - the Java implementation has experienced several major updates and now up-to-date according to the latest specification release (one proof is now nearly all clinical archetypes from the openEHR knowledge repository can be handled by the Java parser). Several tools and pilot applications have been developed based on the Java components from the project, e.g. LiU archetype editor. Both academic and commercial R&D projects have been conducted on the Java implementation. All these early implementations have been valuable for validation and improvement of the openEHR design specifications. This experience has been summarized as a research paper and accepted to Medinfo 2007. I am more optimistic than I was three years ago since 1) the design specifications have been finally finalized so the main focus of the Java project will shift to adding new functionalities from updating existing software; 2) the interest on openEHR and archetypes based EHR systems have been increased a lot in the past 12 months - so it's not unlikely that the Java project gets external funding to speed up the implementation work; 3) my current employer, Cambio Healthcare Systems, a leading Sweidsh healthcare only Software supplier will sponsor the Java project development through my work, which means I don't have to use only my spare time on the Java project. In fact, they also donated an Linux server with high internet bandwidth to the Java project. A continuous integration server based on Apache Continuum has been configured there and will be announced through the Java project shortly. And finally the project page will be updated and a new release will be announced soon before Medinfo. Cheers, Rong 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070807/161b60cc/attachment.html>
