Ian, just a bit faster then me, asking the same question. Thanks, Rong, for the good news
Except from the persistence layer, there are lot more needs. But all at its own time. Rongs message revives for me the hope that implementation is an option for the near future. Ian says a relational DB is not an option, that is bad news, for me, I prefer a relational DB, if possible, The advantage of a Relational DB is that they are technical much more mature, and there are many good products available, and if you write your persistence-layer well, .... Anyway, it is possible to abstract the persistence-layer to a vendor and technique independent layer. Changing the DB is then, just a question of writing a few classes. even is it possible to use an object-database below that layer. I hope Rong can tell us something more, because he announces in his message, he a persistence-layer-solution for OpenEhr. I do not know if it is useable in OpenEhr context, but I like the ideas of Scott W. Ambler, he wrote a paper about persistence-layers:http://www.ambysoft.com/downloads/persistenceLayer.pdf But besides the persistence-layer, the GUI is important, how does it connect to the kernel? I wonder. Really good news, I hope we will learn more. In fact, that will be the whole thing, the rest is proven technology, isn't it? regards bert verhees Ian McNicoll MMS wrote: > Hello again Rong, > > Glad to hear things are progressing. Do you have any thoughts about > persistence layer options? > > 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. > > 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, >> > >
