I meant to write curious instead of anxious, stupid autocorrection of iPad.
That is one dangerous--and very amusing--iPad. :-) Speak calmly to it next
time. Bert, by this you got my day off to a rollicking start.
Randy
On Sat, Apr 20, 2013 at 6:17 PM, Bert Verhees bert.verhees at rosa.nl
, rather than saying: let me use
sql/whatever_other_query_language_that_my_persistence_layer_uses for now
and I'll implement AQL later
On Thu, Apr 18, 2013 at 2:00 AM, Randolph Neall randy.neall at veriquant.com
wrote:
Seref, I was simply trying to take your hint. :).
On Wed, Apr 17, 2013 at 5
or storage technologies?
Randy
On Thu, Apr 18, 2013 at 6:09 AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 17/04/2013 22:04, Randolph Neall wrote:
Thomas, somehow I'm not finding the AQL specification. It's probably right
under my nose on your specification/release page. Also, do
(at which point we start looking at air
travel;-).
- thomas
On 17/04/2013 15:58, Randolph Neall wrote:
Hi Seref,
Hint: think about how you're going to get data out before thinking how
you're supposed to keep it. There are lots of possibilities, but you need
to anchor those with a single
DBMS in its own right, at least with regard to reads, capable
of managing AND/OR logic trees and serving up flat tables of joined data
structures like any RDBMS.
Randy
On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 17/04/2013 18:47, Randolph
Seref, I was simply trying to take your hint. :).
On Wed, Apr 17, 2013 at 5:08 PM, Seref Arikan
serefarikan at kurumsalteknoloji.com wrote:
AQL is not part of the official specification yet.
Regards
Seref
On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall
randy.neall at veriquant.com
and the literary talent you have exercised
in making it all clear. Great work!
Randy
On Mon, Apr 15, 2013 at 3:39 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 15/04/2013 17:11, Randolph Neall wrote:
You've all been very helpful and clear in responding to my questions.
What
answering my questions.
Randy
On Tue, Apr 16, 2013 at 4:46 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 16/04/2013 18:55, Randolph Neall wrote:
Hi Thomas,
Again, you've advanced my grasp of openEHR.
the change set in openEHR is actually not a single Composition, it's
You've all been very helpful and clear in responding to my questions.
What I've learned is that the basic unit of storage--and retrieval--is a
single composition, nothing bigger, nothing smaller, and certainly not the
complete roster of compositions as I had thought (based on my mistaken
notion
widely is it used for actual instance-level storage?
Thanks,
Randy
On Wed, Apr 10, 2013 at 3:57 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 10/04/2013 16:42, Randolph Neall wrote:
The real question thus comes down to what level of thought the nameable
components
AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
I am always somewhat surprised as well. Thanks by the way for your
clarifying notes, that is exactly how I would summarise the discussions.
- thomas
On 07/04/2013 22:08, Randolph Neall wrote:
Hi Thomas,
I'm surprised
to flat files, but then I probably
missed the parent schema into which they all fit.
Randy Neall
On Fri, Apr 5, 2013 at 9:34 PM, Randolph Neall randy.neall at
veriquant.comwrote:
Cook: There is no need for specialisation or redefinition in MLHIM.
Concept
Constraint Definitions (CCDS
Cook: There is no need for specialisation or redefinition in MLHIM. Concept
Constraint Definitions (CCDS) are immutable once published. In
conjunction with their included Reference Model version they endure in
order to remain as the model for that instance data. Unlike you, I
believe that the
tables,
straight from Grail objects.
Thanks again!
Randolph Neall
On Wed, Feb 22, 2012 at 7:22 PM, pablo pazos pazospablo at hotmail.com wrote:
Hi Randolph,
OK, what you say is reassuring. One of the things I had admired about
OpenEHR was what I thought you were violating with ORM, which
Hi Pablo,
I'm sorry for being so slow responding to your questions. I may not be
understanding you fully, nor have I made myself totally clear to you.
First, a DLL is a file system file known as a Dynamic Link Library, a unit
of compiled machine-executable code, typically invoked from a computer
Pablo,
OK, what you say is reassuring. One of the things I had admired about
OpenEHR was what I thought you were violating with ORM, which, in many
contexts does exactly what I described, but evidently not in yours.
The schema is generated when you start the server, so all the process is
Other models I didn't try yet are Object Oriented DBs and Document
Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast
for store highly hierarchical structures, but you need to write some ugly
queries if you want your data back :D
Aren't several major OpenEHR systems using
are interested.
Thanks,
Randy
On Wed, Jun 8, 2011 at 6:03 AM, Roger Erens roger.erens at e-s-c.biz wrote:
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
... [well, I'd better
leave out the rest]. He does like the OpenEHR concept of archetypes,
however.
Thanks,
Randy
On Wed, Jun 8, 2011 at 6:03 AM, Roger Erens roger.erens at e-s-c.biz wrote:
On Wed, Jun 8, 2011 at 04:54, Randolph Neall randy.neall at veriquant.com
wrote:
...
Some EAV designs
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
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
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
Following this debate is for me more interesting than a tennis match, and,
in my opinion, it is advantage-Beale.
Randy Neall
On Fri, Nov 19, 2010 at 5:44 AM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:
On 19/11/2010 05:49, Williamtfgoossen at cs.com wrote:
Hi all,
Given this
Thank you very much everyone, and lately you, Thomas. You've clarified a
lot. I now understand (as well as I could at the moment) how change is
managed. And thanks for posting your piece on data storage. That was
helpful.
Randolph
-- next part --
An HTML attachment was
Heath,
Good clear answer. Thanks.
You enable me to take us back to where this conversation started. I can now
make a possibly uneducated guess how the Ocean querying works: You
parse AQL queries into two distinct parts, (1) for the relational DB and its
paths and (2) for the object layer. The
One more comment, Thomas. I think, at base, what you're saying is that when
you try to put your data into traditional rows and columns, you've made a
heavy, unchangeable commitment, or least one that is not easily changed. But
if you use something else, like structured text documents (such as XML)
Thanks, David. I'll give it a close read.
Randolph
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071108/ebb036ab/attachment.html
It works, but you have to be patient. It takes a while.
Randolph
On 11/8/07, Eddy Rospide edrs22 at yahoo.com wrote:
Hi David,
The thesis link does not work.
Thanks,
Eddy
*David Ingram d.ingram at chime.ucl.ac.uk* wrote:
The interesting discussion about database persistence layers
Thanks, Rong.
On 11/8/07, Rong Chen rong.acode at gmail.com wrote:
On 11/8/07, Randolph Neall randy.neall at veriquant.com wrote:
So are you saying that persisted clinical data is never converted to
conform to newer versions of an achetype, or simply that one is not
compelled to convert
On 11/7/07, Erik Sundvall erisu at imt.liu.se wrote:
On 11/7/07, Randolph Neall randy.neall at veriquant.com wrote:
Can I assume that what Thomas here advocates, (relational databases can
be
used very effectively as a low-level store of blobs keyed by path) is
what
how the ocean
-bounces at openehr.org [mailto:
openehr-technical-bounces at openehr.org] *On Behalf Of *Randolph Neall
*Sent:* Tuesday, 6 November 2007 2:03 PM
*To:* For openEHR technical discussions
*Subject:* Re: OpenEHR queries
Thanks. Of course, as you say, the Sql parser will vary depending
the data or may do something to the
underlying schema to make it more efficient etc. These kind of changes
would be completely transparent to any software accessing the AQL software
layers.
regards Hugh
Randolph Neall wrote:
Thanks. Of course, as you say, the Sql parser will vary depending
,
Chunlan
*From:* openehr-technical-bounces at openehr.org [mailto:
openehr-technical-bounces at openehr.org] *On Behalf Of *Randolph Neall
*Sent:* Tuesday, November 06, 2007 2:03 PM
*To:* For openEHR technical discussions
*Subject:* Re: OpenEHR queries
Thanks. Of course, as you say
Hugh, you and Thomas Beale are apparently colleagues at Ocean, and this is
what Thomas said in the past day or two:
well, yes and no. If you try to make the relational model have anything
to do with the clinical information model, you will usually hit a wall.
Instead, relational databases can be
As a developer from the US who sometimes tries to follow discussions here, I
have a question probably well answered if I took more time myself to find
the answer. Against what do your archetype queries run? Against the DB
itself or some representation of the data in memory? I ask because a few
?
Thanks,
Randy Neall
On 11/5/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote:
*From:* openehr-technical-bounces at openehr.org [mailto:
openehr-technical-bounces at openehr.org] *On Behalf Of *Randolph Neall
*Sent:* Tuesday, November 06, 2007 3:35 AM
*To:* For openEHR
that Ocean uses is a trade off between completely
atomising objects and storing them as blobs. This has been a process of
optimisation and we are really happy with the current performance of the
system. This is only one of many possible methods of openEHR persistence.
regards Hugh
Randolph Neall
I'm a .Net developer in the U.S. researching development of EHR. I've been
absolutely fascinated by the recent debate between advocates of HL7 and
openEHR. For me it was hugely informative and I'm glad it all happened. You
don't learn this stuff just be reading the papers from each community.
in Europe? Hospitals only? Private practices?
Randolph Neall
Veriquant, LLC
Thomas,
Yes, I had seen that document and had started to read it. On your
recommendation, I will summon additional discipline and fortitude and slog
through it.
We use C#.
Randolph Neall
- Original Message -
From: Thomas Beale thomas.be...@oceaninformatics.biz
To: openehr-technical
40 matches
Mail list logo
