Greetings,
Somehow this conversation failed to fall into my primary mail screen,
hence the late response and apologies...
When I say specialize in the DB layer, I mean do not fall into the
trap of delegating managing the DB layer design and use completely to
something like Hibernate. There is now an incredibly common dogma in
the software world where everyone is repeating "it is bad to have
logic in DB, so don't go there, instead use this shiny nice tool.."
That is carrying a useful advice way beyond its usefulness IMHO. Think
a lot before you buy the argument: "but you can easily change
databases if you use ORM and this tool and that" Yes, you can, but
very few real life products support multiple DBs. There is great power
in DB layer, and you can leverage that if you learn the specific
features an capabilities of particular DBs. When I say specialize, I
mean : learn the capabilities of a DB server you'll choose, and
leverage them without breaking the generally accepted principles of
software engineer. It is possible. You can use hibernate, but still
carve out a lot of performance from the DB. I choose to specialize in
postgresql, and that allows me to stay in the 500 millisecond barrier
for queries, inserts etc (which is an unofficial psychological barrier
that was introduced to my work by Thomas Beale)
My third point is: nothing is free, so if you invest in EAV, get ready
to pay the price. You'll have to write more code for simple stuff
sometimes, so plan ahead. Don't buy the EAV argument just like you
should not buy the "oh, hibernate can generate the whole DB" argument.
In general, I'm trying to not to sing along with the chorus in the
software domain, getting ever loud and crowd :) Healthcare is a very
challenging domain, so practices of e-commerce, or advice from books
written by academics who has never implemented a single production
system in their lives won't cut it.
Best Regards
Seref
On Sun, Jun 5, 2011 at 8:50 PM, Randolph Neall
<randy.neall at veriquant.com> wrote:
> 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
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
