Seref, You make three points, beginnging with "specialize in the DB layer." Could you elaborate just a bit more?
I understand your second basic point ("Do not let domain information to dominate DB design"), but lose you beginning where you say, "Yes, it would be easy to have a similar/same representation across multiple layers ...." From that point on I don't follow your elaboration of your second point. >From your third point I take it you are opposed to EAV of any sort. The only other alternative would be to persist serialized byte streams and/or XML documents, which is what I assume to be the OpenEHR approach. Thanks, Randy Neall On Fri, Jun 3, 2011 at 9:12 AM, Seref Arikan < serefarikan at kurumsalteknoloji.com> wrote: > 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 > > > > > > _______________________________________________ > 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/20110605/bf77d294/attachment.html>