Alberto, I am not sure if your second question is entirely valid. If you are talking about the modelling granularity of the archetypes, the impact of this factor on performance is directly related to the design you are using for implementation. So someone may claim that the granularity is OK, while it may cause issues in another implementation. So a performance based metric for granularity of models would not be valid IMHO.
Regarding performance, we may have a more useful discussion if you can provide more details about what you have done. What kind of architecture did you use, that led to the conclusion that you may have performance issues? My feedback regarding your question would be as follows: 1) Specialize in the DB layer. It is good to be able to switch from DB to DB, but don't buy this argument blindly. It would take too long to go into details, but I suggest that you pick up one DB for your project, and see what kind of performance improvement you can achieve. On postgresql, I've managed to increase performance a lot by using stored procedures. Most software engineers will claim that it is bad design to write code in the DB, but remember that I'm not talking about business logic code. I'm talking about the persistence mechanism related code, which brings us to the next one 2) Do not let domain information to dominate DB design. Just because concepts in the models (openEHR/13606/CDA...) have relations among them does not mean that you need to model those relations in the DB. Yes, it would be easy to have a similar/same representation across multiple layers. Same structures powering GUI, then sent to middle tier, and later persisted to DB. Sadly, this has become the dominant approach to all projects, but the problem is, EHR domain uses complex tree structures, with dynamic links created due to different data that needs to be used for different clinical cases. So the approach for a single design that spans multiple layers does not really perform that well for EHR work. Yes, it may work, and there are systems that prove that, but there is more you can achieve if you specialize in your layers, especially in the DB. Take a look at http://en.wikipedia.org/wiki/Entity-attribute-value_model . See references at the bottom. Why do you think medical systems are mentioned alongside this model? 3) The price you'll pay for an unorthodox db design will be that you'll have to consider means of getting data out of the db, and putting it back, for secondary purposes. You won't be able to write sql queries directly if you go for a specialized DB layer, so you need to evaluate your use cases carefully. You won't be able to use off the shelf reporting tools for example, most of which assume that you can connect to a DB and provide some tables, or some SQL queries. With an entity attribute value model, this is not straightforward, and most of the time it is not possible at all. Cheers Seref On Fri, Jun 3, 2011 at 1:27 PM, Alberto Moreno Conde <albertomorenoconde at gmail.com> wrote: > Dear all, > > Within the Virgen del Rocio University Hospital we are analysing how to > implement a EHR based on Dual Model Approach.? When we analysed direct > implementation a database based on of either OpenEHR Reference Model? or ISO > 13606, we have detected that it could have slow performance . Given that we > are concerned about this problem, we would like to know possible strategies > have been identified by implementers in order to fasten the performance of > storage and query. > > Also the granularity level is one open issue that impacts on the > performance, I would like to know if the level of granularity of the > archetypes contained within the OpenEHR CKM is able to satisfy the > requirements of? an EHR with more than 1 million records. > > Kind Regards > > Alberto > > Alberto Moreno Conde > GIT-Grupo de Innovaci?n Tecnol?gica > Hospital Universitario Virgen del Roc?o > Edif. Centro de Documentaci?n Cl?nica Avanzada > Av. Manuel Siurot, s/n. > C.P.: 41013 ???SEVILLA > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
