I'm glad you've considered doing that. In my humble opinion, AQL is the most neglected, yet, probably one of the most important components of an openEHR implementation. It is not part of the implementation, but it has been implemented by at least two vendors that I know of, with a third having something quite similar to it. Personally, I'm happy that it is being cooked in real life before becoming a part of the implementation. If you're interested in implementing openEHR, I suggest that you keep AQL as a high level priority, rather than saying: "let me use sql/whatever_other_query_language_that_my_persistence_layer_uses for now and I'll implement AQL later"
On Thu, Apr 18, 2013 at 2:00 AM, Randolph Neall <randy.neall at veriquant.com>wrote: > Seref, I was simply trying to take your hint. :). > > > On Wed, Apr 17, 2013 at 5:08 PM, Seref Arikan < > serefarikan at kurumsalteknoloji.com> wrote: > >> AQL is not part of the official specification yet. >> >> Regards >> Seref >> >> >> >> On Wed, Apr 17, 2013 at 10:04 PM, Randolph Neall < >> randy.neall at veriquant.com> wrote: >> >>> Thomas, somehow I'm not finding the AQL specification. It's probably >>> right under my nose on your specification/release page. Also, do you have >>> any references describing the AQL processor? Did you write *that* from >>> scratch?? It would seem that the AQL processor would indeed function as >>> a formidable DBMS in its own right, at least with regard to reads, capable >>> of managing AND/OR logic trees and serving up flat "tables" of joined data >>> structures like any RDBMS. >>> >>> Randy >>> >>> >>> On Wed, Apr 17, 2013 at 4:17 PM, Thomas Beale < >>> thomas.beale at oceaninformatics.com> wrote: >>> >>>> On 17/04/2013 18:47, Randolph Neall wrote: >>>> >>>> >The performance is perfectly adequate in all of these systems for the >>>> kinds of queries used in point of care (e.g. typically sub 1-second), and >>>> in some cases where ETL is implemented, the performance is also acceptable. >>>> It's also true that quite a lot of effort and thinking has gone into >>>> optimising AQL queries. There is always a query that can be written that >>>> will take a long time to answer, but so far there is no overlap between >>>> those type of queries and point of care latency requirements i.e. such >>>> queries are always report-oriented, research queries or some other kind of >>>> population query, where a (let's say) 5 second response is perfectly >>>> acceptable. >>>> >>>> That's excellent! Can you give any idea how long it takes to retrieve >>>> into live memory and screen on a user's computer an entire EHR record of >>>> "typical" size and complexity? Or does that not generally happen, with >>>> records instead being fetched in smaller pieces? >>>> >>>> >>>> Right - you wouldn't ever pull an entire EHR to the screen. I have seen >>>> openEHR applications pulling the main managed lists (say 6-8 Compositions), >>>> latest lab results, plus a chronological list of consultations / events for >>>> the last year or so, plus key demographic data, all sub 0.5 sec. Then the >>>> user starts clicking on things, and more comes back. >>>> >>>> More interesting screens contain a mixture of text and e.g. vital signs >>>> real-time graphs, which AQL copes with nicely - you can bring back just a >>>> 2-D array of numbers and timestamps for the graph, using AQL. >>>> >>>> - thomas >>>> >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> openEHR-technical at lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130418/2a308576/attachment.html>
