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>
