Bert Verhees wrote: > 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 agree that relational DB is probably the most mature and understood persistence technology. With help of OR mapping tools, it's not that painful working with RDBMS anymore. > > > 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 This is about the same architecture as we used in our application. Hibernate is such a product implemented the persistence layer described in his document. In fact, the openEHR kernel is not aware of any persistence layer. The application is interacting with the service layer which uses the underlying persistence layer to perform CRUD and queries. > > 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. We are trying to build generic GUI totally driven by the domain models (archetypes). Again, as the persistence layer this is an area requires lots of exploration and experiment. Fortunately, the reference model is not dependent on either the presentation or persistence layer allowing EHR systems implemented with different GUI and persistence can interact with each other.
Cheers, Rong > > 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, >>> >> >> >
