On Wed, Jun 8, 2011 at 04:54, Randolph Neall randy.neall at veriquant.com
wrote:
...
Some EAV designs are
foolish and unusable. But others aren't.
Thanks for your interesting explanation, Randy. Do you have some
examples or links available that may teach us unusable/usable designs?
Roger
Roger,
The web site www.veriquant.com gives a few more details, but not the
low-level design information you are probably interested in. We can talk
more about this privately if you are that interested and I can let you
see what we currently have in action along with some low-level detail. There
OK, guys, here's a brand new reference:
http://www.springer.com/public+health/book/978-0-85729-509-5
This concerns Prakash Nadkarni, of Yale University, and his new book, to be
generally available in a few days, *Metadata-driven Software Systems in
Biomedicine*. He just now told me about it. (I
Hi!
When we have approached openEHR storage we have tried to keep use
cases separate and not solve everything with only one database
structure.
A simplified (perhaps naive) version of the reasoning:
1. If you want to access data as big chunks in a certain serialization
format (like openEHR
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
Hi,
Speaking from the HL7 RIMBAA perspective, and echoing a lot of older
cross-industry best practices: to create a database solely based on the
RM is fine - if your aim is to have a database that's not optimized for
any particular purpose, one that can be used for any purpose. In HL7
we've
Hi Seref,
From what we've seen in HL7 RIMBAA EAV is rarely embraced wholesale -
in practice people (if they use EAV at all) use a mixed RDBMS - EAV
approach. RDBMS for its speed and indexing capabilities, EAV for
blob-type storage of rarely searched/used data. If you don't need the
ultimate
Hi Rene,
I did not mean to suggest that EAV is the only design that one should
use. I guess a better attempt to express what I have in mind is this:
people use relational design too heavily in DB layer, mostly due to
benefit of tooling in other layers.
Good analogy about the pudding :)
On Tue,
?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
From: alandma...@gmail.com
To: openehr-technical at openehr.org
Subject: RE: Dual Model EHR implementation
Date: Fri, 3 Jun 2011 11:24:04 -0300
Hi all
databases), I feel it is intrinsically underperformant.
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos
Sent: Tuesday, June 07, 2011 12:22 PM
To: openehr technical
Subject: RE: Dual Model EHR implementation
I agree with Alan
Regarding content structures, these could be persisted as objects in ad
hoc field in the database.
What kind of objects? And how would any approach of this sort be much
better than XML? You'd still have to retrieve, parse or otherwise
deserialize the
entire blob before you could productively
Alan,
Thanks for clarifying. I thought in your earlier post you had ruled out XML.
I was curious what the alternative would be. JSON, as you suggest, would be
better.
Since writing my post I realized I had not given you credit for one
innovation I had not seen before, namely, placing structure
(to store documents XML or JSON).
Just my 2 cents.
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
Date: Tue, 7 Jun 2011 16:53:10 -0400
Subject: Re: Dual Model EHR
and intelligent as openEHR
strikes me to be.
Cheers and thanks for listening
From: openehr-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall
Sent: Tuesday, June 07, 2011 5:53 PM
To: For openEHR technical discussions
Subject: Re: Dual Model EHR
Hi Alan and Pablo,
You have mitigated some of the problems that emerge from trying to combine
relational data with structured document data. I'll be very interested to
see your progress.
The choices are, as you yourselves have just noted: (1) some sort of object
database, (2) regular relational
Hi Alberto,
A few naive comments/questions from a clinical modelling perspective.
The granularity of the archetypes is mostly determined by issues of
clinical validity and reuseability, rather then performance. We do try
to keep archetype tree structures as 'flat' as possible i.e remove
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
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
Hi, I'm somewhat new to the group and openEHR (on technical level). So excuse
my ignorance. I was wondering about the use of non sql databases. Has anyone
tried to see if something like couchDB or MongoDB could be used to store EHR
data. I know there are definate performace gains with nonsql
-technical-boun...@openehr.org
[mailto:openehr-technical-bounces at openehr.org] On Behalf Of Alberto Moreno
Conde
Sent: Friday, June 03, 2011 9:28 AM
To: For openEHR technical discussions
Subject: Dual Model EHR implementation
Dear all,
Within the Virgen del Rocio University Hospital we
Hi Robert,
The kind of systems you mentioned have the main advantage of scaling
up without very expensive software licenses. I would not say anything
about definite performance gains without having a well defined context
though.
These persistence mechanisms mainly serve large data processing
+Open+EHR-Gen+Framework
--
Kind regards,
Ing. Pablo Pazos Guti?rrez
LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
Blog: http://informatica-medica.blogspot.com/
Twitter: http://twitter.com/ppazos
Date: Fri, 3 Jun 2011 14:27:55 +0200
Subject: Dual Model EHR implementation
From
22 matches
Mail list logo
