Ian McNicoll MMS wrote: > Hello again Rong, > > Glad to hear things are progressing. Do you have any thoughts about > persistence layer options? Hello Ian!
Well, we have been exploring the persistence layer ourself. We started with using Prevayler for our demo application, and later chose to use MySQL + Hibernate + Spring solution for our pilot system, which is the kind of persistence solution we are most familiar and experienced with. We did full OR mapping for the openEHR reference model. With the complexity of the reference model, the generated relational model is quite complex too (50+ tables). We haven't had any performance problem yet even the mapping is not fully optimized. On the other hand, we also noticed that having whole reference model fully mapped into relational model doesn't really give us the advantage of querying the data directly using SQL. Therefore, we are also considering other alternatives like the one described by Thomas which essentially only maps certain high level objects and serialize (native or XML) the rest low level objects to reduce the complexity of the relational model. Then the question is really where to set the break point. Hopefully all these early implementation experience would lead to some proven and elegant persistence solutions which can later be abstracted into future specification. > > In Scotland there is a hope to move to a single EHR for the whole > country across all specialities. Personally I remain unconvinced that > this is totally achievable, but if it is, it will demand a highly > flexible and extensible architecture, backed by an equally structured > complex persistence layer - the traditional relational DB will simply > not work. Please keep us informed regarding this move. Regards, Rong > > Regards, > Ian > > >> >> As I promised to reply to your post on the list, here I am. :) >> >> Personally I am convinced it is possible to implement the openEHR >> specification even at this stage. We, at Acode, already proved it by >> building a pilot EHR system which meets real-life requirement. Of >> course, it wasn't easy since we started from scratch with the Java >> implementation (kernel, parser, persistence, GUI), but also the >> specification has been a moving target. After the version 1.0 >> specification is released, the situation will be quite different. >> Since then, there won't be any major changes on the reference model >> which really is the foundation of interoperable EHRs. This will >> hopefully encourage more open source or commercial development on >> openEHR in the near future. >> >> Cheers, >> >
