I should probably point out that there are some dozens of openEHR operational deployments <http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities>, all heavily using AQL for screen population, reporting and so on. 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.
There is probably about 3 years of experience of such systems now (there's more like 6 years experience of commercially deployed AQL) that show that the performance challenges of this kind of framework are satisfiable, and no longer a research question (they were once obviously!). The second order types of structures I mentioned below rely less on AQL, and more on smart commit type rules / triggers logic, which effectively enables pre-built query results to be maintained in a live system. We're somewhere on a road where we are already riding in motorised transport, but we don't really know if what we have today is a Fiat Punto or a Maserati. Hopefully it's the Fiat, because that leaves us a lot of fun and room to get to the Maserati (at which point we start looking at air travel;-). - thomas On 17/04/2013 15:58, Randolph Neall wrote: > Hi Seref, > > >Hint: think about how you're going to get data out before thinking > how you're supposed to keep it. There are lots of possibilities, but > you need to anchor those with a single method of access. I suggest a > brief look at Archetype Query Language (AQL) > > That's the whole point, Seref--"how you're going to get the data out." > And certainly AQL is one way to do that. My concern has to do with > querying performance (deserialization as a prerequisite to record > inspection, etc.) and the infrastructure resources necessary to > support them. Thomas hints at possibly some big changes when he said, > "There is an emerging set of 'second order' object definitions, that > use the URI-based referencing approach in very sophisticate ways to > represent things like care plans, medication histories and so on. I > can't point to a spec right now, but they will start to appear." I > don't know how radical that will prove to be. I'd assume they'd still > occur within the AQL paradigm. But it does appear that openEHR itself > is evolving on this point and perhaps for good reason. > > Please don't interpret my remarks as any sort of disrespect for > openEHR; I hope it has been apparent that my respect for the entire > system has grown as I have learned more about it. Some really > brilliant people, perhaps including you, put this whole thing > together. And you all do the whole world a favor by make it all open > and by making yourselves available for the sort of questions I have > raised. > > Randy > ** -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130417/96e4bd84/attachment.html>
