OpenEHR queries
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 first part narrows down the range of blobs you must look at as far as possible, and the second part penetrates into specific values in the blobs themselves. If you end up with 10,000 blobs resulting from part 1, you must parse and instantiate each one into the memory of your object server and then step through each one to find which of them satisfies the query. Without going into the details of te exact architecture (its not interesting), ou are missing one important factor: we can know in advance a lot about what is in the blobs due to having the archetype 'path-map' for each blob. For example, if teh query concerns HbA1C levels, we know that only the HbA1C archetype is implicated. There is no need to even bother instantiating any blob not containing the HbA1C archetype paths. The archetype path maps give yo an x-ray view of the data. - thomas beale
OpenEHR queries
Thomas, thanks for your extended remarks. Your point is one you've made for a long time, that relational db schemas cannot keep up with the real world. I'm just wondering if moving the problem out of the relational DB and into blobs (persisted objects, I take it) solves the problem you so eloquently depict. Yes, it solves the schema problem. I grant you that. But you're Well it does more than that - it allows the databse to be used to perform optimised querying for a certain category of data (e.g. archetyped, blobbed data), rather than for particular content (e.g. path results versus patient details). still left with imperfect and changing models even with blobs. imperfect in what sense? I've read the openEHR specs enough to know that when an archetype version changes, one is obliged to convert all existing records (blobs) to conform to the new version, and that, it seems, would not be trivial. That task would worry Not, not at all. Archetypes are immutable, and the data always conform to thesame archetype. A new 'version' is in fact a new archetype which just happens to have a similar name. New versions are not made very often, because built-in flexibility (see e.g. generic archetypes like the lab archetype) new revisions (compatible changes) and specialisations are used to deal with almost all new requirements relating to existing archetypes. If a new version becomes necessary, it is a new archetype. Data created with the previous version still conform to that previous version, which is always available in the repository. The data could be migrated to conform to the new version, but this is only sensible if it is a useful thing to do. The main thing to understand is that new 'versions' are not the main way of dealing with changing requirements in archetypes. me. Every affected blob would have to be rewritten. Maybe the only real problem you're even trying to solve is that of the relational schema. You allow that there are many ways other than the path-blob approach, but you've made it clear that your preference is definitely that, another indication of how intractable the root problem actually is. You could just as easily use an object database. We have for example used Matisse on other projects - it is an excellent product, and allows object data to be correctly represented in a language independent way (unlike VM-style caches like db4o). It could be used perfectly well with openEHR. - thomas
OpenEHR queries
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? Usually there zould be no reason to convert - no more than there would be to convert data of archtype A into a form corresponding to archetype B. IN openEHR, new versions are only used to upgrade an archetype when a new _incompatible_ requirement occurs on an existing archetype. There are unlikely to be many of these once you analyse a few possibilities - and it is important to realise that such changes are most likely to be local. Most changes that you can think of are dealt with by: - judicious initial design; e.g. adding 4th sound to BP (systlic and diastolic are 1st and 5th sound pressures respectively) can be done with no changes to the BP measurement archetype. - specialisation: if you want a new kind of lab test to be specifically modelled, just create a new specialisation of the lab result archetype - revision: certain changes like adding a new field, or changing a cardinality from 1..1 to 1..0 can be made to the current version of the archetype. - template changes: templates can turn off and on ad rename various parts of archetypes with no effect to the archetype semantics. Hope this helps. - thomas Randolph On 11/8/07, Rong Chen rong.acode at gmail.com wrote: On 11/8/07, Randolph Neall randy.neall at veriquant.com wrote: Thomas, thanks for your extended remarks. Your point is one you've made for a long time, that relational db schemas cannot keep up with the real world. I'm just wondering if moving the problem out of the relational DB and into blobs (persisted objects, I take it) solves the problem you so eloquently depict. Yes, it solves the schema problem. I grant you that. But you're still left with imperfect and changing models even with blobs. I've read the openEHR specs enough to know that when an archetype version changes, one is obliged to convert all existing records (blobs) to conform to the new version, and that, it That is not true. When an archetype version changes, new data are created/validated by new version of the archetype while old data (blobs or whatever) are still processed by old archetypes. In the root node of the data, there is always information about the archetype (and its version) used to create the data ( LOCATABLE.archetype_details). So there is really no need to convert existing data when archetype changes. Hope this clarifies the matter. Cheers, Rong -- Thomas Beale Chief Technology Officer Ocean Informatics
OpenEHR queries
The reality of the problem domain _will_ change over time, and must be reflected in software somewhere, somehow. Not directly in the software. The following types of logic can be represented formally outside the software: - many kinds of business rules, often expressed in a special language - workflow specifications, e.g. in languages like XPDL or BPEL - computerised guidelines, in languages like GLIF, Arden - structural specifications like archetypes - terminology, like Snomed Changing any of these artefacts does not require changes to the database or software in general; of course, if someone decides to build say a GUI or application specific to a given guideline then this will be affected. But normally this is t be avoided. - thomas beale
OpenEHR queries
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 scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071109/79432f60/attachment.html
OpenEHR queries
Randy, We have already indicated that we store indexed blobs. We can store these blobs as XML, DADL or Binary. It doesn't matter, it is just a serialisation format and the MAGIC happens in the object layer. Another benefit of this is that it obfuscates the EHR content forcing the data access through the EHR Server to ensure that the semantics and security of the content is maintained. This is a deterrent to traditional application developers bypassing these important EHR requirements. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.biz From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Thursday, 8 November 2007 1:26 AM To: erisu at imt.liu.se; For openEHR technical discussions Subject: Re: OpenEHR queries Erik, as I ask my questions about the Ocean system, I'm getting the growing sense, perhaps mistaken, that I'm pushing against trade secrets. Have they told me as much as they're going to? If they're storing the real guts of their clinical information as blobs (low-level blobs, as Tom implies, which could be mere binary serializations of their objects) then it would seem querying would be an interesting issue. I assume Ocean is the premier implementation of openEHR, what with its ultimate champion in Tom Beale, and if they've had to go this route, this would be significant. Tom works there, and I'm assuming that what he says reflects how they do it. If they had all their data in MS Sql tables and columns, not blobs, and it worked well that way, I doubt Tom would be inveighing against relational databases for clinical data. Maybe they've got some serious magic in play. Randolph 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 persistence layer actually works? Beyond this, Thomas apparently has little use for the capacities of Sql-type RDBMS systems to handle clinical information. Does the Ocean system ultimately amount to blobs keyed by paths (presumably string paths)? If so, what kind of blobs, XML blobs, or some other structured text system? A guess from someone outside Ocean: If Tom has been involved I'd guess it's stored as blobs of DADL or something similar ;-) not XML... In a master thesis project here some time ago the students used db4o (http://www.db4o.com/) to store openEHR RM objects, but in a rudimetary way mostly as a simple datastore for Java objects. Query was not the focus of that project so they did not test proper advanced querying or scalability using db4o. // Erik ___ 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/20071108/e3940e94/attachment.html
OpenEHR queries
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071108/5cbfba3a/attachment.html
OpenEHR queries
Randolph Neall 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 persistence layer actually works? Beyond this, Thomas apparently
has little use for the capacities of Sql-type RDBMS systems to handle clinical
information. Does the Ocean system ultimately amount to blobs keyed by paths
(presumably string paths)? If so, what kind of blobs, XML blobs, or some other
structured text system?
to clarify: yes, more or less. If you lock the relational schema, or even an
object schema (i.e. an object model expressed as classes and/or as an ODB
schema, say in ODL) directly to a model of the real world phenomena your
system deals with (e.g. patient visits, path results, GP notes, physical
examinations, referrals etc) then there will be permanent problems of
maintainability. This has been borne out for as long as I have known anything
about computers (let's say 20 years working + 5 years university, when Edition
2 of Somerville was our idea of 'software engineering').
I have kept wondering why software engineering talks about the problem of
maintenance and having to continually throw away and rebuild systems, the
problems of drifting away from requirements and so on, as if they were being
solved. But they are mostly not being solved. The technical book shelves are
full of books teaching the same old thing (count the number of information
system books using airline booking or hotel or conference booking case
studies), implying that it works. But in real life it doesn't. We don't seem
to have any sustainable information systems - we have to keep fiddling with
them. (Note: I am talking about 'information' systems here - there are many
other computational systems whose information is more or less static and which
mostly do number crunching or visualisation or some other job).
The root problem in my view is that if you build an information system in such
a way that its business logic and database encode the facts of the domain (as
gathered last week, by you and a few colleagues, perhaps following 'use case'
analysis or some such idea), the database and logic of the system are
connected to the reality being modelled. However, since reality keeps
changing, along with our idea of it (and hence our modelling of it), the
system is never correct; we have to kee modifying it. This might be easy with
a small system, but with large distributed systems and billions of records,
and numerous changing requirements, it doesn't perform well at all (altough we
often delude oursevles that it is ok by restricting our work practices to
those that fit the software).
In other words, directly modelling the aspects of reality we are concerned
with as first-order concepts in the software and database is a recipe for
costly and permanent maintenance. I believe we have to instead model the
reality as a second order concept, with first order concepts in the system
being stable models of the classes of things found in the reality of the
domain. Hence in openEHR we model only things like Composition ('recording'),
Section ('heading'), Party, various kinds of Entry like Observation and so on.
We don't model any medical or clinical thing directly. Everything modelled as
a first order concept is domain-invariant - it has the same meaning right
across teh entire domain of application. Of course we can debate whether we
have gotten it right or not, but this is the intention.
We are not the first to do something like this of course - there are hundreds
of solutions in a similar vein, various kinds of business rule modelling
languages and so on. What we do in openEHR is just one (fairly comprehensive,
we think) approach to solving the problem of unmaintainable software systems.
It also happens to help solve the problem of getting the requirements from the
domain experts - far better than 'use case analysis a la Jacobson' does.
It now seems quite clear to me that building any real world concepts directly
into the software infrastructure of an information system is a mistake. We can
do far better than that, and we always should aim to do so.
Having said all this, then there is the obvious question: well what do we use
the database for? My view on that (and there are far better experts than I) is
this: once you clear your head of any idea of trying to model patients,
visits, pathology results, prescriptions, medications, etc etc etc in the
database, you have an incredible freedom to use the power of these systems -
and most modern databases are extremely powerful. We just use them in the
wrong way a lot of the time. Using a relational database for medicine in my
view makes sense as long as you build a schema that has no first-order domain
concepts in it, and instead encodes information in a generic way. That could
be blobs, paths, indexable columns, or some other method. There are many
variations available, and I doubt if we
OpenEHR queries
In other words, directly modelling the aspects of reality we are concerned
with as first-order concepts in the software and database is a recipe for
costly and permanent maintenance. I believe we have to instead model the
reality as a second order concept, with first order concepts in the system
being stable models of the classes of things found in the reality of the
domain. Hence in openEHR we model only things like Composition ('recording'),
Section ('heading'), Party, various kinds of Entry like Observation and so on.
We don't model any medical or clinical thing directly. Everything modelled as
a first order concept is domain-invariant - it has the same meaning right
across teh entire domain of application. Of course we can debate whether we
have gotten it right or not, but this is the intention.
Thanks for explaining your view, Thomas.
Doesn't this model division of the problem domain into two concepts just
mean that you're shifting the bulk of development and maintenance
complexity/costs from first order concept level to the second order
concept level? The reality of the problem domain _will_ change over
time, and must be reflected in software somewhere, somehow.
Of course I agree that divide-and-conquer is one of the best strategies
a human mind can work with; especially when at some point in time one
doesn't have to worry anymore about basic first order concepts because
they have cristallized into stability. But this looks very much like
well-known modern programming languages and the libraries (abstract
classes in OOP) available for them. Or is this a wrong analogy?
Roger
OpenEHR queries
On Thu, 2007-11-08 at 16:10 +0100, Roger Erens wrote: Thanks for explaining your view, Thomas. Doesn't this model division of the problem domain into two concepts just mean that you're shifting the bulk of development and maintenance complexity/costs from first order concept level to the second order concept level? The reality of the problem domain _will_ change over time, and must be reflected in software somewhere, somehow. Hi Roger, DISCLAIMER: I do not, nor do I have any intention of speaking for anyone but myself. In many ways you are EXACTLY correct in that we (the plural openEHR Foundation we) are shifting the complexity to the second level. That *really* is the point. Our (my) point is to develop software applications that can deal with the changing knowledge model of healthcare. I have no intention of being the domain expert. I could really care less (as we say in the US) whether it is a podiatrist or a cardiologist that wants to commit information to my application. I MUST be able to consume and manage that information. Their responsibility is to create archetypes that represent their knowledge *AND* fit into the information management model that we make available for them. So, while we may be shifting a bit of the work (which is sharable via openly available archetypes) we are also saying that if you create a clinical application specific to cardiology or podiatry, the patient centric PHR/EMR/EHR can still understand that information, in context; to how it was created. Yep, it's a shift. Hopefully it is a shift that makes sense to those that have seen the real world issues of previous healthcare information systems. Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
OpenEHR queries
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 first part narrows down the range of blobs you must look at as far as possible, and the second part penetrates into specific values in the blobs themselves. If you end up with 10,000 blobs resulting from part 1, you must parse and instantiate each one into the memory of your object server and then step through each one to find which of them satisfies the query. If I'm right, your system could run reasonably fast if part 1 of the query does not not yield a large result or if your object server runs on some heavy iron. I'm not sure if one of your blobs represents one complete patient record or merely a fragment of the record, but if it does encompass the complete record, the blob size could be large and the instantiation process (involving parsing if XML) in itself would consume resources and take time. Maybe you've found that querying against a large set of blobs is seldom necessary. There are tradeoffs no matter how one goes, and I can see your logic. You mention the need for (1) obfuscation and (2) semantic integrity. Thomas's concern centered more on the complexities of expressing hierarchies in traditional relational terms, and in maintaining ever-changing models (see his extended comment in this thread). Either way, you end up with your chosen architecture. Did Ocean consider, at the beginning, using a relational node-based graph (verticies, edges, etc) structure, without blobs and without the schema itself ever having to change, and reject the idea? Best regards, Randolph On 11/7/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Randy, We have already indicated that we store indexed blobs. We can store these blobs as XML, DADL or Binary. It doesn't matter, it is just a serialisation format and the MAGIC happens in the object layer. Another benefit of this is that it obfuscates the EHR content forcing the data access through the EHR Server to ensure that the semantics and security of the content is maintained. This is a deterrent to traditional application developers bypassing these important EHR requirements. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.comheath.frankel at oceaninformatics.biz -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071108/c9a7a48b/attachment.html
OpenEHR queries
They can answer that but for your info I considered it and accepted it :-). Which brings me to the next question but I will start a new thread. On 11/8/07, Randolph Neall randy.neall at veriquant.com wrote: 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 first part narrows down the range of blobs you must look at as far as possible, and the second part penetrates into specific values in the blobs themselves. If you end up with 10,000 blobs resulting from part 1, you must parse and instantiate each one into the memory of your object server and then step through each one to find which of them satisfies the query. If I'm right, your system could run reasonably fast if part 1 of the query does not not yield a large result or if your object server runs on some heavy iron. I'm not sure if one of your blobs represents one complete patient record or merely a fragment of the record, but if it does encompass the complete record, the blob size could be large and the instantiation process (involving parsing if XML) in itself would consume resources and take time. Maybe you've found that querying against a large set of blobs is seldom necessary. There are tradeoffs no matter how one goes, and I can see your logic. You mention the need for (1) obfuscation and (2) semantic integrity. Thomas's concern centered more on the complexities of expressing hierarchies in traditional relational terms, and in maintaining ever-changing models (see his extended comment in this thread). Either way, you end up with your chosen architecture. Did Ocean consider, at the beginning, using a relational node-based graph (verticies, edges, etc) structure, without blobs and without the schema itself ever having to change, and reject the idea? Best regards, Randolph On 11/7/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Randy, We have already indicated that we store indexed blobs. We can store these blobs as XML, DADL or Binary. It doesn't matter, it is just a serialisation format and the MAGIC happens in the object layer. Another benefit of this is that it obfuscates the EHR content forcing the data access through the EHR Server to ensure that the semantics and security of the content is maintained. This is a deterrent to traditional application developers bypassing these important EHR requirements. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.comheath.frankel at oceaninformatics.biz
OpenEHR queries
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) of some sort, you've made a lighter, more retractable commitment, and one that more easily expresses flexible hierarchies. Randolph -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071108/f1230850/attachment.html
OpenEHR queries
On 11/8/07, Randolph Neall randy.neall at veriquant.com wrote:
Thomas, thanks for your extended remarks. Your point is one you've made
for a long time, that relational db schemas cannot keep up with the real
world. I'm just wondering if moving the problem out of the relational DB and
into blobs (persisted objects, I take it) solves the problem you so
eloquently depict. Yes, it solves the schema problem. I grant you that. But
you're still left with imperfect and changing models even with blobs. I've
read the openEHR specs enough to know that when an archetype version
changes, one is obliged to convert all existing records (blobs) to conform
to the new version, and that, it
That is not true. When an archetype version changes, new data are
created/validated by new version of the archetype while old data (blobs or
whatever) are still processed by old archetypes. In the root node of the
data, there is always information about the archetype (and its version) used
to create the data (LOCATABLE.archetype_details). So there is really no need
to convert existing data when archetype changes. Hope this clarifies the
matter.
Cheers,
Rong
seems, would not be trivial. That task would worry me. Every affected blob
would have to be rewritten. Maybe the only real problem you're even trying
to solve is that of the relational schema. You allow that there are many
ways other than the path-blob approach, but you've made it clear that your
preference is definitely that, another indication of how intractable the
root problem actually is.
Thanks again.
Randolph
On 11/8/07, Thomas Beale thomas.beale at oceaninformatics.com wrote:
Randolph Neall 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 persistence layer actually works? Beyond this, Thomas
apparently
has little use for the capacities of Sql-type RDBMS systems to handle
clinical
information. Does the Ocean system ultimately amount to blobs keyed by
paths
(presumably string paths)? If so, what kind of blobs, XML blobs, or some
other
structured text system?
to clarify: yes, more or less. If you lock the relational schema, or
even an
object schema (i.e. an object model expressed as classes and/or as an
ODB
schema, say in ODL) directly to a model of the real world phenomena your
system deals with (e.g. patient visits, path results, GP notes, physical
examinations, referrals etc) then there will be permanent problems of
maintainability. This has been borne out for as long as I have known
anything
about computers (let's say 20 years working + 5 years university, when
Edition
2 of Somerville was our idea of 'software engineering').
I have kept wondering why software engineering talks about the problem
of
maintenance and having to continually throw away and rebuild systems,
the
problems of drifting away from requirements and so on, as if they were
being
solved. But they are mostly not being solved. The technical book shelves
are
full of books teaching the same old thing (count the number of
information
system books using airline booking or hotel or conference booking case
studies), implying that it works. But in real life it doesn't. We don't
seem
to have any sustainable information systems - we have to keep fiddling
with
them. (Note: I am talking about 'information' systems here - there are
many
other computational systems whose information is more or less static and
which
mostly do number crunching or visualisation or some other job).
The root problem in my view is that if you build an information system
in such
a way that its business logic and database encode the facts of the
domain (as
gathered last week, by you and a few colleagues, perhaps following 'use
case'
analysis or some such idea), the database and logic of the system are
connected to the reality being modelled. However, since reality keeps
changing, along with our idea of it (and hence our modelling of it), the
system is never correct; we have to kee modifying it. This might be easy
with
a small system, but with large distributed systems and billions of
records,
and numerous changing requirements, it doesn't perform well at all
(altough we
often delude oursevles that it is ok by restricting our work practices
to
those that fit the software).
In other words, directly modelling the aspects of reality we are
concerned
with as first-order concepts in the software and database is a recipe
for
costly and permanent maintenance. I believe we have to instead model the
reality as a second order concept, with first order concepts in the
system
being stable models of the classes of things found in the reality of the
domain. Hence in openEHR we model only things like Composition
('recording'),
Section ('heading'),
OpenEHR queries
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? New version of an archetype is created when the changes are so significant that it can't be backwards compatible. In other words, conversion old data to conform to newer versions of an archetype might not even be possible. Quoted from Archetype Principles: http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/am/archetype_principles.pdf Principle 14: There is a means of evolving existing archetypes to accommodate changing requirements, without invalidating data created with earlier versions. Since archetypes are used to create data, changes to archetypes must be regarded as creating a new archetype; i.e. the identifier of an archetype must incorporate its version. The only types of change to archetypes that can be made without changing the version are those which do not invalidate previously created data. Formally, such changes must not 'narrow' constraints expressed in the existing version. /Rong Randolph On 11/8/07, Rong Chen rong.acode at gmail.com wrote: On 11/8/07, Randolph Neall randy.neall at veriquant.com wrote: Thomas, thanks for your extended remarks. Your point is one you've made for a long time, that relational db schemas cannot keep up with the real world. I'm just wondering if moving the problem out of the relational DB and into blobs (persisted objects, I take it) solves the problem you so eloquently depict. Yes, it solves the schema problem. I grant you that. But you're still left with imperfect and changing models even with blobs. I've read the openEHR specs enough to know that when an archetype version changes, one is obliged to convert all existing records (blobs) to conform to the new version, and that, it That is not true. When an archetype version changes, new data are created/validated by new version of the archetype while old data (blobs or whatever) are still processed by old archetypes. In the root node of the data, there is always information about the archetype (and its version) used to create the data ( LOCATABLE.archetype_details). So there is really no need to convert existing data when archetype changes. Hope this clarifies the matter. Cheers, Rong ___ 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/20071108/e29a87c7/attachment.html
OpenEHR queries
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? New version of an archetype is created when the changes are so significant that it can't be backwards compatible. In other words, conversion old data to conform to newer versions of an archetype might not even be possible. Quoted from Archetype Principles: http://www.openehr.org/svn/specification/TAGS/Release-1.0.1/publishing/architecture/am/archetype_principles.pdf Principle 14: There is a means of evolving existing archetypes to accommodate changing requirements, without invalidating data created with earlier versions. Since archetypes are used to create data, changes to archetypes must be regarded as creating a new archetype; i.e. the identifier of an archetype must incorporate its version. The only types of change to archetypes that can be made without changing the version are those which do not invalidate previously created data. Formally, such changes must not 'narrow' constraints expressed in the existing version. /Rong Randolph On 11/8/07, Rong Chen rong.acode at gmail.com wrote: On 11/8/07, Randolph Neall randy.neall at veriquant.com wrote: Thomas, thanks for your extended remarks. Your point is one you've made for a long time, that relational db schemas cannot keep up with the real world. I'm just wondering if moving the problem out of the relational DB and into blobs (persisted objects, I take it) solves the problem you so eloquently depict. Yes, it solves the schema problem. I grant you that. But you're still left with imperfect and changing models even with blobs. I've read the openEHR specs enough to know that when an archetype version changes, one is obliged to convert all existing records (blobs) to conform to the new version, and that, it That is not true. When an archetype version changes, new data are created/validated by new version of the archetype while old data (blobs or whatever) are still processed by old archetypes. In the root node of the data, there is always information about the archetype (and its version) used to create the data ( LOCATABLE.archetype_details). So there is really no need to convert existing data when archetype changes. Hope this clarifies the matter. Cheers, Rong ___ 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/20071108/395b378e/attachment.html
OpenEHR queries
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071107/551ff23a/attachment.html
OpenEHR queries
Randy, I have no control over this t_persistence_notes.htm link but I have sent an email to the webmaster about it. There are quite a number of complex archetypes, even OBSERVATION.blood_pressure.v1 is more complex than you would expect as archetypes are a maximal data set. The complexity comes when you aggregate archetypes together to construct a complete composition. Some of the NHS composition templates have dozens of archetypes aggregated together. The real killer for a persistence layer is the number of archetypes that could be used, their specialisations and the potential revisions over time. I would suggest that a good openEHR persistence model should be able to store data for any archetype and any of its specialisations and revisions without manual modifications to the software. The Ocean EhrBank EHR Server is able to do this and in fact does this without knowing about the archetype, just the openEHR RM. Another openEHR implementation may do this by requiring archetypes to be registered allowing it to support a new data structure. Hope this helps. Heath From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Wednesday, 7 November 2007 6:27 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Heath, thanks much! I'd very much like to see the t_persistence_notes.htm, but that one cannot be reached at the moment. I hope to find it soon. I asked Chunlan for an example of your baddest archetype, one that involves some hierarchy and that would challenge a persistence layer. If one comes to mind, let me know. Thanks again, Randolph On 11/6/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Randolph, As openEHR has no specification for a persistence model, there is no such thing as a conformant DB schema. At Ocean we have developed a DB schema that is still evolving but this is transparent to any application as the API is based on the openEHR Information Model. We may explore alternate DB schema's and even alternate data store technology, but again this will be transparent to the application. The main article available on this topic was located at http://www.openehr.org/FAQs/t_persistence_notes.htm but has not yet been moved to the new web site. This is really just some suggestions about how a persistence layer could be implemented, it is by no means a specification for conformance. Regards Heath From: openehr-technical-boun...@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 on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least some implications--how the underlying store would have to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your
OpenEHR queries
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071107/2e87aff0/attachment.html
OpenEHR queries
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071107/310ec56b/attachment.html
OpenEHR queries
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 persistence layer actually works? Beyond this, Thomas apparently has little use for the capacities of Sql-type RDBMS systems to handle clinical information. Does the Ocean system ultimately amount to blobs keyed by paths (presumably string paths)? If so, what kind of blobs, XML blobs, or some other structured text system? A guess from someone outside Ocean: If Tom has been involved I'd guess it's stored as blobs of DADL or something similar ;-) not XML... In a master thesis project here some time ago the students used db4o (http://www.db4o.com/) to store openEHR RM objects, but in a rudimetary way mostly as a simple datastore for Java objects. Query was not the focus of that project so they did not test proper advanced querying or scalability using db4o. // Erik
OpenEHR queries
Erik, as I ask my questions about the Ocean system, I'm getting the growing sense, perhaps mistaken, that I'm pushing against trade secrets. Have they told me as much as they're going to? If they're storing the real guts of their clinical information as blobs (low-level blobs, as Tom implies, which could be mere binary serializations of their objects) then it would seem querying would be an interesting issue. I assume Ocean is *the* premier implementation of openEHR, what with its ultimate champion in Tom Beale, and if they've had to go this route, this would be significant. Tom works there, and I'm assuming that what he says reflects how they do it. If they had *all * their data in MS Sql tables and columns, not blobs, and it worked well that way, I doubt Tom would be inveighing against relational databases for clinical data. Maybe they've got some serious magic in play. Randolph 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 persistence layer actually works? Beyond this, Thomas apparently has little use for the capacities of Sql-type RDBMS systems to handle clinical information. Does the Ocean system ultimately amount to blobs keyed by paths (presumably string paths)? If so, what kind of blobs, XML blobs, or some other structured text system? A guess from someone outside Ocean: If Tom has been involved I'd guess it's stored as blobs of DADL or something similar ;-) not XML... In a master thesis project here some time ago the students used db4o (http://www.db4o.com/) to store openEHR RM objects, but in a rudimetary way mostly as a simple datastore for Java objects. Query was not the focus of that project so they did not test proper advanced querying or scalability using db4o. // Erik ___ 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/20071107/c864b312/attachment.html
Searching/Accessing your data was: OpenEHR queries
a) real-world things are almost always hierarchical compositions (due to our human way of describing them) you can store those in a relational schema. It seems to me that the problem is that sql doesn't really make it efficient to do heirarchical type things with them. I know some old data analysts who still bemoan the fact that sql won the day, given how poor it was at so many things, this being one of them. b) real-world things keep changing (modiyfing the schema of a database is a pain in the neck when you have 200m records and 50 tables). so, you can move the deckchairs on the titanic; changing the schema of any system is painful. The actual conversion time is usually the least painful part of it. Using relational in the classical way works for things like tax and bank databases because the data are not 'real' things, but tabular accounting constructs. oh? what's a real thing? I don't think these things are any less real than other things, just that the business environment dictated that IT requirements came first a thousand years ago. Grahame
OpenEHR queries
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071106/54a6a4ce/attachment.html
OpenEHR queries
Hi Greg, o/items[at0004]/value is actually an invalid path as the identifier o represents an OBSERVATION class and an OBSERVATION does not have an attribute of items, it has a data attribute that is of type HISTORY, which has an events attribute that is of type LISTEVENT, an EVENT has an attribute of data of type ITEM_STRUCTURE which for a ITEM_LIST has an attribute of items. Just like in XPath you need to provide the full path unless you provide a wild card as indicated by Thomas. AQL and the Ocean Query Process does support this wild card and a path such as o//*/items[at0004] can be used. However, we don't really see that these paths will be used directly and the paths will be generated using tools such as the Ocean Template Designer and Archetype Query Builder. Therefore the length of the paths are not a concern and having the complete path actually allows the query processor to perform its job more efficiently as it does not need to search for the leaf node by traversing all possible paths within the data graph. Heath -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:49 PM To: For openEHR technical discussions Subject: Re: OpenEHR queries Question on the query below, if at0004 occurs *only* once in the archetype model, in the position data[at0001]/events[at0002]/data[at0003]/items[at0004]/value, could one theoretically have the shorter query SELECT o/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/items[at0004]/value/magnitude $n The reason I ask is it would be tempting to store (in my data model) the single discrete value at0004 to map to my equivalent item. Of course that would break if a new data element was added in a position (fabricated) data[at0001]/events[at0099]/data[at00100]/items[at0004]/value but the simplicity is tempting. thanks Greg http;//www.patientos.org On 11/5/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph:+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my
OpenEHR queries
Randolph, You could consider AQL to be a logical query language, this allows semantic queries to be shared amongst heterogeneous (and potentially, non-openEHR) systems without the need to know the systems underlying data model. Therefore, AQL logically runs against the Information Model (using Tim's words) gaining its semantics from Archetype Models. The Ocean Implementation of the query processor physically uses both the data model and information model to execute a query. Another implementation might purely use the data model or information model. Non-openEHR or non-Archetype-based systems may support only a small subset of AQL queries where they have provided an AQL to native query mapping. The point is, AQL is independent of the implementation and are sharable, semantic queries based on shared archetypes. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph: +61 (0)8 8223 3075 mb: +61 (0)412 030 741 email: heath.frankel at oceaninformatics.com mailto:heath.frankel at oceaninformatics.biz From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Randolph Neall Sent: Tuesday, 6 November 2007 3:35 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries 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 months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? Thanks, Randy Neall Veriqant, L.L.C. On 11/4/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: Hi Greg, Rong has indicated there is a paper about archetype query language. Thanks Rong. That paper introduced basic query syntax. It was written at the beginning of this year. The query syntax has been enriched recently in order to support more complicated queries. I've already started to write the specifications, but need to resolve some known issues before release. Anyway, I handcrafted the following queries for you (I cannot build my query builder at the moment because of some integration issues). The query statement below shows that all observation instances with respiratory rate greater than n will be returned. SELECT o FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' If you want the respiratory quantity object been returned, the query would look like: SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' Just for your information, the single letter 'o' is the observation class variable name, /data/events[at0002]/data[at0003]/items[at0004]/value is the archetype path to respiratory quantity node. If you have the archetype workbench running, you can identify this path there. '$ehrId' is the parameter name which can be substituted with real EHR ehr_id value at run time. The query language supports parameterization. Some archetype query statements would be very long if the query criteria are complicated. In fact, we don't need to write the above queries by hand. Ocean Informatics has implemented a tool - Archetype Query Builder, which can be used to create/edit queries easily. Additionally, Ocean has also implemented a query parser and query engine as well. The above query statements are consistent to the query syntax introduced by the MedInfo paper. The current query tools also support this query syntax. However, as I have said that we have enriched the query syntax and all the enhancements can be found from the query specifications. Hope this helps. Regards, Chunlan -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, November 05, 2007 6:48 AM To: openEHR-technical at openehr.org Subject: OpenEHR queries Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all
OpenEHR queries
Greg, The AQL query parser or query processor is not intended to be implemented in Java by Ocean but it may be implemented by others in the openEHR Java reference implementation at some point. BTW, the openEHR Java reference implementation already has an interface to the Ocean EhrBank EHR Server using Web Services. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:48 PM To: For openEHR technical discussions Subject: Re: OpenEHR queries I appreciate the information. Writing new queries wouldn't be too hard, it is parsing the queries and then executing the corresponding queries or service calls against the implemented system that is the tricky part. Is Ocean Informatics planning to provide a open source java (or similar language) implementation of the query parsing engine (I am not implying you should, just a question in case you were)? If you were it would be useful to look at how I could plug in my integration, the early I look at these things in the design the easier it gets. thanks! Greg http://www.patientos.org On 11/5/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph:+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
OpenEHR queries
Randolph, As openEHR has no specification for a persistence model, there is no such thing as a conformant DB schema. At Ocean we have developed a DB schema that is still evolving but this is transparent to any application as the API is based on the openEHR Information Model. We may explore alternate DB schema's and even alternate data store technology, but again this will be transparent to the application. The main article available on this topic was located at http://www.openehr.org/FAQs/t_persistence_notes.htm but has not yet been moved to the new web site. This is really just some suggestions about how a persistence layer could be implemented, it is by no means a specification for conformance. Regards Heath From: openehr-technical-boun...@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 on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least some implications--how the underlying store would have to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? Thanks, Randy Neall On 11/5/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: From: openehr-technical-boun...@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 technical discussions Subject: Re: OpenEHR queries 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 months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? That's good question. You've noticed that I didn't mention anything about the data store here. In general, query languages are designed specifically for a type of data store. For instance, SQL is run against relational databases. XQuery is run against XML structured data. Object Oriented Query Language need to be run against Object oriented database management systems etc
OpenEHR queries
Hi Randolph, What data query language you want to use for the underlying data model is depend on what data store structure you want to use. If you want to use relational db, then you need to derive sql queries from AQL. If you want to use XML, you may need to generate XQuery statements or Xpath based on the AQL to be able to get the appropriate data. Currently, SQL2005 also provides the SQLXML features which is even handy to retrieve data from relational table fields as well as XML blobs. Path-value persistence data model mentioned by Tom is one of the option for openEHR based data instances. Relational data model with xml blobs is another option as well. Object oriented persistence layer is another option. It is absolutely vendors design decision on what sort of persistence layer they prefer. You just asked What does it take for a DB schema to be conformant? I think what Hug means is that the DB schema can be used to search and retrieve the data that is required by the AQL. Let's use the AQL statement that I did for Greg: SELECT o FROM EHR e[ehr_id/value='1234'] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden Imagine you are using a SQL server and you need to use sql query statement to query your database. In the database, you have a table called EHR and you have an id field which matches with the ehr_id/value. The AQL FROM clause requires all data must be from the EHR with id='1234', so in your sql statements, there must be a criteria somewhere EHR.id='1234' The AQL statement (in the SELECT clause) also requires all respiration observation instances, which have respiration rate is greater than n, been returned. You have to somehow generate one or a set of sql queries to get the qualified observation data. If your DB schema can support all these, then I see it is conformant. Regards, Chunlan From: openehr-technical-boun...@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, the Sql parser will vary depending on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least some implications--how the underlying store would have to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? Thanks, Randy Neall On 11/5/07, Chunlan
OpenEHR queries
An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071106/e5ab72df/attachment.html
OpenEHR queries
I am not sure I sent this email successfully or not. If you have got one, please ignore this. Hi Randolph, What data query language you want to use for the underlying data model is depend on what data store structure you want to use. If you want to use relational db, then you need to derive sql queries from AQL. If you want to use XML, you may need to generate XQuery statements or Xpath based on the AQL to be able to get the appropriate data. Currently, SQL2005 also provides the SQLXML features which is even handy to retrieve data from relational table fields as well as XML blobs. Path-value persistence data model mentioned by Tom is one of the option for openEHR based data instances. Relational data model with xml blobs is another option as well. Object oriented persistence layer is another option. It is absolutely vendors design decision on what sort of persistence layer they prefer. You just asked What does it take for a DB schema to be conformant? In my understanding it is that the DB schema can be used to search and retrieve the data that is required by the AQL. Let's use the AQL statement that I did for Greg: SELECT o FROM EHR e[ehr_id/value='1234'] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden Imagine you are using a SQL server and you need to use sql query statement to query your database. In the database, you have a table called EHR and you have an id field which matches with the ehr_id/value. The AQL FROM clause requires all data must be from the EHR with id='1234', so in your sql statements, there must be a criteria somewhere EHR.id='1234' The AQL statement (in the SELECT clause) also requires all respiration observation instances, which have respiration rate is greater than n, been returned. You have to somehow generate one or a set of sql queries to get the qualified observation data. If your DB schema can support all these, then I see it is conformant. Regards, Chunlan From: openehr-technical-boun...@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, the Sql parser will vary depending on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least some implications--how the underlying store would have to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected
OpenEHR queries
Heath, thanks much! I'd very much like to see the t_persistence_notes.htm, but that one cannot be reached at the moment. I hope to find it soon. I asked Chunlan for an example of your baddest archetype, one that involves some hierarchy and that would challenge a persistence layer. If one comes to mind, let me know. Thanks again, Randolph On 11/6/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Randolph, As openEHR has no specification for a persistence model, there is no such thing as a conformant DB schema. At Ocean we have developed a DB schema that is still evolving but this is transparent to any application as the API is based on the openEHR Information Model. We may explore alternate DB schema's and even alternate data store technology, but again this will be transparent to the application. The main article available on this topic was located at http://www.openehr.org/FAQs/t_persistence_notes.htm but has not yet been moved to the new web site. This is really just some suggestions about how a persistence layer could be implemented, it is by no means a specification for conformance. Regards Heath *From:* openehr-technical-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 on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least *some* implications--how the underlying store would *have* to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, *Hugh Leslie* hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? 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 technical discussions *Subject:* Re: OpenEHR queries 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 months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale
OpenEHR queries
Thank you, Hugh. Are you free to tell me what kind of persistence layer Ocean uses, OODBMS, XML, or RDBMS? You have claified some issues for me. It would just be interesting to know what basic persistance type you have. Randolph On 11/6/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph By conformant, I just meant conformant to the openEHR (and AQL) specification. The only thing that can really currently be said about the Ocean implementation of this is that it works and is fast and efficient - not that it is the 'best' design. The underlying DB schema is not part of the openEHR or AQL specification and will depend on the application. For instance, there is likely to be a version that uses an XML file based database that can easily reside on a memory stick. This won't change the AQL query, just the implementation of it in the data access layers. I think that there are many possible schemas with openEHR and many possible ways of persisting the data. Using an OODBMS is another possible solution that we haven't looked at and there are many ways of writing a RDBMS schema with pros and cons for the different ways including using application layers like Hibernate to provide an object relational mapping. It will really be up to the implementer to decide. As Heath has said, when you use our software, you access the software layers and run AQL queries. At some stage we may decide that there are better strategies for persisting 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 on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least *some* implications--how the underlying store would *have* to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? 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 technical discussions *Subject:* Re: OpenEHR queries As a developer from the US who sometimes tries to follow discussions here, I have a question
OpenEHR queries
Thank you, Chunlan. Your examples are clear. There are basically three choices for persistence types, as you and others have pointed out, XML, OODBMS, RDBMS, and XML. What is proving to be the most popular, most preferred, by the openEHR community? I am trying to find out, for instance, which of these three types Ocean adopted. Also, one more thing: could you give me an example (web URL) of your biggest, baddest, nastiest archetype, or set of nested archetypes, that a system would should be capable of accommodating? Randolph On 11/6/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: I am not sure I sent this email successfully or not. If you have got one, please ignore this. Hi Randolph, What data query language you want to use for the underlying data model is depend on what data store structure you want to use. If you want to use relational db, then you need to derive sql queries from AQL. If you want to use XML, you may need to generate XQuery statements or Xpath based on the AQL to be able to get the appropriate data. Currently, SQL2005 also provides the SQLXML features which is even handy to retrieve data from relational table fields as well as XML blobs. Path-value persistence data model mentioned by Tom is one of the option for openEHR based data instances. Relational data model with xml blobs is another option as well. Object oriented persistence layer is another option. It is absolutely vendors design decision on what sort of persistence layer they prefer. You just asked What does it take for a DB schema to be conformant? In my understanding it is that the DB schema can be used to search and retrieve the data that is required by the AQL. Let's use the AQL statement that I did for Greg: SELECT o FROM EHR e[ehr_id/value='1234'] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden Imagine you are using a SQL server and you need to use sql query statement to query your database. In the database, you have a table called EHR and you have an id field which matches with the ehr_id/value. The AQL FROM clause requires all data must be from the EHR with id='1234', so in your sql statements, there must be a criteria somewhere EHR.id= '1234' The AQL statement (in the SELECT clause) also requires all respiration observation instances, which have respiration rate is greater than n, been returned. You have to somehow generate one or a set of sql queries to get the qualified observation data. If your DB schema can support all these, then I see it is conformant. Regards, 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, the Sql parser will vary depending on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least *some* implications--how the underlying store would *have* to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, *Hugh Leslie* hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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
OpenEHR queries
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 used very effectively as a low-level store of blobs keyed by path. I wrote a web page on this aproach which we still have not transferred to the new site, but will in the next week or so - it may shed some light on the matter. The argument of Object databases versus Relational databases is an old one that I expect most people have already chosen their camp based upon their personal career experiences. I used to think that (seriously) until I realised how bad relational databases are at storing real-world models of anything but how great they are as a method of storing blobs, paths, indexable values and so on, in a totally generic way (i.e. where the schema will not change regardless of changes in the content of the data, or even its domain level information model). I believe that the textbook theory of using either E-R models or object models to represent any but the most generic things in the real world is relatively useless, for anything but a demonstration database or small, unchanging application (does such exist?). For anything real, it doesn't work because a) real-world things are almost always hierarchical compositions (due to our human way of describing them) and b) real-world things keep changing (modiyfing the schema of a database is a pain in the neck when you have 200m records and 50 tables). Using relational in the classical way works for things like tax and bank databases because the data are not 'real' things, but tabular accounting constructs. * * * 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 persistence layer actually works? Beyond this, Thomas apparently has little use for the capacities of Sql-type RDBMS systems to handle clinical information. Does the Ocean system ultimately amount to blobs keyed by paths (presumably string paths)? If so, what kind of blobs, XML blobs, or some other structured text system? Thanks for your efforts to enlighten me. In that you are making progress :). - Show quoted text - -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071106/037d324e/attachment.html
OpenEHR queries
Hi Greg, Rong has indicated there is a paper about archetype query language. Thanks Rong. That paper introduced basic query syntax. It was written at the beginning of this year. The query syntax has been enriched recently in order to support more complicated queries. I've already started to write the specifications, but need to resolve some known issues before release. Anyway, I handcrafted the following queries for you (I cannot build my query builder at the moment because of some integration issues). The query statement below shows that all observation instances with respiratory rate greater than n will be returned. SELECT o FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' If you want the respiratory quantity object been returned, the query would look like: SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' Just for your information, the single letter 'o' is the observation class variable name, /data/events[at0002]/data[at0003]/items[at0004]/value is the archetype path to respiratory quantity node. If you have the archetype workbench running, you can identify this path there. '$ehrId' is the parameter name which can be substituted with real EHR ehr_id value at run time. The query language supports parameterization. Some archetype query statements would be very long if the query criteria are complicated. In fact, we don't need to write the above queries by hand. Ocean Informatics has implemented a tool - Archetype Query Builder, which can be used to create/edit queries easily. Additionally, Ocean has also implemented a query parser and query engine as well. The above query statements are consistent to the query syntax introduced by the MedInfo paper. The current query tools also support this query syntax. However, as I have said that we have enriched the query syntax and all the enhancements can be found from the query specifications. Hope this helps. Regards, Chunlan -Original Message- From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, November 05, 2007 6:48 AM To: openEHR-technical at openehr.org Subject: OpenEHR queries Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
OpenEHR queries
Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards ? Heath ? Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ? ph:?+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:?heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ 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
OpenEHR queries
I appreciate the information. Writing new queries wouldn't be too hard, it is parsing the queries and then executing the corresponding queries or service calls against the implemented system that is the tricky part. Is Ocean Informatics planning to provide a open source java (or similar language) implementation of the query parsing engine (I am not implying you should, just a question in case you were)? If you were it would be useful to look at how I could plug in my integration, the early I look at these things in the design the easier it gets. thanks! Greg http://www.patientos.org On 11/5/07, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Greg, The Archetype Query Language (AQL, formerly known as EHR Query language or EQL) was developed by Ocean Informatics and a specification is being prepared to be offered to the openEHR foundation as a candidate openEHR specification. For now the paper referred to by Rong is the main reference but we hope to provide something on the openEHR WIKI soon. The Ocean Template Designer provides these openEHR (XPath-like) paths as a property of each node but Ocean is also developing an Archetype Query Builder tool that will actually generate the complete query for you. Here is the query generated by the tool as per your use case (it is slightly simpler than the example provided by my colleague Chunlan). SELECT o/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value FROM EHR [uid = $ehrUid] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.respiration.v1] WHERE o/data[at0001]/events[at0002 and name/value='Any event']/data[at0003]/items[at0004]/value/magnitude $n The units can be included as an additional criteria as indicated by Chunlan but it is unnecessary as the archetype only allows one kind of unit for rate. Let me know if you would like further details regarding the Ocean tools. Regards Heath Heath Frankel Product Development Manager Ocean Informatics Ground Floor, 64 Hindmarsh Square Adelaide, SA, 5000 Australia ph:+61 (0)8 8223 3075 mb: +61 (0)412 030 741 email:heath.frankel at oceaninformatics.com -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, 5 November 2007 9:30 AM To: For openEHR technical discussions Subject: Re: OpenEHR queries Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR- OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA .p df Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ 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 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
OpenEHR queries
Greg Caulton wrote: Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. Actually, a complete drag and drop query editor is in the pipeline. - thomas beale
Searching/Accessing your data was: OpenEHR queries
On Mon, 2007-11-05 at 06:18 -0500, Greg Caulton wrote: Of course that would break if a new data element was added in a position (fabricated) data[at0001]/events[at0099]/data[at00100]/items[at0004]/value but the simplicity is tempting. This is of course why you should (IMHO) change your focus (it takes an Ah Ha moment) from data model to information models. Using an object database (ZODB, POET, Gemstone, Versant, Objectivity/DB, etc.) in your chosen implementation language is usually transparent at that point. If your heart can't handle that (OODB) approach for some reason and you insist on PostgreSQL or Oracle (please do NOT use MySQL for healthcare information) you should still look at using the custom data type capabilities of them and follow the information model as defined in the specifications. Again, you end up with an information model approach and you do not adhere to (necessarily) to a relational model but you still maintain data integrity and the relationships defined in the information model UML. DISCLAIMER: I understand that Ocean Informatics uses MS-SQL but I do not know what their data model/information model looks like at the persistence level. The really cool thing about truly supporting the openEHR Information Models is that it doesn't matter as long as you can support and EHR Extract in context of the information requested. My 1 cent (the USD is in trouble). Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Searching/Accessing your data was: OpenEHR queries
One reason for the question was that it wasn't clear whether the at uniquely identifies a concept within the ADL. I think it still does, but it can have different context depending on where it occurs. Implementing a hierarchy of information (information model) using entity relationships (data model) is common place. The argument of Object databases versus Relational databases is an old one that I expect most people have already chosen their camp based upon their personal career experiences. I will agree with you that MySQL is not well suited to terabyte databases with 1000's of concurrent users, with many people attempting to update the same patient record :-) My own hospitals largest table is growing at a rate of 500,000 rows per day, MySQL would choke with the number of queries and updates hitting it regardless of hardware IMHO. Greg http://www.patientos.org On 11/5/07, Tim Cook timothywayne.cook at gmail.com wrote: On Mon, 2007-11-05 at 06:18 -0500, Greg Caulton wrote: Of course that would break if a new data element was added in a position (fabricated) data[at0001]/events[at0099]/data[at00100]/items[at0004]/value but the simplicity is tempting. This is of course why you should (IMHO) change your focus (it takes an Ah Ha moment) from data model to information models. Using an object database (ZODB, POET, Gemstone, Versant, Objectivity/DB, etc.) in your chosen implementation language is usually transparent at that point. If your heart can't handle that (OODB) approach for some reason and you insist on PostgreSQL or Oracle (please do NOT use MySQL for healthcare information) you should still look at using the custom data type capabilities of them and follow the information model as defined in the specifications. Again, you end up with an information model approach and you do not adhere to (necessarily) to a relational model but you still maintain data integrity and the relationships defined in the information model UML. DISCLAIMER: I understand that Ocean Informatics uses MS-SQL but I do not know what their data model/information model looks like at the persistence level. The really cool thing about truly supporting the openEHR Information Models is that it doesn't matter as long as you can support and EHR Extract in context of the information requested. My 1 cent (the USD is in trouble). Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
OpenEHR queries
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 months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? Thanks, Randy Neall Veriqant, L.L.C. On 11/4/07, Chunlan Ma chunlan.ma at oceaninformatics.com wrote: Hi Greg, Rong has indicated there is a paper about archetype query language. Thanks Rong. That paper introduced basic query syntax. It was written at the beginning of this year. The query syntax has been enriched recently in order to support more complicated queries. I've already started to write the specifications, but need to resolve some known issues before release. Anyway, I handcrafted the following queries for you (I cannot build my query builder at the moment because of some integration issues). The query statement below shows that all observation instances with respiratory rate greater than n will be returned. SELECT o FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' If you want the respiratory quantity object been returned, the query would look like: SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' Just for your information, the single letter 'o' is the observation class variable name, /data/events[at0002]/data[at0003]/items[at0004]/value is the archetype path to respiratory quantity node. If you have the archetype workbench running, you can identify this path there. '$ehrId' is the parameter name which can be substituted with real EHR ehr_id value at run time. The query language supports parameterization. Some archetype query statements would be very long if the query criteria are complicated. In fact, we don't need to write the above queries by hand. Ocean Informatics has implemented a tool - Archetype Query Builder, which can be used to create/edit queries easily. Additionally, Ocean has also implemented a query parser and query engine as well. The above query statements are consistent to the query syntax introduced by the MedInfo paper. The current query tools also support this query syntax. However, as I have said that we have enriched the query syntax and all the enhancements can be found from the query specifications. Hope this helps. Regards, Chunlan -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Greg Caulton Sent: Monday, November 05, 2007 6:48 AM To: openEHR-technical at openehr.org Subject: OpenEHR queries Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ 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/20071105/5145b2c3/attachment.html
Searching/Accessing your data was: OpenEHR queries
Why? (Not that I intend to do that) Gerard -- private -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 On Nov 5, 2007, at 1:20 PM, Tim Cook wrote: (please do NOT use MySQL for healthcare information) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20071105/3f4ea615/attachment.html
Searching/Accessing your data was: OpenEHR queries
On Mon, 2007-11-05 at 19:25 +0100, Gerard Freriks wrote: Why? (Not that I intend to do that) On Nov 5, 2007, at 1:20 PM, Tim Cook wrote: (please do NOT use MySQL for healthcare information) I will assume that your WHY? question was in response to this statement I made? In general (and for the speed results MySQL claims) it trades off ACID qualities to attain them. There are **MANY** documents available on the Internet to adjudge the differences between the needs of a high speed blog service etc, and the needs of a real DBMS with ACID integrity and MVCC. There are many benchmarks ( I have no interest in either system ) that show that large scale SMP systems perform better with PostgreSQL vs. MySQl. IMHO, you should use an OODBMS for most installations anyway. I Cheers, Tim -- Timothy Cook, MSc Health Informatics Research Development Services http://timothywayne.cook.googlepages.com/home LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook
Searching/Accessing your data was: OpenEHR queries
Tim Cook schreef: On Mon, 2007-11-05 at 19:25 +0100, Gerard Freriks wrote: Why? (Not that I intend to do that) On Nov 5, 2007, at 1:20 PM, Tim Cook wrote: (please do NOT use MySQL for healthcare information) I will assume that your WHY? question was in response to this statement I made? In general (and for the speed results MySQL claims) it trades off ACID qualities to attain them. There are **MANY** documents available on the Internet to adjudge the differences between the needs of a high speed blog service etc, and the needs of a real DBMS with ACID integrity and MVCC. This old news, it depends on many parameters how MySQL behaves. You can use the InnoDB table format which acts 100% according to ACID-specs. Not that I would advise MySQL, but I would not advise against it for the reason you gave, because that is not valid anymore, since version 5.x. InnoDB is supported by MySQL since 2001. It is a good DBMS, in fact, it uses SAP-technology (read this, from 2003: http://www.infoworld.com/article/03/05/27/HNmysql_1.html) Oracle has taken a license on the InnoDB format because it is very good, yes, it is the same format which you can use in MySQL (just one line in the configuration-file) http://sql-info.de/mysql/oracle-acquires-innodb.html There are many benchmarks ( I have no interest in either system ) that show that large scale SMP systems perform better with PostgreSQL vs. MySQl. IMHO, you should use an OODBMS for most installations anyway. I It is a good idea, but there are also downsides on this. - it is not really necessary, because there are very good ways to map from objects to relational databases. Read the papers from Scot W. Ambler on this. - it limits your choice of vendors - it limits your choice of programming languages, OS-platforms - it makes your software less transparant to vendor idnependency - OORDMS's are much more expensive - they are less mature And to map the RM-objects to a relational database it is really suffcient to use ANSI 1992 SQL, which means that your SQL-code is not vendor-specific. regards Bert Verhees
OpenEHR queries
I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? 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 technical discussions *Subject:* Re: OpenEHR queries 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 months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? That's good question. You've noticed that I didn't mention anything about the data store here. In general, query languages are designed specifically for a type of data store. For instance, SQL is run against relational databases. XQuery is run against XML structured data. Object Oriented Query Language need to be run against Object oriented database management systems etc. These types of query language are data query languages, i.e. they query at the data level. You have to know DB schema when you write a SQL query statement. Archetype Query Language is different from the general query languages. It's a semantic query language, i.e. it queries data at semantic level. It's neutral to persistence layer and system design. We only need to use archetype path and openEHR reference model to construct AQL statement. You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. That's why AQL queries can be shared across systems and enterprise boundaries. Sharing AQL is one of the key solution to achieve semantic interoperability. Cheers, Chunlan Thanks, Randy Neall Veriqant, L.L.C. On 11/4/07, *Chunlan Ma* chunlan.ma at oceaninformatics.com wrote: Hi Greg, Rong has indicated there is a paper about archetype query language. Thanks Rong. That paper introduced basic query syntax. It was written at the beginning of this year. The query syntax has been enriched recently in order to support more complicated queries. I've already started to write the specifications, but need to resolve some known issues before release. Anyway, I handcrafted the following queries for you (I cannot build my query builder at the moment because of some integration issues). The query statement below shows that all observation instances with respiratory rate greater than n will be returned. SELECT o FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' If you want the respiratory quantity object been returned, the query would look like: SELECT o/data/events[at0002]/data[at0003]/items[at0004]/value FROM EHR e[ehr_id/value=$ehrId] CONTAINS COMPOSITION CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.respiration.v1.adl] WHERE o/data/events[at0002]/data[at0003]/items[at0004]/value/magnituden AND o/data/events[at0002]/data[at0003]/items[at0004]/value/units = '/min' Just for your information, the single letter 'o' is the observation class variable name, /data/events[at0002]/data[at0003]/items[at0004]/value is the archetype path to respiratory quantity node. If you have the archetype workbench running, you can identify this path there. '$ehrId' is the parameter name which can be substituted with real EHR ehr_id value at run time. The query language supports parameterization. Some archetype query statements would be very long if the query criteria are complicated. In fact, we don't need to write the above queries by hand. Ocean Informatics has implemented a tool - Archetype Query Builder, which can be used to create/edit queries easily. Additionally, Ocean has also implemented a query parser and query engine as well. The above query statements are consistent to the query syntax
OpenEHR queries
Thanks. Of course, as you say, the Sql parser will vary depending on the structure of the underlying store, and underlying store designs can vary, one of the strengths of openEHR. It would still seem, however, that whole chunks of the AQL would have to end up in the Sql, and that, in turn, would have implications--at least *some* implications--how the underlying store would *have* to be designed. Only certain schemas would even work with openEHR. Does the openEHR community offer any suggestions? At Ocean you evidently felt that a certain design was best, not just any design, which you imply when you refer to the need to be conformant. What does it take for a DB schema to be conformant? The persistence model that Ocean uses is a trade off between completely atomising objects and storing them as blobs. Have you disclosed any of the details regarding this tradeoff? Randolph On 11/5/07, Hugh Leslie hugh.leslie at oceaninformatics.com wrote: Hi Randolph, Currently, the only AQL query parser that I know of is one that is part of the Ocean Informatics suite of products and runs against the Ocean EhrBank openEHR repository. Converting AQL to SQL will depend entirely on what your underlying persistence model is and also to some extent what relational database flavour you are using. openEHR doesn't mandate any particular persistence model and as has been already stated, the really nice thing about AQL is that queries are independent of any underlying relational (or object) data model. So an AQL query that is run against two separate and completely independently developed openEHR repositories that probably use a completely separate persistence model should return exactly the same data (as long as they are both conformant). The persistence model 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 wrote: I think I understand. Thanks. What actually gets persisted, I suspect, are the paths--and values pointed to by those paths--implicit in your archetype object graph, correct? And to convert AQL query into an SQL query you somehow extract that path from AQL and convert it into some sort of SQL, right? Is there anything on your web site about this, about deriving a DB query from an archtype query? You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. --That's the question. How do you get expected results back based on the AQL Statement? 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 technical discussions *Subject:* Re: OpenEHR queries 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 months ago, someone from openEHR said in one of the discussions that a DB schema is not part of openEHR, that some private participant in openEHR had one for sale, and Ocean, maybe, but that was it. So, again against what do these queries (see example in Chunlan Ma's message below) run? That's good question. You've noticed that I didn't mention anything about the data store here. In general, query languages are designed specifically for a type of data store. For instance, SQL is run against relational databases. XQuery is run against XML structured data. Object Oriented Query Language need to be run against Object oriented database management systems etc. These types of query language are data query languages, i.e. they query at the data level. You have to know DB schema when you write a SQL query statement. Archetype Query Language is different from the general query languages. It's a semantic query language, i.e. it queries data at semantic level. It's neutral to persistence layer and system design. We only need to use archetype path and openEHR reference model to construct AQL statement. You can have whatever persistence layer as long as it can get expected results back based on the AQL statement. That's why AQL queries can be shared across systems and enterprise boundaries. Sharing AQL is one of the key solution to achieve semantic interoperability. Cheers, Chunlan Thanks, Randy Neall Veriqant, L.L.C. On 11/4/07, *Chunlan Ma* chunlan.ma at oceaninformatics.com wrote: Hi Greg
OpenEHR queries
Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org
OpenEHR queries
Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA.pdf Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ 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/20071104/16dd2911/attachment.html
OpenEHR queries
Thanks Rong, Just the thought for someone but it would be handy to have the XPath (such as o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/value) for a data value somewhere accessible in the editor or in the html generated content such as http://svn.openehr.org/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.body_weight.v1.html Just easier for adhoc testing so not a big deal. On 11/4/07, Rong Chen rong.acode at gmail.com wrote: Hi Greg, There was a paper published at Medinfo2007 on this topic. The paper is available at: http://www.openehr.org/downloads/publications/archetypes/MedInfo_2007_EQL_MA.pdf Cheers, Rong On 11/4/07, Greg Caulton caultonpos at gmail.com wrote: Hi, Somewhere I recall reading that there was an OpenEHR query that theoretically an OpenEHR compliant system could execute a return results for. Is there a spec somewhere, preferably with a simple example. So if someone knew my patient and queried for all instances of Respiratory Rate greater than n? openEHR-EHR-OBSERVATION.respiration.v1.adl Rate at0004 n Units /min (is that a default or are the units passed in the query) Or is this future functionality? thanks Greg http://www.patientos.org ___ 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
